Last week we discussed What a Model Means to a Systems Engineer. This week we are going to discuss common definitions of the word “model” and how does this knowledge help us as systems engineers.
Merriam-Webster defines a model as:
- a usually small copy of something
- a particular type or version of a product (such as a car or computer)
- a set of ideas and numbers that describe the past, present, or future state of something (such as an economy or a business)
While Dictionary.com defines a model as:
- a standard or example for imitation or comparison
- a representation, generally in miniature, to show the construction or appearance of something
- an image in clay, wax, or the like, to be reproduced in more durable material
Finally, Business Dictionary defines a model as:
“Graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world. The objectives of a model include:
- to facilitate understanding by eliminating unnecessary components
- to aid in decision making by simulating ‘what if’ scenarios
- to explain, control, and predict events on the basis of past observations”
As you can see, there are many definitions of the word model. The following definitions refer to a model as a representation of selected aspects of a domain of interest to the modeler:
- a physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process (DoD 1998)
- a representation of one or more concepts that may be realized in the physical world (Friedenthal, Moore, and Steiner 2009)
- a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system (Bellinger 2004)
- an abstraction of a system, aimed at understanding, communicating, explaining
- designing aspects of interest of that system (Dori 2002)
- a selective representation of some system whose form and content are chosen based on a specific set of concerns; the model is related to the system by an explicit or implicit mapping (Object Management Group 2010)
George Edward Pelham Box believed, that a model represents reality. By only “representing reality” it means that we are simplifying reality as it would take the Universe to model the Universe completely. Box thought, “Essentially, all models are wrong, some models are useful.” By useful, a model must meet the needs of both the developers of the model and their audience.
Looking at these definition we can see that a model is a drawing. But is that what we want as Model-Based Systems Engineers? As MBSE’s we are trying to establish a difference between the classic “documents based” systems engineering and Model-Based Systems Engineering. We want to create models from the information base. You would need roughly 20 factorial drawings to represent all the information combinations (assuming roughly 20 entity classes that are related to themselves and one another), while a model has all that information in a database. So when we discuss the difference between a model and a drawing, we are really looking at a database.
Model-Based Systems Engineering means you need a database of information from which the drawings are automatically generated following the rules of logic and notations associated with the drawing standards. Most tools require the user to “draw” them and allow some reuse of entities. However, using these kinds of tools you can create the same kind of errors you did with a pure drawing tool, like Visio. Real MBSE modeling tools will put the information in the correct format. Think of this like getting your code to compile. It means you have taken care of the static syntax errors.
The next thing your MBSE tool must do is analyze the diagram dynamically. This verification of the logic is like actually running the code. All programmers are familiar with the term “run-time errors.” For MBSE, we use simulators (usually both discrete event and Monte Carlo) to perform the run-time verification of the logic, thus ensuring we don’t build in design errors that aren’t discovered until much later in the lifecycle.
In my article, “Drawings Do Not Equal Models” that’s what I meant by drawings do not equal models (context is everything!).