Diagnostic Coverage (DC) of a safety mechanism is the fraction of the failure rate of an element that is detected (or controlled) by that mechanism:
DC = (rate of detected failures) / (total failure rate of element)
Or equivalently: DC = 1 − (residual failure rate / total failure rate)
DC is expressed as a percentage and must be justified by evidence for each safety mechanism.
| Safety Mechanism | Fault Type Detected | DC Range | Notes |
|---|---|---|---|
| Plausibility check (range) | Stuck-at-high/low, open | 60–90% | Limited: doesn't catch drift within range |
| Cross-channel comparison | Drift, stuck-at, offset | 90–99% | Requires diverse channels; CCF risk |
| CRC-16/CRC-32 on data | Data corruption, bit flip | ≥ 99% | Multi-bit errors; coverage depends on polynomial |
| ECC (SEC) on RAM/flash | Single bit flip | 100% detect + correct | SEC: corrects 1 bit; DED: detects 2 bits |
| ADC reference channel | ADC gain/offset error | 90–97% | Internal reference vs external reference comparison |
| Window watchdog | Task hang, timing violation | ≥ 99% | If correctly sized and not trivially kickable |
| Lockstep CPU | CPU instruction execution error | ≥ 99% | Random hardware faults only; not SW bugs |
| ROM CRC test (startup) | ROM bit corruption | ≥ 99% | Must be done at every startup or periodically |
| RAM March test (periodic) | Latent RAM cell fault | 60–90% | Coverage depends on test algorithm depth |
/* Fault injection testing: validate that safety mechanism achieves claimed DC */
/* Required for ASIL-D to justify DC > 90% (ISO 26262 Part 5 Annex D) */
/* Method 1: Compile-time fault injection (mutation testing) */
/* Tool: Squore, Parasoft, LDRA with mutation support */
/* Inject fault: flip a bit in sensor reading; confirm diagnostic detects it */
/* Method 2: Runtime fault injection via debugger/test interface */
/* Available: JTAG hardware breakpoint → modify variable → confirm detection */
/* Example: injecting torque sensor stuck-at fault */
#include "TorqueSensor.h"
#include "SafetyMonitor.h"
#ifdef FAULT_INJECTION_ENABLED /* compile flag; only in test builds */
static boolean g_fi_ch_a_stuck = FALSE;
static float g_fi_ch_a_value = 0.0f;
float TorqueSensor_ReadChannelA(void)
{
float real_value = ADC_Read(ADC_TORQUE_CH_A);
if (g_fi_ch_a_stuck) {
return g_fi_ch_a_value; /* override with injected fault */
}
return real_value;
}
/* Test: inject stuck-at-0V fault; confirm range check triggers within 20ms */
void FaultInjection_Test_RangeCheck(void)
{
g_fi_ch_a_stuck = TRUE;
g_fi_ch_a_value = 0.0f; /* 0V = below valid range (0.3V–4.7V) */
uint32_t t_start = Timer_GetMs();
while (!SafetyMonitor_IsFaultActive(FAULT_TORQUE_CH_A_RANGE)) {
if (Timer_GetMs() - t_start > 20u) {
TEST_FAIL("Range check did not trigger within FTTI (20ms)");
break;
}
}
uint32_t detection_ms = Timer_GetMs() - t_start;
TEST_LOG("Range check detection time: %u ms", detection_ms);
TEST_ASSERT(detection_ms <= 10u); /* FHTI = FTTI/2 = 10ms */
g_fi_ch_a_stuck = FALSE;
SafetyMonitor_ClearFault(FAULT_TORQUE_CH_A_RANGE);
}
#endif /* FAULT_INJECTION_ENABLED */| Method | Evidence Type | Accepted For | Limitations |
|---|---|---|---|
| ISO 26262 Annex D lookup | Standard reference table | All ASIL levels; fast | Conservative estimates; may underestimate actual DC |
| Analytical calculation | Mathematical model of failure modes vs mechanism | ASIL-C/D where higher DC is claimed | Requires detailed fault model; must be reviewed |
| Fault injection testing | Test evidence from hardware fault injection | Best evidence; supports > 99% claims | Expensive; requires test infrastructure |
| FMEA cross-reference | FMEA-derived DC from failure mode analysis | ASIL-B/C; supports Annex D values | Less rigorous than injection; acceptable with review |
DC estimation is one of the most scrutinised aspects of a functional safety assessment because it directly determines whether the SPFM and LFM targets are met. Using ISO 26262 Annex D lookup values is conservative and well-accepted; claiming DC values above Annex D requires additional evidence (fault injection tests or detailed analytical justification). A common assessor finding: a project claims DC = 99% for a plausibility check, but ISO 26262 Annex D caps plausibility checks at 90% — the higher claim requires fault injection test evidence. The fault injection tests themselves must be systematic (covering all failure modes in the FMEA) and documented in a test report that links each test case to the specific DC claim it validates.
This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.
Key principles to reinforce:
Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.