Proof Test or Diagnostic Test — Most Engineers Can't Tell the Difference

Most engineers know that testing is part of functional safety. Fewer know that the same physical test can be classified as a proof test in one process and a diagnostic test in another — and that the classification changes your functional safety work. Getting this wrong does not just affect paperwork. It corrupts your PFD calculation, distorts your SIL claim, and leaves you exposed in an audit.

Failures Do Not Announce Themselves

There are three ways a failure gets revealed in an industrial process.

The first is abnormal process behavior. The process stops behaving as expected — a transmitter fails safe, a valve gets stuck, a vessel cannot be emptied. Something breaks, and you notice because the process tells you.

This is not a detection method. It is a failure mode. If you only discover a problem when the plant shuts down or an explosion occurs, you have not detected the failure — you have experienced its consequence. Relying on process behavior as a failure-detection mechanism is not functional safety practice. It is the absence of it.

The second and third ways are the only ones that count: proof testing and diagnostic testing.

Every Test Has Three Characteristics

Before separating the two test types, it is worth being precise about what a test actually is. A test that produces a result nobody acts on is not a test. It is a formality.

Every valid test has exactly three characteristics:

Frequency. How often is the test performed? Monthly? Annually? Hours? Milliseconds? Frequency determines how long a dangerous failure can exist before it is found.

Coverage. What percentage of failure modes does this test actually detect? A test with low coverage leaves large gaps, even if run frequently.

Response. What happens when the test detects something? A result without a decision is noise. If an alarm fires and nobody acts, the test served no purpose. The response can range from an automated safe state to a maintenance work order — but there must be a defined response.

These three characteristics apply to every test in functional safety. The distinction between proof testing and diagnostic testing is not about the characteristics — it is about how a specific test satisfies them.

The Four Rules for a Diagnostic Test

A test is a diagnostic test when it meets all four of the following conditions:

1. It runs automatically. No person initiates it. No operator presses a button. No field technician is involved. The test runs by itself — built into the device or system.

2. It runs frequently. "Frequently" in this context means often enough to qualify under IEC 61508 as a diagnostic mechanism. In practice this means continuously or at a cycle short enough to influence the diagnostic coverage fraction in your calculation.

3. It produces an automated, safe response. The result of the test must trigger a defined automated action. That action may be as simple as raising an alarm — "this device needs attention" — or as significant as initiating a safe shutdown. What it cannot be is nothing.

4. It is relevant to the safety function. A diagnostic test in the functional safety sense must detect failure modes that are relevant to the safety function. If a transmitter's diagnostic confirms that its local display has failed, that matters for maintenance — but it does not qualify as a safety-relevant diagnostic in terms of functional safety. The safety function is what the test must protect and in this case the safety function works even without the display.

What Proof Testing Covers

If a test does not meet all four conditions above, it is a proof test.

Proof tests most of the time have one or more persons involved. An operator initiates the test. A field technician observes whether the valve closes. A maintenance team follows a written procedure and records the result. The human element is what most directly distinguishes a proof test from a diagnostic test.

This has practical consequences. Proof tests are typically:

• Not built in. To proof test a final element such as a safety valve, you may need additional equipment — limit switches to confirm valve position, a positioner to stroke the valve, bypass procedures to isolate the function safely. This equipment is often not provided with the device itself. You specify it, procure it, and install it.
• Less frequent. Because proof tests require human involvement and often require a process interruption, they are typically carried out on intervals of months or years — not minutes or seconds.
• Limited in coverage. A proof test can be partial or full. A partial stroke test on a shutdown valve exercises part of the failure mode space. It does not confirm full closure. The test coverage can reflect this in your PFD calculation.

The partial stroke test example is a useful one. If an operator initiates a partial stroke test on a safety valve once a month, that is a proof test — an operator is involved. If you fully automate that partial stroke test, it still may not qualify as a diagnostic. Frequency matters: if the automated partial stroke runs only once a month, the frequency is not high enough to count as a diagnostic under IEC 61508. It is still a proof test, now just one that happens to be initiated automatically.

Where Engineers Get This Wrong

The most common error is treating automated initiation as sufficient to classify a test as diagnostic. It is not. Automation satisfies the first condition. It does not satisfy the frequency or response conditions on its own.

A second common error is including non-safety-relevant diagnostics in the diagnostic coverage or DC. A device may have a rich set of internal diagnostics — communication checks, memory checks, configuration monitors — but only those that detect failures relevant to the safety function can be credited in the calculation. The rest are maintenance diagnostics, not functional safety diagnostics.

A third error is applying the wrong test interval to the proof test frequency calculation. Proof test interval directly affects PFD. If your procedure says annual proof testing but the test is actually carried out every 18 months in practice, your PFD calculation is wrong and your SIL claim is unsupported.

What Correct Looks Like

For every safety function, there should be a clear and documented answer to these questions:

• Which failures does the diagnostic test detect, and what is its coverage fraction?
• Which failures are only detectable by the proof test?
• What is the actual proof test interval — and is it confirmed in the maintenance records?
• Is the response to both tests defined, assigned, and followed?

The split between diagnostic coverage and proof test coverage is what determines the dangerous undetected failure fraction in your PFD calculation. If the boundary between the two test types is blurry, so is your number.

Why All This Talk About Testing

We need to have this discussion because there are other functional safety parameters that depend on it. Failure rates — detected, undetected, SFF, DC, PFD, PFS — all depend on or are influenced by whether a test was classified as a diagnostic test or a proof test. And that is going to be the topic of other articles.

For every safety function you work on: can you clearly separate which failures the diagnostic catches and which only the proof test will find?