Stateflow User's Guide Previous page   Next Page

Coverage Reports for Stateflow Charts

The following sections of a Model Coverage report were generated by simulating the Bang-Bang Boiler demonstration model, which includes the Stateflow Chart block Bang-Bang Controller. The coverage metrics for Decision Coverage, Condition Coverage, and MCDC Coverage are enabled for this report; the Look-up Table Coverage metric is Simulink dependent and not relevant to the coverage of Stateflow charts.

This topic contains the following subtopics:

For information on the model coverage of truth tables, see Model Coverage for Truth Tables.

Summary Report Section

The Summary section shows coverage results for the entire test. It appears at the beginning of the Model Coverage report after the listing of the Start and End execution times for the test (simulation).

Each line in the hierarchy summarizes the coverage results at its level and the levels below it. It includes a hyperlink to a later section in the report with the same assigned hierarchical order number that details that coverage and the coverage of its children.

The top level, sf_boiler, is the model itself. The second level, Bang-Bang Controller, is the Simulink Stateflow chart block. The next levels are superstates within the Stateflow chart control logic in order of hierarchical containment. Each of these superstates uses an SF: prefix. The bottom level, Boiler Plant model, is an additional subsystem in the model.

Chart as Subsystem Details Report Section

The Subsystem report sees the chart as a block in a Simulink model, instead of a chart with states and transitions. You can confirm this by taking the hyperlink of the subsystem name in the title; it takes you to a highlighted Bang-Bang Controller Stateflow block sitting in its resident Simulink block diagram.

Chart as Superstate Details Report Section

The Chart report sees a Stateflow chart as the superstate container of all of its states and transitions. You can confirm this through the hyperlinked chart name, which takes you to a display of the control logic chart in the Stateflow diagram editor.

Cyclomatic complexity and decision coverage are also displayed for the chart and for the chart including its descendants. Condition coverage and MCDC are both not applicable (NA) coverages for a chart, but apply to descendants.

State Details Report Section

The example state section contains a report on the state On. The Stateflow diagram for On is as follows:

On resides in the box Heater, which has its own details report (not shown) because it contains other Stateflow objects. However, because On is a superstate containing the two states HIGH and NORM along with a history junction and the function warm, it has its own numbered report in the Details section.

The decision coverage for the On state tests the decision of which of its states to execute. The results indicate that six of a possible six outcomes were tested during simulation. Each decision is described as follows:

  1. The choice of which substate to execute when On is executed
  2. The choice of which state to exit when On is exited
  3. The choice of which substate to enter when On is entered and the History junction has a record of the previously active substate

Because each of the above decisions can result in processing either HIGH or NORM, the total possible outcomes are 3 x 2 = 6.

The decision coverage tables also display the number of occurrences for each decision and the number of times each state was chosen. For example, the first decision was made 124 times. Of these, the HIGH state was executed 88 times and the NORM state was executed 36 times.

Cyclomatic complexity and decision coverage are also displayed for the On state including its descendants. This includes the coverage discussed above plus the decision required by the condition [warm()] for the transition from HIGH to NORM for a total of eight outcomes. Condition coverage and MCDC are both not applicable (NA) coverages for a state.

Transition Details Report Section

Reports for transitions appear under the report sections of their owning states. They do not appear in the model hierarchy of the Summary section, since that is based entirely on superstates owning other Stateflow objects.

The decision for this transition is based on the broadcast of 40 sec events and the condition [cold()]. If, after the reception of 40 sec events (equivalent to a 40 second delay) the environment is cold (cold() = 1), the decision to execute this transition and turn the Heater on is made. For other time intervals or environment conditions, the decision is made not to execute.

For decision coverage, both the true and false evaluations for the decision occurred. Because two of two decision outcomes occurred, coverage was full (that is, 100%).

Condition coverage shows that only 4 of 6 condition outcomes were tested. The temporal condition after(40,sec) is a short form expression for sec[after(40,sec] which is actually two conditions: the event sec and the accumulation condition after(40,sec). Consequently, there are actually three conditions on the transition: sec, after(40,sec), and cold(). Since each of these decisions can be true or false, there are now six possible outcomes.

A look at the Decisions analyzed table shows each of these conditions as a row with the recorded number of occurrences for each outcome for that decision (true or false). Decision rows in which a possible outcome did not occur are shaded. For example, the first and the third decision rows did not record an occurrence of a false outcome and are therefore shaded.

In the MC/DC report, all sets of occurrences of the transition conditions are scanned for a particular pair of decisions for each condition in which the following are true:

For three conditions related by an implied AND operator, these criteria can be satisfied by the occurrence of the following conditions.

Condition Tested
 True Outcome
 False Outcome
1
 TTT
 Fxx
2
 TTT
 TFx
3
 TTT
 TTF

Notice that in each line, the condition tested changes from true to false while the other condition remains constant. Irrelevant contributors are coded with an "x" (discussed below). If both outcomes occur during testing, coverage is complete (100%) for the condition tested.

The preceding report example shows coverage only for condition 2. The false outcomes required for conditions 1 and 3 did not occur, and are indicated by parentheses for both conditions. Therefore the table lines for conditions (rows) 1 and 3 are shaded in red. Thus, while condition 2 has been tested, conditions 1 and 3 have not and MCDC is 33%.

For some decisions, the values of some conditions are irrelevant under certain circumstances. For example, in the decision [C1 & C2 & C3 | C4 & C5] the left side of the "|" is false if any one of the conditions C1, C2, or C3 is false. The same applies to the right side result if either C4 or C5 is false. When searching for matching pairs that change the outcome of the decision by changing one condition, holding some of the remaining conditions constant is irrelevant. In these cases, the MC/DC report marks these conditions with an "x" to indicate their irrelevance as a contributor to the result. This is shown in the following example.

Consider the very first matched pair. Since condition 1 is true in the True outcome column, it must be false in the matching False outcome column. This makes the conditions C2 and C3 irrelevant for the false outcome since C1 & C2 & C3 is always false if C1 is false. Also, since the false outcome is required to evaluate to false, the evaluation of C4 & C5 must also be false. In this case, a match was found with C4 = F, making condition C5 irrelevant.


Previous page  MCDC Coverage Colored Stateflow Diagram Coverage Display Next page

© 1994-2005 The MathWorks, Inc.