## Types of Model Coverage

Simulink® Coverage™ can perform several types of coverage analysis.

### Execution Coverage (EC)

Execution coverage is the most basic form of coverage. For each item, execution coverage determines whether the item is executed during simulation.

### Decision Coverage (DC)

Decision coverage analyzes elements that represent decision points in a model, such as a Switch block or Stateflow® states. For each item, decision coverage determines the percentage of the total number of simulation paths through the item that the simulation traversed.

For an example of decision coverage data in a model coverage report, see Decisions Analyzed.

### Condition Coverage (CC)

Condition coverage analyzes blocks that output the logical combination of their inputs (for example, the Logical Operator block) and Stateflow transitions. A test case achieves full coverage when it causes each input to each instance of a logic block in the model and each condition on a transition to be true at least once during the simulation, and false at least once during the simulation. Condition coverage analysis reports whether the test case fully covered the block for each block in the model.

When you collect coverage for a model, you may not be able to achieve 100% condition coverage. For example, if you specify to short-circuit logic blocks, by selecting Treat Simulink Logic blocks as short-circuited in the Coverage pane in the Configuration Parameters, you might not be able to achieve 100% condition coverage for that block. See MCDC Analysis for more information.

For an example of condition coverage data in a model coverage report, see Conditions Analyzed.

### Modified Condition/Decision Coverage (MCDC)

Modified condition/decision coverage analysis by the Simulink Coverage software extends the decision and condition coverage capabilities. It analyzes blocks that output the logical combination of their inputs and Stateflow transitions to determine the extent to which the test case tests the independence of logical block inputs and transition conditions.

• A test case achieves full coverage for a block when a change in one input, independent of any other inputs, causes a change in the block output.

• A test case achieves full coverage for a Stateflow transition when there is at least one time when a change in the condition triggers the transition for each condition.

If your model contains blocks that define expressions that have different types of logical operators and more than 12 conditions, the software cannot record MCDC coverage.

Because the Simulink Coverage MCDC coverage may not achieve full decision or condition coverage, you can achieve 100% MCDC coverage without achieving 100% decision coverage.

Some Simulink objects support MCDC coverage, some objects support only condition coverage, and some objects support only decision coverage. The table in Model Objects That Receive Coverage lists which objects receive which types of model coverage. For example, the Combinatorial Logic block can receive decision coverage and condition coverage, but not MCDC coverage.

To achieve 100% MCDC coverage for your model, as defined by the DO-178C/DO-331 standard, in the Coverage pane of the Configuration Parameters, select Modified Condition/Decision Coverage (MCDC) as the Structural coverage level.

When you collect coverage for a model, you may not be able to achieve 100% MCDC coverage. For example, if you specify to short-circuit logic blocks, you may not be able to achieve 100% MCDC coverage for that block.

If you run the test cases independently and accumulate all the coverage results, you can determine if your model adheres to the modified condition and decision coverage standard. For more information about the DO-178C/DO-331 standard, see DO-178C/DO-331 Checks (Simulink Check).

For an example of MCDC coverage data in a model coverage report, see MCDC Analysis. For an example of accumulated coverage results, see Cumulative Coverage.

### Cyclomatic Complexity

Use this metric to calculate the cyclomatic complexity of the model. Cyclomatic complexity is a measure of the structural complexity of a model. The complexity measure for the model can be different than the generated code due to code features that this analysis does not consider, such as consolidated logic and error checks.

To compute the cyclomatic complexity of an object (such as a block, chart, or state), model coverage uses the following formula:

`$c=\sum _{1}^{N}\left({o}_{n}-1\right)$`

N is the number of decision points that the object represents and on is the number of outcomes for the nth decision point. The calculation considers a vectorized operation or a Multiport switch block as a single decision point. The tool adds 1 to the complexity number for atomic subsystems and Stateflow charts.

The results provide local and aggregated cyclomatic complexity for the:

• Model

• Subsystems

• Charts

• MATLAB® Functions

Local complexity is the cyclomatic complexity for objects at their hierarchical level. Aggregated cyclomatic complexity is the cyclomatic complexity of an object and its descendants.

Cyclomatic complexity:

• Does not run on library models.

• Analyzes content in masked subsystems.

• Does not analyze inactive variants.

• If specified, analyzes the content of library-linked blocks or referenced models.

• Does not analyze referenced models in accelerated mode.

For an example of cyclomatic complexity data in a model coverage report, see Cyclomatic Complexity in the Model Coverage Report. For more information about cyclomatic complexity for code, see Cyclomatic Complexity.

### Lookup Table Coverage

Lookup table coverage (LUT) examines blocks, such as the 1-D Lookup Table block, that output information from inputs in a table of inputs and outputs, interpolating between or extrapolating from table entries. Lookup table coverage records the frequency that table lookups use each interpolation interval. A test case achieves full coverage when it executes each interpolation and extrapolation interval at least once. For each lookup table block in the model, the coverage report displays a colored map of the lookup table, indicating each interpolation. If the total number of breakpoints of an n-D Lookup Table block exceeds 1,500,000, the software cannot record coverage for that block.

For an example of lookup table coverage data in a model coverage report, see N-Dimensional Lookup Table.

Note

Configure lookup table coverage only at the start of a simulation. If you tune a parameter that affects lookup table coverage at run time, the coverage settings for the affected block are not updated.

### Signal Range Coverage

Signal range coverage records the minimum and maximum signal values at each block in the model, as measured during simulation. Only blocks with output signals receive signal range coverage.

The software does not record signal range coverage for control signals, signals used by one block to initiate execution of another block. See Control Signals.

If the total number of signals in your model exceeds 65535, or your model contains a signal whose width exceeds 65535, the software cannot record signal range coverage.

For an example of signal range coverage data in a model coverage report, see Signal Range Analysis.

Note

When you create cumulative coverage for reusable subsystems or Stateflow constructs with single range coverage, the cumulative coverage has the largest possible range of signal values. For more information, see Obtain Cumulative Coverage for Reusable Subsystems and Stateflow® Constructs.

### Signal Size Coverage

Signal size coverage records the minimum, maximum, and allocated size for all variable-size signals in a model. Only blocks with variable-size output signals are included in the report.

If the total number of signals in your model exceeds 65535, or your model contains a signal whose width exceeds 65535, the software cannot record signal size coverage.

For an example of signal size coverage data in a model coverage report, see Signal Size Coverage for Variable-Dimension Signals.

### Objectives and Constraints Coverage

The Simulink Coverage software collects model coverage data for the following Simulink Design Verifier™ blocks and MATLAB for code generation functions:

Simulink Design Verifier blocksMATLAB for code generation functions
Test Condition (Simulink Design Verifier)`sldv.condition` (Simulink Design Verifier)
Test Objective (Simulink Design Verifier)`sldv.test` (Simulink Design Verifier)
Proof Assumption (Simulink Design Verifier)`sldv.assume` (Simulink Design Verifier)
Proof Objective (Simulink Design Verifier)`sldv.prove` (Simulink Design Verifier)

If you do not have a Simulink Design Verifier license, you can collect model coverage for a model that contains these blocks or functions, but you cannot analyze the model using the Simulink Design Verifier software.

• Check the results of a Simulink Design Verifier analysis, run generated test cases, and use the blocks to observe the results.

• Define model requirements using the Test Objective block and verify the results with model coverage data that the software collected during simulation.

• Analyze the model, create a test harness, and simulate the harness with the Test Objective block to collect model coverage data.

• Analyze the model and use the Proof Assumption block to verify any counterexamples that the Simulink Design Verifier identifies.

If you specify to collect Simulink Design Verifier coverage:

• The software collects coverage for the Simulink Design Verifier blocks and functions.

• The software checks the data type of the signal that links to each Simulink Design Verifier block. If the signal data type is fixed point, the block parameter must also be fixed point. If the signal data type is not fixed point, the software tries to convert the block parameter data type. If the software cannot convert the block parameter data type, the software reports an error and you must explicitly assign the block parameter data type to match the signal.

• If your model contains a Verification Subsystem block, the software only records coverage for Simulink Design Verifier blocks in the Verification Subsystem (Simulink Design Verifier) block; it does not record coverage for any other blocks in the Verification Subsystem.

If you do not specify to collect Simulink Design Verifier coverage, the software does not check the data types for any Simulink Design Verifier blocks and functions in your model and does not collect coverage.

For an example of coverage data for Simulink Design Verifier blocks or functions in a model coverage report, see Simulink Design Verifier Coverage.

### Saturate on Integer Overflow Coverage

Saturate on integer overflow coverage examines blocks, such as the Abs block, with the Saturate on integer overflow parameter selected. Only blocks with this parameter selected receive saturate on integer overflow coverage.

Saturate on integer overflow coverage records the number of times the block saturates on integer overflow.

A test case achieves full coverage when the blocks saturate on integer overflow at least once and does not saturate at least once.

For an example of saturate on integer overflow coverage data in a model coverage report, see Saturate on Integer Overflow Analysis.

### Relational Boundary Coverage

Relational boundary coverage examines blocks, Stateflow charts, and MATLAB function blocks that have an explicit or implicit relational operation.

For these model objects, the metric records whether a simulation tests the relational operation with:

• Equal operand values.

This part of relational boundary coverage applies only if both operands are integers or fixed-point numbers.

• Operand values that differ by a certain tolerance.

This part of relational boundary coverage applies to all operands. For integer and fixed-point operands, the tolerance is fixed. For floating-point operands, you can either use a predefined tolerance or you can specify your own tolerance.

The tolerance value depends on the data type of both the operands. If both operands have the same type, the tolerance follows the following rules:

Data Type of OperandTolerance
Floating point, such as `single` or `double`

```max(absTol, relTol* max(|lhs|,|rhs|))```

• `absTol` is an absolute tolerance value you specify. Default is `1e-05`.

• `relTol` is a relative tolerance value you specify. Default is `0.01`.

• `lhs` is the left operand and `rhs` the right operand.

• `max(x,y)` returns `x` or `y`, whichever is greater.

Fixed pointValue corresponding to least significant bit. For more information, see Precision (Fixed-Point Designer). To find the precision value, use the `lsb` (Fixed-Point Designer) function.
Integer1
BooleanN/A
EnumN/A

If the two operands have different types, the tolerance follows the rules for the stricter type. If one of the operands is boolean, the tolerance follows the rules for the other operand. The strictness decreases in this order:

1. Floating point

2. Fixed point

3. Integer

If both operands are fixed point but have different precision, the smaller value of precision is used as tolerance.

You specify the value of absolute and relative tolerances for relational boundary coverage of floating point inputs when you select this metric in the Coverage metrics section in theCoverage Pane of the Configuration Parameters dialog box.