Model-based systems engineering (MBSE) is a digital modeling approach to the conceptualization, specification, design, verification, and production of cyber-physical systems and systems of systems. In MBSE, models replace the massive paper-based documentation that was the basis of previous systems engineering (SE) approaches. The model provides a single point of truth for all the design and engineering teams involved in the process and includes discipline-specific information flows and tools.

This FAQ begins with a look at what’s expected from the model and the anticipated benefits of MBSE, considers metamodels and schemas, how the models support system design and analysis, how MBSE maintains the integrity and relevance of the model and closes by returning to a higher level view of four elements in MBSE models.

MBSE models are complex logical structures. They must be sufficiently detailed to include all important nuances and elements of the system to be designed. At the same time, they should not be overly complex since they need to enable and not encumber the SE process. The level of detail should accurately describe all the system elements and their relationships without ambiguity and enable accurate simulations, validations, and verifications of the system’s performance as it develops.

Depending on the project, the model will need to support the needs of a range of SE participants, such as business managers, numerous engineering disciplines, program managers, acquisition and production personnel, and even natural and social scientists. MBSE is intended to speed time to market and reduce costs, collectively called ‘cycle reduction.’ To achieve those objectives, the model needs to have specific characteristics, including (Figure 1):

• Support for model-based conceptual design (MBCD). It should be able to use the requirements architecture to create, compare and validate various design concepts.
• Requirements management (RWG). It should be designed to support development and management of system requirements (which can change as the SE process moves forward), and tie those performance requirements and features to validation and verification (V&V). V&V are requisite activities in quality management systems such as ISO 9000.
• It should be able to respond quickly and efficiently to changing requirements throughout the SE process.
• It should streamline the SE processes, reducing design time and cost while providing the necessary level of detail to support the required results.

Schemas and metamodels

The concepts of schemas and metamodels are important when considering the nuances of a good MBSE model. A schema is a structured framework for developing information categories and their relationships. A schema, as applied in MBSE, directly relates to the definition of a system as a group of devices or subsystems and their relationships in the overall system. Schemas can help structure databases to support MBSE models and metamodels.

An MBSE model consists of a collection of models that support specific SE activities. The metamodel is a higher-level view of the individual models or a model of the models. It is not an aggregation of the individual models; it’s a framework that enables the models to interact and provide efficient communication between the various engineering disciplines involved in the SE effort. An SE effort will include various model types such as software models, physics-based models, manufacturing process models, and so on. The metamodel helps to maximize agile communication in a lean environment. Metamodeling involves analyzing the output and input relationships between various system elements and then developing the right metamodel to represent those behaviors. It can be viewed as a ‘map’ describing the flow of information between the individual models. So, the metamodel is the framework for developing the working models used by various MBSE design teams. The schema provides the framework for containing and maintaining the information needed to build the models.

System design and analysis

A good metamodel and schema are the basis for a good MBSE model that can support problem analysis and solution design in SE. With the proper structure and level of detail, the model will be sufficiently complete and consistent to improve the outcome of the MBSE process throughout the system’s operating lifetime. The MBSE model supports all of the SE activities, from identification and analysis of needs to product features and behaviors, through the actual system design, validation, and verification, and into commissioning, production, and decommissioning at end of life. It uses modeling to enable an efficient design process using digital twins and a digital thread to bind the virtual and physical worlds together (Figure 2). The digital twin is the virtual representation of the system, and the digital thread contains all of the information related to the development of, and changes to, the digital twin throughout the system lifecycle.

The MBSE environment provides a standards-based process for digitally documenting the system that can be automated to validate the model, remove any data or structural inconsistencies and ensure that all stakeholders and groups adhere to the common modeling language and structure. Using digitized system data, digital twins, and the digital thread supports consistent data availability to all stakeholders. That data is updated in real time as the SE process moves forward. One of the characteristics of a good MBSE model is providing the environment, perspective, and tools to reduce development risks.

In most MBSE implementations, the systems engineering office is responsible for overall model maintenance. SE begins by developing the system architecture and breaking the system down into subsystems, which are decomposed into physical architectures (Figure 3). The subsystem teams consist of experts exploring various design alternatives, remaining within the specified design envelope. Using system decomposition supports agility while maintaining top-level control by SE, ensuring that requirements management and V&V are coordinated. The digital thread provides real-time information flows between the various teams, further speeding the MBSE process. Model changes can be suggested by any design team but are only implemented after approval by SE. That provides one location for accountability and tracking of all the changes and verification steps that populate the digital thread. And one location is responsible for maintaining the relevance and integrity of the model throughout the MBSE process.

A good MBSE model supports the ability to describe the problem the system will solve, usually by describing various functions and behaviors, plus the ability to design and solution and how the system will be integrated and produced. The problem and solution sides are referred to as the operational and system perspectives, respectively, and encompass four elements.

Four operational and system elements

The operational perspective presents the concerns and needs of business personnel, users, and operators and includes the business objectives, organizational structure, processes, specific applications, and flows of information. The system perspective consists of the solution and the system’s architecture that provides the solutions to the problem(s) presented by the operational perspective. The system model describes the architecture and structure of the system, its features and behavior, as well as the data that flows within the system. It should accommodate the consideration and comparison of alternative architectures and solutions and ultimately describes how the system is deployed.

The operational and system elements can be further subdivided into logical (or digital) and physical parts. This separation is a natural part of MBSE (see Figure 2 above) and provides a framework for managing the complexity of the process. Once the system architecture and functionality have been finalized, the logical parts of the model usually remain fairly stable. The physical parts of the model are more dynamic and can change as a natural result of the SE process in response to unanticipated technology advances and other factors.

In a good MBSE model, the four quadrants are tightly connected and interrelated. All the activities should ultimately flow into the allocated solution description of the physical system (Figure 4). Each conceptual problem statement in the operational logic quadrant should be traceable to the system logic and the physical system. And they should flow into the description of the actual problem and into the physical system. And conversely, if there’s a change needed to the physical system, the logical side of the model should identify specific functionalities that will be impacted. And if a business objective or manufacturing process changes, the model can identify any impact on the solution description.

Summary

Models form the basis of MBSE, and a good model is necessary for a successful implementation of MBSE. MBSE models (and digital twins) provide a single point of truth for MBSE design teams. Those models are based on the concepts of schemas and metamodels that provide the needed semantic and logical frameworks. Systems engineering is usually responsible for model maintenance and works with the various design groups on system decomposition to spin out specific models for each subsystem. An MBSE model can be subdivided into operational and system elements that can be further subdivided into logical and physical parts.

References

An Introduction to Model-Based Systems Engineering (MBSE), Carnegie Mellon University
Applying Model Based Systems Engineering to Reduce Nuclear Weapons Development Cycle Time, US Department of Energy Office of Scientific and Technical Information
Digital Engineering for electrical and electronic design, eBook, Zuken
Systems Thinking: Schemas, Metamodels, and MBSE, Vitech
The System Engineering “V” – Is It Still Relevant In the Digital Age?, Boeing