Automation Glossary • Diagnostic Coverage

What Is Diagnostic Coverage (DC)?

Merobix Engineering • • 6 min read

Diagnostic coverage is the fraction of dangerous failures that a subsystem's automatic online diagnostics detect on their own. It is one of the most powerful levers in safety design because it decides how many dangerous failures are caught continuously, while the process runs, rather than lying hidden until a proof test or a real demand. A high diagnostic coverage moves failures from the truly threatening undetected category into the manageable detected category. That single shift improves reliability, shortens the time a fault stays dangerous, and feeds directly into other constraints on the achievable integrity level.

Back to Blog

Diagnostic Coverage in one line: Diagnostic coverage (DC) is the proportion of a subsystem's dangerous failure rate that its automatic diagnostics detect, expressed as the dangerous detected failure rate divided by the total dangerous failure rate. By converting dangerous undetected failures into dangerous detected ones, high diagnostic coverage lowers the probability of failure on demand, raises the safe failure fraction, and lets faults be repaired long before a proof test or real demand would expose them.

How Diagnostic Coverage Splits Dangerous Failures

Every subsystem has a rate of dangerous failures, failures that could prevent the safety function from acting. Diagnostic coverage splits that rate into two parts: the dangerous detected failures, which the automatic diagnostics catch, and the dangerous undetected failures, which slip past them. The coverage figure is simply the detected share of the total dangerous failure rate. A coverage of ninety percent means the diagnostics catch nine of every ten dangerous failures automatically and let one go unseen.

The reason this split matters so much is that the two halves behave completely differently in service. A dangerous detected failure announces itself: diagnostics flag it, an alarm is raised, and the fault can be repaired promptly, often before it ever has a chance to defeat a demand. A dangerous undetected failure does the opposite, sitting silently in the subsystem, accumulating until either a proof test finds it deliberately or a real demand finds it at the worst possible moment. Diagnostic coverage is the parameter that governs how many failures fall into each of these very different fates.

Diagnostics achieve this coverage through mechanisms like continuous self-tests, plausibility and range checks on signals, watchdogs, and comparison between redundant channels. The completeness of these mechanisms, and how many failure modes they can actually observe, determines the coverage. Because coverage describes detection specifically for dangerous failures, it is a sharper and more safety-relevant measure than a general count of how many total failures a diagnostic can see.

Why Diagnostic Coverage Drives PFD and Integrity

Diagnostic coverage is a primary driver of the probability of failure on demand for a low-demand function. The undetected dangerous failures are the ones that accumulate between proof tests and dominate the failure-on-demand calculation, because they are the failures that could be present, unnoticed, when a demand arrives. Raising diagnostic coverage shrinks that undetected population directly, which lowers the average probability of failure on demand without changing the raw hardware failure rate at all. It is often the most cost-effective way to improve a function's integrity.

The influence of diagnostic coverage reaches beyond the probability calculation into the architectural constraints as well. Because a dangerous detected failure counts on the favorable side of the safe failure fraction, better diagnostic coverage raises the safe failure fraction, which in turn can relax the fault-tolerance needed to claim a given integrity level. In this way diagnostic coverage ties together several of the core reliability parameters: it improves the numerical failure probability and it strengthens the architectural position at the same time.

There is also a time dimension that pure probability numbers understate. Because detected failures are repaired quickly, high diagnostic coverage keeps the average time a fault stays dangerous very short, whereas undetected failures can remain dangerous for the entire proof test interval. This is especially important for functions demanded often, where a fault that lingers is likely to meet a demand. High coverage therefore not only lowers the calculated risk but also compresses the window during which the function is quietly compromised.

Diagnostic Coverage, SCADA, and Acting on Detections

Diagnostic coverage only delivers its benefit if the detections are acted upon. A dangerous detected failure that is flagged but never repaired is, in practical terms, little better than an undetected one, because the function is still compromised when the demand arrives. The value of high coverage depends on a reliable path from the diagnostic that finds the fault to the maintenance that fixes it. Detection is only the first half; response is the half that actually reduces risk.

This is where continuous monitoring turns diagnostic coverage from a design parameter into a real safety benefit. A SCADA platform that collects diagnostic status from field devices, compares redundant channels, and escalates a detected fault to an operations team ensures the detections are seen and acted on rather than logged and forgotten. The field diagnostics generate the coverage; the monitoring layer makes sure a detected dangerous failure becomes a repair order quickly, which is what the reliability model assumes will happen.

For remote and unmanned oil and gas assets this link is decisive, because there is no one on site to notice a local diagnostic alarm. A detected failure at a distant well or station only leads to repair if the detection reaches a central team through reliable telemetry. Cloud monitoring that dependably surfaces diagnostic findings, prioritizes them, and tracks them to resolution is what allows a high diagnostic coverage figure on paper to translate into genuinely lower risk in the field. Good coverage and good monitoring together are what keep dangerous failures short-lived rather than merely visible.

Frequently Asked Questions

What is the formula for diagnostic coverage?

Diagnostic coverage is the dangerous detected failure rate divided by the total dangerous failure rate, usually expressed as a percentage. It measures the share of dangerous failures that the automatic diagnostics catch on their own, as opposed to those that stay undetected until a proof test or real demand. It deliberately focuses on dangerous failures rather than all failures, because those are the ones that threaten the safety function.

How does diagnostic coverage lower the probability of failure on demand?

Undetected dangerous failures accumulate between proof tests and dominate the failure-on-demand calculation, because they may be present and unnoticed when a demand arrives. Higher diagnostic coverage moves failures out of the undetected category into the detected one, where they are repaired quickly, so fewer dangerous failures are present at any moment. This lowers the average probability of failure on demand without changing the raw hardware failure rate.

What is the difference between diagnostic coverage and proof test coverage?

Diagnostic coverage is the fraction of dangerous failures caught automatically and continuously by online diagnostics while the process runs. Proof test coverage is the fraction of dangerous failures found by a periodic, deliberate proof test. Diagnostics catch failures in near real time so they can be repaired promptly, whereas proof testing catches the remaining failures only at scheduled intervals, so the two work together to limit how long dangerous failures persist.

From Definitions to a Live Dashboard

Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.

Request a Free Demo +1 (903) 307-7300
More in Automation Glossary
Common Cause Failure  •  Logic Solver  •  Final Element  •  Spurious Trip  •  Swinging Door Compression  •  Boxcar & Backslope Compression  •  All Automation Glossary →
Free SCADA operator training
Merobix University - 70 video lessons & 261 quiz questions, from first login to compliance reporting. No demo call required.
Start free →