The credibility of an engineering model is of critical importance in large-scale projects. How concerned should an engineer be when reusing someone else's model when they may not know the author or be familiar with the tools that were used to create it? In this report, the authors advance engineers' capabilities for assessing models through examination of the underlying semantic structure of a model--the ontology. This ontology defines the objects in a model, types of objects, and relationships between them. In this study, two advances in ontology simplification and visualization are discussed and are demonstrated on two systems engineering models. These advances are critical steps toward enabling engineering models to interoperate, as well as assessing models for credibility. For example, results of this research show an 80% reduction in file size and representation size, dramatically improving the throughput of graph algorithms applied to the analysis of these models. Finally, four future problems are outlined in ontology research toward establishing credible models--ontology discovery, ontology matching, ontology alignment, and model assessment.
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.
A one-day workshop was held on April 14, 2016 to explore Nuclear Weapons Mission Area (NWMA) strategy enablers from a systems perspective. This report documents the workshop and is intended to identify initiatives, based on the workshop exchanges, and catalyze these initiatives to enable implementation of the NWMA strategy using systems thinking and methodology. Topics explored include Model-based Engineering, Enabling Viable Capabilities, and Enterprise Decision Awareness. The morning of the workshop featured Dr. Dinesh Verma (Stevens Institute/SERC) as keynote and during the afternoon attendees participated in three facilitated sessions on the topics. There were over 70 participants from about 40 departments across Sandia National Laboratories.
The genesis for this systematic literature review was to search for industry case studies that could inform a decision of whethe r or not to support the change process, investment, training, and tools needed to implement an MBSE approach across the engineering enterprise . The question asked was, how the change from a document - based systems engineering approach (DBSE) to a model - base d systems engineering approach (MBSE) is justified? The methodology employed for this systematic literature review was to conduct a document search of electronically published case studies by authors from the defense, space, and complex systems product eng ineering industries. The 67 case studies without metrics mainly attributed success to completeness, consistency, and communication of requirements. The 21 case studies with metrics on cost and schedule primarily attributed success to the ability of an MBSE approach to improve defect prevention strategies. The primary conclusion is that there is a significant advantage to project performance by applying an MBSE approach. An MBSE approach made the engineering processes on a complex system development effort m ore efficient by improving requirements completeness, consistency, and communication. These were seen in engineering processes involved in requirements management, concept exploration, design reuse, test and qualification , Verification and Validation , and margins analyses . An MBSE approach was most effective at improving defect prevention strategies . The approach was found to enhance the capability to find defects early in the system development life cycle (SDLC), when they could be fixed with less impact a nd prevented rework in late r phases , thus mitigating risks to cost, schedule, and mission. However, if a program only employed an MBSE approach for requirements management , a dvantages from finding defects early could not be leveraged in later phases , where the savings in cost and schedule from rework prevention is realized. Significant performance success was achieved when the systems engineer (SE) held a leadership role over engineering process es. A number of the case studies addressed a general lack of sk illed MBSE engineers as a major hindrance to implementing an MBSE approach successfully .