Modeling embedded designs - Part 2: Modeling method examples
Editor’s Note: In Part 2 of a four-part tutorial on modeling tools, Shelley Gretlein of National Instruments reviews the various modeling methods available to the embedded developer and compares their strengths and weaknesses.
Modeling languages, like programming languages, are well-defined and standard language grammars used to express structural and functional actors and their key relationships over time. Different forms of modeling languages have evolved over time for specific domains. When evaluating modeling languages, it is important to keep in mind the specific domain for which the language is best suited.
The University of California at Berkeley created the term 'Model of Computation' to define Domain Specific Modeling Languages. The critical notion is that modeling languages provide the most productivity benefit to a designer when they cater specifically to a given problem domain. This is both intuitive and true from observed practice, but as we know, designers and modelers, like programmers, can have a healthy bias for their individual language preferences even when ill-suited for the actual task at hand.
Modeling languages take many forms and are either graphical or textual:
Graphical modeling languages use a diagram technique, with named symbols representing concepts, lines connecting the symbols to represent relationships, and various other graphical notations to represent constraints.
Textual modeling languages use standardized keywords accompanied by parameters to make computer-interpretable expressions
There are several key aspects of modeling languages to evaluate: graphical versus textual; documentation, simulation, or execution oriented; and whether they are focused on architectural-level or implementation-level content. Figure 5 captures these dimensions and overlays several standard modeling techniques and approaches.
Moving out of the abstract view of modeling, we can see what it looks like in practice with a few different software approaches. Below in Figures 6 through Figure 11, we use a PID (proportional-integral-derivative) control algorithm (a common algorithm used in control applications based on a generic feedback loop) to help you see a documentation lens as well as the varied visuals and implementation capabilities. As you scan these code snippets, note the value and differences in creating abstraction boundaries – some are clear, some are non-existent.
The standard implementation languages of C, C# and hundreds of other programming languages (Figures 6 and 7) fit in the implementation and execution-oriented cell represented in Figure 5 above.
Among the more prominent hybrid or dual-purpose models are state charts (Figure 8) and their more prohibitive sibling Finite State Machines (FSMs.) These modeling languages are useful in capturing higher-level architectural views. They are able to run in simulation with a high-fidelity, natural mapping to native execution, or the ability to easily map the language to the compiler/execution engine.
Models like time-based simulation (Figure 9) can specify algorithmic simulation, but then require a code-generation step into one of the execution-dominant programming languages like C, VHDL, or G.
The quality of the code generation, the naturalness with which the model can map to execution, and the breadth of expressiveness of the model all dictate the quality of the simulation-based approach.