Modeling embedded systems - Part 3: Where to model - Embedded.com

Modeling embedded systems – Part 3: Where to model

Editor’s Note: In Part 3 of a four-part tutorial on modeling tools, Shelley Gretlein of National Instruments considers the situations when modeling is your best choice in developing an embedded systems design.

Modeling is useful, if not required, in mission- and safety-critical applications, highly complex applications, and large development team projects. But although there are numerous benefits to modeling, you shouldn’t necessarily model every embedded system. Certain simple systems or prototypes don’t require this level of formality. In this part of the series, we will consider situations when prototyping is not an option.

Mission- and safety-critical applications
Software as a percentage of the overall system is growing rapidly in all embedded systems, but particularly in mission-and safety-critical applications. The definition of ‘mission critical’ may vary depending upon whom you talk to, but generally speaking, the term refers to any application whose failure could potentially cost large amounts of money, cause injury, or seriously damage the reputation of a company. For mission- and safety-critical systems, software modeling, combined with best practices in software engineering and formal industry standards such as DO-254B, all combine to facilitate and guarantee safe and reliable embedded systems.

As we see more software content in embedded systems, governments and industry are evolving the required provisions in the overall design process. Typically, these start with formal requirements tracking with documented paper trails, clear correlation of the design requirements to code, and very clear correlation of tests validating each of the design requirements. In the most idealistic sense, we seek a design tool and modeling language that creates correct-by-design solutions or provably correct systems, but in the absence of these theoretically attainable, embedded systems, safety critical especially can derive great benefit from the union of software engineering best practices with software modeling approaches.

Highly-complex applications and systems
Every embedded system report or embedded community survey speaks to the skyrocketing complexity of our designs combined with shrinking timelines.
To highlight the evolution of complexity in embedded design, the list below shows a few facts about different hardware capabilities and software content in different hardware and software systems:

  • Apollo Guidance Computer (AGC) <64 Kilowords, 1.024MHz
  • 1960’s jet fighter ~ 50 thousand lines
  • JSF ~50 million lines
  • F-22 Raptor uses 2.5 million lines while the F-35 uses 5.6 million lines
  • 100 million lines of code in a modern vehicle

Figure 14 – Modern embedded systems have grown exponentially in complexity.

Embedded control systems for the automotive space are good examples of complex and critical designs. Specifically, modern automotive powertrain control systems benefit from modeling techniques as they must continue to evolve to satisfy requirements, including regulating exhaust emissions to meet increasingly stringent standards; providing improved fuel economy to comply with corporate average fuel economy (CAFE) regulations;, and meeting customer demands for performance and comfort. These objectives are interrelated but often conflict. For example, lean-burn technology can reduce fuel consumption significantly, but it also reduces three-way catalytic conversion efficiency, causing additional air pollution. Because of this complexity, modeling is a desirable and efficient way to optimize your design. Using software modeling for automotive designs, you can much more easily understand the impact of the overall design while tweaking the numerous parameters.

When Visteon, an automotive design house in the United Kingdom, had such a challenge, they used software-modeling techniques (Figure 15 ) to simulate multiple variables to validate complex automotive engine designs and achieve the best fuel economy, engine performance, and emissions control.

One project was to design a twin-independent variable camshaft timing engine where both the intake and exhaust camshafts are adjusted independently. The variation is a function of throttle position and engine speed. Because the system offered a large number of degrees of freedom for obtaining engine performance, they needed a method to optimize the valve-timing parameters for the best fuel economy, engine performance, and emission control, while understanding and implementing the highly complex real-time control algorithm that results from this design.

Click on image to enlarge.


Figure 15 – Using NI LabVIEW as a modeling tool, this automotive embedded design engineering team was able to create interactive simulation for modeling their real-time control system.

The embedded engineers chose a real-time control and analysis approach for their design. The purpose was to provide the engine with torque reference tracking while minimizing brake-specific fuel consumption and optimizing combustion stability. They chose to do their modeling and simulation with a graphical system design tool that not only could perform the modeling and simulation, but was also tightly integrated with the real-time hardware they needed for the prototype and deployment of their design.

For the engine model, the main manipulated variables for the control system include mass airflow into the intake manifold, independent camshaft positioning of the inlet, and exhaust/valve timing with respect to the crankshaft. The controlled outputs are the engine torque, brake-specific fuel consumption, and the coefficient of variance of indicated mean effective pressure. Other variables influencing the system, such as engine speed and engine coolant temperature, are treated as external parameters and are used as scheduling variables for control.

Using the graphical modeling software, they were able to ensure that the continuous time engine model combined a static characteristic of the combustion process with differential equations describing actuators and the intake manifold to obtain a dynamic model. The resulting nonlinear engine model (Figure 16 ) with multiple input, multiple output (MIMO) properties was analyzed by manipulating each input variable, and exhibited strong cross-interaction between inputs and outputs. A local model was developed for the control application by linearizing the nonlinear model at fixed operating points.

Click on image to enlarge.


Figure 16 – A screenshot demonstrating the MIMO (multiple input, multiple output) control design approach used in this design.

An advanced optimal controller was designed using the LQR technique. The controller in this design had two objectives – offset minimization and regulator action. These objectives were achieved by introducing integral action within the loop to remove steady-state errors in the presence of disturbances. To define the performance index and to minimize the output error and rate of change in the output, the gain was obtained using the modeling software for the engine-state feedback and reference tracking using the optimal theory of continuous time systems.

As shown in Figure 17 , the local controller and linearized model were also built and simulated in their software. The system tracked the engine torque with an accurate steady state value corresponding to the set point, while simultaneously minimizing brake-specific fuel consumption and the coefficient of variation in indicated mean effective pressure. To ensure online response tuning by visual inspection, the Q and R tuning parameters were made available on the front panel, which optimized the interactive simulation capabilities of the embedded application.

The embedded engineers chose to implement the structure of the model and controller in discrete time so it could easily be transferred to computer hardware for final implementation. The discrete controller can either be derived from the designed continuous controller or designed directly in discrete time using the same LQR application.

Click on image to enlarge.


Figure 17 – Many control design and simulation software tools are designed for linear and nonlinear systems.

Since their model was nonlinear, the optimal gain parameters that produce the desired response at one operating point might not produce a satisfactory response at another operating point. Therefore, gain scheduling can be applied using different sets of optimal gain parameters for different regions of operation of the nonlinear model. The process of gain tuning was streamlined using interactive adjustment of parameters through the graphical user interface.

This automotive example demonstrates how valuable modeling and simulation can be in an embedded application with many different design parameters. Without these powerful software tools, this design could have easily taken twice as long to design and may never have resulted in such an optimal design.
Operational complexity
Complexity can also be operational, asin the case of Agworks, Inc (Ontario, Canada). They needed to develop anembedded control system capable of automating a large soybeanprocessing plant with multiple concurrent processes and provide asoftware architecture that was both scalable and maintainable.

Developingand integrating a state-based application with so many concurrentprocesses presented a unique challenge. Because much of their equipmentis not directly viewable, developers had to rely on development tools toaid in the integration and debugging of the code.

A statechart implementation (Figure 18 )was ideal for this application. During the design phase, theabstraction provided by the NI LabVIEW Statechart Module made it mucheasier to visualize how all the separate processes would work together.The self-documenting nature of statechart diagrams also saved valuabletime during the design phase of the project.

Click on image to enlarge.


Figure 18 – The abstractionthat the statechart software provided made it much easier to visualizehow the complex network of systems would work together.

Asdevelopment progressed, extensive use of the statechart tool helpedkeep the code organized and readable. When integration began, theutility for debugging the statecharts was crucial. With highlightexecution enabled, the developers were able to monitor many concurrentprocesses closely. They could tell exactly when a transition wastriggered and exactly which state it went into. This saved a great dealof time during the debugging process.

After several months ofoperation, Agworks needed some additional features. The upfront softwaredesign, modeling, and documentation made a complex application mucheasier to understand and much faster to learn.

The statechartdiagrams provided a clear overall picture of the embedded system. Notonly was it clear, but the statechart in this complex situation was alsoeffective in explaining the architecture and self-documenting,demonstrated by the fact that the new developer on the Agworks team wasable to get up to speed quickly with this large project and edit theapplication, adding capabilities to satisfy the customer’s request.

Forthese types of complex applications, using the right software tool andmodeling approach can be beneficial in every step of the developmentlife cycle, and continue to benefit you and your customers throughoutthe lifecycle of the product.

Cost of defect versus when detected

Ensuringyou employ proper modeling and simulation techniques isn’t just aboutgetting a better design; it is also about cost savings and getting itright sooner. After an analysis of more than 60 software developmentprojects(http://www.irma-international.org/proceeding-paper/gathering-user-needs/32282/) at companies such as IBM, GTE, and TRW, we can clearly see the costof finding a problem early in the process is far less expensive (Figure 19 ).

Click on image to enlarge.


Figure 19 – The cost of a defect is significantly impacted by when the defect is found.

Modelingcombined with software engineering best practices will help addressmost if not all of the common pitfalls in poor embedded system designprogramming.
Figure 20 is a simple way of viewing the softwareengineering process. It reflects what is typically referred to as thewaterfall method of development. While great in principle, most softwareengineers accept that the waterfall method is impractical and thatreality requires significant overlap between these various phases. Inother words, it’s almost impossible to avoid changes to requirementslater in development.

The key is to have tools and practices tomitigate the risks caused by these last minute changes and to understandhow these changes will impact other aspects of your application. Youcan apply software engineering and modeling techniques throughout thisdevelopment.

Figure20 – The software engineering process is independent of programminglanugage but can be applied throughout your embedded design practices.

Large development teams require modeling
Eventhough the modern trend is to create small, agile development teams, weknow that certain complex embedded projects require larger teams. Largeteams suffer from a few critical challenges, such as communicationchallenges, geographic and language distribution, and tool differences.Modeling can help address some of these issues.

First, andperhaps the most impactful, modeling can facilitate clear communicationamong different teams on one embedded project. Project requirements canonly look to serve as a project calibration device to a point, and thenthe engineers must get into the actual application. If the team candesign a useful system model, it is a dynamic, accurate representationof the project that can ease cross-team communication.

Related,this type of project communication can easily span multiple speakinglanguages as well as geographic locations. Instead of relying on eitherwritten documentation that would need to be translated, an embeddedmodel can be the consistent ‘voice’ of the project. While physicalprototypes are capable of demonstrating the concepts and goals of aproject, they are limited to being in a single geography.

Whenyou have a large team you are also bound to have developers withdiffering tool preferences. This means you need to keep your model insoftware that can be shared between tools – something open and viewableby anyone on the team.
Just employing modeling doesn’t solve largedevelopment team issues, you still must develop readable (and thereforemaintainable) code, document your code, employ source code control andchange management, utilize unit testing, and get as much standardizationand code reuse as possible.

Part 1: Why model?
Part 2: Modeling examples

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.

Thisarticle is based on material by Shelley Gretlein written for inclusionin “Software Engineering for embedded systems,” edited by Robert Oshanaand Mark Kraeling, to be published early in 2013 by Morgan Kaufmann, adivision of Elsevier, Copyright 2013. For more information about“Software engineering for embedded systems” and other similar books,visit www.elsevierdirect.com.

Leave a Reply

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