The second trap has to do with what constitutes a model. As we say on page 65 of Vitech’s Primer for Systems Engineering, “There are major advantages arising from using models as the basis of systems engineering. Models thoroughly consider the entire engineering problem, use a consistent language to describe the problem and the solution, produce a coherently designed solution, and comprehensively and verifiably answer all of the system requirements posed by the problem. These traits of model-based systems engineering are significant advantages when seeking a solution to the systems design problem at hand.”
The trick comes in understanding models. To be a model in the sense meant by MBSE, there must be a consistent language with which to describe the system being modeled, a structure which allows the model to capture the behavior of the system, a logical presentation of the “argument” (that “makes the case”) that the solution being modeled is in fact an effective and efficient solution to the problem and a way of presenting the argument through a series of views of the model.
It is tempting to think of a set of views as a “model” of the design. If we have a “complete” set of views don’t we have a model?
A view is a presentation of a subset of the information in the model. It can be thought of as a structured response to a query of the model in which information about the model (e.g. “Show me the process flow”) is returned in a particular way (e.g.- as an activity diagram). Even a set of views cannot become a model because it cannot capture the information in a logical and executable architecture. The views are a presentation of an underlying model but they do not become the model itself.
Using the language of the model, we capture the requirements, the behaviors and the physical components in one database. Instead of a set of representations or a requirements model, a logical model and a physical model, we need a unified model in a single database where we can test the execution of the logical architecture by the physical architecture against the requirements. Vitech’s CORE ® actually accomplishes this purpose by uniting rather than separating the models.
Other tools will claim to “work together” in concert to represent the different models of a system design. But CORE® has power at a whole new level beyond providing a way of cobbling together single domain models (requirements, behavior, components) to instantiate incompleteness (e.g. no logical architecture) or inefficiencies (e.g. representations posing as models). CORE® covers all of the domains in a way that communicates in real time and assures integrity and completeness. This unleashes the true power of models and MBSE.
As a true model, the CORE® model uses its language, structure, argument and presentations to embody a complete picture of the requirements, logical architecture and physical architecture of the systems design solution. It also provides an integrated simulation environment in which to verify and validate the design back against the requirements.
