Over the past few years, use of block-diagram-based tools has become the preferred method for modeling and simulating complex dynamic systems. These tools provide the graphics for simulation and model-based design that facilitate rapid model construction, execution, and analysis of simulation results. Models developed with these tools have clean, well-defined interfaces for use in multiple aspects of the system design process.
As a result of advances in automated code-generation technology, another application of these models has become viable: They can serve as input to an automatic embedded code-generation process. The code generated by these models is efficient, can be read and tested, and is suitable for safety-critical applications.
PROVEN APPROACH Model-based design is a proven approach for the efficient development of solutions to complex engineering problems. It is a method for devising complicated systems using mathematical models of system components and their interactions with the environment. These models have many applications in the design process, including system simulation, stability analysis, and control algorithm design, plus as a specification for embedded controller software.Off-the-shelf software tools for model-based design, such as Simulink, support the specification, design, and validation of high-fidelity plant models for a range of system design applications. The resulting models can be as detailed as necessary—assuming that sufficient information is available to support the construction and validation of the model. One important application for high-fidelity plant models is system simulation.
Having made a high-fidelity plant model, the next step is to develop a model of the control system and integrate it into system simulation. By working with a system-level simulation that combines the plant and controller, it is possible to test the control-system design thoroughly and make changes and improvements quickly.
FINAL SOFTWARE After the controller design is optimised and validated in the simulation environment, the next challenge for embedded-system designers is to develop the final software for production. This task usually means the recoding of the controller from its simulation implementation to meet the different requirements of production embedded software. This recoding often results in new coding errors that must be identified and debugged.Now, if model-based design is used alongside advances in automatic code-generation technology, it is easy to use the embedded-controller simulation model as the basis for final production code. This is because the model of the embedded software's behaviour contains all of the information needed to fully describe the embedded code.
However, the control system's simulation model may need other adaptations to the embedded execution environment before it can be used as a complete source for the embedded code. Possible changes include:
- Conversion to discrete-time. It is normally simplest to model dynamic system components through continuous-time elements, whereas embedded code-generation design is implemented as a discrete-time system. This step necessitates continuous-time blocks being converted to equivalent discrete-time blocks in the controller model
- Conversion from floating-point to fixed-point mathematics. Typically, simulation models use double-precision floating-point representation. In embedded software, signals are often represented as fixed-point integer values to conserve memory and increase execution speed. Converting a floating-point signal to fixed-point involves choosing an integer word size and a scale factor to represent the signal value as a fixed-point integer
- Addition of I/O interfaces. The model of the control system must be modified to include I/O interfaces at each point where a signal passes between the controller software and an external device. These blocks represent the interaction of the controller algorithms with a device driver.
After completing some or all of the design modifications described above, as necessary, the control system model is ready for use in the code-generation process. Source code can be automatically generated from the block diagrams for use on target processor hardware.
EXECUTION AND TESTING The correct way to change the generated code is to modify the model or change the code-generation options. The goal of using model-based design is to gain the benefits of the block-diagram modeling environment when developing embedded software. In many cases, the automatically generated C code can be treated as an intermediate language used in the compilation process and essentially ignored. For some safety and mission-critical embedded applications, however, the developer must closely examine and test the generated C source.Figure 1 outlines a typical application. It is a top-level diagram showing a model of a helicopter (the plant) and a control system that operates the helicopter. The plant model is a six-degree-of-freedom (6DOF) representation of the helicopter's dynamic behaviour. The controller maintains the stability of the helicopter and flies it along a trajectory that takes it to a series of positions in space.
The three blocks in Figure 1 are the controller, the helicopter plant model, and a display showing information about the plant's behaviour during simulation execution. The controller and helicopter blocks are library blocks, that is, they're stored in a model library. Using library blocks in model development allows system components to be shared among simulations and provides updates to the models to propagate immediately to all simulations using them.
Figure 2 is an example of one of the lower-level blocks within the controller model. This is the position control subsystem that guides the helicopter by developing tilt commands for the main rotor. It employs a proportional-derivative (PD) control algorithm, using relative position and the helicopter's velocity as inputs, and produces pitch-and-roll rotor tilt commands as outputs.
The helicopter controller design uses a controller area network (CAN) serial data bus for all communications between the embedded microprocessor and the sensors and actuators in the helicopter control system. The processor selected for this application is the Motorola MPC555, which is based on the PowerPC architecture.
AUTOMATIC CODE The controller block in Figure 1 represents the embedded software for this system. The controller model, which has been modified for discrete-time operation, will make use of the MPC555's floating-point processing hardware. The first step in the code-generation process is to create a new model containing the controller block and appropriate I/O blocks to interface with each of its input and output signals.Figure 3 shows the model of the controller, together with subsystems containing the CAN I/O interfaces.
The remaining subsystem in this diagram, labeled MPC555 Resource Configuration, is needed by the MPC555 embedded target for configuring system and I/O attributes, which can include interrupt request (IRQ) levels and CAN interface bit rates.
Note that the controller block in Figure 3 is identical to the controller block in Figure 1. If a design problem is detected during testing, the controller can be changed in the diagram of Figure 3. The change will propagate to the simulation of Figure 1 for further analysis and testing.
The control system of Figure 3 is configured to operate in discrete-time with a step time of 0.01 seconds. At each time step, the model reads input signals through the CAN receive block, performs the computations contained in the controller block, and transmits output signals via the CAN send block.
The complete set of generated code for this embedded application consists of two .cfiles and four .hfiles containing a total of 1850 lines of code and comments.
The code-generation process also produces an HTML report summarising the attributes (such as RAM and ROM usage) of the generated code.
HARDWARE-IN-THE-LOOP It is necessary to either place the target processor into an actual embedded system or connect it to a simulated plant to test the automatically generated embedded code. Early in the system development process, a physical representation of the plant may be unavailable, or it may not be a good idea to test early versions of embedded software on an expensive one-of-a-kind system prototype.An alternative to executing on the actual plant is to test the embedded controller on a simulated plant. The simulated plant executes in real-time and must interface to the embedded processor using the interfaces over which the processor expects to communicate.
This is called hardware-in-the-loop (HIL) simulation, where the embedded processor hardware and the embedded software execute in real-time in the context of a larger system simulation.
A model built around the helicopter block from Figure 1 is needed to create an HIL simulation for this application. This model is similar to the one in Figure 3, except that it runs on a target processor which is different from the embedded processor.
A target suitable for this application is xPC Target, which uses an ordinary PC as a real-time execution platform—xPC Target loads a small real-time kernel that supports the execution of compiled Simulink models.
COMPLETE CONFIGURATION The helicopter plant model for HIL simulation is shown in Figure 4. This model contains CAN interfaces that communicate with the embedded controller inputs and outputs shown in Figure 3. The block named displays passes data to the host PC for display during execution. In addition, selected signals are displayed on the monitor of the relevant PC by the Target Scopes subsystem during execution.
The complete configuration for the HIL simulation with the embedded processor and the plant simulation is shown in Figure 5. The connection between the host PC and target PC is Ethernet. The link from the host PC to the embedded processor is a BDM debug interface.
The configuration and build process for the plant simulation is similar to the process used to build the embedded software. Once the plant simulation is built and downloaded to the target PC, and that PC is connected to the embedded controller via CAN cabling, real-time simulation can begin.
Sufficient data must be captured on the host PC during the run so that the developer can determine whether the controller is operating in accordance with requirements.
Plant and controller models can be applied in the design and testing of embedded controllers. After validating a controller design in the simulation environment, code can be generated for an embedded controller to implement the design. Using HIL simulation, the automatically generated code can be tested as it executes in real-time on the target processor in conjunction with the high-fidelity plant simulation, which is also running in real-time.
This sequence of events typically begins early in the product development cycle, dramatically reducing the risk that serious design problems will remain undetected until late in the cycle. By implementing and testing controller designs at an early stage in the project, overall project risk and cost can be significantly reduced.