MathWorks recommends comparing simulation and code generation results to troubleshoot and avoid any unintended results during to the code generation process.
This document will highlight the different approaches that can be taken to accomplish this comparison. However, choosing the right approach which is appropriate for the application being built depends on the overall goal and the licensed products.
Before we begin, It is important to realize that there are products and features that simulate through code generation. For instance, Stateflow and using Model Reference within Simulink both use code generation technology for simulation purposes. The scope of this document is for those aspects of the tool that DO NOT simulate through code generation.
The results used for comparison can come from a variety of sources. Root level outports or Simulink States are two useful and generally appropriate variables to consider. Comparison of the data can be simply plotting the different results and visually inspecting, or more detailed manual/automated comparisons. The actual approach of the data comparison depends on the individual application. The purpose is to find significant differences, and not numerical aspects. For more information on numerical considerations, please refer to the related solutions.
The following are different approaches which can be used to compare Simulation Vs Code Generation results.
1. Using the Simulink Accelerator
2. Model Reference
3. RSIM target
4. RTW s-function target
5. RTW EC s-function wrapper
6. Processor-in-the-Loop Verification
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
1. Using the Simulink Accelerator
Note: As of R2007b, Simulink Accelerator functionality has been incorporated into Simulink.
Because the Simulink Accelerator uses code generation technology to be able to run simulations faster, it can be used to compare answers between simulation and code generation. The process entails acquiring one set of test data with the Accelerator off (simulation in “Normal” mode), and acquiring a new set of test data with the Accelerator on.
The required products are:
MATLAB
Simulink
Simulink Accelerator
As an example, the following steps demonstrate this approach with the "sldemo_f14" demo model to compare the results:
a. Open the "sldemo_f14" demo model using the following command at MATLAB command prompt:
sldemo_f14
b. In the Simulation->Configuration Parameters->Data Import/Export Pane, verify that the Time and State data is being saved to the workspace.
c. Run the simulation in Normal mode (default) and plot the results. The following example code plots the state data obtained from simulating the model:
figure;
plot(tout,xout(:,1),'r');
clear all;
d. Run the simulation in Accelerator mode by selecting "Accelerator" in the pull-down menu next to simulation time and plot the state data as shown below:
hold on;
plot(tout,xout(:,1),'b-.');
For more information regarding how Simulink Accelerator works, refer to the following link in the documentation:
2. Model Reference
Model Referencing can be used by creating a new model that is simply a Model Reference block that calls into the model that you would like to test. The Model block can be found in Simulink->Ports and Subsystems Library.
Getting a set of test data from the standalone model, and one from the root model will give the two sets of test data for comparison. As an example, the following steps demonstrate this approach with the "sldemo_mdlref_bus" demo model to compare the results:
a. Open the "sldemo_mdlref_bus" model using the following command at the MATLAB command prompt.
Sldemo_mdlref_bus
Note that this model contains a Model block (CounterA) referencing to the "sldemo_mdlref_counter_bus" model.
b. In the Simulation->Configuration Parameters->Data Import/Export Pane, verify that the Time, State and Signal Logging data is being saved to the workspace. (Note that any other signals that need to be compared can be recorded using the Signal Logging feature. Observe that the current model has two testpoints to log bus signals to the workspace as "topOut" - COUNTERBUS (input to the Model block) and OUTPUTBUS (output of the Model block). This can be verified by observing that Signal Logging is checked with the output variable name given by “topOut” in the Simulation->Configuration Parameters->Data Import/Export Pane)
c. Run the simulation in Normal mode (default) and plot the results. The following example code plots the the logged signal data for the OUTPUTBUS obtained from simulating the model:
figure;
plot(topOut.OUTPUTBUS.inputsignal.input.Time,topOut.OUTPUTBUS.inputsignal.input.Data, 'r')clear all;
d. Double click on the CounterA block to open the referenced model
e. Refer to the step 2 about logging data including Time, State Outputs and any other specific signal data. Observe that the input block of this model outputs a non-virtual bus object (COUNTERBUS) which is being logged to the workspace as "subOut".
f. In the Simulation->Configuration Parameters->Data Import/Export Pane for this referenced model, observe that the input option is checked with the input being loaded from the Base Workspace variable “topOut.COUNTERBUS”
g. Run the simulation for just this referenced model which is taking the same inputs as in the other case but this time is being simulated as standalone. Plot the results. The following example code plots the the logged signal data for the OUTPUTBUS obtained from simulating the referenced model:
hold on;
plot(subOut.OUTPUTBUS.inputsignal.input.Time,subOut.OUTPUTBUS.inputsignal.input.Data, 'b-')clear all;
For more information on Model referencing and how it is different from subsystems, refer to the documentation available at the following link:
3. RSIM target
The RSIM target uses the GRT target to create a standalone executable of a Simulink model. It can then be used to pass in inputs, and log various sets of outputs (to include states if desired). These sets of data can then be compared.
The required products for using RSIM target are:
MATLAB
Simulink
Real-Time Workshop
Host platform C Compiler
A standalone executable can be built from the Simulink model using RSIM target. Then change the parameter for a block in the Simulink model and compare the results of the simulation versus those obtained using the standalone with the new parameter passed as an argument to the standalone executable. As an example, the following steps demonstrate this approach with the "sldemo_f14" demo model to compare the results:
a. Open the "sldemo_f14" model using the following command at the MATLAB command prompt:
sldemo_f14
b. Open Simulation->Configuration Parameters->Data Import/Export Pane and verify that the Time and State data is being saved in Workspace
c. From the Simulation->Configuration Parameters->Real-Time Workshop Pane, select the system target file to be “rsim.tlc”
d. Click on “Build” to build the executable
NOTE: RSIM target is the only Real-Time Workshop target that supports generation of code for a model based on variable-step solver.
e. Now in the model, change the gain block’s (Mw) parameter to a different value
f. Run the simulation and plot the results. The following example code plots the state data obtained from simulating the model:
figure;
plot(tout, xout(:,1),'r');
g. Extract the current parameter of the model into a MAT file using the following set of commands:
param_struct = rsimgetrtp('sldemo_f14');
save myrsimdata.mat param_struct
h. Run the standalone executable using the updated set of parameters and plot the results using the following code:
!sldemo_f14 -p myrsimdata.mat % the bang operator to call system commands
hold on
plot(rt_tout,rt_xout(:,1),'b-.');
For more information on running rapid simulations and specifying different forms of arguments to the standalone executable, refer to the documentation available at the following URL:
4. RTW s-function target
RTW S-Function target can be used to build an S-function component out of a subsystem or a model and use it as an S-Function block in another model. A simple test to verify if the S-Function generated behaves in the same way as the original subsystem or model can be done by replacing the subsystem with the generated S-Function block and compare the results in both the cases.
For more detailed information on how to generate S-Function component from a subsystem or model, refer to the following link in the documentation:
5. RTW EC s-function wrapper
For production code users, when using Real Time workshop Embedded Coder to generate production code, there is an option that take that exact code and creates an s-function wrapper around it, such that it can be brought back into the Simulink model and run the generated code within Simulink.
The required products for using embedded targets to build models are:
MATLAB
Simulink
Real-Time Workshop
Real-Time Workshop Embedded Coder
Host platform C Compiler (Microsoft Visual C/C++ or Watcom C/C++) and a cross-compiler for the target processor. Stateflow Coder is also required when generating code for Simulink models containing Stateflow chart
One approach to verify if the generated code behaves in the same way as the original model is to create an S-Function for this model and compare the results obtained when the same inputs are given to the S-Function block. The following steps show how to create an additional S-Function block when building a model using ERT target:
1. In the Simulation->Configuration Parameters->Real-Time Workshop Pane, select the system target file as "ert.tlc"
2. In the Simulation->Configuration Parameters->Real-Time Workshop ->Interface Pane, under the Verification tab, select the "Create Simulink S-Function block" option.
The same inputs can be provided to this block and the results can be verified with that of the original model.
The steps given below demonstrate this process with the "rtwdemo_sil.mdl" demo that ships with the Real-Time Workshop Embedded Coder:
a. Open the "rtwdemo_sil" model using the the following command at the MATLAB command prompt:
rtwdemo_sil
b. Log the signal being fed to the Scope block. To do this right click on the signal, select "Signal Properties". This will open the Signal Properties dialog box. Enter the value "my_signal" for the "Signal Name" property and enable the "Log Signal Data" option in the dialog box.
c. In the Simulation->Configuration Parameters->Data Import/Export Pane, verify that the Time, State and Signal Logging are enabled and are being saved to Workspace as "tout", "xout" and "sigsOut" respectively.
d. Run the Simulation and plot the results. The following example code plots the "my_signal" data coming out of the "Plant" subsystem:
figure;
plot(sigsOut.my_signal.Time, sigsOut.my_signal.Data,'r')
e. Now, open the Real-Time Workshop Interface page by double-clicking the yellow button in the model.
f. Ensure that the "Create Simulink (S-Function) block" option is selected.
g. Right-click the Controller subsystem and select Real-Time Workshop > Build Subsystem.
h. When the parameter dialog appears, click the Build button. An S-Function block is created in an untitled library. This S-function is a wrapper for the generated subsystem code, and can be used to verify that the code provides the same result as the original subsystem.
i. Replace the original system with the S-function block and rerun the simulation to verify the output is correct by plotting the "my_signal" data as shown below:
hold on;
plot(sigsOut.my_signal.Time, sigsOut.my_signal.Data,'b-')
6. Processor-in-the-Loop Verification
For production code users, when using Real Time Workshop Embedded Coder with an Embedded IDE Link™ product (for example, Embedded IDE Link™ TS or Embedded IDE Link™ CC) to generate production code, there is an option that takes the generated code, compiles and executes it on an embedded microprocessor or instruction set simulator supported by the Link product, and performs a co-simulation with the plant model or test harness in Simulink.
The required products for performing Processor-in-Loop verification for models are:
MATLAB
Simulink
Real-Time Workshop
Real-Time Workshop Embedded Coder
An Embedded IDE Link™ product (e.g., Embedded IDE Link™ TS or Embedded IDE Link™ CC)
Host platform C Compiler (Microsoft Visual C/C++ or Watcom C/C++)
A cross-compiler and Integrated Development Environment supported by the Link product and target processor
Stateflow and Stateflow Coder are also required when generating code for Simulink models containing Stateflow charts
Target processor hardware (optional)
Processor-in-Loop (PIL) is used to verify if the generated and compiled object code behaves in the same way on the target processor as the original model. This is different than the previously described approaches which focus on executing the generated code on the same host processor used to simulate the original model. For Model-Based Design, it is important to understand and assess how the target environment affects numerical results.
PIL is an advanced topic and will not be described in detail here. Refer to the Embedded IDE Link™ TS documentation for a general overview of PIL:
