Course contentsShow
← Embedded Systems & Computer Architecture
Lesson 694 of 9369. Embedded Systems Reliability and SafetyFree lesson

Measuring Code Coverage for Mission Critical Systems

Quantify test effectiveness using statement, branch, and modified condition/decision coverage metrics to ensure all execution paths are thoroughly validated.

In this lesson, you will learn how to quantify the effectiveness of your verification process using structural coverage metrics to ensure your mission-critical firmware is thoroughly exercised.

When developing safety-critical embedded systems, knowing that a test suite "runs" is insufficient; we must prove which parts of the control logic have actually been executed by the CPU. We use three primary metrics to provide this objective evidence:

1. Statement Coverage

Statement coverage is the simplest metric, measuring the percentage of individual lines of code executed. If your code is if (x) { do_a(); }, statement coverage confirms that do_a() was reached. However, it fails to reveal if the if condition was ever evaluated as false.

2. Branch Coverage

Branch coverage requires that every path from a decision point is taken. For the code block below, we must test both the true and false outcomes of the condition:

if (sensor_value > THRESHOLD) {
    activate_safety_latch(); // Branch 1
} else {
    clear_safety_latch();    // Branch 2
}

If you only test sensor_value scenarios that trigger the latch, you have 100% statement coverage but only 50% branch coverage.

3. Modified Condition/Decision Coverage (MC/DC)

In mission-critical systems (like aerospace or medical devices), standard branch coverage is often considered inadequate for complex logic. MC/DC is the gold standard; it requires showing that each individual condition within a complex decision can independently affect the outcome.

Consider if (A || B). To achieve MC/DC, you must test cases where:

  1. A is true, B is false (result is true).
  2. A is false, B is true (result is true).
  3. A is false, B is false (result is false).

By demonstrating that each variable can independently change the decision outcome, we prove that there is no "dead code" or logic paths that could trigger an unvalidated system state during a fault. In safety-critical development, achieving 100% MC/DC is often a regulatory requirement to prove that every bit of logic contributes to the safety of the system.

Key Takeaway: Measuring coverage via statement, branch, and MC/DC metrics ensures that your tests are not just executing code, but are rigorously validating every logical decision point to prevent latent faults in safety-critical systems.