Modeling embedded designs - Part 2: Modeling method examples - Embedded.com

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.

Figure 5: There are several key aspects of modeling languages to evaluate

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.

Figure 6: Documentation of a PID control algorithm

Figure 7: C code: textual, execution, implementation language

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.

Figure 8: Statechart: graphical, architectural and implementation

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.

Figure 9: Time-based simulation: graphical, implementation, simulation tool

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.
Dataflow modeling (Figures 10 and 11 ) spans implementationsimulations and execution implementations. Most dataflow languages arevisual (typically graphical) and also do an inherently good job atexpressing the architecture of your design – certainly more than atraditional text-based modeling software package.

Figure 10: Dataflow: graphical, architectural and implementation software


Figure 11: A zoomed out view of the same dataflow diagram in Figure 10

Whendelving into the simulation-oriented models as applied to a typicalembedded control application, it’s interesting to note key touch pointsin a particular implementation. These points often serve as usefullocations to define abstractions such that any one part of the systemcan be swapped in and out between a simulated system element and realsystem element.

Figure 12 shows a typical embeddedcontrol system pattern in which there is some notion of a plant – realor simulated, a controller- real or simulated, and a supervisory controlsystem which can also be real or simulated.

Between each ofthese main system elements, you can identify critical communicationpaths (network and I/O) as key points to abstract within a design. Thediscipline to do this well (documented, consistently) allows you toswitch between the real and simulated components as you refine yourdesign.

Figure 12: A typical embedded control system pattern

The V-diagram promise
Notall modeling languages are executable, and for those that are, theiruse doesn't necessarily mean that programming is no longer required. Onthe contrary, executable modeling languages are intended to amplify theproductivity of skilled programmers so they can address challengingproblems such as distributed systems and parallel computing.

Somemodeling languages combine a high-level architectural model with areasonable amounts of expressiveness, and also easily map to animplementation. State charts, specifically finite state machines,combine these characteristics well. The ideal modeling language wouldclearly express architectural aspects of code, be as expressive as fullyopen programming languages, and map simply to execution.

Let’s look at a common visual in the embedded space, Figure 13 ,which illustrates the embedded control “V Diagram”, often used todescribe an embedded modeling development cycle. The V was originallydeveloped to encapsulate the design process of many different softwareapplications. Several versions of this diagram can be found to describe avariety of product design cycles. Here we have shown one example ofsuch a diagram representing the design cycle of embedded controlapplications common to automotive, aerospace, and defense applications.

Figure 13: The 'V' diagram

Inthe V diagram, the general progression of the development stages intime is shown from left to right. Note, however, that this is often aniterative process and the actual development will not proceed linearlythrough these steps. The goal of rapid development is to make this cycleas efficient as possible by minimizing the iterations required for adesign. If the x-axis of the diagram is thought of as time, the goal isto narrow the V as much as possible by drawing the two legs of thediagram closer, thereby reducing development time. The y-axis of thisdiagram can be thought of as the level at which the system componentsare considered.

Early in development, overall systemrequirements must be considered. As the system is divided intosubsystems and components, we find very low-level processes, down to thepoint of mapping implementation to hardware architectures.

Afterwardscomponents are integrated and tested together until such time that theentire system can enter final production testing. Therefore the top ofthe diagram represents the high-level system view and the bottom of thediagram represents a very low-level implementation and mapping view.

Traditionally,engineers involved with each stage of the process have observed strictboundaries between the specification, design, coding, and testingactivities, relying on design documents to provide the communicationbetween each of the steps. The tools within the overall flow of the Vdid not directly facilitate sharing, leading to large discontinuities intooling and in design and test re-use and overall team collaboration.

Overcoming the V diagram curse
TheV diagram process described suffers from a variety of drawbacks,including the difficulty of keeping documentation updated because mostorganizations do not have the discipline and/or tooling to synchronizedocumentation with design and implementation as both are refined.Similar to documentation ‘drift’, there is also often drift between thedesign intent and actual implementation.

A well-integratedmodeling approach can greatly reduce the drift between the systemdocumentation, design, tests, and actual implementation.

Modelingreduces this drift by requiring the design, test, and implementationteams to design a model of the expected end system before it isbuilt. This basic premise forces a key distinguishing discipline that isoften skipped by design teams in all domains.

The model is thusused to vet early design considerations, elaborate system requirements,and facilitate early development of tests that run against the nascentmodel. Most of these benefits could be derived through carefully managedorganizational discipline without a modeling software approach, butpractice has proven that few teams have the discipline to use amodel-centric view and or the tooling that facilitates it.

In addition to the key benefits listed above, modeling approaches lead directly to additional efficiency and accuracy gains.

Efficiencycan be defined as efficiency of time and/or efficiency in terms ofcost. As you will see in the ‘cost of getting it wrong’ table, it isundeniably more cost- and time-efficient to find design issues early inyour embedded design cycle. Modeling, using the right techniques and theright tools, will help teams find issues early.
Modeling oftensaves further development time by reducing the number of compiles anditerations on the final embedded target, since more time can be spentworking through issues at the top of the V rather than in finaldeployment to hardware. For example, if you’re designing an FPGA-basedembedded application, the synthesis and deployment can take hours ordays per iteration depending on the complexity of your design. Bymodeling the system properly ahead of time, you directly reduce therequired number of design/debug iterations saving development time.

Modelingoften results in a more accurate and more precise solution byincreasing the rate of iterating on different design options. Byreducing the cycle time of tweaking the algorithm, teams are far morelikely to experiment with many different combinations of inputs,outputs, and algorithm combinations. Another way that your system can bemore accurate is the built-in commonality it provides between thedesign and test teams in your organization.

By designing a modelof your embedded system, you have created a common tool the embeddeddesigners can use to optimize the design and then the test team can turnaround and use to validate the design during testing. The model isversatile and applicable to both teams – often enabling the convergenceof design and test as expressed in the central idea of the V diagram.

Inthe rest of this series, we will discuss how designing your embeddedsystem with well-defined structure, clear visualization of relationshipsbetween components, with well-defined abstractions, enables productiveand efficient embedded designs.

Part 1: Why model?
Part 3: Where to model?
Part 4: If prototypes aren't possible

Shelley Gretlein is the Director of Software Product Marketing at NationalInstruments. Currently focused on growing the application and success ofgraphical system design globally, Gretlein is responsible for thedevelopment strategy and worldwide evangelism of the LabVIEW softwareplatform including LabVIEW Real-Time and LabVIEW FPGA. She joinedNational Instruments in 2000 and holds a bachelor’s degree in computerscience and management systems as well as minors in Mathematics andFrench from the Missouri University of Science and Technology.

This article is based on material by Shelley Gretlein written for inclusion in “Software Engineering for embedded systems,” edited by Robert Oshana, to be published early in 2013 by MorganKaufmann, a division of Elsevier, Copyright 2013. Used by permission. 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.