As companies attempt to transform their design processes into a model-based systems engineering (MBSE) environment, they often find that the road to transformation is less than smooth. Many of the bumps and potholes in that road stem from the tendency to pick up on a term without being very rigorous in the way that it is defined. In fact, the temptation is to pick up the term and run with it—with everybody running in different directions. This causes the literature and the adoption experiences to be inconsistent—magnified by the inconsistent interpretations that are placed on these reports.
The troubles begin with inconsistency around the definition of “model-based” itself. We have treated elsewhere what it means to be model-BASED as opposed to model-INVOLVED. A lack of discipline around this distinction creates our first pothole.
POTHOLE #1: Any old model(s) will do.
Models are important to engineering. There are many kinds of models and each of them provides valuable information to the engineer seeking solutions. This creates the tendency to believe that any old model will do in support of our quest to be “model-based.” Some folks even define MBSE to mean “developing a set of models” that helps to design the system under development. This comes to mean different things in different settings, with claims of practicing MBSE being based on all kinds of models from sophisticated physics-based performance models to domain-specific spreadsheets of system elements.
The first pothole, then, is the idea that involving any kind of model or models will make our practice “model-based systems engineering.”
The reality is that true MBSE requires an integrated system model that describes the system elements in all of their relationships to each other so that the efficacy of the system design can be seen, evaluated and modified in a disciplined manner. Anything less falls into the first pothole of believing that any old fragmented model or models will produce the advantages of model-based systems engineering.
POTHOLE #2: Systems views don’t need all that attention.
We give almost universal endorsement to the “systems” leg of “systems engineering,” but that can pretty easily drift into lip service. This is dangerous, and the danger rises with the increase in complexity. The task of the engineer designing a system solution to a problem is to understand the context in which the problem lives and the behavior needed to alter the problem effects in a way that will “solve” it. To do this, the engineer must be able to look at the system under design and predict how it will behave when introduced into the context. This allows the engineer to judge whether the system behavior will solve the problem. In addition, the engineer must be able to anticipate unintended consequences arising from the solution and assure that they do not create additional or even bigger problems.
The behavior of systems arises from the ways in which the elements relate to each other. Understanding that demands a view of the system—all its elements and all their relationships. That view—a system view—is the key to effective solution design. Too often, its criticality is forgotten and/or sacrificed to the use of tools that fragment the elements and blind us to their relationships. When that happens, we fall into the pothole of denigrating the importance of the systems view and sacrificing our ability to make accurate predictions about problem characteristics and solution effects.
POTHOLE #3: Metamodel? We don’t need no stinking metamodel.
One of the primary purposes of the systems engineering model is communication. The effectiveness of that communication is grounded in the semantic meaning created by the metamodel. As David Long explained in a recent blog, The Meaning is in the Metamodel, the metamodel “can be considered an explicit representation of the information necessary to engineer a system. It is a framework within which the fundamental concepts and their interrelationships are defined with clear semantic meaning.”
Again, the temptation is to take a disjoint approach with model communications divided among the views in a single tool or compartmented in several tools. But without the framework of a coherent metamodel we can’t track and communicate all the relationships which make the system what it is. That means we don’t have a systems view, and without it, we stumble back into Pothole #2.
POTHOLE #4: Requirements can be managed separately.
When we talk about requirements management, we very often focus on the traceability of source requirements to their children and back again. Spreadsheet-based tools have sprung up in support of this endeavor. These have been expanded to allow us to track the source of the requirements, the history of their forms, the quality of their statements. As helpful as this information is, it arises from managing requirements documents as opposed to managing the requirements themselves.
The problem with this approach is two-fold. First, it is largely manual, with changes being tracked into what is most often a large, unwieldy database. This becomes labor intensive, and that intensity increases directly with the complexity of the system under design.
The second aspect is both more subtle and more critical to the design success. Requirements tools that are separated from the system model stymie the ability to predict whether or not the system behavior will actually satisfy the requirements. Traceability into the source-parent-child relationships is important, but identifying the links in the chain between the requirements, the behavior that satisfies them and the mechanism by which that behavior is performed is critical to the design success. Without it, we get stuck in the pothole created by the belief that requirements can be managed separately.
Conclusion
While this list is a warning about four significant potholes, it is by no means a complete listing. Lots of problems await the unwary who seek a smooth, quick road to MBSE. A successful journey demands a rigorous adherence to the fundamentals.
These pitfalls illustrate that problems often come disguised as solutions. A wide variety of models can provide valuable and even crucial information to the engineering team. The information from them can connect discipline engineering into the system design in a way that heightens solution quality. But, the model that makes systems engineering “model-based” has to be system-wide in perspective, affording the design team the necessary systems view.
The information collected from views and models must fit into a coherent metamodel in order to connect the value into a usable system model that will offer an effective design solution. No matter how valuable information may be in its narrow setting, it doesn’t provide benefit to the solution-seeker until it is connected through the metamodel. Effective requirements management is critical to targeting the design on the problem, but until it is integrated it can’t provide its real value to the solution design.
The journey to MBSE is hard. Potential potholes must be avoided, and it requires effort to take a disciplined approach. But it holds its considerable rewards for the diligent and persistent organ
