Y4.06.3Proof testing of safety functionsdesign

A safety function's failure probability has to be reconfirmed by periodic testing, not assumed forever

Aliases: proof testing of safety functions · functional safety

What it is

The failure probability a safety function achieves is not a one-time calculation that holds forever; it needs periodic proof testing to stay confirmed. Latent dangerous failures that online diagnostics cannot see accumulate between tests. A proof test does not re-award a SIL — it confirms that the failure probability and test interval assumed in the original risk calculation still hold.

Why it happens

Online diagnostics — self-test, comparison, watchdogs — catch only a limited range of faults; a sensor drifting slowly or a mechanical part sticking often falls outside their coverage. Once such a fault occurs, it sits undetected until the next proof test or a real demand exposes it — and if it is the latter, the safety function fails exactly when it is needed. A longer test interval widens the window for undetected accumulation and raises the average probability of failure on demand; lower test coverage and longer repair time do the same. An easy trap is incomplete test scope: checking only sensor signals, or simulating a trigger in logic without letting the final element actually move, which skips exactly the stage that produces the safety effect.

Where it stops holding

Testing itself is not risk-free: it may require bypassing the safety function to inject a test signal, during which protection is effectively absent, and full-stroke testing of the final element may only be possible during a shutdown window, so online testing rarely gives complete coverage. Test intervals should not follow an industry-wide calendar figure; they should be derived from the target failure probability and assumed failure rate, then corrected against observed field failure data.

Applying it

Break each safety function into sensor, logic, output, and final-element stages, and design a test step for each, making sure the final element actually moves rather than being verified only at the signal level. Record what failure modes each test covered, the result, any bypass and its duration, and confirmation of restoration. Treat an overdue function as explicitly managed risk rather than silently carrying it forward, and justify interval changes with field defect rates under controlled approval.

Related

  • Same group: Y4.06.1 Safety integrity level determination · Y4.06.2 Architecture and independence at higher SIL · Y4.06.4 Safety integrity versus general reliability
  • Nearby: Y3.10 Parameter limits and safety interlocks · Y4.02 Redundancy and voting
  • Search terms: proof test · probability of failure on demand · functional safety · test interval

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y4.06.3