FENNECWhat Is Diagnostic Coverage (DC)? How It Affects Your SIL Calculations
Diagnostic coverage determines whether your safety architecture can actually achieve its SIL target. Here’s how to calculate it and design around it.
)
Most engineers encounter “diagnostic coverage” somewhere deep in a SIL calculation spreadsheet, usually as a percentage they’re supposed to fill in without a clear explanation of what it actually measures. They pick a number, the spreadsheet turns green, and they move on.
That works until an assessor asks how they arrived at the figure, or until the architecture they designed around an incorrect DC value fails to achieve the required SIL.
This post explains what diagnostic coverage actually is, how to calculate it, how it cascades into architecture decisions, and what it takes to track it accurately at scale.
What Diagnostic Coverage Actually Measures
Diagnostic coverage quantifies how effectively the diagnostic tests in a safety function detect dangerous failures before they cause harm.
The definition from IEC 61508:
DC = (failure rate of detected dangerous failures) / (failure rate of all dangerous failures)
In plain terms: of all the dangerous hardware failures that could occur, what fraction does your diagnostic test catch?
A DC of 90% means 90% of dangerous failures are detected. The other 10% are undetected dangerous failures (those drive your residual risk).
DC is not a measure of test frequency. It is not a measure of diagnostic depth. It is specifically about the fraction of dangerous failures that get detected by whatever diagnostics you have implemented.
DC Categories: None, Low, Medium, High
IEC 61508 defines DC in bands rather than exact values. Here is how they map:
DC Category | Coverage Range | Typical Application | SIL Impact |
|---|---|---|---|
None | < 60% | No diagnostics or very limited self-test | Limits you to low SIL without redundancy |
Low | 60% to < 90% | Basic diagnostics (e.g., simple output monitoring) | Achievable at SIL 1; challenging at SIL 2 without architectural constraints |
Medium | 90% to < 99% | Moderate diagnostics (e.g., plausibility checks, watchdog timers) | Supports SIL 2 in many single-channel architectures |
High | >= 99% | Comprehensive diagnostics (e.g., cross-channel comparison, signature analysis) | Required for SIL 3 in single-channel; enables SIL 2 with simpler hardware |
The category you achieve constrains what SIL level is achievable given your hardware fault tolerance (HFT) and your safe failure fraction (SFF). You cannot independently optimize DC and expect SIL to follow.
How DC Feeds Into SIL Calculations
DC enters the SIL calculation via the probabilistic failure model. When you compute PFH (probability of dangerous failure per hour) or PFD (probability of failure on demand), undetected dangerous failures contribute more heavily than detected ones.
A detected dangerous failure can trigger a safe state or a maintenance action. An undetected failure sits dormant, accumulating risk until the proof test interval catches it or a demand exposes it.
The simplified relationship for a 1oo1 (single-channel) architecture:
Detected dangerous failures: contribute at a lower effective rate because the diagnostic response limits exposure
Undetected dangerous failures: contribute at the full rate, weighted by the proof test interval (T1)
Raising DC reduces the undetected fraction, which reduces PFH/PFD directly. This is why DC is not a documentation checkbox. It is a variable in the math that determines whether you hit your SIL target.
When engineers underestimate DC, they build a system that they believe achieves SIL 2 but actually falls short. When they overestimate DC, they over-engineer redundancy they did not need.
Architectural Implications: How DC Shapes Your Redundancy Decisions
This is where the DC calculation actually drives hardware choices. The interaction between DC and hardware fault tolerance (HFT) determines what architectures are viable at each SIL level.
Consider two scenarios for a SIL 2 target:
Scenario A: High DC (99%), 1oo1 architecture
A single channel with comprehensive diagnostics may achieve SIL 2 if the failure rate of the hardware is low enough. The high diagnostic coverage means very few dangerous failures go undetected.
Scenario B: Low DC (80%), 1oo1 architecture
The same hardware with weaker diagnostics cannot achieve SIL 2 in a 1oo1 architecture. You would need to move to a 1oo2 or 2oo3 configuration to compensate.
1oo2 (one-out-of-two) architectures improve fault tolerance at the cost of introducing common cause failures (CCF). You need to demonstrate beta factor (common cause failure fraction) separately.
2oo3 (two-out-of-three) architectures offer higher availability alongside fault tolerance but carry higher hardware and validation costs.
The architectural choice you make traces directly back to the DC you can demonstrate. If you commit to a 1oo1 architecture early in design, you are committing to high DC. If you find out your DC is medium after the architecture is set, you are either adding redundancy late or accepting a lower SIL ceiling. That retrofit is expensive. The hazard analysis and architecture decisions need to happen together, not sequentially.
Where DC Estimation Goes Wrong
The most common errors:
Using vendor claims without verification. Sensor or actuator datasheets sometimes include DC figures. Those figures apply under specific diagnostic implementations. If your implementation does not match what the vendor assumed, the published DC does not apply.
Assigning DC to the component rather than the diagnostic test. DC is a property of what your system detects, not of the component itself. A component with a high dangerous failure rate and poor diagnostics has low DC regardless of how well-built it is.
Ignoring proof test coverage. The proof test interval (T1) and proof test coverage interact with DC. A long proof test interval with medium DC produces a higher PFD than a short proof test interval with the same DC.
Treating DC as a one-time calculation. DC changes when hardware changes, when diagnostics are updated, and when the safety function scope is modified. It needs to be tracked across the lifecycle, not computed once and filed.
This tracking burden is part of why roughly 60% of safety engineering time gets spent on documentation rather than actual design work. When DC values live in spreadsheets disconnected from the architecture they describe, every change requires manual reconciliation across multiple documents.
How ASAP Handles DC Tracking
A platform built for the full safety lifecycle needs to make DC a first-class input, not an annotation in a separate spreadsheet.
ASAP connects DC values to the architecture they describe. When a component’s diagnostic configuration changes, the affected SIL calculations update. When you add a channel to a 1oo1 architecture to move to 1oo2, the model reflects that. The safety case stays current without a separate reconciliation pass.
This matters at scale. A single autonomous system may have dozens of safety functions, each with its own DC values, each contributing to an overall safety argument. Tracking that manually is where errors accumulate and where assessors find gaps.
Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. The qualification gives independent evidence about those named tools and versions. It does not replace project-specific review of diagnostic coverage, SIL calculations, or safety-case evidence. The T2 Tool Qualification covers the calculations, the traceability, and the documentation, so the output you give an assessor is already at the evidentiary standard they require.
Frequently asked questions
What is the difference between diagnostic coverage and safe failure fraction (SFF)?
DC measures the fraction of dangerous failures that get detected. SFF measures the fraction of all failures (safe and dangerous) that are either safe or detected. They are related but distinct. SFF includes safe failures, which are counted as contributing positively to the safety argument even without detection. DC focuses specifically on dangerous failures and what fraction of them your diagnostics catch. Both feed into SIL capability calculations.
Can I use manufacturer-supplied DC values in my calculation?
You can use them as a starting point, but you need to verify that your diagnostic implementation matches the assumptions behind those values. Manufacturer figures often assume specific test types, test rates, and diagnostic architectures. If your implementation differs, you need to justify the figure you use in your safety case.
Does higher DC always mean better?
Higher DC reduces the undetected dangerous failure rate, which is generally good. But higher DC usually requires more sophisticated diagnostics, which adds complexity, potential failure modes, and cost. There is a point of diminishing returns, and the right DC target depends on what SIL you need and what architecture you are using. Designing for DC higher than your SIL target requires is unnecessary engineering.
How does DC interact with proof test intervals?
Undetected dangerous failures accumulate between proof tests. A longer proof test interval means more exposure time for undetected failures, which increases PFD. Higher DC reduces the number of undetected failures, which partially offsets a longer proof test interval. In practice, both are design variables you can trade against each other, within limits set by your SIL target.
Do I need to recalculate DC when I update firmware or change a diagnostic routine?
Yes. DC is a property of what your diagnostic tests actually detect. If you change the test, you have changed DC. Any modification to diagnostics, diagnostic test rate, or the scope of what the diagnostic covers requires re-evaluation of the DC figure and, potentially, re-evaluation of the SIL calculation that depends on it.
)