Search NASA⌕ Search

SEARCH · Search NASA

Results for “Digital engineering”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
DOE OSTI2020

Deep Lynx: Digital Engineering Integration Hub

The construction of megaprojects has consistently demonstrated challenges for project managers in regard to meeting cost, schedule, and performance requirements. Megaproject construction challenges are common place within megaprojects with many active projects in the United States failing to meet cost and schedule efforts by significant margins. Currently, engineering teams operate in siloed tools and disparate teams where connections across design, procurement, and construction systems are translated manually or over brittle point-to-point integrations. The manual nature of data exchange increases the risk of silent errors in the reactor design, with each silent error cascading across the design. These cascading errors lead to uncontrollable risk during construction, resulting in significant delays and cost overruns. Deep Lynx allows for an integrated platform during design and operations of mega projects.

Darrington, JohnW↗
DOE OSTI2021

Vulcan Digital Engineering Application

The application is being developed with the goal of preventing the entropy of all the different single purpose applications. This application utilizes a framework that enables different file formats to be read and understood through plugins dynamically loaded to the main application containing the framework. The main application provides interoperability to all the different plugins, this allows each file format to convert to every other file format that has been read. There is no theoretical limit to the number of plugins that can be used by the application. Even though the plugins may be individually written and serve a purpose like single use scripts, the plugins can only be used with the main application, this forces the application and plugins to be linked. In theory this will force better data management, or at least the bundling of the main application with the plugins.

Lehmer, JacobP↗
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 OSTI2026

Engineering Against Digital Risk in CIP Applications: Cyber-Informed Engineering Use Cases

Cyber-Informed Engineering (CIE) addresses the reality that cyber attacks on engineered systems can have consequences far beyond data loss or disruption of digital networks. When control systems are compromised, safety, reliability, and performance of the physical process itself may be threatened. This presentation discusses engineered controls of 7 categories and the CIE database of controls that provides clear examples and guidance for defining and applying engineered controls in CIE. It explains what engineered controls are, how they differ from information security measures, and how they are integrated into system design.

99 - GENERAL AND MISCELLANEOUS↗
DOE OSTI2023

3D Modeling of Safety-Related Upgrade Pilot Project

Constellation Energy and the United States Department of Energy (DOE) have established a public/private partnership to implement a pilot digital upgrade to replace legacy analog, safety-related reactor protection and emergency safety feature actuation systems (RPS/ESFAS) with modern digital systems. This effort is occurring at Constellation’s Limerick Generating Station. This project is being performed in accordance with industry processes that have been adapted to better support digital upgrades. These processes include IP-ENG-001, Standard Design Process, NISP-EN-04, Standard Digital Engineering Process and Electric Power Research Institute Report 3002011816, Digital Engineering Guide. The Light Water Reactor Sustainability (LWRS) Program at the Idaho National Laboratory (INL) has been supporting this effort. Latest INL HFE efforts in support of this project have focused on definition and implementation of the Human Factors Engineering (HFE) Program in support of Constellation design and related licensing efforts. This paper will present the development of the HFE 3D modeling execution of the Main Control Room safety upgrades. New equipment and modifications are planned for upgrading the new safety systems. 3D modeling allows for visualization of the new equipment and modifications to be shared with engineering and design teams for evaluation and review. Anthropometric considerations such as sight lines and functional reach can be evaluated directly using the 3D model. This effort has helped to provide visualizations for additional review with operations personnel and project stakeholders.

3D Modeling↗