Review: A Primer for Model-Based Systems Engineering (MBSE)
Summary: If you are expecting a SysML modeling guide, this book is not for you. Instead, the MBSE primer deals with the basic principles of model-based system development. The book does not expect any special prior knowledge. Instead, it uses a concrete example to show how the basic principles manifest themselves in reality. To this end, it explains step by step what systems, system development, modeling and finally MBSE are. The insights are often profound. It is worth re-reading this elementary book every few years so as not to lose sight of the big picture.
Target group: Experienced engineers and managers who want to understand the principles of model-based system development. Rather unsuitable for career starters.
Read on to find out how many stars I gave the book.
Rating: ★★★★★ This small book (just over 100 pages long) is a quick read. It requires no prior knowledge, as it deals with the principles of MBSE with the subject. There are also many exciting insights for experienced system engineers. The only danger is that the reader goes to the MBSE primer with the wrong expectations and expects a modeling guide.
Authors: David Long, Zane Scott
Acquire: The book is available free of charge as an eBook (registration required) or on paper at www.vitechcorp.com/mbse-primer/
Details: The book offers exactly what the title says: It is an introduction to MBSE, and the structure follows from this: First, it explains what a system is. This is the prerequisite for understanding systems engineering. After explaining what a model is, Model-Based Systems Engineering can be explained. So far, no surprise.
The book is accompanied by a suitable case study: A geo-library that obtains images for customers via a satellite network. A simple use case, but one with enormous complexity.
Systems
I've had a book by Russell Ackoff on my to-do list for a long time. Ackoff is the founder of the idea of the Systems Thinking. System Thinking begins where Enlightenment (epistemology) ends. In the age of cognition, understanding was sought by dividing things into their individual parts in order to understand the whole. But that is precisely what does not work with systems: the whole is more than the sum of the parts. This is a paradigm shift, and this is clearly emphasized once again in this book.
The critical idea here is that we begin not from a decomposition of the system into its parts but from the point of view of the system in its context. [tweetthis]We begin not with the parts of the system, but from the system in its context.[/tweetthis]
And conceptually, a system only consists of a few entities: there are entities, attributes and relationships. Whether the entities are atoms or motors is irrelevant.
Systems Engineering
The system engineer's area of responsibility is clearly defined: it relates to the overall system and the external interfaces. The system engineer must ensure that the requirements of the stakeholders are understood and correctly implemented in functions that are realized via the components of the system. This is both a technical and a management process.
There are only three basic problems in systems engineering: (1) new systems, (2) improvements and (3) replicas. Unfortunately, we often only encounter the first basic problem in training and textbooks, although the other two play a major, often even greater role in practice.
In systems engineering, you only encounter three different basic problems: New systems, improvements and replicas. Unfortunately, the last two are often neglected in teaching. [tweetthis]Unfortunately, improvement and replication projects are often neglected in SE teaching[/tweetthis].
Furthermore, SE theory often neglects the fact that we are dealing with not just one, but three systems: In addition to the system to be developed, there is also the system context, which is a system in its own right, and the system that is used for development. The latter is important insofar as it significantly influences the quality of the system to be developed. Accordingly, the authors also address this topic in detail.
The development process is divided into four domains, which are certainly familiar to the reader: Requirements, Behavior (functionality), Architecture and Verification and Validation (V&V). These are partly taught using the example system.
Finally, the important topic of communication is addressed.
Models
Models can cover the entire spectrum from form to function - for example, from a wooden model to a mathematical formula. In this chapter, the discourse is again guided by basic principles. A model consists of four elements:
- Language - Every model must have the clearest and most precise language possible.
- Structure - The elements of the model must be related to each other, which would be difficult without a structure.
- Reasoning - A model should be created with a clear objective, and the model must be able to argue with regard to the objective.
- Presentation - It is not enough for the basis of the argument to be hidden somewhere in the model. It must also be possible to present it in a convincing way.
These four elements are described in detail and with examples in the following sub-chapters.
It is important not to confuse the model with an image or a view of the model. The aspect of language is also critical. It should not be forgotten that systems engineering ePresentation is an overarching activity and must therefore be understood by people from different disciplines.
The need for a clear, unambiguous system definition language is reinforced by the presence of a large number of subject matter experts involved in system design. [tweetthis]MBSE calls for a clear, unambiguous system definition language[/tweetthis]
Furthermore, a model cannot be taken apart so easily without losing essential properties. This is where systems thinking comes into play: a system is more than its individual parts. This also applies to the development system.
I am somewhat skeptical about the statement that languages for behavior must be graphical (page 39, Language of Behavior). I would be very interested in the opinion of my readers here. To be fair, even an N² matrix is classified as graphical, which qualifies the statement somewhat. On the other hand, I fully agree that language must enable black-box thinking. However, the behavior of the subsystem encapsulated in the black box must not be lost.
In this context, the separation of logical and physical models is also important, because while a physical system is subject to major change (due to technological progress), the logical system, or behavior, remains relatively constant. An example is the change from CRTs to LCD screens - the function is unchanged, the underlying technology has changed drastically. These concepts are explained practically using concrete modeling languages such as FFBDs, activity diagrams and sequence diagrams.
When it comes to argumentation, traceability inevitably comes into play, which is presented as a clear advantage over document-based work: The fact that relationships can be navigated in any direction in a model enables navigation not only downwards, but also upwards (How did we arrive at this decision?) or horizontally (Where are there interactions?). Here again, systems thinking crystallizes: the whole is more than the parts.
MBSE
Condensed into one sentence, the authors describe MBSE in the primer as a thought process: a framework is set that ensures effectiveness and consistency from the outset, but at the same time leaves enough freedom for the specific situation. Specifically, the following advantages are listed:
- It is possible to look at the overall problem
- Problem and solution are described in a consistent language
- The result is a coherent design
- The implementation of the system requirements and their completeness can be demonstrated
This is the first time that the MBSE primer shows that it supports a commercial company (Vitech Corporation) (apart from the large logo on the cover). This is because the STRATA approach developed by the authors and commercialized by Vitech™ mentioned. The name was derived from "Strategic Layers", as the problem converges strategically to the solution via increasingly detailed layers.
Traditionally, each domain of system development (requirements, functionality, architecture, V&V) is self-contained until the solution is found. With STRATA, however, the layers are self-contained. The advantage here is that iterative work can be carried out in individual layers without disrupting the overall development. Another advantage is that the overall context is never lost sight of.
The approach of solving problems in layers is the core of MBSE [tweetthis]The approach of solving problems in layers is the core of MBSE[/tweetthis]
To show that MBSE is a sensible approach, the authors of the primer start - how could it be otherwise - with the requirements, i.e. the requirements for the development process. They set out four key requirements and show that MBSE implements these well:
- The process must reliably lead to the development of successful systems
- The process must be able to manage the complexity of the system
- The process must lead to an effective solution for a broad range of customer needs
- The process must take into account all problem classes (new development, improvement, reverse engineering)
STRATA is used to show how these requirements are realized by an MBSE method. However, I see no fundamental problem in implementing them with other MBSE methods if they are used carefully. However, the authors claim that many SE processes - in contrast to STRATA - are not good at dealing with interactions and consistency. The extent to which this also applies to other MBSE approaches remains to be seen.
In order to concretize what has been described so far, three of the levels or layers of the solution manifested in STRATA will now be derived. This is described in detail for the first layer, which consists of requirements, functionality and architecture. In the second layer, behavior (thread development) is examined in detail. This is particularly interesting because it clearly shows how evolving complexity can be dealt with. The authors differentiate between behavior and functions. It is helpful to standardize the behavior in order to avoid redundancy in the functions.
Finally, the MBSE primer describes in general terms how the layer principle is propagated in the subsequent layers.
Verification & Validation
V&V activities are also carried out in step with the layer approach, with at least one design review per layer. In contrast to the traditional approach, V&V activities can also be formalized in the model-based approach. This chapter is kept quite short. On the one hand, this is understandable, but it is nevertheless a pity, as in practice V&V is not given the attention it deserves (and which also pays off).
Conclusion
For me, the MBSE primer fills an important need in the market for which I don't think there is too much literature yet: The technically sound business case for MBSE, written for experienced systems engineers and decision makers. The book is technical enough to communicate the arguments convincingly, yet assumes little basic knowledge. As such, it has the potential to become a timeless classic.
Kudos also to the authors for keeping their commercial interests out of this book. The authors make no secret of their role in the Vitech Corporation. At no point is the content marketing or sales material. Compliments!
