In the world of model-based systems engineering (MBSE), there is still a fair amount of confusion around what makes a good—or even acceptable—MBSE model.
George E. P. Box, the English statistician, famously observed, “All models are wrong, but some are useful.” He further clarified that idea with this expansion, “Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.” As Box brings into focus, there is a point at which the representation can be limited in a way or ways that interfere with use to which the model is purposed. The usefulness of a model is judged by its fitness for its purpose.
Purpose
The purpose of using a model as the basis of systems engineering is to further the mission of the systems engineer. The International Council on Systems Engineering (INCOSE) defines systems engineering as, “. . . a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.” That makes the mission of the systems engineer to “enable the successful realization, use, and retirement of engineered systems.” In order to accomplish that mission, the systems engineer must be able to predict how the design or changes to be realized in the system of interest will perform against the requirements that drive their creation—the real measure of the success of the system.
Making that prediction rests on the ability to see the system as an entirety. This recognizes that the properties of any system are the product of the interactions of all the system elements with each other. Any model of the system that does not provide this complete view will not, therefore, support the necessary prediction that is the basis of the work of the system. The first characteristic of a good MBSE model is this complete, holistic view. Without that, the systems engineering is not truly model-based.
Complexity
The MBSE model must support a sufficient level of detail to depict the relevant complexity and nuance of the problem to be solved and any proposed solution(s). It can be tempting to simplify the structure and detail of our models, particularly in the quest for accessibility. But, we must preserve the ability to describe accurately the system elements and their relationships at a level that leads to understanding the behavior and performance of the system being modeled. Anything relevant that is lost or made ambiguous in the simplification effort has the potential to hamper the prediction the systems engineer seeks to make. In order to be a good MBSE model, it must be nuanced and detailed enough to accurately support that prediction.
Connection through communication
We use MBSE models to understand problems and their solutions, but we also use them to communicate to a variety of audiences who are essential participants in the design and ownership of the systems we model. In its definition of systems engineering, INCOSE points out that engineered systems “may be composed of any or all people, products, services, information, processes, and natural elements.” The diversity of these elements itself creates a wide variety of natural constituencies who have a role and/or stake in the creation or modification of the system solution.
Among the constituencies, we find business champions and process owners, domain subject matter experts and discipline engineers, social and natural scientists, program managers and acquisition personnel—the list goes on and on. All of these specialties and disciplines both use and make valuable contributions to system models. Their information input and consumption must be aligned to achieve a broad understanding and agreement regarding the ultimate solution. This means that they must be able to see, understand and contribute to the model.
That means that the model must be structured in a way that facilitates communication. They will not all understand or speak the same language as they describe aspects of the model from the perspective of their areas of expertise. Systems engineers may think of it in SysML representations. Discipline engineers and subject matter experts may derive their understanding from physics-based models. Program managers and process owners may see their areas in flow charts or specialty business process notations. Others will have their own preferences for communicating their questions and answers.
To maximize its effect, the information generated in any and all of these areas must find a home in the model structure. This is made possible by structuring the model in a system metamodel that organizes the information around all of the system elements and their relationships. When the model is organized structurally and semantically, it can be opened up to the flow of information to and from the various constituencies. For example, performance data from physics-based models can be tied to the applicable parts of the model, and its impact assessed and considered in the design decisions and trade-offs. This happens through the underlying structure provided by the metamodel.
The metamodel provides the basis for a map across which information can travel in and out of the model. Information is contributed or extracted through a query of the structure for a subset of model information. This information can be formatted according to any set of rules understood by the database (SysML, structured analysis, tabular representations, etc.) for use by the communicant. To facilitate this communication, a good MBSE model must be built on the structuring framework of a system metamodel.
Solution design and analysis
The good MBSE model supports the problem analysis and solution design processes. This means that the model will minimize ambiguity and facilitate completeness and consistency in the solution design. Consistency and completeness can only be judged in the framework of a fully integrated model. Integration of the model also facilitates the verification and validation of the design against its requirements. All of this enables the critical systems engineering prediction of solution success. To be truly useful, a good MBSE model must be integrated.
Conclusion
A “good” (useful) MBSE model must be fit for the purpose of making the systems engineering prediction of success for the solution it models. It must provide a holistic, systems view. It must be complex and nuanced enough in its expression of the reality of the solution to provide the needed fidelity for an accurate understanding of its success or failure against its requirements. It must be organized in a way that can be leveraged to provide a map for communicating information to a broad community of constituencies. And it must be fully integrated so that it will support the design and solution analysis processes.
