This example shows how to use Processor-in-the-Loop simulation mode of the Model block to verify Fixed-Point Fuel Control System on target hardware.
IDE/tool chain: Analog Devices™ VisualDSP++®
IDE/tool chain: Texas Instruments™ Code Composer Studio™
|On this page…|
This application example shows how to use Processor-in-the-Loop (PIL) simulation mode of a Model block for non real-time numerical verification on processors supported by IDE Link component. The example models show a fault-tolerant fuel control system using Simulink® and Stateflow®. These models are based on the Fault-Tolerant Fuel Control SystemFault-Tolerant Fuel Control System.
Top model PlantPlant uses a model block to reference the fixed-point fuel rate controller algorithm, which is abstracted in a separate model Fault-Tolerant Fuel ControllerFault-Tolerant Fuel Controller. When the simulation mode of the model block is set to "Normal", the referenced component runs entirely within Simulink. However, when the simulation mode is set to PIL, the referenced component compiles and runs on target hardware; the rest of the model continues to execute in Simulink. To accomplish numerical verification of the algorithm on the target hardware, one compares the results of the two simulation modes of the model block.
In practice, there are two ways to compare the execution results:
The first technique is to run the simulation twice. The user changes the simulation mode of the model block between runs, logging the results of both runs to MATLAB® workspace, and then post-processes them after the second run.
The second technique, which this example uses, accomplishes the comparison in a single simulation run. The model contains two model blocks that reference the same algorithmic model, but which execute in two different simulation modes.
2. Open the Model Configuration Parameters dialog and select "Coder Target" under "Code Generation". Click "Target Hardware Resources" and set the parameters to match your target hardware.
NOTE: For some processors, the default memory map is not sufficient to accommodate all the code and data. For example, in MPC5554, set the ".data" to use "sram_stdby". For more information, see IDE Link documentation.
3. In the Model Configuration Parameters dialog under "Solver" > "Solver Options", set the "Type" to "Fixed-step" and "Solver" to "ode3 (Bogacki-Shampine)".
4. Click "OK" to save the settings and close the Configuration Parameters dialog box.
6. Open the Model Configuration Parameters dialog and select "Coder Target" under "Code Generation". Click "Target Hardware Resources" and set the parameters to match your target hardware.
7. Select "Simulation" > "Model Configuration Parameters" from the Fault-Tolerant Fuel ControllerFault-Tolerant Fuel Controller menu bar. Under "Code Generation" > "Interface", clear the "absolute time" check box. Click OK to save the settings and close the Configuration Parameters dialog box.
2. Connect available input and output signals to the second Model block.
3. Right-click the second Model block. Under "Block Parameters (ModelReference)" > "Simulation mode" select "Processor-in-the-loop".
4. Close the dialog and observe that the appearance of the second model block changed to reflect the new setting.
At this point, your model should look as follows:
1. In your model, click "Run" button.
2. View the scopes to compare the simulation and processor implementation results.
3. Simulate sensor failures by double-clicking any of the four Switch blocks that model the throttle, speed, EGO and MAP sensors.
4. Stop the simulation.
This example uses the IDE debugger for communication between the top Simulink model and the compiled component executing on target hardware.
Depending on your execution platform, you may be able to use TCP/IP or SCI for PIL simulation. PIL simulation using TCP/IP or SCI is generally much faster than the PIL simulation using IDE debugger.
This example showed how to verify the fault-tolerant fuel control algorithm on target hardware. Using the Processor-in-the-loop simulation mode of the Model block, you compared the simulation results with those of the algorithm running on the processor.