Model coverage helps you understand how completely you have tested your Simulink models. Achieving full coverage in objectives such as Modified Condition/Decision Coverage, or MCDC, is often required by industry standards, including DO-178 and ISO 26262, to show sufficient testing for safety critical applications.
However, circumstances in your design may prevent you from achieving the necessary coverage, for example if your model contains unsatisfiable objectives. In other situations, coverage results for portions of your model are either unneeded or even distracting.
Filtering allows you to justify or excluded missing coverage from the results and focus on the parts of your system that you want to test in this context. Filtered results may also be a more representative metric of your testing efforts because you can scope the results only to the addressable coverage objectives.
Deactivated logic is a common cause for unaddressable coverage. This arises, for instance, when a Simulink Subsystem has multiple configurations, but only one of them is used for this particular model. Activating this logic solely to achieve full coverage could put the model in a state not specified for this design.
You can reconcile the missing coverage by adding a justification filter explaining why the blocks in question are deactivated. The filter description is later added to the results report, documenting the deactivated logic as required by some industry standards. To do this effectively, you should filter only those paths in your model that are explicitly deactivated. Justifying the whole subsystem might exclude critical behavior from the coverage analysis.
This controller has multiple discrete filters with missing condition and MCDC coverage. Looking under the mask I see some blocks whose outcomes I always expect to be false. In fact, the output of the subsystem should never be true in any valid configurations for this project. As this is the case for all instances of the block, I can extend the filter to every subsystem of this type.
Custom libraries are often produced by a centralized group within an organization and then distributed to design teams. The blocks in the custom library are thoroughly tested so that end users don't have to be concerned with their internal logic. Yet such library blocks will often contain complex logic that could result in missing coverage for the design model. This is often also the case for other types of reusable subsystems.
To address the missing coverage, you could duplicate the tests used by the team that created the block, but this might require significantly expanding the size of your test suites, which makes them more burdensome and increases their execution time.
An alternative is to exclude any decision and condition coverage objectives for the library blocks. This can be done for each instance of a library block or reusable subsystem individually, but if you want to exclude all library blocks of the same type from coverage analysis you can use this menu option instead.
The Test Manager in Simulink Test can specify filters at the Test File, Test Suite, and Test Case levels, which are applied to the appropriate model elements in the results. If you forget to apply some filters before running the tests, don't worry, they can still be applied retroactively in the results pane and so there is no need to rerun your tests. The metadata defining the filter can also be stored within the .MLDATX file so that it is persistent across sessions, being applied consistently and automatically.
Missing coverage can also be due to dead logic making an objective unsatisfiable. In this Stateflow chart, my tests are unable to achieve full coverage because some transitions are unreachable.
Depending on your requirements, you might have to eliminate the dead logic from your model, but in other cases it might be enough to identify it, explain it, and then deal with the unsatisfiable objective with a filter. You can use Simulink Design Verifier to detect dead logic and automatically create a filter justifying the missing coverage.
Use filters to justify unsatisfiable or unnecessary coverage objectives, so you can concentrate your testing efforts on the addressable portions of your model, and get more actionable results that accurately reflect your testing quality, documenting your rationale along the way. Specify coverage filters in your Simulink Test files, applying them consistently to all appropriate tests and displaying them in generated reports, or introduce them retroactively to existing results.
For more information on filtering coverage results, please follow the documentation and example links below.
