{"id":17438,"date":"2025-03-10T14:53:58","date_gmt":"2025-03-10T18:53:58","guid":{"rendered":"https:\/\/blogs.mathworks.com\/simulink\/?p=17438"},"modified":"2025-05-15T18:59:55","modified_gmt":"2025-05-15T22:59:55","slug":"using-test-points-to-log-signals-for-software-in-the-loop-simulation","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2025\/03\/10\/using-test-points-to-log-signals-for-software-in-the-loop-simulation\/","title":{"rendered":"Using Test Points to log Signals for Software-In-The-Loop Simulation"},"content":{"rendered":"
\"\"<\/img><\/a><\/div>
This week's post is a suggestion from <\/span>Raymond Estrada<\/span><\/a> from <\/span>MATLAB and Simulink Consulting Services<\/span><\/a>. Raymond reached out recently to share a tip for verifying and validating logged signals in the code generated from Simulink.<\/span><\/div>

The Problem<\/span><\/h2>
It's a common practice in the verification and validation world to run simulations and look at the value of outputs and (sometimes) intermediate signals, and compare those to expected values.<\/span><\/div>
When generating code using <\/span>Simulink Coder<\/span><\/a> and <\/span>Embedded Coder<\/span><\/a>, you want to verify that those values are the same (within tolerance) as what you got in simulation. That\u2019s what we call \u201c<\/span>equivalence testing<\/span><\/a>\u201d or \u201c<\/span>back-to-back testing<\/span><\/a>\u201d, where you compare the results from normal mode simulation to results from <\/span>Software-in-the-Loop Simulation<\/span><\/a> (SIL) and <\/span>Processor-in-the-Loop Simulation<\/span><\/a> (PIL). <\/span><\/div>
Now here is where you can run into a problem: Some of those values you need to observe don\u2019t exist in the generated code. Intermediate signals may not be available in generated code due various optimizations like <\/span>Signal storage reuse<\/span><\/a> and <\/span>Eliminate superfluous local variables (Expression folding)<\/span><\/a>. Expression folding is an optimization that collapses block computations into single expressions in generated code.<\/span><\/div>
To illustrate this, let's use a very simple model where I add two signals and multiply the result by 2. I want to verify the results for the logged signal \"x\".<\/span><\/div>
\"\"<\/img><\/div>
Using the <\/span>Simulink Test Manager<\/span><\/a> we can create an <\/span>Equivalence Test<\/span><\/a>. This test simulates the model in normal mode and <\/span>Software-in-the-Loop Simulation<\/span><\/a>, and compare the results.<\/span><\/div>
\"\"<\/img><\/div>
We run the test and see that if failed. When expanding the test results, we can see that the logged signal <\/span>x<\/span> is not present in the SIL results.<\/span><\/div>
\"\"<\/img><\/div>
When hovering over the equivalence criteria result, we see this note:<\/span><\/div>
One or more signals did not match within tolerance specified<\/span><\/span><\/div><\/div>
Let's see how to debug and fix this.<\/span><\/div>

The Explanation<\/span><\/h2>
In the Test Manager, if you look carefully at the <\/span>logs<\/span> sections of the test results, you will find more explanations:<\/span><\/div>
\"\"<\/img><\/div>
Let's also run the test programmatically to make the log easier to search and copy. For that, I like to use the function <\/span>matlab.unittest.TestSuite.fromProject<\/span><\/a>. This function conveniently finds all the tests in a project and creates a test suite.<\/span><\/div>
suite = matlab.unittest.TestSuite.fromProject(currentProject);<\/span><\/span><\/div><\/div>
results = run(suite);<\/span><\/span><\/div>
Setting up ProjectFixture\r\nDone setting up ProjectFixture: Project 'SIL_TestPoints' is already loaded. Setup is not required.\r\n__________\r\n\r\nRunning SILTest > SIL Equivalence\r\n\r\n================================================================================\r\nVerification failed in SILTest > SIL Equivalence\/Basic SIL Equivalence.<\/strong>\r\n ---------------------\r\n Framework Diagnostic:\r\n ---------------------\r\n Failed criteria: Equivalence\r\n --> Logs:\r\n Simulation 2:\r\n Model, SumAndGain, simulating in SIL or PIL mode, contains these signals, which are configured for signal logging, but are not supported and are not logged during SIL or PIL simulation:\r\n \r\n SumAndGain\/Add, 'Output Port 1': Signal not found in code description, or signal is virtual, inactive, or has a variable size.\r\n \r\n For list of signals that are nonvariable size and produce message \"Signal not found in code description, or signal is virtual, inactive, or has a variable size.\", this warning might be avoidable:\r\n 1. For each signal, select Signal Properties > Test point.\r\n 2. Clear model configuration parameter 'Ignore test point signals'.\r\n 3. For virtual subsystem output signals, make subsystem atomic (nonvirtual). Select subsystem block parameter 'Treat as atomic unit'.\r\n 4. If generated code is C++ and model configuration parameter 'CodeInterfacePackaging' is set to 'C++ class', to allow access to internal data, set parameter 'InternalMemberVisibility' to 'public' or in Code Mappings editor, in Data Visibility column, for 'Signals, states, and internal data', select 'public'.\r\n 5. If you are testing an atomic subsystem in a Simulink Test harness, make changes in original model that contains subsystem.\r\n \r\n Alternatively, for listed signals, disable signal logging.\r\n \r\n --> Simulink Test Manager Results:\r\n Results: 2025-Mar-02 12:57:59\/SILTest\/SIL Equivalence\/Basic SIL Equivalence\r\n================================================================================\r\n.\r\nDone SILTest > SIL Equivalence\r\n__________\r\n\r\nTearing down ProjectFixture\r\nDone tearing down ProjectFixture: Teardown is not required.\r\n__________\r\n\r\nFailure Summary:\r\n\r\n Name Failed Incomplete Reason(s)\r\n ==============================================================================================\r\n SILTest > SIL Equivalence\/Basic SIL Equivalence X Failed by verification.<\/div><\/div><\/div><\/div><\/div>
What this log tells us is that the generated code does not contain a variable corresponding to the logged signal <\/span>x<\/span>.<\/span><\/div>
When looking at the generated model step function, we can confirm that expression folding has been applied, combining the Sum and Gain blocks in a single expression:<\/span><\/div>
\"\"<\/img><\/div>

The Solution<\/span><\/h2>
Let's apply the first suggestion in the above log:<\/span><\/div>
1. For each signal, select Signal Properties > Test point.<\/span><\/span><\/div><\/div>
If you are not familiar with test points, I recommend this documentation: <\/span>Configure Signals as Test Points<\/span><\/a>.<\/span><\/div>
In this case, a simple way to add the test point is using the Property Inspector:<\/span><\/div>
\"\"<\/img><\/div>
With this change, we can run the test suite again to confirm that the test point fixes the issue and enables the test to pass.<\/span><\/div>
\"\"<\/img><\/div>

Conclusion & Considerations<\/span><\/h2>
Adding a Test Point is one solution that allows for verification of requirements using signals that would otherwise be optimized via expression folding. However, note that the addition of a test point did change the generated code. In this case, the model step function becomes:<\/span><\/div>
\"\"<\/img><\/div>
Since adding test points changes the code and can block optimizations, you only want to use this where it is truly necessary. Also, since they impact the generated code, test points should persist throughout the design and should not be toggled between the different stages of development (development, testing & verification, code generation).<\/span><\/div>

Now it's your turn<\/span><\/h2>
Are you verifying and validating signals internal to your algorithms? Let us know in the comments below if you have tips and tricks for that.<\/span><\/div>\r\n
\r\n<\/div>