Modeling embedded designs - Part 2: Modeling method examples

Shelley Gretlein, National Instruments

November 8, 2012

Shelley Gretlein, National Instruments

Dataflow modeling (Figures 10 and 11) spans implementation simulations and execution implementations. Most dataflow languages are visual (typically graphical) and also do an inherently good job at expressing the architecture of your design – certainly more than a traditional text-based modeling software package.




When delving into the simulation-oriented models as applied to a typical embedded control application, it’s interesting to note key touch points in a particular implementation. These points often serve as useful locations to define abstractions such that any one part of the system can be swapped in and out between a simulated system element and real system element.

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

Between each of these main system elements, you can identify critical communication paths (network and I/O) as key points to abstract within a design. The discipline to do this well (documented, consistently) allows you to switch between the real and simulated components as you refine your design.



The V-diagram promise
Not all modeling languages are executable, and for those that are, their use doesn't necessarily mean that programming is no longer required. On the contrary, executable modeling languages are intended to amplify the productivity of skilled programmers so they can address challenging problems such as distributed systems and parallel computing.

Some modeling languages combine a high-level architectural model with a reasonable amounts of expressiveness, and also easily map to an implementation. State charts, specifically finite state machines, combine these characteristics well. The ideal modeling language would clearly express architectural aspects of code, be as expressive as fully open 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 to describe an embedded modeling development cycle. The V was originally developed to encapsulate the design process of many different software applications. Several versions of this diagram can be found to describe a variety of product design cycles. Here we have shown one example of such a diagram representing the design cycle of embedded control applications common to automotive, aerospace, and defense applications.



In the V diagram, the general progression of the development stages in time is shown from left to right. Note, however, that this is often an iterative process and the actual development will not proceed linearly through these steps. The goal of rapid development is to make this cycle as efficient as possible by minimizing the iterations required for a design. If the x-axis of the diagram is thought of as time, the goal is to narrow the V as much as possible by drawing the two legs of the diagram closer, thereby reducing development time. The y-axis of this diagram can be thought of as the level at which the system components are considered.

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

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

Traditionally, engineers involved with each stage of the process have observed strict boundaries between the specification, design, coding, and testing activities, relying on design documents to provide the communication between each of the steps. The tools within the overall flow of the V did not directly facilitate sharing, leading to large discontinuities in tooling and in design and test re-use and overall team collaboration.

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

A well-integrated modeling approach can greatly reduce the drift between the system documentation, design, tests, and actual implementation.

Modeling reduces this drift by requiring the design, test, and implementation teams to design a model of the expected end system before it is built. This basic premise forces a key distinguishing discipline that is often skipped by design teams in all domains.

The model is thus used to vet early design considerations, elaborate system requirements, and facilitate early development of tests that run against the nascent model. Most of these benefits could be derived through carefully managed organizational discipline without a modeling software approach, but practice has proven that few teams have the discipline to use a model-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.

Efficiency can be defined as efficiency of time and/or efficiency in terms of cost. As you will see in the ‘cost of getting it wrong’ table, it is undeniably more cost- and time-efficient to find design issues early in your embedded design cycle. Modeling, using the right techniques and the right tools, will help teams find issues early.
Modeling often saves further development time by reducing the number of compiles and iterations on the final embedded target, since more time can be spent working through issues at the top of the V rather than in final deployment to hardware. For example, if you’re designing an FPGA-based embedded application, the synthesis and deployment can take hours or days per iteration depending on the complexity of your design. By modeling the system properly ahead of time, you directly reduce the required number of design/debug iterations saving development time.

Modeling often results in a more accurate and more precise solution by increasing the rate of iterating on different design options. By reducing the cycle time of tweaking the algorithm, teams are far more likely to experiment with many different combinations of inputs, outputs, and algorithm combinations. Another way that your system can be more accurate is the built-in commonality it provides between the design and test teams in your organization.

By designing a model of your embedded system, you have created a common tool the embedded designers can use to optimize the design and then the test team can turn around and use to validate the design during testing. The model is versatile and applicable to both teams – often enabling the convergence of design and test as expressed in the central idea of the V diagram.

In the rest of this series, we will discuss how designing your embedded system with well-defined structure, clear visualization of relationships between components, with well-defined abstractions, enables productive and 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 National Instruments. Currently focused on growing the application and success of graphical system design globally, Gretlein is responsible for the development strategy and worldwide evangelism of the LabVIEW software platform including LabVIEW Real-Time and LabVIEW FPGA. She joined National Instruments in 2000 and holds a bachelor’s degree in computer science and management systems as well as minors in Mathematics and French 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 Morgan Kaufmann, a division of Elsevier, Copyright 2013. Used by permission.