Shortening the Embedded Design Cycle with Model-Based Design

Publish Date: Oct 22, 2012 | 34 Ratings | 4.24 out of 5 |  PDF

Overview

Today's control engineers face ever-increasing challenges in the design of embedded systems. First, there are the traditional competitive expectations of delivering products to market faster and at lower cost. It is well documented that delivering a product to market ahead of all competitors typically results in a decided advantage. In most cases, the embedded control system is a single part of a much larger system, such as flight controllers for today’s modern aircraft. For these systems, it is imperative to deliver the production control system on schedule to prevent delaying overall project development.

Second, today’s control engineers are required to deliver implementations for increasingly complex systems. A simple motor controller in a modern white goods appliance now has several speeds and modes. A FADEC (full authority digital engine control) system in a jet aircraft includes a hybrid control strategy to reduce emissions and fuel consumption in addition to traditional control systems. At the same time, product quality continues to be a major issue. These innovative control systems, while increasing product performance, often increase the risk of poor product reliability, requiring control developers to deliver accuracy and robustness that meet exacting standards. All of these challenges must be met or exceeded with fewer system prototypes while maintaining enough flexibility to adapt to any last-minute requirement changes.

Using traditional control development methods, design took place early in the development process, but test and implementation of the embedded control systems had to wait until late in the process. This delay was tied to the availability of production prototypes for testing the behavior of the control software, a critical step in revealing errors in the embedded software behavior. Because the initial integration of hardware and software took place so late in the development cycle, the discovery of errors often resulted in production delays, as well as additional expense in code updates and verification tests.

Control engineers today are addressing these challenges with the help of sophisticated tools and new development techniques. For instance, model-based control design software, such as National Instruments MATRIXx, and real-time hardware are now used throughout the design cycle for system characterization, simulation, and prototyping, moving test and implementation earlier in the development cycle, so control engineers can identify problems early and reduce risk. These model-based design tools feature built-in mathematical functions and routines optimized for designing and analyzing control strategies through off-line simulation. In addition, these tools can be easily coupled with real-time hardware, supplementing traditional off-line simulation with real-world testing. This can aid in the elimination of errors early in the design, resulting in a more robust control system, fewer iterations in the development cycle, and reduced development time and cost.

Table of Contents

  1. Model-Based Design Process
  2. System Definition
  3. Modeling and Simulation
  4. Rapid Control Prototyping
  5. Targeting
  6. Hardware in the Loop
  7. Functional Test
  8. Summary

1. Model-Based Design Process

Figure 1 illustrates the embedded control “V Diagram” often used to describe the development cycle. 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 this 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 targeting code to individual processors. 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 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. This process suffers from a variety of drawbacks, including the difficulty of keeping documentation updated. Another is that the coding process is often completely removed from the general design process. These are two instances where model-based design can greatly improve the design process.

We will now step through each of the steps in the design process and examine how model-based design improves the outcome of each step. In this discussion we will use as an example the design of a FADEC for a jet engine. A FADEC controls the power plant, providing it with the correct fuel, air, and ignition ratios required for optimum performance with minimum fuel expenditure. Although we are using an aerospace example in this discussion, these steps easily can be applied to a wider range of industries.

Back to Top

2. System Definition


The System Definition phase begins with analysis and documentation of the requirements of the system; overall system architecture design is performed and behavior specifications are made. Here you specify the particular controller hardware that is to be used and the overall system functionality. In the FADEC example, the control system will be tasked with monitoring turbine temperatures, compressor pressures, stage rpm, throttle position, and in turn controlling the injection of fuel and speeds of each of the compressor and turbine stages. Requirements such as how fast the engine should run and the levels of emissions considered satisfactory also would be specified.

This process, traditionally, has been accomplished using paper-based methods, a system that often results in poor communication of requirements through the design process, errors in design, and limited traceability between the design and requirements. Using a software-based system model in the design process, an engineer can create a testable prototype without the need for hardware, which provides a documented method for verifying and validating the design against requirements prior to moving to developing the actual controller and hardware. A software model also provides a platform that can be iterated quickly during the transition from requirements to design stages; important given that requirements are not always fully known prior to the beginning of design. Shorter iterations earlier in the design process always result in reduced cost and time.

Back to Top

3. Modeling and Simulation


A key component of shrinking the “V” through model-based design is to begin developing the embedded control as early in the design cycle as possible. Modeling and simulation, using the MATRIXx SystemBuild graphical environment (Figure 2) for example, provides the ability to begin simulating control behavior while hardware prototypes are still unavailable. In addition, models from previous designs may be reused to further reduce the effort necessary to produce a model. If prototype or existing hardware is available, the modeling effort may be complemented by using real-world input/output data to produce models with system identification techniques.




MATRIXx SystemBuild offers a variety of advanced control design tools in an interactive environment that helps the designer quickly evaluate a control system without the need for prototype hardware. This capability provides the design engineer with the ability to determine specification, requirements, and modeling errors immediately instead of waiting for testing later in the design flow.

Back to Top

4. Rapid Control Prototyping


With model-based design software packages, you can design the control algorithm and perform off-line simulation on the desktop. However, software simulations cannot account for all of the unique behaviors of an actual dynamic environment. This is why a hardware prototype is often developed to aid in the testing of the control algorithm in real-time.




These hardware prototype platforms, composed primarily of commercial off-the-shelf components configured to meet the I/O specifications of the system, provide a quick, seamless way to connect the control model with real-world I/O, making it easier to test and iterate the design. As shown in Figure 3, the controller design is tested in a real-time environment and connected to actual engine hardware. This provides excellent verification and validation feedback on the fidelity of the modeling effort and the resulting control design early in the design flow. Further refinements to the controller and hardware designs and requirements can be made prior to finishing the design of the production systems.

Back to Top

5. Targeting


After validation of the control design from the previous two stages, the production code is deployed on the final target hardware. Traditionally, this was a time-consuming task because control modeling tools are designed to provide a very high-level block diagram representation as opposed to production-ready source code for use on a target. Therefore, the target code generation step required the passing of the design from the control engineer to the embedded programmer, usually in the form of a prepared software specification based on the original graphical system design effort.




This process was error-prone, time-consuming, and difficult to test until late in the design cycle. Modern model-based design tools, such as MATRIXx, provide tools to automatically generate both prototype and production code directly from the control design models. The design model serves as the specification and design for the generated code, so all design changes automatically flow through to final implementation. This process results in significant time and cost savings due to the inherent reproducibility and testability of the generated code and the elimination of communication errors.

Back to Top

6. Hardware in the Loop


In hardware-in-the-loop (HIL) testing, the designer can simulate real-time behavior and characteristics of the final system to verify the production system controller without the need for the physical hardware or operational environment. As seen in Figure 5, the control code is running on the target controller hardware while the engine is simulated in real-time on a test computer.




During this testing phase, it is important to test the complete functionality of the controller. While you can connect the target hardware with the actual engine, testing against a simulated engine offers several advantages. A desktop simulator, often call a hardware-in-the-loop (HIL) tester, is far more cost-efficient, and easier to reproduce, than a physical plant. The simulated engine also can simulate a variety of operating conditions or even fault conditions, such as engine stall, that would be difficult, costly, and/or dangerous with the actual plant.

Back to Top

7. Functional Test


Finally, when all the individual components and subsystems have been tested and validated, they are combined and tested together to ensure that the original design requirements are met. In some cases, parameters in the engine controller are finely tuned during this phase to meet original design requirements. One of the drawbacks to this step is that testing can be an expensive and time-consuming process, often requiring specialized equipment or facilities. In addition, because it is the last step of the design process, testing schedules and funds are often cut to account for delays and expenditures encountered earlier in the process.

Although the model-based design process does not completely eliminate the need for testing, it offers several opportunities to reduce the amount of test that will be required prior to the release of the production system. Additionally, model-based design technology is currently evolving to aid in automating the final testing process. Early tool-providers in this space automatically generate test vectors and execute scripted sequences to verify both models and automatically generated code. Soon, these capabilities will extend to physical tests, scripting test sequences, including real-world I/O connections, needed to verify all behaviors of the control system.

Back to Top

8. Summary


Model-based control design provides a time and cost-effective approach to development of simple or incredibly complex dynamic control systems, all based on a single plant model maintained in a tightly integrated software suite. Using block-diagram-based modeling tools such as MATRIXx/SystemBuild, you can design and perform initial validation in off-line simulation. These models then form the basis for all subsequent development stages.

Model-based design provides numerous advantages over the traditional design approach. Using the model-based approach, you reduce the risk of mistakes and shorten the development cycle by performing verification and validation testing throughout the development instead of only during the final testing stage. Design evaluations and predictions can be made much more quickly and reliably with a system model as a basis. This iterative approach results in improved designs, both in terms of performance and reliability. The cost of resources is reduced, because of reusability of models between design teams, design stages, and various projects and the reduced dependency on physical prototypes. Development errors and overhead can be reduced through the use of automatic code generation techniques. These advantages translate to more accurate and robust control designs, shorter time to market, and reduced design cost.

Back to Top

Bookmark & Share

Ratings

Rate this document

Answered Your Question?
Yes No

Submit