In this demo, we will walk you through subsystem
back-to-back testing using MATLAB's [INAUDIBLE]
Back-to-back testing is done to ensure
the equivalence between model and your generated code.
Coverage analysis is another aspect of back-to-back testing.
Standards, such as ISO 26262 and DO-254
recommend back-to-back testing.
We would be using the subsystem Roll Reference
to demonstrate the workflow.
The prerequisite for a subsystem to be eligible
for subsystem back-to-back testing is that its code
interface packaging should be either set to Reusable
or Nonreusable function.
The Roll Reference subsystem already
has some of the requirement-based test
cases written in a Test Sequence hardness.
The equivalence test case leveraging
existing requirement-based tests is defined in a Simulink Test
file.
We would be setting the coverage to MCDC for this specific Test
Case.
And the Equivalence Test case in the SIMULATION 1,
we will set the Simulation Mode as Normal.
For SIMULATION 2, we would be using the same Harness,
and we would be setting the Simulation Mode
as Software-in-the-Loop.
We also captured the Equivalence Criteria
for the signal, which needs to be compared in MIL and SIL runs
Once the test case is run from the Simulink Test Manager,
we can observe that the signals in the defined equivalence
criteria have been passed.
However, the structural coverage is not 100%.
This implies the requirement-based test cases
are not sufficient to get 100% model and code
coverage for the subsystem.
We generate test cases for missing coverage.
We would now be using Simulink Design Verifier.
To do that, we select the respective coverage results.
And we'll click on Add Test cases for Missing Coverage.
This step, will invoke SLDV for subsystem SIL-based Test Case
generation.
Once the test cases are generated, in the SLDV report,
we can see that there is one unsatisfiable objective,
for the condition objectives associated with the Relational
Operator block.
This specific condition is not covered for true outcome.
Here, we can see that the input is compared
to a parameter whose value is set to 0
and storage class is set to ExportedGlobal.
From some new Test Manager, we will now
rerun the added subsystems three best test cases
and when visualize the Coverage Results.
Once the test case execution is done,
we can see that coverage metric is improved after writing
test cases from SLDV.
However, it is still not 100%.
In the generated Coverage Report,
we can see the SLDV reported unsatisfiable condition
objective for the Relational Operator block
is not covered for true part.
Parameter tuning can be performed
to improve the structural coverage.
Starting R22A, SLDV can automatically
infer the parameters that can be tuned
based on the generated code.
The parameter associated with unsatisfiable objective,
as shown previously, is tunable in the generated code.
SLDV can automatically infer this and tune the parameter.
To do this, we would be setting the SLDV Parameter
Configuration as Automatically infer parameter specification.
Now, we would be, again, navigating to Coverage Results
in the Simulink Test Manager.
And we add tests for missing coverage,
with SLDV parameter tuning enabled.
In the SLDV results, we can now see that all the code coverage
objectives are satisfied.
The Parameter Constraint section shows the parameter,
which is tuned.
And in the generated Test Case, we
can observe the deemed value of the parameter.
Now, we again re-execute the Simulink Test Case.
And once that Test Case is run, we
can observe that 100% of code coverage
is achieved for a specific subsystem.
In the previous case, we were able to tune
the parameter associated with the unsatisfiable objective.
However, if the parameter is not enabled in the generated code,
this objective can never be satisfied
and would be a dead logic.
We can justify the same using sldvmakefilter API.
This API is introduced in release 22a
and takes model and SLDV data as inputs.
Once filter is created, we can apply the same
on the Simulink Test Case.
We can observe the justified coverage.
This would be highlighted in light-blue color
in the coverage results.
The Coverage Report shows the justified objectives.
Each and every step, which we have shown in this demo,
can be automated using scripts.
We will make these resources available to you.
With this, we conclude this demonstration.
Thanks for listening.