What is Good System Model?
In this post, I will talk about the characteristics and importance of a good system model, the goals of MBSE, and how SysML can help us.
First, what is a good system model?
The model is different from the designs we as designers are familiar with. A good model is one that serves its intended purpose well. On the other hand, a good design is assessed by how well the design satisfies requirements and to what extent it incorporates quality design principles.
For example, a car model is a good model if it serves its intended purpose well. However, if the car’s design lacks stability, it cannot be considered a good design.
Good models are important for design teams to identify problems and assess quality, and the selection of model-based systems engineering (MBSE) methods and tools is essential for this.
Assessing the effectiveness of your model and deriving quality attributes can help you improve your modeling practices, and modeling tools can help you determine the quality of your model. These evaluations contribute to improving design quality.
The following items should be considered when evaluating the quality of a model. If these things are well considered, I think it can be said to be a good model.
1. Scope of the model : Determining the scope of the model first determines the ‘width’ of the model, to what extent the necessary parts of the system are modeled. For example, if your car design focuses on fuel economy and acceleration, you might focus on the powertrain system. Secondly, ‘depth’ refers to the level of the system design hierarchy that the model should cover, in the initial design phase it only covers the upper level, but if further development is required for a particular part, a deeper level of modeling may be required.
Thirdly, ‘fidelity’ determines the level of detail required by the model; while low-fidelity models are sufficient to represent simple sequences of operations, high-fidelity models can include more complex details such as message structures and communication protocols. . All of these factors have a significant impact on the level of resources required for modeling.
2. Completeness of the model : A key factor in assessing model completeness is whether the breadth, depth, and fidelity of the model match the defined scope. Additionally, whether naming conventions for the model are applied and whether design elements are traced to requirements are also important in assessing completeness. The MBSE metric can be used to further establish these criteria for completeness.
3. Compliance with model constraints : A well-constructed model should adhere to the rules of the modeling language you use. For example, SysML allows specific relationships between requirements and system components, but does not allow direct inclusion. The modeling tool should provide the ability to enforce these rules and constraints and report violations.
4. Model consistency : SysML uses built-in rules and constraints to ensure model consistency, including interface compatibility and unit consistency checks. However, there are limitations to preventing design inconsistencies that can arise when multiple modelers work, such as different naming for the same component, which can be resolved through reviews and reports, well-defined model rules and a systematic process. helps minimize this.
5. Understandability of the model : The understandability of the model is largely determined by the effective use of model abstraction, the integration of different levels of abstraction, the modeling approach of SysML, the ability to control information in diagrams, the use of modeling rules, and the degree of self-documentation of the model. This is important to avoid information overload for model reviewers and to clearly communicate certain aspects of the design.
6. Modeling rules and standards : Documentation and consistent use of modeling rules and standards are important to ensure consistent representation and style across models, including establishing naming conventions for model elements and diagrams, and stylistic aspects of the language ( (case, use of spaces in names, etc.), restrictions on alphanumeric and special characters caused by the tool, and template settings for each diagram type.
7. Model documentation and information provision : When assessing whether a model provides sufficient supporting information and is self-documenting, the use of annotations and descriptions applied consistently throughout the model is important. These annotations may include the rationale for design decisions, identification of problems to be solved, and additional textual descriptions of model elements, contributing to the long-term maintainability of the model and its effective communication to others.
8. Integration of models : Whether or not models are integrated depends on the methods, tools, and modeling languages used. In particular, the way information is transferred between system models such as SysML and software models using UML is important. This integration relies on an agreed-upon representation of modeling information to effectively communicate information to developers and analysts across a variety of disciplines. This model integration approach is designed around the needs of model users.
MBSE – Six Key Goals to Transform Systems Engineering
What is the next goal we want to achieve by applying MBSE?
(This section references chapter 3 of David Hetherington’s book SysML for Beginners.)
Goal 1 – This Single Version of the Truth
The first goal of Model-Based Systems Engineering (“MBSE”) is to enable building and maintaining a single version of the truth for large, complex projects.
All stakeholders in the system must reach a common understanding of what the system does and how it operates. Building this common understanding is a key role of MBSE in general and SysML in particular. The goal is to provide a set of diagrams that are semantically accurate, but flexible and simple enough to be understood by everyone from mechanical engineers to ethics experts.
SysML does not replace individual expert tools.
It is important to note that each professional has specialized tools. Mechanical engineers have several computer-aided design tools at their disposal. Each software engineer uses different specialized languages and design tools.
Accountants certainly have the same professional tools as lawyers or even ethics experts. SysML does not replace these specialized tools. SysML’s role is to create a single version of the truth that allows each expert to contribute their part of the overall system using specialized tools.
Goal 2 – Divide and Conquer
Allows systems engineers to have highly focused discussions with each stakeholder, one at a time. The key here is that true MBSE allows you to create a simple diagram for each stakeholder that focuses only on aspects of the problem of interest to that particular stakeholder. At the same time, the model can integrate all these different perspectives.
Goal 3 – Common Understanding of Diagrams
Goal 3 may seem similar to Goal 1, but Goal 3 is important enough that it deserves separate mention. It is important that all stakeholders agree on a ‘Single Version of the Truth’, but even more important is that they understand that truth and that they all understand it in the same way.
Goal 4 – Simplification
Modeled-Based Systems Engineering (MBSE) originated in the aerospace industry. Legend has it that one day the airplane manufacturers realized that their specifications were heavier than the airplane. The goal of Goal 4 of MBSE and SysML is to reduce dependency on complex text artifacts in large-scale systems development projects.
But there is an old saying:
“A picture is worth a thousand words.”
SysML won’t completely eliminate the need for textual descriptions of things. However, a well-designed SysML model can reduce the need for long writing blocks. In addition to reducing the amount of text, well-designed SysML diagrams should be easier to understand than the dense blocks of writing they replace.
Goal 5 – Knowledge Management
When used correctly and consistently, SysML models can be an excellent way to extract and normalize the complex “tribal knowledge” inherent in large systems development organizations.
I once spoke with a technical expert at one of the largest defense companies in the United States. He explained that his company systematically analyzes and models the functionality of legacy software based on what it considers intellectual property best practices. In other words, the code itself was very difficult to review for reuse. Good graphical models make it much easier to understand the functionality and capabilities of legacy software blocks. This improved understanding helped the company manage this legacy software as a library of reusable intellectual property assets.
Goal 6 – Avoiding High-Level Mistakes
Goal 6 is for MBSE to help teams avoid high-level mistakes. Recent research on companies adopting MBSE confirms that the greatest benefits occur early in the project.
In software development, the benefits of eliminating bugs early in a project are well known. Bugs detected at the requirements or architecture stage are eliminated at a much lower cost than bugs detected after the product has been deployed to thousands of customers. MBSE and SysML are very helpful in moving the detection of basic mistakes, misunderstandings, conflict between goals, and other problems to the left of the curve shown in Figure 3-14.
The Essentials of SysML: A Key Tool to Achieve MBSE Goals
Finally, then why should we use SysML?
The reason is rather simple. This is because SysML meets the six goals outlined above.
And on top of that, SysML offers incredible flexibility. all. A set of nine concise diagram types can be used to model a variety of different systems. SysML can be used to model airplanes, ships, automobiles, medical devices, rail networks, semiconductor architectures, and just about any other system imaginable. SysML can also be used to model political systems. Also, one of the benefits of SysML is the sheer number of tools to choose from. In this blog, I plan to additionally post how to use Enterprise Architect, one of the tools, and the process of system modeling using this tool.
This concludes my post about MBSE. I hope this post was of some help in understanding MBSE. In the next post, I will finally give an overview of SysML, the main theme of this blog. We ask for your continued interest.
If you are interested in other articles on systems engineering in the automotive electronics industry, please refer to the links below!
[Systems Engineering] #1. INTRODUCTION – Navigating Systems Engineering
[Systems Engineering] #2. Definition of System
[Systems Engineering] #3. Understanding Systems Thinking
[Systems Engineering] #4. Useful knowledge of systems thinking
[Systems Engineering] #5. Understanding Systems engineering
[Systems Engineering] #6. Who is Systems Engineer
[Systems Engineering] #7. Understanding MBSE (Model Based Systems Engineering)
[Systems Engineering] #8. Additional practical knowledge about MBSE
[Systems Engineering] #9. What is Good System Model?
[Systems Engineering] #10. Understanding SysML (System Modeling Language)