System models are powerful tools that allow improving many aspects of Systems Engineering, from traceability, change management to test case generation. But there is also a dark side: Modeling can become an end in itself, without a clear definition of a goal for the model. Chaotic, hard to read models can create more problems then they solve. A problem from software engineering called “code rot” also applies to models. Models, like software code, must follow conventions and refactored on a regular basis.
But enough of the problems: You can use models for a lot of useful activities, and increase efficiency. Here is our – likely incomplete – list. What else can be done with system models? Feel free to add your thoughts in the comment area (Comments).
A graphical view on the model in particular can be a powerful tool for communication. It’s important to be clear on whether it’s “just a drawing” or a “view on a model.”
2. Document Generation
Generating documents goes hand in glove with communication: It is not unusual that a small number of people create models, while most (80%-90%) users consume models, often by reading generated documents. Document generation also allows the stepwise introduction of MBSE.
A generated document or printed diagram is often the first point of contact with modeling
Creating a view of the model is simply one extra step from the previous point: But in contrast to documents, views can be interactive, or aggregate information from the model.
4. Generating Test Cases
A well-structured model makes it super-easy to derive test cases. For instance, each precondition or invariant implies one ore more test cases. Depending on the formality of the model, test cases can even be generated automatically.
5. Generating Code
Especially in the development of embedded systems, models are often used for code generation. The main challenge is embedding the generated code cleanly into the complete system. It is almost never practical to generate the system as a whole.
6. Track Progress
The cool thing about system models is that fact that you can provide a formal definition of progress. For instance: “All requirements have the status ‘approved’.” Progress can be queried at any time and processed further, for instance by project management.
7. Check Completeness
Similar to tracking process, completeness can be checked. This requires a proper definition of completeness, and a correctly maintained model.
8. Aggregate Information
Besides progress and completeness, any kind of information can be aggregated at any time and be presented in a pleasing manner, from number of model element to test coverage. But be cautious, operating numbers can create a lot of damage in the wrong hands.
9. Automatic Verification
With an appropriately formal system model, it is even possible to skip manual verification altogether, as tools can perform these automatically. An example would be the verification on whether a state machine ever violates an invariant.
If used correctly, models can increase effectiveness of V&V activities significantly
10. Understand the Implications of Changes
As the granularity of models is much finer, compared to working with documents, the effects of changes can be analyzed quickly. Note that this requires a clean and up to date traceability, and proper tool support.
11. Assess Risk
The assessment of risk is just one of many analyses, which can be performed with a properly structured and maintained model.
12. Recognize Conflicts
A trivial example: A system that requires 12V power cannot be connected to 240V without a transformer. A model makes this obvious, as you simply cannot the interfaces.
13. Identify Inconsistencies
Imaging having a specification of 200 pages: On page 12 it is stated that the case shall be green, on page 158 it requires the case to be blue. How probable is it that you will notice this inconsistency? In a good model, the color would be a property of the case and would be stated exactly once.
14. Animate the Model (Simulation)
Static aspects of the system are rarely the problem: Most challenges are caused by the dynamic aspects. Some models allow the analysis of dynamic aspects via simulation. This can be priceless!
15. The Model as the Specification
Almost trivial: The model can be used as the specification. Incidentally, this happens to be the third stage of the SYSMOD Intensity Models.
If the model becomes the specification, we finally have “real” MBSE
16. Model for Structuring
Documents are structured in chapters. But there are rarely clean borders between the various subsystems, and disciplined working is necessary. With a good model structure, even large systems can be broken down into cleanly isolated subsystems.
17. Manage Knowledge
Knowledge management can take on many faces, but a specific example is domain knowledge, which can be manifested in a clean domain model. This provides a clean, precise vocabulary, which is difficult to realize otherwise.
Models allow reuse to a degree that is hard to realize otherwise. Subsystems hat are cleanly defined and isolated can be reused.