With Embedded Coder®, you can run software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations of your model. These simulations generate source code for either the top model or part of the model. A SIL simulation compiles and runs the generated code on your development computer. A PIL simulation cross-compiles source code on your development computer, and then downloads and runs the object code on a target processor or an equivalent instruction set simulator.
With SIL and PIL simulations, you can:
Test whether your model and generated code are numerically equivalent.
Observe code coverage.
Perform code execution profiling.
Through SIL and PIL, you can early on test and fix defects. For example, you can model and test a system component in normal mode. Then, you can reuse your test suites in a SIL or PIL simulation that runs compiled generated code. To check numerical equivalence, you compare normal and SIL or PIL simulation results. You do not have to leave the Simulink® environment to test generated code on a separate infrastructure.
This table describes situations where you can use SIL and PIL.
|Test numerical equivalence between model and generated code by reusing test vectors developed for normal mode simulation to verify numerical output of generated (or legacy) code. See SIL/PIL Manager Verification Workflow and Test Two Simulations for Equivalence (Simulink Test)||SIL and PIL|
Collect metrics for generated code:
|SIL and PIL|
(Requires an IEC Certification Kit license.)
and validation activities on the generated C/C++ code in
accordance to the requirements of the overall software
safety lifecycle as defined by the ISO 26262-6, IEC 61508-3,
IEC 62304, EN 50128, and EN 50657 functional safety
standards. For detailed information about the SIL and PIL
verification activities in the IEC Certification Kit Model-Based Design workflow, see the
Reference Workflow for Embedded C/C++
|SIL and PIL|
(Requires a DO Qualification Kit license.)
Test the output of the
integration process to satisfy relevant objectives in the
DO-178C and DO-333 safety standards. For additional
information, see Testing
of Outputs of Integration Process (DO Qualification Kit). This
information is available also in the Model-Based
Design Workflow for DO-178C
|SIL and PIL|
|Without target hardware, get a convenient alternative to PIL.||SIL|
With target hardware, for example, an evaluation board or instruction set simulator:
Normal simulation techniques do not account for restrictions and requirements that the hardware imposes, such as limited memory resources or behavior of target-specific optimized code.
For information about running PIL simulations on specific targets, see Sample Custom Targets.
The SIL and PIL simulation modes are not designed for the reduction of model simulation times. If you want to speed up the simulation of your model, use the rapid accelerator mode. For more information, see What Is Acceleration?.
In a SIL or PIL simulation, code is generated for either the top model or part of the model. With SIL, this code is compiled for and executed on your development computer. With PIL, the code is cross-compiled for the target hardware and runs on the target processor.
Through a communication channel, Simulink sends stimulus signals to the code on your computer or target processor for each sample interval of the simulation.
For a top model, Simulink uses stimulus signals from the base or model workspace.
If you have designated only part of the model to simulate in SIL or PIL mode, then a part of the model remains in Simulink and code is not generated for this part of the model. Typically, you configure this part of the model to provide test vectors for the software executing on the hardware. This part of the model can represent other parts of the algorithm or the environment in which the algorithm operates.
When your computer or target processor receives signals from Simulink, the processor executes the SIL or PIL algorithm for one sample step. The SIL or PIL algorithm returns output signals calculated during this step to Simulink through a communication channel. One sample cycle of the simulation is complete, and Simulink proceeds to the next sample interval. The process keeps repeating itself and the simulation progresses. SIL and PIL simulations do not run in real time. In each sample period, Simulink and the object code exchange I/O data.
|Type of SIL or PIL Simulation||What Happens in SIL Simulation||What Happens in PIL Simulation|
|Use SIL or PIL block created from subsystem.|
You generate standalone code when you perform, for example, a top-model or right-click subsystem build for a single deployable component. You can compile and link standalone code into a standalone executable or integrate it with other code. For more information on the standalone code interface, see Configure C Code Generation for Model Entry-Point Functions.
When you generate code for a referenced model hierarchy, the software generates standalone executable code for the top model and a library module called a model reference target for each referenced model. When the code executes, the standalone executable invokes the applicable model reference targets to compute the referenced model outputs. For more information, see Build Model Reference Targets.
To integrate generated code with legacy code, use standalone code because the standalone code interface is documented.
SIL and PIL simulations do not provide direct support for custom code interfaces. You can incorporate these interfaces into Simulink as an S-function, for example, using the Legacy Code Tool, S-Function Builder, or handwritten code. Then, you can verify the custom code by using SIL and PIL simulations.
This table provides the interfaces that SIL and PIL simulations generate.
|SIL/PIL Simulation||Code Interface|
SIL/PIL simulation generates the standalone code interface. If code exists, simulation calls standalone code for the model . If code does not exist, simulation generates standalone code.
If you set Code interface block
If you set Code
interface block parameter to
|SIL or PIL block||Block uses standalone code interface.|
There are algebraic loops that occur in SIL and PIL simulations but not in normal mode simulations:
For more information, see:
|Exported functions in feedback loops|
If your model has function-call subsystems and you export a subsystem that has context-dependent inputs (for example, feedback signals), the results of a SIL/PIL simulation with the generated code and the results of the normal mode simulation of your model can differ. One approach to make SIL/PIL and normal mode simulations yield identical results is to use Function-Call Feedback Latch blocks in your model. You can make context-dependent inputs become context-independent.
Embedded Coder generates a warning identifying context-dependent inputs of exported function-call subsystems if you set the Context-dependent inputsconfiguration parameter to one of the following:
For more information, see:
A SIL or PIL simulation does not modify the code generated from the model. If you use imported data, the SIL or PIL simulation generates additional code that is required to support compiling and linking of the SIL or PIL target application. The additional generated code corresponds to interfaces that you specify in the model.
This section describes:
For imported data, when the SIL or PIL simulation defines storage and when you must define storage.
Interfaces for which a SIL or PIL simulation generates additional code
In SIL and PIL simulations, you can use signals, parameters, and data stores that specify storage classes with imported data definitions. The simulations define storage for imported data associated with:
Signals at the root level of the component (on the I/O boundary).
Parameters in the base workspace or a data dictionary. For parameters in the model workspace:
Top-model SIL/PIL and SIL/PIL block simulations define storage.
Model block SIL/PIL simulations do not define storage. You must define storage and specify initial values that match MATLAB values.
Global data stores.
SIL and PIL simulations do not define storage for other imported data. For example, the simulations do not define storage for imported data associated with:
Internal signals (not on the I/O boundary). Note that, if the data for internal signals is in structures that are imported through the use of pointers, the simulations define storage.
Local data stores.
In these cases, define the storage through custom code included
by the component under test or through the PIL
See also Tunable Parameters and SIL/PIL.
This table describes scenarios where a SIL or PIL simulation generates additional code for interfaces.
SIL and PIL simulations support the
|Custom storage class of type
To enable SIL and PIL support for the custom
storage class where Type is set to
classdef CSCOtherAttributes < Simulink.CustomStorageClassAttributes properties(PropertyType = 'logical scalar') SupportSILPIL = true; end end
For more information about custom attributes, see Further Customize Generated Code by Writing TLC Code and Finely Control Data Representation by Writing TLC Code for a Storage Class.
build the SIL or PIL application interface, the code
generator calls the
For a custom storage class that is not grouped:
For a custom storage class that is grouped:
To determine whether the SIL
or PIL application can access the variable in the code
by address, the code generator uses the elements
The code generator assumes
You can construct
the custom TLC file associated with a custom storage
class of type
... %case "contents" %if !LibIsAccessingCustomDataForSILPIL(record) %matlab functionWithSideEffects() %endif %return LibDefaultCustomStorageContents(record, idx, reim) ...
See also Other custom storage class limitations.
|AUTOSAR Runtime Environment|
You can use top-model and Model block SIL/PIL and SIL/PIL block simulations to perform model-based testing of an AUTOSAR software component. The software links generated code for the AUTOSAR software component with a basic component-specific AUTOSAR Runtime Environment (RTE) to create a test application. This application tests AUTOSAR API calls made by the AUTOSAR software component.
a top-level AUTOSAR software component that contains
referenced models, you can run top-model or
Model block (Code
interface set to
You can also run
Model block (Code
interface set to