Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Interoperability”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 397 records · Page 22
All sourcesNASA NTRSDOE OSTI
DOE OSTI2015

Campus Challenge, Part 1: Benefits and Challenges of BACnet

Here, the BACnet protocol was designed to achieve interoperability among building automation vendors and evolve over time to include new functionality as well as support new communication technologies such as the Ethernet and IP protocols as they became prevalent and economical in the market place. For large multi-building, multi-vendor campus environments, standardizing on the BACnet protocol as an implementation strategy can be a key component in meeting the challenge of an interoperable, flexible, and scalable building automation system. The interoperability of BACnet is especially important when large campuses with legacy equipment have DDC upgrades to facilities performed over different time frames and use different contractors that install equipment from different vendors under the guidance of different campus HVAC project managers. In these circumstances, BACnet can serve as a common foundation for interoperability when potential variability exists in approaches to the design-build process by numerous parties over time. Likewise, BACnet support for a range of networking protocols and technologies can be a key strategy for achieving flexible and scalable automation systems as campuses and enterprises expand networking infrastructures using standard interoperable protocols like IP and Ethernet.

42 ENGINEERING↗
DOE OSTI2014

Enabling communication concurrency through flexible MPI endpoints

MPI defines a one-to-one relationship between MPI processes and ranks. This model captures many use cases effectively; however, it also limits communication concurrency and interoperability between MPI and programming models that utilize threads. This paper describes the MPI endpoints extension, which relaxes the longstanding one-to-one relationship between MPI processes and ranks. Using endpoints, an MPI implementation can map separate communication contexts to threads, allowing them to drive communication independently. Endpoints also enable threads to be addressable in MPI operations, enhancing interoperability between MPI and other programming models. These characteristics are illustrated through several examples and an empirical study that contrasts current multithreaded communication performance with the need for high degrees of communication concurrency to achieve peak communication performance.

Communication↗
DOE OSTI2018

Argobots: A Lightweight Low-Level Threading and Tasking Framework

In the past few decades, a number of user-level threading and tasking models have been proposed in the literature to address the shortcomings of OS-level threads, primarily with respect to cost and flexibility. Current state-of-the-art user-level threading and tasking models, however, are either too specific to applications or architectures or are not as powerful or flexible. In this paper, we present Argobots, a lightweight, low-level threading and tasking framework that is designed as a portable and performant substrate for high-level programming models or runtime systems. Argobots offers a carefully designed execution model that balances generality of functionality with providing a rich set of controls to allow specialization by the user or high-level programming model. We describe the design, implementation, and optimization of Argobots and present integrations with three example high-level models: OpenMP, MPI, and co-located I/O service. Evaluations show that (1) Argobots outperforms existing generic threading runtimes; (2) our OpenMP runtime offers more efficient interoperability capabilities than production OpenMP runtimes do; (3) when MPI interoperates with Argobots instead of Pthreads, it enjoys reduced synchronization costs and better latency hiding capabilities; and (4) I/O service with Argobots reduces interference with co-located applications, achieving performance competitive with that of the Pthreads version.

Seo, Sangmin (ORCID:0000000295159836)↗
NASA NTRS2025

Evolving the SpaceFOM: Lessons Learned and Future Development

For over fifty years, simulation has been a cornerstone technology for space missions. In many cases, one single simulator, developed by one team, is not enough to meet the simulation objectives. Astronaut crew training, docking, vehicle testing and complex mission planning all require several simulations to be connected and to interoperate, in order to achieve the goal of the simulation. To facilitate the development of interoperable simulations, an open standard, the SISO SpaceFOM was developed in collaboration between government, industry and academia. The standard was released in 2020. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. A number of requirements for the next version of SpaceFOM have been identified and proposed solutions are already under development. One key area is the object classes used for data exchange, where a richer set of classes have been proposed, based on practical use cases. For time management, the use of variable time resolutions and variable time steps is also proposed. For execution control, save and restore of simulations is considered as well as improved robustness, to handle failing components. A number of clarifications are also under consideration. This paper provides both a forward-looking view of the technical developments underway and a retrospective on the standard's evolution. The authors emphasize that prioritizing core challenges and delivering a practical first version were crucial steps. While not every idea was implemented in the initial release, the timely delivery of a functional standard enabled real-world applications, the growth of a user community, and the collection of valuable insights to shape future versions. The authors look forward to working with the next version of SpaceFOM together with the growing user community.

Simulation Interoperability↗
DOE OSTI2026

Wildfire-Power Grid Interactions: Feedback, Impacts, Monitoring, Modeling, and Mitigation Strategies

Wildfires are increasingly interacting with electric power systems through a two-way hazard chain: fires damage grid assets and trigger cascading outages, while grid faults can ignite new fires under hot, dry, and windy conditions. This review synthesizes the state of knowledge across five domains: (i) physical impacts of flames, heat, and smoke on lines, towers, insulators, and substations; (ii) power-infrastructure-initiated ignitions via conductor clash, high-impedance faults, and corona discharge; (iii) widespread blackouts and disproportionate societal impacts; (iv) multi-scale monitoring spanning laboratory tests, in-situ and grid-integrated sensors, and Earth observation; (v) coupled modeling that links fire behavior with grid operations; and (vi) technological and strategic mitigation pathways spanning prevention, response, and recovery. We integrate these domains into a novel 'feedback-aware' socio-technical framework. Through a longitudinal analysis (2005-2025) of global incidents, we identify that while vegetation contact remains the most frequent ignition source, aging infrastructure failure has emerged as a critical driver of catastrophic 'mega-fires'. We further identify persistent gaps, including limited interoperability of high-frequency grid and environmental data, scarce real-time data assimilation, and under-developed equity metrics for outage management. We conclude by outlining a research agenda to (1) deploy interoperable sensing architectures, (2) advance feedback-coupled fire-grid simulations, and (3) evaluate mitigation portfolios through techno-economic and fairness lenses. Recognizing wildfire-grid interactions as coupled socio-technical systems is essential for protecting infrastructure and communities and for ensuring reliable, sustainable electricity in a changing world.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2024

ISO_Fortran_binding_m v0.1.0

The Fortran programming language standard defines a broad feature set supporting the interoperability of Fortran programs with program written according to the C programming language standard. Among Fortran's C-interoperability features is a a C header file "ISO_Fortran_binding.h" This header file defines the interface to various C data structures and functions that C programs may use to access Fortran data entities. The ISO_Fortran_binding_m software defines a native Fortran module that presents an interface to these same data structures and functions. ISO_Fortran_bind_m thus enables Fortran programs to access and manipulate Fortran entities in ways that precisely mirror what C programs can do using ISO_Fortran_binding.h. ISO_Fortran_binding_m facilitates writing portable standard-conforming Fortran programs that emulate non-interoperable features, e.g., dynamic polymorphism, in a standard-conforming interoperable way similar but broader than what is demonstrated in Berkeley Lab's Caffeine software [1]. ISO_Fortran_binding_m also enables a Fortran programmer to extend Fortran's capabilities to emulate certain C functionality such as memory address arithmetic or computing C's "sizeof" function. [1] https://github.com/BerkeleyLab/caffeine/blob/213e3df1c319f0663306354414f352acda42a24f/src/caffeine/collective_subroutines/co_reduce_s.f90#L88 [2] https://github.com/BerkeleyLab/ISO_Fortran_binding_m/blob/0c585362bb4f2c72cf9049c800a7115b529ec533/src/iso_fortran_binding_m.F90#L196

Rouson, Damian↗
DOE OSTI2020

Recommendations for Data-in-Transit Requirements for Securing DER Communications

With the adoption of Distributed Energy Resource (DER) interoperability standards, common communication protocols are now being deployed between power system operators and DER devices. In 2018, a revision to the US interconnection and interoperability standard, Institute of Electrical and Electronics Engineers (IEEE) Std. 1547, required DER equipment to have an IEEE 2030.5, IEEE 1815, or SunSpec Modbus communication exchange interface. This change supports the future transition to secure connection and exchange of information between the DER equipment and implementing parties, such as grid operators. Adoption of standardized communication protocols and associated information models is a critical step toward interoperability between power system operators and DER, such as photovoltaic (PV) and energy storage systems. However, security requirements for these standardized communication protocols are not comprehensive, resulting in non-standard and vendor-specific implementation that may leave DER equipment susceptible to cyberattacks. This paper examines the data-in-flight security requirements for standardized DER communication protocols, per IEEE 1547-2018 revision, as it relates to device authentication, key management, and encryption. The state of the art for these security features is also explored, addressing their impact on communication and performance of low-cost single board computers, which are typical of DER devices. In conclusion, a recommendation is provided to adopt a common set of communication requirements, which are intended to achieve interoperability and implement data security over DER network pathways, while ensuring reliable, secure, and real-time information delivery.

42 ENGINEERING↗
DOE OSTI2021

Metadata Schemas and Ontologies for Building Energy Applications: A Critical Review and Use Case Analysis

With the increasing digitalization of processes throughout the lifecycle of buildings, data exchanged between stakeholders and between building systems has grown significantly. However, a lack of semantic interoperability between data in different systems is still prevalent, hindering the development of applications that can be reused across buildings and limiting the scalability of innovative solutions. Semantics refers to the description of the meaning of the data in a way that can be consistently understood by applications. Recently, several competing initiatives have been developing metadata schemas and ontologies to express this semantic information for different applications in the building domain. This paper systematically reviews these schemas and conducts an analysis of five of them to evaluate their applicability to three high-value use cases for building operations: energy audits, automated fault detection and diagnostics and optimal control. The survey finds 40 schemas published in the last 10 years but but their actual use in industry is difficult to estimate. Among the five selected ontologies, several gaps are highlighted in relation to the three use cases. Recommendations for the future include better harmonization of these initiatives, more centralized repositories and search engines for these schemas as well as better industry engagement to facilitate their adoption.

Smart Building, Sematic, Metadata, Ontology, Data ↗
NASA NTRS2012

A Human View Model for Socio-Technical Interactions

The Human View was developed as an additional architectural viewpoint to focus on the human part of a system. The Human View can be used to collect and organize data in order to understand how human operators interact and impact the other elements of a system. This framework can also be used to develop a model to describe how humans interact with each other in network enabled systems. These socio-technical interactions form the foundation of the emerging area of Human Interoperability. Human Interoperability strives to understand the relationships required between human operators that impact collaboration across networked environments, including the effect of belonging to different organizations. By applying organizational relationship concepts from network theory to the Human View elements, and aligning these relationships with a model developed to identify layers of coalition interoperability, the conditions for different levels for Human Interoperability for network enabled systems can be identified. These requirements can then be captured in the Human View products to improve the overall network enabled system.

Handley, Holly A.↗
NASA NTRS2016

UAS Integration into the NAS: Detect and Avoid Display Evaluations in Support of SC-228 MOPS Development

At the May 2015 SC-228 meeting, requirements for TCAS II interoperability became elevated in priority. A TCAS interoperability work group was formed to identify and address key issuesquestions. The TCAS work group came up with an initial list of questions and a plan to address those questions. As part of that plan, NASA proposed to run a mini HITL to address display, alerting and guidance issues. A TCAS Interoperability Workshop was held to determine potential displayalertingguidance issues that could be explored in future NASA mini HITLS. Consensus on main functionality of DAA guidance when TCAS II RA occurs. Prioritized list of independent variables for experimental design. Set of use cases to stress TCAS Interoperability.

detect and avoid↗
NASA NTRSDate not supplied

International Coordination and Cooperation on LunaNet Spectrum

LunaNet is planned to be the network of networks operated by a set of cooperating organizations to provide interoperable Communications, networking, Position, Navigation, and Timing (CPNT) services to users on and around the Moon based on a framework of mutually agreed-upon standards, protocols, frequency bands and interface requirements. LunaNet follows a service-oriented architecture that is agnostic about the types of organizations that provide services, e.g., government, industry, or academia. LunaNet is open, scalable, resilient, secure, and extensible. To achieve these goals, LunaNet Service Providers (LNSP) must coordinate with each other to define and develop the architecture, to plan initial and evolved capabilities, and to operate their networks. One of the central LunaNet tenets is the use of shared spectrum. For example, the Lunar Augmented Navigation Service (LANS) acts like a Global Navigation Satellite System (GNSS) such as the US Global Positioning System (GPS) or European Galileo but the LNSPs’ contributions to LunaNet must use the same frequency band (2483.5 MHz-2500.0 MHz) and transmit the same waveform synchronized by highly accurate clocks so that Users ‘see’ one virtual network and use the same multilateration algorithm to determine their positions. This necessitates a high degree of spectrum coordination. NASA’s Lunar and Human Spaceflight Spectrum Management Team has been actively supporting development of the LunaNet Interoperability Specification (LNIS), soliciting inputs from spectrum policy and planning experts across NASA, ESA and JAXA. Cislunar spectrum use considerations have been studied and adjudicated within the Space Frequency Coordination Group (SFCG) and inform the ongoing discussion of a lunar communication and navigation architecture within the existing radio regulatory framework of the International Telecommunication Union, leading to the 2027 World Radiocommunication Conference (WRC-27). The frequency plan contained in the publicly released draft of the LunaNet Interoperability Specification reflects the initial phase of exploration (roughly to 2030) defining an optimal set of radio frequencies in appropriately allocated services consistent with WRC-23 decisions for use by known or planned CPNT applications, while striving to maximize coexistence and compatibility amongst cislunar systems and other systems within the near-Earth regime (< 2 million km from Earth). Important considerations include: protection of extremely sensitive receive-only radio astronomy systems on the lunar far side, known as the Shielded Zone of the Moon (SZM); compatibility between Direct with Earth (DWE) communications links and links needed to support relay satellites in lunar orbit with their customer systems on orbit or on the lunar surface; compatibility between multiple lunar surface communications systems and capabilities over varied and challenging terrain and distances; as well as ensuring compatibility and interoperability between navigation systems which either leverage Earth-based or in-situ lunar systems. In addition, the lunar CPNT architecture is envisioned to be the basis – with adjustments – of the future Mars CPNT architecture as we expand into the solar system using Interplanetary Networking (IPN). The second phase of lunar spectrum definition will address planned international capabilities for the next decade that will require action at WRC-27 and beyond. This paper will discuss each of these considerations in more depth and how the current LunaNet frequency plan addresses them.

LunaNet↗
DOE OSTI2024

Guide to Developing Energy Services Interfaces

This document provides guidance to develop communications interfaces that are highly interoperable and adhere to a set of energy services interface (ESI) principles. It can be applied in the context of information and communications technology interface standards and implementation profiles that enable the integration of a facility with responsive distributed energy resources (DER) into an electric power system consistent with the fundamental ESI principles. In this context, a DER facility may consist of a single DER with a communicating controller or may be as complex as a microgrid campus with several buildings and many DERs. This document is not a technical interface standard, but the requirements described can be used to check that existing, augmented, or new interface standards meet the interoperability requirements of the ESI concept. In this way, this guide for the ESI specification can support future advancements in developing interoperability standards and implementation profiles. The intended audience for this document is DER integration practitioners and ecosystem groups that are in the business of developing and implementing communications interfaces for DER integration. It is intended that these groups apply the information and processes in this document to develop communications standards and implementation profiles that are consistent with fundamental ESI principles.

2030.5↗
DOE OSTI2026

Use of Hardware-in-the-Loop to De-Risk Field Deployment of Hydrogen Assets

Grid-forming assets are required in microgrids to act as voltage-frequency masters. These grid-forming assets can operate in two modes of operation: grid-following mode and grid-forming mode. In grid-following mode of operation, these assets will follow real power and reactive power setpoints and in grid-forming mode of operation these assets will follow voltage and frequency setpoints. Traditionally, diesel generators or natural gas-based generators are widely used to act as a voltage-frequency master. However, many utilities are aiming to replace generators with grid forming-inverters supplied by solar photovoltaics (PV), batteries or fuel cells. Since grid-forming assets need a long-term reliable energy source, fuel cells are a reasonable and viable choice to supply the grid-forming inverters, but some of the challenges facing the wide deployment of grid-forming fuel cell inverters need to be addressed. Specifically, in our proposed work, we aim to focus on the interconnection and interoperability requirements of grid-forming fuel cell inverters. Currently, state-of-the-art fuel cell inverters follow the general interconnection requirements of distributed energy resources (DERs) and general interoperability requirements of DERs, but these requirements were built with PV and battery systems in mind. Fuel cells have different operational requirements, and therefore these requirements need to be appropriately modified for the grid operators to use. These additional steps add to the investment and operational cost to the grid operators. Through the ARIES platform, this proposed project aims to bridge this gap and use power hardware-in-the-loop (PHIL) and controller hardware-in-the-loop (CHIL) experiments to inform the creation of open-source interconnection and interoperability information that can aid in faster and cheaper installation and operation of grid-forming fuel cell inverters.

08 HYDROGEN↗
DOE OSTI2026

Aligning NASA Earth Science Data Stewardship with FAIR Principles: Outcomes, Recommendations, and Future Directions

The FAIR Principles—Findable, Accessible, Interoperable, and Reusable—offer a widely accepted framework for improving the sharing and reuse of digital scientific data by both human and machine users. Following these principles is critical for effective scientific data stewardship, broader scientific collaboration, and compliance with federal and agency data policies. This paper, based on the work of NASA’s Open, Free, and FAIR Working Group (O’FAIR WG) under the Earth Science Data Systems Program, presents an overview of how FAIR is being applied within NASA’s Earth science data landscape. It highlights ongoing progress and challenges, identifies FAIR-enabling resources, and offers recommendations and strategic actions to enhance the FAIRness of NASA-funded open and free Earth science data products. The FAIR-enabling resources identified underscore the vital role of NASA's existing enterprise processes, standards, tools, and infrastructures in supporting FAIR implementation. Our findings show strong performance in making NASA Earth science data more findable and accessible. However, further work is needed—especially in enhancing interoperability, so that different systems and tools can better understand and exchange data. This is especially important for enabling machine-driven discovery and analysis. We emphasize the importance of a balanced strategy that combines a centralized, top-down approach—focused on building enterprise-level capabilities and processes—with a decentralized, bottom-up approach driven by discipline-specific needs and community practices. We advocate for coordinated efforts to enhance (meta)data interoperability to facilitate seamless data and information sharing and exchange of Earth science data both within NASA and across other agencies managing Earth science data.

Data Product↗
NASA NTRSDate not supplied

Evolving the SpaceFOM: Lessons Learned and Future Development

For over fifty years, simulation has been a cornerstone technology for space missions. In many cases, one single simulator, developed by one team, is not enough to meet the simulation objectives. Astronaut crew training, docking, vehicle testing and complex mission planning all require several simulations to be connected and to interoperate, in order to achieve the goal of the simulation. To facilitate the development of interoperable simulations, an open standard, the SISO SpaceFOM was developed in collaboration between government, industry and academia. The standard was released in 2020. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. A number of requirements for the next version of SpaceFOM have been identified and proposed solutions are already under development. One key area is the object classes used for data exchange, where a richer set of classes have been proposed, based on practical use cases. For time management, the use of variable time resolutions and variable time steps is also proposed. For execution control, save and restore of simulations is considered as well as improved robustness, to handle failing components. A number of clarifications are also under consideration. This paper provides both a forward-looking view of the technical developments underway and a retrospective on the standard's evolution. The authors emphasize that prioritizing core challenges and delivering a practical first version were crucial steps. While not every idea was implemented in the initial release, the timely delivery of a functional standard enabled real-world applications, the growth of a user community, and the collection of valuable insights to shape future versions. The authors look forward to working with the next version of SpaceFOM together with the growing user community.

FOMs↗
DOE OSTI2024

Improving and Automating Building Model Data Exchange

There are many instances throughout a project’s lifecycle where there arises a need for quick and accurate risk assessment of building designs. For example, an unexpected design change during construction may necessitate structural engineers to perform a seismic risk assessment on analytical models of the updated building design using high fidelity structural analysis software, such as ANSYS or Abaqus. However, the efficiency of such workflows often depends upon the interoperability of architectural design software and structural analysis software. When the quality of this interoperability is lacking or even non-existent, the efficiency of virtual engineering workflows is hampered, which increases project costs. A McGraw Hill industry survey of professional users of Building Information Modeling (BIM) technologies found that there is high demand for BIM interoperability for structural analysis, but that the value/difficulty ratio is currently too low for practical use. There have been efforts by the academic community to facilitate model data exchange between the architectural design and structural analysis domains, but such solutions have not been widely adopted by industry, face technical challenges, and oftentimes are limited in applicability for users of various BIM software. Therefore, INL is developing capabilities to improve, automate, and generalize model data exchange between architectural BIM software (e.g., Revit) and structural analysis software (e.g., SAP2000, ANSYS). The goal is to help expedite and automate as much of the pre-processing step for creating analytical models in finite element analysis software as reasonably as possible. Such a "BIM-to-FEA" conversion tool should provide direct benefit to end-users through accuracy, automation, quick turn-around, and wide applicability. To generalize the application of this BIM-to-FEA conversion tool and increase its useability among the many different commercial BIM software currently used by industry, the program is being developed with the concept of openBIM. OpenBIM is the application of non-proprietary, open data standards that allow for BIM model data exchange in a format that is accessible, retainable, and useable for all users. The most widely used open, non-proprietary data exchange format for BIM is the Industry Foundation Classes (IFC) schema. IFC is developed by buildingSMART international and is ISO certified (ISO 16739-1:2018). The BIM-to-FEA conversion tool is being developed for compatibility with typical commercial building designs of steel framed structures. The tool is currently capable of importing architectural BIM data of framed building structures, recognizing and extracting the aspects of the model that are required for structural analysis, adjusting the connectivity of frame members, and finally exporting to an analytical model stored in the IFC format. The exported IFC analytical model can then be imported into various openBIM compliant software, such as SAP2000. Such capabilities have already been tested on commercial software, as shown above, and continue to be improved. Work is underway to test the conversion on various commercial BIM software, develop a user-friendly interface, incorporate the program into the broader DeepLynx data warehouse project being developed by INL, and to eventually open-source the tool for the benefit of the community. Future development of the tool envisions the ability for efficient iterative risk assessment of generative building designs, all within a workflow utilizing open-source tools. One such open-source tool will be MOOSE, an advanced finite element analysis tool developed at INL. The conversion tool will also branch out from typical commercial building designs and will aim to incorporate nuclear construction. The aim will be to convert both structural and non-structural components of nuclear facilities, such as curved concrete containment structures and piping systems, respectively.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

An overview of data tools for representing and managing building information and performance data

Building information modeling (BIM) has been widely adopted for representing and exchanging building data across disciplines during building design and construction. However, BIM's use in the building operation phase is limited. With the increasing deployment of low-cost sensors and meters, as well as affordable digital storage and computing technologies, growing volumes of data have been collected from buildings, their energy services systems, and occupants. Such data are crucial to help decision makers understand what, how, and when energy is consumed in buildings—a critical step to improving building performance for energy efficiency, demand flexibility, and resilience. However, practical analyses and use of the collected data are very limited due to various reasons, including poor data quality, ad-hoc representation of data, and lack of data science skills. To unlock value from building data, there is a strong need for a toolchain to curate and represent building information and performance data in common standardized terminologies and schemas, to enable interoperability between tools and applications. This study selected and reviewed 24 data tools based on common use cases of data across the building life cycle, from design to construction, commissioning, operation, and retrofits. The selected data tools are grouped into three categories: (1) data dictionary or terminology, (2) data ontology and schemas, and (3) data platforms. The data are grouped into ten typologies covering most types of data collected in buildings. This study resulted in five main findings: (1) most data representation tools can represent their intended data typologies well, such as Green Button for smart meter data and Brick schema for metadata of sensors in buildings and HVAC systems, but none of the tools cover all ten types of data; (2) there is a need for data schemas to represent the basis of design data and metadata of occupant data; (3) standard terminologies such as those defined in BEDES are only adopted in a few data tools; (4) integrating data across various stages in the building life cycle remains a challenge; and (5) most data tools were developed and maintained by different parties for different purposes, their flexibility and interoperability can be improved to support broader use cases. Finally, recommendations for future research on building data tools are provided for the data and buildings community based on the FAIR principles to make data Findable, Accessible, Interoperable, and Reusable.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2024

Experimental Characterization Test of a Grid-Forming Inverter for Microgrid Applications

Standardized experimental testing protocols for grid forming (GFM) inverters to ensure expected operation under both normal and contingency conditions do not exist. Such protocols increase the confidence of system owner/operators that an inverter deployed in a proposed system will engage in typical behaviors to ensure interoperability with other units and ancillary equipment (e.g. protection equipment). This paper presents systematic and comprehensive test protocols to evaluate the performance of GFM inverters under the following operational configurations: islanded operation, heterogeneous islanded operation (parallel with a synchronous generator), grid-connected operation, and transition operation. A commercial GFM inverter is used to verify the test protocols and to understand the inverter's performance and functionalities. In particular, required configuration and tuning of the inverter will be explained in the full paper to enrich the testing protocol.

black start↗