Embedded IDE Link™ MU

Using Processor-in-the-Loop

Processor-in-the-Loop Overview

Processor-in-the-loop (PIL) operation provides a powerful verification capability in your development process. Processor-in-the-loop (PIL) cosimulation is a technique designed to help you evaluate how well a candidate algorithm, such as a control system, operates on the actual processor selected for the application.

Cosimulation reflects a division of labor in which Simulink models the plant, while code generated from the controller subsystem runs on the processor hardware.

During the Real-Time Workshop Embedded Coder code generation process, you can create a PIL block from one of several Simulink components including a model, a subsystem in a model, or subsystem in a library. You then place the generated PIL block inside a Simulink model that serves as the test harness and run tests to evaluate the processor-specific code execution behavior.

Why Use Cosimulation?

PIL cosimulation is particularly useful for simulating, testing, and validating a controller algorithm in a system comprising a plant and a controller. In a classic closed-loop simulation, Simulink and Stateflow^® model such a system as two subsystems with the signals transmitted between them, as shown in the following block diagram:

Your starting point in developing a combined plant and controller system model is to model the combined system as two subsystems in closed-loop simulation. As your design progresses, you can use Simulink external mode with standard Real-Time Workshop targets (such as GRT or ERT) to help you model the controller system separately from the plant.

However, these simulation techniques do not help you account for restrictions and requirements imposed by the hardware, such as limited memory resources, or behavior of processor-specific optimized code. When you reach the stage of deploying controller code on the processor hardware, you may need to make extensive adjustments to the controller system to account for the hardware specifics. After you make these adjustments, your deployed system may have diverged significantly from your original model. Such discrepancies can create difficulties if you need to change the original model.

PIL cosimulation addresses these issues by providing an intermediate stage between simulation and deployment. In a PIL cosimulation, the processor participates fully in the simulation loop—hence the term processor-in-the-loop.

Two new terms appear in the following sections

• PIL Algorithm — The algorithmic code, such as the control algorithm, to test during the PIL cosimulation. The PIL algorithm resides in compiled object form to allow verification at the object level.

• PIL Application — The executable application to run on the processor. The PIL application is created by linking the PIL algorithm object code with wrapper code or a test harness that provides an execution framework that interfaces to the PIL algorithm.

  The wrapper code includes the string.h header file so that the memcpy function is available to the PIL application. The PIL application uses memcpy to facilitate data exchange between Simulink and the cosimulation processor.

  Note   Whether the PIL algorithm code under test uses string.h is independent of the use of string.h by the wrapper code, and is entirely dependent on the implementation of the algorithm in the generated code.

How Cosimulation Works

In a PIL cosimulation, Real-Time Workshop software generates an executable application for the PIL algorithm. This code runs (in simulated time) on a processor platform. The plant model remains in Simulink without the use of code generation.

During PIL cosimulation, Simulink simulates the plant model for one sample interval and exports the output signals (outn of the plant) to the processor platform via Green Hills MULTI. When the processor platform receives signals from the plant model, it executes the PIL algorithm for one sample step. The PIL algorithm returns its output signals (ontn of the algorithm) computed during this step to Simulink in inn, via the Green Hills MULTI interface. At this point, one sample cycle of the simulation is complete and the plant model proceeds to the next sample interval. The process repeats and the simulation progresses.

PIL tests do not run in real time. After each sample period, the simulation halts to ensure that all data has been exchanged between the Simulink test harness and object code. You can then check functional differences between the model and generated code.

Back to Top

PIL Block

The PIL cosimulation block is the Simulink block interface to PIL and the interface between the Simulink plant model and the executable application running on the processor. The Simulink inputs and outputs of the PIL cosimulation block are configured to match the input and output specification of the PIL algorithm.

The block is a basic building block that enables you to perform these operations:

• Select a PIL algorithm

• Build and download a PIL application

• Run a PIL simulation

The PIL block inherits the shape and signal names from the parent subsystem, like those in the following example. This inheritance feature is convenient for copying the PIL block into the model to replace the original subsystem for cosimulation.

Back to Top

PIL Issues

• Data Types Must Be the Same Size in MATLAB and on the Processor

• Buses and MUX Signals Not Supported at PIL Component Boundary

• Signals with Custom Storage Classes Not Supported at PIL Component Boundary

• Continuous Sample Times Not Supported

• Real-Time Workshop grt.tlc-Based Targets Not Supported

• Using Breakpoints and PIL

• Using TimeMachine and PIL

Consider the following issues when you work with PIL blocks.

Data Types Must Be the Same Size in MATLAB and on the Processor

Only data types with the same size on the host and processor are supported at the PIL I/O boundary.

The data types used at the PIL I/O boundary are restricted based on the following rule: PIL supports the data type only if the data type size in MATLAB is the same as the data type size on the processor.

• For Boolean, uint8, and int8, the size is 8 bits on the processor and in MATLAB.

• For uint16 and int16, the size is 16 bits on the processor and in MATLAB.

• For uint32 and int32, the size is 32 bits on the processor and in MATLAB.

• For single, the size is 32 bits on the processor and in MATLAB.

• For double, the size is 64 bits on the processor and in MATLAB.

Examples of unsupported data types:

• On the DSP563xx — single and double are not supported (floating point types are 24 bits on the processor)

• On the 8051 — double is not supported (double is 32 bits, the same as single)

To avoid data type problems, do not use the example data types in your model because the data type on the processor does not match the built-in MATLAB data type.

Buses and MUX Signals Not Supported at PIL Component Boundary

Buses and MUX Signals are not supported at the PIL component boundary.

There is no resolution for this issue.

Signals with Custom Storage Classes Not Supported at PIL Component Boundary

Signals with Custom Storage Classes are not supported at the PIL component boundary.

There is no resolution for this issue.

PIL does support the standard storage classes, such as ExportedGlobal.

Continuous Sample Times Not Supported

Continuous sample times are not supported by PIL. If you encounter this you see the following error:

??? Processor-in-the-Loop (PIL) does not support continuous
time. Please uncheck "continuous time" in the RTW Interface
configuration set options or disable PIL.

You must use discrete sample times in your model configuration parameters when you use PIL.

Real-Time Workshop grt.tlc-Based Targets Not Supported

Real-Time Workshop grt.tlc-based targets are not supported for PIL.

To use PIL, select the Real-Time Workshop multilink.ert target provided by Real-Time Workshop Embedded Coder.

Using Breakpoints and PIL

Green Hills MULTI debugger allows you to add breakpoints to your projects. When you run a PIL simulation that includes added breakpoints, the following dialog box appears:

The dialog box gives you two options:

• Stop the running simulation by closing the dialog box.

• Go to MULTI, remove the breakpoint you added, and press F5 to continue running your simulation.

When you use MULTI to add breakpoints to the generated PIL code, the PIL simulation doesn't know how to use the debug points. If you use the add function to add a breakpoint, you do not encounter the dialog box shown.

Using TimeMachine and PIL

MULTI IDE provides a debugging suite called TimeMachine™. The software provides controls that allow you to step forward and backward through paused code.

If you stop a running PIL program at a breakpoint, and then use the TimeMachine debugging features, you must restore the program pointer to the breakpoint before you restart the program. If you do not restore the pointer location, MATLAB returns an error message and PIL stops working.

Note   Do not remove the data breakpoint the PIL build process inserts. You can remove any breakpoint that you insert in the code.

To use TimeMachine for debugging without problems, follow these steps:

1. Generate your PIL block.

2. Generate program code from the model that contains the PIL block.

3. Download the program to your processor.

4. From MATLAB or in the IDE, insert one or more breakpoints in the program. For more information about adding breakpoints from MATLAB, refer to add in the online Help system.

5. Run the program. The program stops at a breakpoint. Note the line number or breakpoint where the program stopped. You will return the program pointer to this location when you finish your debugging session.

6. Use TimeMachine controls to step the program pointer forward or backward in your program to debug as needed.

7. When you finish debugging, use TimeMachine controls to return the program pointer to the line or breakpoint where the program stopped in step 5.

8. Restart your program.

Repeat steps 5 through 9 until you finish debugging your program.

Back to Top

Creating and Using PIL Blocks

Using PIL and PIL blocks to verify your processes begins with a Simulink model of your process. To see an example of one such model used to implement PIL, refer to the demo Comparing Simulation and Processor Implementation with Processor-in-the Loop (PIL) (multilinkpilsumdiff.mdl) in the Getting Started with Application Development demo for Embedded IDE Link MU.

Note   Models can have multiple PIL blocks for different subsystems. You cannot have more than one PIL block for the same subsystem. Including multiple PIL blocks for the same subsystem causes errors and incorrect results.

To create and use a PIL block

Perform the following tasks to create a new PIL block and use the block in a model:

1. Develop the model of the process to simulate.

   Use Simulink to build a model of the process to simulate. The blocks in the library multilinklib can help you set up the timing and scheduling for your model.

   For information about building Simulink models, refer to Simulink Getting Started Guide in the online Help system.

2. Convert your process to a masked subsystem in your model.

   For information about how to convert your process to a subsystem, refer to Creating Subsystems in Using Simulink or in the online Help system.

3. Open the new masked subsystem and add a Target Preferences block to the subsystem.

   The block library multilinklib contains the Target Preferences block to add to your system. Configure the Target Preferences block for your processor. For details about the options on the Target Preferences block, refer to the Target Preferences block reference in the online Help system.

4. Configure your model to enable it to generate PIL algorithm code and a PIL block from your subsystem.

   1. From the model menu bar, go to Simulation > Configuration Parameters in your model to open the Configuration Parameters dialog box.

   2. Choose Real-Time Workshop from the Select tree. Set the configuration parameters for your model as required by the software. Get more information about setting the Real-Time Workshop parameters in Setting Real-Time Workshop Options for supported hardware in the online Help system.

   3. Under Target selection, set the System target file to multilink_ert.tlc (PIL requires Real-Time Workshop Embedded Coder).

5. Configure the model to perform PIL building and PIL block creation.

   1. Select Embedded IDE Link MU on the Select tree.

   2. From the Build Action list, select Create_processor_in_the_loop_project to enable PIL block creation and cosimulation.

   3. From the PIL block action list, select Create PIL block.

   4. Click OK to close the Configuration Parameters dialog box.

6. To create the PIL block, right-click the masked subsystem in your model and select Real-Time Workshop > Build Subsystem from the context menu.

   This step builds the PIL algorithm object code and a PIL block that corresponds to the subsystem, with the same inputs and outputs. Follow the progress of the build process in the MATLAB command window.

   A new model window opens and the new PIL block appears in it.

7. Copy the new PIL block from the new model to your model, either in parallel to your masked subsystem to cosimulate the processes, or replace your subsystem with the PIL block.

   To see the PIL block used in parallel to a masked subsystem, refer to the demo Getting Started with Application Development in the demos for Embedded IDE Link MU.

8. Click Simulation > Start to run the PIL simulation and view the results.

Back to Top

What Is Verification?

Real-Time Execution Profiling