Why diagnostic coverage is the first question in DCS troubleshooting
A DCS controller that reports "healthy" is only reporting what its own diagnostics test. In functional-safety language, diagnostic coverage (DC) is the proportion of dangerous failures that the built-in tests detect. IEC 61508 defines it as a ratio: dangerous detected failure rate divided by total dangerous failure rate, and it is usually expressed as a percentage band rather than a single number.
The practical consequence for maintenance teams is that a silent failure — a slightly drifting analogue input, a sluggish output, a communication path that only degrades under load — can sit inside a controller that passes every self-test. Understanding which failure modes the system actually covers is the difference between a real diagnosis and a false sense of security.
Safety and stop conditions first
- Never disable, bypass or force a safety instrumented function, watchdog, interlock or redundant-controller switchover to "test" diagnostics.
- Do not open cabinets, remove I/O modules, disconnect field wiring or touch terminals while the loop is live. Controller and I/O faults are investigated from the engineering station and with the loop owner's permission.
- If the plant is in an upset, a trip is pending, or a safety function has already degraded, stop troubleshooting and hand control back to the shift supervisor.
- Any change to diagnostic configuration on a SIL-rated controller is a management-of-change action, not a maintenance quick fix.
Group the likely causes before touching anything
When a DCS does not detect a fault you believe exists, the cause usually falls into one of four groups:
1. The failure mode is outside the diagnostic scope
Most controllers monitor for rail voltage out of range, memory errors, watchdog expiry, scan overruns and card communication loss. They typically do not detect a field instrument that still outputs a plausible but wrong value, an impulse line partially blocked, or a valve that strokes slowly. That is a coverage limit, not a fault in the controller.
2. Diagnostics are configured but not annunciated
A diagnostic bit that is set but never routed to an operator alarm is effectively invisible. Check whether the diagnostic is mapped into the alarm and event subsystem, whether it is suppressed by an alarm flood, and whether the message priority is below the operator's attention threshold.
3. Redundancy is masking the fault
In a redundant pair, one controller or one I/O card can fail while the system continues to run. The fault is visible only in the diagnostic buffer, the redundancy status display, or the sequence-of-events log. Undetected degradation of the standby side converts a protected system into a single point of failure.
4. Test intervals are longer than the failure is tolerable
Proof tests and partial-stroke tests prove coverage only at the moment they are performed. A diagnostic that only runs during a proof test provides no coverage between tests, however good the documented percentage looks.
Safe checks in order
- List the failure modes claimed in the safety manual or vendor documentation. Do this from documents, not from memory. Note which modes are marked as detected, undetected, or not applicable.
- Match each claim to a real diagnostic in the running system. For each detected mode, identify the specific diagnostic function, its location (controller CPU, I/O card, field device), and its default configuration state.
- Confirm the diagnostic is enabled and annunciated. Review the alarm and event configuration for the diagnostic source. Suppressed or shelved alarms count as undetected from an operator's point of view.
- Review the diagnostic buffer and sequence-of-events history for entries that cleared before anyone acted — repeated card resets, communication retries, redundancy sync errors. A pattern of self-clearing entries is the strongest evidence of a real degradation.
- Check scan time, CPU load and communication statistics against the baseline recorded at commissioning. Rising scan time or retry counters indicate a developing fault that may not yet trip any threshold.
- Compare against the last proof-test record. Look at what was actually tested, by whom, and with what result — not just the pass tick.
Interpreting the results
Three outcomes are common and each points a different way:
- Diagnostics are present, correct and annunciated, but the suspected failure is undetected. The failure mode is outside coverage. The response is a design review of the loop's detection strategy, not controller repair.
- Diagnostics are present but were silenced, shelved or never mapped. A configuration and alarm-management issue. Fix the mapping, then verify with a controlled test procedure under management of change.
- Diagnostics are absent or fail their own self-test. A genuine controller or I/O hardware fault. Escalate to the vendor with the diagnostic buffer export and the sequence-of-events extract.
Documented DC values are input to a reliability calculation, not a measurement of your plant. Treat any figure in a manual as a target to be verified against the installed configuration.
When to escalate
- Any safety instrumented function with a claimed integrity level whose diagnostic coverage cannot be demonstrated in the installed system.
- Repeated redundancy sync errors, controller resets or card dropouts, even if the plant stayed online.
- Any diagnostic disabled, shelved or overridden with no recorded justification or expiry date.
- Proof-test records that show the same loop repeatedly failing the same step.
- Discrepancies between the installed configuration and the safety manual that no one can explain.
Prevention
- Keep a living diagnostic coverage register per controller: failure mode, diagnostic, location, alarm destination, last verified date.
- Record a commissioning baseline of scan times, CPU load and communication counters, and re-baseline after every significant change.
- Review standing alarm suppressions and overrides at every shift handover or at a fixed weekly cadence.
- Schedule partial tests between full proof tests so coverage is demonstrated more often than once a maintenance cycle.
- Feed every detected-but-unactioned diagnostic event into the alarm rationalisation process rather than deleting it.
What to record
For each investigation, capture: controller and I/O hardware identities, firmware version, the failure mode under investigation, the diagnostic mapped to it and its state, alarm configuration evidence, diagnostic buffer and event-log extracts, scan time and load readings against baseline, and the decision taken. This record is what makes a later audit or incident review possible.
Sources
- IEC 61508 (functional safety of electrical/electronic/programmable electronic safety-related systems) — definitions of diagnostic coverage, safe failure fraction and hardware fault tolerance.
- IEC 61511 (functional safety for the process industry sector) — requirements for safety instrumented systems and proof testing.
- ISA-18.2 and IEC 62682 — alarm management practices covering annunciation, suppression and rationalisation.
- Controller vendor safety manuals and diagnostic documentation for the specific hardware installed at your site.
Standards and vendor documents are revised periodically; verify the edition and the exact figures against the copy held by your site before relying on them.