What does it mean to be model-BASED?

The Systems Engineering Body of Knowledge* defines a model as “a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system.” There is broad acceptance that models are limited or simplified representations of a reality of interest. There is not, however, the same level of understanding on what kind of model it takes to be “model-based.”

The meaning of model-based is couched in the concepts of “based” and on the model choice. Confusion around the term model-based is most often tied to some confusion or disagreement about these two concepts. The important questions to ask are: “What does it mean for systems engineering to be based on a model?” and “What kind of model does it take to form the basis of systems engineering?” Getting to the answers to these two questions can be tougher than it seems at first blush. The failure to do so explicitly is the source of confusion for many systems engineers.

What does it mean for systems engineering to be based on a model?
Beginning with the first question, the key issue turns on the difference between “model-based” and “involves the use of models.” The dictionary definition of basis is, “the underlying support or foundation for an idea, argument, or process.” Being “based on” means “having its basis in.” To be model-based means having its basis in a model.

Why belabor such a simple definitional concept? This “simple” concept causes way more trouble than its obvious nature would cause us to suspect. The trouble frequently takes the form of substituting the idea of systems engineering that involves models in some aspects of the design or verification, and validation for the concept of the use of a model that forms the basis of those processes. Significant numbers of systems engineers base their belief that their engineering is “model-based” on the use of physics-based performance models or limited representations of pieces of their designs (requirements, components etc.). These models are valuable and may even be indispensable to the design process, but they are not an adequate basis for systems engineering.

What kind of model does it take to form the basis of systems engineering?
That brings us to the second question, “What kind of model does it take to form the basis of systems engineering?” This turns on the purpose of the model. We have explored this issue previously using George E.P. Box as our guide.

George E. P. Box, the English statistician, famously observed, “All models are wrong but some are useful.” He further clarified that idea with this expansion: “Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.” What did he mean?

Box’s assertion first tacitly points to the definition of a model as a “limited representation.” That means it approximates, but does not match, the reality being represented. To this extent it is “wrong” because it fails in one or more aspects to accurately depict all of the aspects of the reality. But in a “useful” model, that failure is inconsequential because the shortcomings of the depiction do not deprive the modeler of necessary insight into the reality.

As Box brings into focus, there is a point at which the representation can be limited in a way or ways that interfere with use to which the model is purposed. Beyond that point the model is not useful because it doesn’t support its use. The representation lacks something essential to its purpose. So what does it take to qualify as a useful “systems engineering” model?

Four requirements for the systems engineering process
In the Vitech Primer for Model-based Systems Engineering (Long, D. and Scott, Z., Vitech 2011, pp. 43-47), the authors identify four requirements for the systems engineering process.

1. The process must consistently lead to the development of successful systems.
2. The process must manage system complexity well.
3. The process must lead to effective solutions to a broad range of customer needs.
4. The process must accommodate the three main problem classes (engineering unprecedented systems, reverse engineering, and middle-out engineering).

Particularly with regard to meeting the first two process requirements, systems engineering must be able to identify and predict the emergent behaviors of complex systems, both in the context system and the system of interest. In order for a model to be adequate to its purpose as a system model for systems engineering, it must be able to provide the insight necessary for that understanding. To paraphrase Box, to the extent it can provide that basis, it is useful. To the extent it cannot, it is just plain wrong.

Understanding complex systems requires a model that provides a clear view of all the system elements and their relationships to each other. It is through the relationships—the ways the elements are put together—that the systems behaviors emerge. To quote INCOSE’s A Complexity Primer for Systems Engineers, “. . . emergence is a collective phenomenon that requires aggregation—emergence will not be observed until the system is considered as a whole.” (A Complexity Primer for Systems Engineers, INCOSE 2016, p. 14, emphasis mine.)

With that in mind, it becomes clear why models that address pieces and parts of systems can’t become the “basis” for model-based systems engineering. No matter how accurately and clearly they depict their piece of the system, it is still a “piece” and not the whole. Without the view of the whole system there is no insight into the collective phenomenon of emergence. Without that insight, systems engineers lack the ability to make the predictions necessary or to manage system complexity well enough to consistently develop successful system designs. Fragmented models—even when cobbled together—are not the basis contemplated by systems engineering that is truly model-based. Model-based systems engineering depends on a fully integrated systems model that allows the systems engineer to consider the system as a whole. Only then is the systems engineering really “model-based.”
_____________________________________
* (BKCASE Editorial Board. 2017. The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 1.9. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. Accessed 21 August 2018. www.sebokwiki.org BKCASE is managed and maintained by the Stevens Institute of Technology Systems Engineering Research Center, the International Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Computer Society.)