How do the use MBSE? military and aerospace

By Jeff Shepard

Model-based systems engineering (MBSE) is broadly defined as the structured use of digital modeling to support system features, requirements, design, verification, and validation extending from the conceptual design phase and continuing until end of life. The concept of systems engineering is deeply engrained in the military and aerospace communities. MBSE represents a shift from highly developed linear and document-centric processes to a collaborative and non-linear, digital information-based approach. The traditional system engineering approach has proven unsuited to new generations of complex, cyber-physical systems.

Before the introduction of MBSE, the DoD used a robust, highly (paper) documented linear system to design, verify, test, and acquire complex systems. This approach consisted of siloed engineering teams with limited direct interaction and little or no real-time exchange of data. It has been illustrated with a V-shaped diagram that pictures the linear steps used by traditional systems engineering approaches, Fig. 1. It moves from the top left to the bottom of the V with activities related to the decomposition of mission requirements and the various steps in the design process. Moving from the bottom and up the right side of the V involves testing, verification, validation, production, and in-the-field operation of the system until the end of its life.

The V illustrates an inherently sequential process with limited accommodation for iterative activities. With the emergence of complex and interrelated cyber-physical systems and systems of systems, these inherently linear systems engineering methodologies have become unusable.

Boeing

Fig. 2. This diamond illustrates the overlay of digital twins on the traditional V process and the collaborative and iterative nature of MBSE as supported by the digital thread. |

No more paper documents

MBSE replaces inflexible, costly, and slow paper documentation of the system engineering process with digital communication based on digital twins and digital threads. A digital twin is a real-time virtual model of a system that spans the entire system lifecycle from initial conceptualization to decommissioning. It has sufficient detail to support performance simulations, virtual verification, validation testing, system integration, monitoring, and maintenance.

The digital thread supports use of the digital twin. A digital thread contains all the information about the initial development of the digital twin and all modifications made throughout the system’s operating life. The digital thread is constantly updated and becomes the single source of ‘truth’ about the design process and the status of the digital twin and can be accessed by all design teams. It can also include operational, maintenance, and other information related to systems in the field. For example, in the case of complex systems such as aircraft and ships, there’s a unique digital thread for each platform in the field. The concepts and methodologies of MBSE do not fit easily into the systems engineering V diagram.

The Boeing diamond

To replace the linear thinking associated with the ‘V,’ the DoD encourages suppliers to adopt MBSE to arrive at a faster and more agile system development process. Stacks of paper documents are being replaced with digital twins and digital threads. For its part, Boeing has developed the “Boeing diamond” as a new way to envision the systems engineering process and depict the addition of real-time modeling, simulation, and collaboration to the traditional ‘V,’ Fig. 2.

The bottom portion includes activities related to the physical system and closely resembles the previous ‘V’ diagram. The top portion includes activities related to the digital twin of the physical system and includes detailed and real-time modeling and simulation. In between is the digital thread that is available to all design teams, including mechanical, electric, electronic, software, and so on, and provides real-time feedback throughout the design, delivery, and deployment of the system.

The DoD and MBSE

In addition to working with suppliers like Boeing, the Department of Defense (DoD) has a strong interest in MBSE for internal use. The DoD looks at the system models as an integrated representation of all aspects of the system architecture and design, including:

• Requirements — anticipated mission operations, stakeholder goals, purposes, and definition of success for the system

• Behaviors — needed transformations of system inputs to create the required responses to the external environment

• Structure — operational sections of the system that produce the behaviors

• Parameters — detail the performance requirements, physical characteristics, and operational rules that constrain and define the structure and behaviors

From the DoD perspective, an MBSE project is built on a foundation of three elements; the programming language, the tools, and approach that combine to produce the system model or digital twin, Fig. 3. In this view, the system model is the single source of truth and contains all current information about the system. It should be unified, consistent, coherent, and structured to provide the various engineering teams with relevant data in an accessible format to enable efficient completion of the system design.

The Systems Modeling Language (SysML) is the primary MBSE modeling language but not the only language. At various stages of the system lifecycle, other languages are used to provide specific functionality. For example, the Object Management Group’s (OMG) Modeling and Analysis of Real Time and Embedded systems (MARTE) language can be combined with the Unified Modeling Language. There’s also Modelica, an object-oriented, multidomain modeling language for systems containing mechanical, electrical, electronic, hydraulic, thermal, control, electric power, and/or processoriented elements.

MBSE uses various tools to describe, analyze, and manage the system over the design lifecycle. These modeling tools provide the various engineering disciplines with access to the application programs and support design analysis activities. The tools can also support collaboration and the ability to manage system changes, enabling multiple individuals and multiple teams to work on the system simultaneously.

The approach is a detailed set of design tasks, identifying what needs to be accomplished, what the team is responsible for, and when it should be completed. It can include specific design review milestones, responsibility for model maintenance, identification