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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
DOE OSTI2023

Development of an Energy Services Interface for the EGoT

The Energy Services Interface (ESI) is a set of rules that ensure private, secure, and trustworthy information exchange between Grid Service Providers (GSPs) and utility customers. Large-scale adoption of Distributed Energy Resources (DERs) will be necessary for GSPs to dispatch effective grid services, and to stimulate technological innovations in DER and DERMS (DER Management Systems) technologies, as well as novel grid service programs. The ESI promotes these objectives by advancing a set of rules and interoperability requirements that define bi-directional, service-oriented, logical interfaces between GSPs and customers’ DERs, with expectations for privacy, security, and trust. The ESI rules and interoperability requirements establish boundaries between customers and GSPs that delineate the functions and responsibilities that must be implemented by the developers of Energy Grid of Things (EGoT) ecosystem products. These rules impose constraints on the implementation of a DERMS. The ESI interoperability requirements are based on the Interoperability Maturity Model (IMM), developed by the Grid Modernization Laboratory Consortium. By emphasizing private, secure, and trustworthy information exchange, and by mandating a service-oriented and interoperable architecture, the ESI promotes the development of an EGoT ecosystem that motivates customer participation and technological innovation. Interoperability will encourage innovation by reducing barriers to entry and increasing confidence of stakeholders. Customers will be willing to participate in DER service programs that establish trust and emphasize customer choice. Large-scale customer participation ensures GSPs have ample DER resources to provide grid services that have significant impact on grid reliability and reduce electricity cost for consumers. This in turn signals economic opportunities that encourage innovation, resulting in the development of a robust EGoT ecosystem.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2015

Smart Grid Demonstration Project (Final Report)

The National Rural Electric Cooperative Association (NRECA) organized the NRECA-U.S. Department of Energy (DOE) Smart Grid Demonstration Project (DE-OE0000222) to install and study a broad range of advanced smart grid technologies in a demonstration that spanned 23 electric cooperatives in 12 states. More than 205,444 pieces of electronic equipment and more than 100,000 minor items (bracket, labels, mounting hardware, fiber optic cable, etc.) were installed to upgrade and enhance the efficiency, reliability, and resiliency of the power networks at the participating co-ops. The objective of this project was to build a path for other electric utilities, and particularly electrical cooperatives, to adopt emerging smart grid technology when it can improve utility operations, thus advancing the co-ops’ familiarity and comfort with such technology. Specifically, the project executed multiple subprojects employing a range of emerging smart grid technologies to test their cost-effectiveness and, where the technology demonstrated value, provided case studies that will enable other electric utilities—particularly electric cooperatives— to use these technologies. NRECA structured the project according to the following three areas: Demonstration of smart grid technology; Advancement of standards to enable the interoperability of components; and Improvement of grid cyber security. We termed these three areas Technology Deployment Study, Interoperability, and Cyber Security. Although the deployment of technology and studying the demonstration projects at coops accounted for the largest portion of the project budget by far, we see our accomplishments in each of the areas as critical to advancing the smart grid. All project deliverables have been published. Technology Deployment Study: The deliverable was a set of 11 single-topic technical reports in areas related to the listed technologies. Each of these reports has already been submitted to DOE, distributed to co-ops, and posted for universal access at www.nreca.coop/smartgrid. This research is available for widespread distribution to both cooperative members and non-members. These reports are listed in Table 1.2. Interoperability: The deliverable in this area was the advancement of the MultiSpeak™ interoperability standard from version 4.0 to version 5.0, and improvement in the MultiSpeak™ documentation to include more than 100 use cases. This deliverable substantially expanded the scope and usability of MultiSpeak™, the most widely deployed utility interoperability standard, now in use by more than 900 utilities. MultiSpeak™ documentation can be accessed only at www.multispeak.org. Cyber Security: NRECA’s starting point was to develop cyber security tools that incorporated succinct guidance on best practices. The deliverables were: cyber security extensions to MultiSpeak™, which allow more security message exchanges; a Guide to Developing a Cyber Security and Risk Mitigation Plan; a Cyber Security Risk Mitigation Checklist; a Cyber Security Plan Template that co-ops can use to create their own cyber security plans; and Security Questions for Smart Grid Vendors.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2021

Retaining Systems Engineering Model Meaning Through Transformation: Demo 2

Digital engineering strategies typically assume that digital engineering models interoperate seamlessly across the multiple different engineering modeling software applications involved, such as model- based systems engineering (MBSE), mechanical computer-aided design (MCAD), electrical computer-aided design (ECAD), and other engineering modeling applications. The presumption is that the data schema in these modeling software applications are structured in the familiar flat- tabular schema like any other software application. Engineering domain-specific applications (e.g., systems, mechanical, electrical, simulation) are typically designed to solve domain-specific problems, necessarily excluding explicit representations of non-domain information to help the engineer focus on the domain problems (system definition, design, simulation). Such exclusions become problematic in inter-domain information exchange. The obvious assumptions of one domain might not be so obvious to experts in another domain. Ambiguity in domain-specific language can erode the ability to enable different domain modeling applications to interoperate, unless the underlying language is understood and used as the basis for translation from one application to another. The engineering modeling software application industry has struggled for decades to enable these applications to interoperate. Industry standards have been developed, but they have not unified the industry. Why is this? The authors assert that the industry has relied on traditional database integration methods. The basic issue prohibiting successful application integration then is that traditional database-driven integration does not consider the distinct languages of each domain. An engineering models meaning is expressed through the underlying language of that engineering domain. In essence, traditional integration methods do not retain the semantic context (meaning) of the model. The basis of this research stems from the widely held assumption that systems engineering models are (or can be) structured according to the underlying semantic ontology of the model. This assumption can be imagined from two thoughts. 1) Digital systems engineering models are often represented using graph theory (the graph of a complex systems model can contain millions of nodes and edges). When examining the nodes one at a time and following the outbound edges of each node one by one, one can end up with rudimentary statements about the model (i.e., node A relates to node B), as in a semantic graph. 2) Likewise, from the study of natural languages, a sentence can be structured into unambiguous triples of subject-predicate-object within formal and highly expressive semantic ontologies. The rudimentary statements about a systems model discerned with graph theory closely mimic the triples used in the ontologies that try to structure natural languages. In other words, a systems models semantic graph can be (or is) structured into an ontology. Additionally, it is well established in industry that through natural language processing (NLP), which provides the means to create language structures, that computers can interpret ontological graphs. Therefore, the authors hypothesized that if the integrity of the underlying semantic structure of a systems model is retained, the contextual meaning of the model is retained. By structuring system models into the triples of the underlying ontology during the transformation from one MBSE application to another, the authors have provided a proof of the concept that the meaning of a system model can be retained during transformation. The authors assert that this is the missing ingredient in effective systems model-to-model interoperability. ACKNOWLEDGEMENTS The authors would like to thank the FY19 Model Interoperability team members who provided a solid foundation for the FY20 team to leverage: John McCloud, for the work he did to guide us toward the right use of technology that will appropriately discover and manipulate ontologies. Carlos Tafoya, for the work he did to develop an application programming interface (API)/Adapter that would export ontology-based data from GENESYS. Peter Chandler, for the work he did to architect our overall integration solution, with an eye toward the future that would influence a large-scale federated production-level systems engineering digital model ecosystem.

42 ENGINEERING↗
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↗