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.
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.
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.
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.
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.
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.
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.
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.