18 things you can do with system models

System modeling is a powerful tool that can be used to improve many aspects of systems engineering, from traceability to change management to test case generation. But there is also a dark side to modeling: it can quickly become an end in itself without clearly defined modeling goals. Chaotic, hard-to-read models can cause more problems than they solve. A well-known problem in software development, "code rot", can also occur in system models. Models, like software, must follow conventions and be regularly tidied up (refactoring).

But enough about the problems: You can also do a lot of useful and efficiency-enhancing things with models. Here is my - certainly incomplete - list. What else can you do with system models? Feel free to add to this list in the comments section (To the comments).

1. communicate

The graphical view of a model in particular can be an extremely powerful tool for communication. It is important to be clear whether you are "still painting" or "already modeling".

2. generate documents

Document generation goes hand in hand with communication: it is not uncommon for only a few people to create models and for most (80%-90%) of the employees to merely consume the models. This consumption often takes the form of reading generated documents. The gradual introduction of MBSE is also possible via document generation.

A generated document or printed diagram is often the first point of contact with modeling [tweetthis]A generated document or printed diagram is often the first point of contact with modeling[/tweetthis]

3. create views

The creation of views is actually only one step further from the previous point: however, unlike a document, views can also be interactive and summarize information from the model.

4. generate test cases

In a well-structured model, the test cases simply tumble out of the model. For example, one or more test cases result from each precondition or invariant. Depending on how formal the model is, the test cases can even be generated automatically.

5. generate code

Models are often used to generate code, particularly in the field of embedded systems. The challenge is usually to embed the generated code cleanly into the overall system. This is because it is almost never practicable to generate the entire system completely.

6. track progress

The nice thing about system models is that a formal definition of progress is possible. For example, "All requirements have the status 'accepted'". Progress can be queried at any time and forwarded to project management, for example.

7. check completeness

Similar to tracking progress, completeness can also be checked. This requires clearly defined completeness criteria and an appropriately maintained model.

8. summarize information

In addition to progress and completeness, all kinds of information can be summarized and presented in an appealing way at any time, from the number of model elements to test coverage. However, caution is advised here, as key figures can also cause a lot of damage in the wrong hands.

9. automatic verification

With correspondingly formal system models, verification can even be dispensed with in some places, as the tools can carry this out independently. One example would be the automatic check that a state machine never violates an invariant.

Used correctly, models can make V&V activities much more effective [tweetthis]Used correctly, models can make V&V activities much more effective[/tweetthis]

10. understanding the effects of changes

Since the modeling works with a finer granularity than with documents, the effects of changes can be analyzed quickly. This requires clean traceability and good tool support.

11. assess risk

Risk assessment is just one of many analyses that can be easily performed with an appropriately structured and maintained model.

12. recognize conflicts

A trivial example: A system that requires a 12V power supply cannot be connected to a 240V network without a transformer. In one model, this is obvious because the interfaces simply do not match.

13. recognize inconsistencies

Imagine you have a 200-page specification: On page 12 it says that the housing should be green. On page 158 it says that the housing should be blue. How likely is it that you will notice this inconsistency? In a good model, the color would be the property of the housing that appears exactly once in the model.

14. animate the model (simulation)

The static aspects of a system are usually not the problem: the challenges often come with the dynamic aspect. Some models make it possible to analyze the dynamic aspects of the system via simulation. This can be invaluable!

15 The model as a specification

Quite banal: The model can simply be used as a specification. Incidentally, this is the third stage of the SYSMOD Intensity Models.

When the model has become the specification, we have real MBSE. [tweetthis]When the model has become the specification, we have real MBSE.[/tweetthis]

16. the model for structuring

In document-based work, we structure with the help of chapters. However, there are rarely clear boundaries between the individual subsystems, and work has to be very disciplined. With an appropriate model structure, even large systems can be structured in such a way that they are clearly isolated from each other.

17. manage knowledge

Knowledge management can take many forms, but a concrete example is domain knowledge, which can manifest itself in a clean domain model. This provides a vocabulary that is difficult to realize with any other precision.

18. reuse

Models enable a degree of reuse that is almost impossible to achieve in any other way. Clearly defined and delimited subsystems can be used repeatedly.