When engineers speak about model-based systems engineering, or MBSE, the term “model” is used in many ways. Unfortunately, this only creates confusion between systems engineers, modeling and simulation engineers, and detail engineers. We all use models, so does this mean we’re now model-based? No.
Remember that MBSE was devised as a contrast to document-based systems engineering. MBSE was envisioned as an improvement for the way we conduct systems engineering. We must be careful that we don’t fall into modeling for the sake of modeling, and become too analytic in our approach. Rather, systems engineers need a way to benefit from all of the many model types, while remaining focused on the overall system design. Here is a guide to the model types that I’ve identified over the course of my engineering career. As a former software engineer, and later, modeling and simulation engineer, I’ve seen my fair share of models.
The System Model
The system model is a model of the system-under-development. The purpose of the system model is to help systems engineers guide the engineering development of the system. Before MBSE, the system model was essentially a collection of mental models held by a number of stakeholders. Text, diagrams and charts contained in documents helped all involved keep a common image of the system, but gaps in the clarity of the system model contributed to misunderstandings of the concept of operations, system design, and interface implementations. It was difficult to keep documentation up to date and identify true sources.
With MBSE, the system model became more formalized. System model information is retained in a project repository and forms the authoritative source of information about the system. It is updated as the system design unfolds, and captures all requirements, behavior, design, design decisions, and decision rationale to help keep stakeholders up to date on the very latest developments. The system model drives all design diagrams and information, ensuring design consistency and allowing engineers to automatically produce completely consistent system documentation. Note that there is a strong relationship between the system model and the systems metamodel, described later.
An executable model is closely associated with the system model. In fact, it’s a subset of the system model. The system model spans all aspects of the system engineering design and journey. The executable model is focused on the behavioral aspect of the system model. An executable model uses behavior information from the system model and additionally models the logical flow and design of behavior, data, and resources. The executable model is part of the system model and is also supported by the systems metamodel, allowing tools to render behavioral diagrams based on data in the project repository. The purpose of the executable model is to identify functional and performance requirements for the upper layers of a system design, and to validate and verify that the allocation of behavior to design components can in fact meet system requirements. The executable model is often confused or conflated with simulations models, described next.
Simulation models also deal with behavioral aspects of a system design. While the purpose of an executable model is to identify necessary functionality of the system, simulation models help identify and validate detailed functional and performance requirements for various parts of a system design. Issues like routing convergence or data latency in telecommunication networks, for example, are best left to simulation tools that are specialized to the applicable domain. Simulation models can also take into account details of physical design components and determine how they affect system performance at the most detailed aspects of the system design.
To distinguish the purpose of an executable model from that of simulation models, the execution model is an aide to high-level aspects of system design, while simulation models are aides to low-level aspects of a system design. While it is tempting to combine all of these models into one, the resulting model can become too detailed or granular for systems engineers and can drive the system design too early into particular solutions. For detailed engineering, the execution model aspect makes the model too broad, taking unnecessary resources to execute.
Physical models use scientific and engineering principles to develop the physical aspects of the system design. Mainly used for developing the early aspects of detailed design, physical models can be connected to the system model to help validate a specific component design with the functionality and performance of the overall system. Also, through the system model, physical models can share key parameters with simulation models.
Design models help identify form, fit, and function of physical components. Design models are implemented in computer-aided design tools, or electrical wire harness design tools. These models serve exacting purposes to ensure design components can be designed and integrated properly to make for a working system. Parameters of design models can also be shared with the system model to ensure the resulting design meets requirements.
Finally, we come to the system metamodel. As we’ve described in many places (Who Needs a Metamodel?, A Grounded Systems Metamodel – Now!, What is the Difference Between a System Model and a Systems Metamodel?, The Systems Metamodel and Communication), the system metamodel identifies all aspects of systems engineering succinctly in an entity-relationship model such that when it is instantiated into the project repository, it allows the systems engineer to develop the system model. By providing a comprehensive framework for constructing systems models, the system metamodel also enables sharing of design information between the system model and across other modeling tools, and can further the seamless integration of the tools.
The systems metamodel, the system model, and the executable model are within the purview of the systems engineer and MBSE. The simulation, physical and design models are in the purview of the detail engineers, and when combined with MBSE through the systems metamodel, form a digital engineering environment. So, the “M” in MBSE actually refers to the systems metamodel. It is through the systems metamodel that we improve the conduct of systems engineering by focusing on producing an effective system model and thereby refocusing away from the document-based systems engineering approach as the basis of systems design.