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.
Executable Models
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
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
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
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.
System Metamodel
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.
Summary
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.
Excellent and timely. Recommend you clarify when, during the N-year life of a system, the three models assure system Fit For Purpose.
– How do you tie all these models together? Do you support the concept of a single unified system model. It sounds like you don’t.
– I don’t see the need for a non-executable system model. Why not capture requirements in an executable system model which maintains all dependencies?
– Are you capturing requirements that cannot be specified as a constraint on a parameter?
John
I applaud the separation of Systems level activities from other activities that can be system-like at their level of detail. So many long-practiced system engineers include their detailed discipline engineering knowledge in their personal definition of systems engineering that that it often appears that a systems engineer needs to DO it all (or at least be able to) rather than maintain the broad perspective that pulls together the many disciplines, skills and perspectives that lead to a successful system.
Jack, John, Bruce,
Thanks for your comments and I’m glad you found the post useful. Happy to follow-up off-line if you have more questions. Here are my responses. Thanks again.
-Mark
When do the models assure fit for purpose?
At every stage of the system development. From Needs Analysis through Concept Design and all the way through Engineering Development (per Kossiakoff), or the “left-side of the V” (per DAU). The models can be used to verify and validate requirements and evolve with the design as the design grows in more detail.
How do you tie all these models together? Do you support the concept of a single unified system model? It sounds like you don’t.
Models are tied together through techniques of digital engineering, connecting the underlying data in the tools. You can have a single unified system model, but with detailed model granularity the models can be burdensome to maintain. It is also difficult or impossible to make a single model detailed enough for analyzing specific design elements, and abstract enough to capture the overall design. Also, for detailed analysis of a single component of the system, it is not always necessary to have every other component of the design modeled to the same level of granularity. Take advantage of abstraction when you can to make the analysis tractable.
I don’t see the need for a non-executable system model?
The non-executable system model that I describe is the entity-relationship model of all the systems engineering elements of the design. The ER system model is based on a systems metamodel (explained in other blog posts) and connects much more than requirements. It also tracks design components, interfaces, functions, risk, issues as they arise and are dealt with. Also the ER system model tracks verification and validation, program management, and if necessary, architecture. So the non-executable model is helping you with all the traceability and helping you document the systems engineering journey that allows you to track decisions and record rationale.
Why not capture requirements in an executable system model which maintains all dependencies?
Yes, this is a great way of tracking functional requirements and is a technique that we recommend. We also recommend defining constraint requirements separately and allowing them to “specify” design components, rather that the function directly. Other requirements types, like performance requirements, can “specify” the functions.
Are you capturing requirements that cannot be specified as a constraint on a parameter?
Yes, absolutely, if you want to use parameters in conjunction with your requirements, you can do that. In GENESYS its possible to embed the actual parameter threshold and objective parameters in the requirements statement. I personally recommend good requirements writing practices, a parameter alone is not descriptive enough to specify work, at least when working with subcontractors.
Good comments all around. I agree with Bruce also, the systems engineer is really there to “guide” the engineering of the system. We have to put aside our own detailed engineering instincts aside and look at engineering development with the overall systems in mind.
Hello
My job relates to reliability and safety analysis of aircraft landing gear systems, based on SAE ARP 4761 and related FAR 25 guidance and regulations, to Support Certification milestone.
The ARP New revision A has added “Model Based Safety Assessment” as part of the Tool Kit to supplement FMEA and FTA etc.
Looking for more guidance on using MBSE based Models of Aircraft systems and introducing faults and errors in components to see the consequences on system level. Will be grateful if you can guide me in this area.
Thanks SYED