For the past 5 months, I have worked on this blog without giving a definition of Model-Based Design and while the definitions of Model-Based Design vary there are a few common concepts. (Note: for this blog post I will only be considering graphical modeling languages such as Simulink. It is possible to follow a Model-Based Design approach using textutal languages however there are additional burdens in doing so)
One truth – many uses
Core to all Model-Based Design workflows is the concept of a “model object” which is used in multiple phases of the design process. That model object, or collection of objects, is elaborated during the design process, e.g. transforming an initial “shell” model into a fully elaborated model at the deployment phase. Then using the deployment phase version of the model during the validation phases.
By maintaining a “one truth – many uses” model the number of handoff between people and roles is reduced thereby minimizing the introduction of errors.
Model represents reality
The aspect of understanding comes in for complex systems where it is difficult, or even impossible to understand how the system will react to a given input. (Note: “complex” is a relative term, even a “simple” dual pendulum is not easy to visualize.)
Finally, the goal of MBD is to abstract implementation from design details. Modeling languages represent aggregate concepts into representative blocks. By removing the implementation details engineers can focus on functionality and safety while software architects can system level composition.
This short introduction, by its very nature, cannot go into detail of how Model-Based Design is applied. However, my hope is that by keeping the three key ideas of MBD, “one truth, many uses”, “model represents reality” and “abstraction” you will have a better understanding of Model-Based Design.