Proof Test and Diagnostic Coverage

Last edit: 01/12/2025

THE DOUBT: What is the difference between a Proof Test and a Diagnostic Test?

CONSIDERATIONS: The concept of the Proof Test originates from IEC 61508 and is particularly important for Safety Instrumented Systems (SIS) operating in low-demand mode.

In low-demand applications, a pressure transmitter used for safety purposes may never actually be called upon, or only very rarely. For example, the expected demand rate might be once every 20 years. Suppose that, in a specific application, a high-pressure condition requiring a safety response occurs only once every 20 years. During those 20 years, the safety loop remains essentially dormant—yet when the demand finally occurs, the system must react reliably and bring the process to a safe state.

Safe failures do not pose a problem. Dangerous detectable failures are also not an issue, as they can be identified automatically by the safety system through its built-in diagnostic test routines. The real concern lies with dangerous undetectable failures. These faults cannot be identified by the automatic diagnostics. The only way to reveal them is by performing an off-line test, known as a Proof Test.

Below are the two relevant definitions.

[IEC 61508-4:2010] 3.8.5  Proof Test : Periodic test performed to detect dangerous hidden failures in a safety-related system so that, if necessary, a repair can restore the system to an “as new” condition or as close as practical to this condition.

[IEC 61508-4:2010] 3.8.6  Diagnostic Coverage DC : Fraction of dangerous failures detected by automatic on-line diagnostic tests. The fraction of dangerous failures is computed by using the dangerous failure rates associated with the detected dangerous failures divided by the total rate of dangerous failures.

In low-demand applications, the real concern is the presence of dangerous undetectable failures, which can be identified only through an off-line Proof Test. The execution of this test must strictly follow the procedures specified by the instrument manufacturer in the safety manual. This is particularly important for devices with complex electronics (Type B components), where end users cannot reasonably determine on their own what steps are required for a proper Proof Test. Only the manufacturer is able to define the full test procedure and clarify whether the Proof Test is complete (detecting approximately 100% of relevant failures) or partial.

Although the Proof Test is also referenced in IEC 62061, it is mainly applied in low-demand mode. In high-demand applications (IEC 62061 and ISO 13849-1), where a proof test is implemented it is set equal to the mission time TM. Dangerous Undetected failures are “accepted” and there is no efford to “discover them”.

The primary performance indicator is the Diagnostic Coverage (DC), which is calculated using the following formula:

Where λdd is the rate of detected dangerous hardware failures and λd is the total rate of dangerous hardware failures.

In high demand, safety components are used regularly (example once every hour), accumulation of faults is unlikely and safety relies a lot on the fact a safety loop is regularly activated and therefore tested.

 

CONCLUSIONS:

The Proof Test is an off-line verification of a safety component at the end of which all faults are normally detected (full proof Test). It is used in Low Demand Applications and it has to be performed with a frequency twice the demand upon the safety function. The reliability of a Safety subsystem is directly dependent upon the proof test interval called Ti.

The Diagnostic Test is an automatic test, usually performed by the functional channel of the Safety System and it allows the detection of the Detectable failures.  In case of single channels in series, with diagnostic coverage, the reliability of the whole safety system depends upon such a parameter with the following formula (1oo1D or Architecture C according to IEC 62061):

Safety in Collaborative Robotics
There is no “Collaborative Robot”. That is one of the first statements you hear from people working in Collaborative Robotics. The reason is because...