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.
Situation | Use |
---|---|
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.) Perform verification
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++
Applications
( | 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. | PIL |
Note
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 |
---|---|---|
Specify through:
|
|
|
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.
Note
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 |
---|---|
Top-model | 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. |
Model block | If you set Code interface block
parameter to If you set Code
interface block parameter to |
SIL or PIL block | Block uses standalone code interface. |
Item | Information |
---|---|
Algebraic loops | 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:
|
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)
Local data stores
In these cases, define the storage through custom code included
by the component under test or through the PIL rtw.pil.RtIOStreamApplicationFramework
API.
See also Tunable Parameters and SIL/PIL.
GetSet
Custom Storage ClassSIL and PIL simulations support the GetSet
custom storage
class. The SIL/PIL test harness provides C definitions of the
Get
and Set
functions that are used
during simulations. For more information, see Access Data Through Functions with Storage Class GetSet.
Other
To enable SIL and PIL support for the custom storage class where
Type is set to Other
, create a
custom attributes class for the custom storage class and associate the custom
attributes class with a Boolean property, SupportSILPIL
, set
to
true
.
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.
To build the SIL or PIL application interface, the code generator calls the
DataAccess
and ClassAccess
functions
in the associated custom TLC file to get required information. The code
generator stores the extracted information in build artifacts in the build
folder.
For a custom storage class that is not grouped:
The code generator calls DataAccess
with the
request argument taking values of define
,
declare
, layout
,
contents
, address
, or
set
.
The code generator uses the string returned by
DataAccess(record, "define", "", "")
to
define the variable in the SIL or PIL application if one of these is true:
The signal or parameter has an
Imported
data scope.
The model uses a model reference code interface.
The model uses a top model code interface,
EnableDataOwnership
is
on
, and the
Owner
attribute for the custom
storage class is not empty and not equal to the name of
the current model
The code generator uses the string returned by
DataAccess(record, "declare", "", "")
to
declare the variable in the SIL or PIL application if the following
are true:
The model uses a top model code interface.
The signal or parameter uses an
Exported
storage class.
EnableDataOwnership
is
off
, or
EnableDataOwnership
is
on
and the
Owner
attribute for the custom
storage class is empty or equal to the model
name.
Code packaging is configured so that the variable is
not declared in
or a header file that is included by
model
.hmodel
.h
For a custom storage class that is grouped:
The code generator calls DataAccess
with the
request
argument taking values of
layout
, address
, or
set
.
The code generator calls ClassAccess
with the
request
argument taking the value of
groupTypeDeclDefn
.
You must provide the grouped type (struct
)
definition and the extern
declaration of the
grouped variable if one of these is true:
The signal or parameter has an
Imported
data scope.
The model uses a model reference code interface.
The model uses a top model code interface,
EnableDataOwnership
is
on
, and the
Owner
attribute for the custom
storage class is not empty and not equal to the name of
the current model
Provide the definition and declaration in a header file associated
with the custom storage class by using the
HeaderFile
attribute or custom code that you
include through the
file. To
define the variable in the SIL or PIL application, the code
generator uses the string returned by model
.hClassAccess(record,
"groupTypeDeclDefn")
.
Static initialization can assume an order of
struct
elements that is different from the
order that is generated if the data scope is
Exported
. When the code generator queries
ClassAccess(record, "groupTypeDeclDefn")
, it
temporarily overrides the data initialization attribute of the
custom storage class with the value None
.
To determine whether the SIL or PIL application can access the variable in the
code by address, the code generator uses the elements returned by
DataAccess(record, "layout", "", "")
. To create the
functionality in the application that transfers input or output port, tunable
parameter, or global data store memory values between the development computer
and target hardware, the code generator uses the output from:
DataAccess(record, "address", idx, reim)
if the
first returned element is scalar
,
vector
, row-mat
, or
col-mat
.
DataAccess(record, "contents", idx, reim)
(or
DataAccess(record, "set", idx, reim)
) if the
first returned element is other
.
The code generator assumes that for row-mat
and
col-mat
, matrices are stored in row-major format
respectively. The assumption is independent of the array layout for the rest of
the model. The code generator assumes that if the array layout of the storage
implemented by the custom storage class differs from the rest of the model, the
TLC file associated with the custom storage file performs the required
transformations.
You can construct the custom TLC file associated with a custom storage class
of type Other
to perform other functions (in addition to
returning the requested code fragments). For example, write directly to a custom
file or call MATLAB functions that change the state of the base workspace. If you do
not always want to execute these functions when
DataAccess
or ClassAccess
are called,
use the LibIsAccessingCustomDataForSILPIL(record)
TLC
function to distinguish between target code generation and requests for code
fragments for the construction of the SIL or PIL application. For
example:
... %case "contents" %if !LibIsAccessingCustomDataForSILPIL(record) %matlab functionWithSideEffects() %endif %return LibDefaultCustomStorageContents(record, idx, reim) ...
See also Other custom storage class limitations.
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.
For a top-level AUTOSAR software component that contains referenced models,
you can run top-model or Model block (Code
interface set to Top model
) SIL or PIL
simulations. In the simulations, the software:
Before compilation of referenced models, generates AUTOSAR RTE header files.
Provides the RTE include path for referenced model compilation.
You can also run Model block (Code
interface set to Model reference
) SIL
or PIL simulations for a referenced model within the top-level AUTOSAR SWC. In
this case, before you run a simulation, you must build the parent component to
generate the RTE header files. If you do not build the parent component, the SIL
or PIL simulation fails.