How to debug and resolve SIL/MIL discrepancies when using AUTOSAR Code Replacement Library (CRL)?

I am utilizing the AUTOSAR Code Replacement Library (CRL) and have observed discrepancies between the simulation results and the Software-in-the-Loop (SIL) outcomes. What could be the root causes of these issues, and how can I implement effective workarounds?

Answer 1

[MathWorks Support Team]

You might notice a SIL/MIL discrepancy when using AUTOSAR Blockset and using AUTOSAR CRL. This means that you get different numerical results for a particular signal when you Simulate the model in Normal model, versus running it in SIL mode. This article is intended to help you identify the root cause, implement a workaround, and report the issue to MathWorks if the behavior is unexpected.

Why do discrepancies occur?

When using AUTOSAR CRL, certain operations in the code are replaced with a call to some function, which we call the CRL routine. For instance, in the following example the power operation powf which is a standard C-Library operation is replaced by Mfl_Pow_f32 which is an AUTOSAR specific implementation. If the logic of the CRL routine (e.g. Mfl_Pow_f32 ) does not exactly match the logic implemented by Simulink, it is possible that for the same inputs, different outputs are generated. Therefore, a discrepancy could occur between the Simulation behavior and the code behavior. See Limitation1 in the limitations section, for an example of such a discrepancy for the power operation.

AUTOSAR specific blocks

To minimize these discrepancies, it is recommended to use AUTOSAR specific blocks when possible. These blocks are specifically designed such that the Simulation behavior closely matches the behavior of the AUTOSAR routine. These blocks are located at AUTOSAR Blockset /Classic Platform/Library Routines/ as shown below. For more details, see: Code Generation with AUTOSAR Code Replacement Library.

Model advisor check

There is a model advisor check that can automatically detect incompatible blocks with the AUTOSAR CRL routines: AUTOSAR Blockset Checks.

Known limitations

Certain operations do not yet have any AUTOSAR specific block and can generate discrepancies between the Simulink behavior and code generation behavior. Also, there are situations where you might face build errors. See the following table for a list of known limitations.

Limitation	Explanation
Limitation1: Power Operation	According to AUTOSAR specification, 0 to the power of a negative value equals 0, while according to Simulink logic this operation results in inf.
Limitation2: Atan Operation	The implementation of Atan function, Mfl_ArcTan2, could have slight numerical mismatches with the Atan operation in Simulink.
Limitation3: Efx Library	Certain Efx library functions are not supported for SIL verifications. These will generate build errors rather than numerical mis-matches.
Limitation4: Not using autosar.tlc	SIL with MathWorks shipped libraries for AUTOSAR CRL is only possible when using autosar.tlc. If you use a System Target File that is not based on autosar.tlc, the code replacement will happen but you might hit build errors when running SIL.

Steps to debug and resolve the mismatch

Step1: Ensure the issue is with CRL

Set the CRL for the model to “none” and re-run the SIL/MIL simulations.

• If the mis-match still exists, the issue is not related to AUTOSAR CRL.
• If the mis-match does not exist, go to Step2.

Step2: Run the model advisor check for incompatible blocks

Run the model advisor check AUTOSAR Blockset Checks to see if any of the blocks are incompatible:

• If the check identifies incompatible blocks, replace them with compatible blocks. If the issue persists go to step3.
• If the check passes, go to step 3.

Step3: Back trace the issue and identify the problematic operation

Back trace the mismatch from the target signal to source of the signal to identify the block or operation responsible for the mis-match. Consider using SIL/PIL debugging Debug Generated Code During SIL or PIL Simulation.

What is a workaround if the mismatch for an operation is identified?

Once you identify the block responsible for the mis-match, you can follow either of the following two workarounds:

Workaround1: Replace the Simulink implementation with a logic that mimics the implementation details of the routine during simulation. Please note that this mis-match does not mean that the Simulation behavior is incorrect. It just means that the replaced routine and Simulink have different implementation of the operation. Therefore, the overall idea of the workaround is that the logic of the generated code remains unchanged (so that the routine replacement can occur), but during Simulation a separate logic is executed that mimics the implementation detail of the replaced routine. This can be achieved by using a code gen/sim variant via a Variant Subsystem or Variant Source . Essentially you can package this as an AUTOSAR specific block for an operation. The example below shows a custom AUTOSAR specific block implemented for the power operation.

Workaround2: If the discrepancy between the logic of the routine and Simulink happens within an input range that is outside your system's operational range, it is better to add necessary checks and protections at the inputs instead. This ensures that operations do not occur within that problematic range. For example, in the case of the power operation, the problematic range occurs when the base (input1) is zero and the exponent (input2) is negative. If a base of 0 is not within your operational range, you can implement an explicit logic to ensure that the power operation only executes when the base is non-zero.

Is the issue a bug?

The issue of AUTOSAR SIL/MIL mismatch using AUTOSAR CRL is a bug when all the following conditions hold:

1. AUTOSAR CRL with MathWorks shipped libraries is used.
2. Model advisor check AUTOSAR Blockset Checks does not identify any incompatible blocks.
3. The operation is not in the list of known limitations mentioned above.

If you find the issue is a bug, please report it to MathWorks technical support.