Open the proof test schedule for a typical plant and ask where each interval came from. For many safety instrumented functions (SIFs), the answer is a vendor safety manual, a licensor package or a project template, not a calculation against the plant's own target. This article shows how a proof test interval calculation works, where it goes wrong, and what to record so that the interval can be defended later.
Why inherited intervals are a problem
A recent iFluids article on IEC 61511 proof testing intervals argues that intervals are often inherited from a vendor default, a licensor recommendation, or a project SRS template, rather than calculated against the plant's own PFDavg target. The article is written from an oil and gas perspective in specific regions, but the pattern will be familiar to many engineers elsewhere.
The standard points the other way. A review of the clause history notes that IEC 61511:2016 says the frequency of proof tests for a SIF is determined through a PFDavg or PFH calculation for the SIS as installed in its operating environment. A default interval is therefore a starting assumption at best. It is not a result.
There is also a change-control consequence. An iFluids guide to SIL verification states that verification must be revisited whenever field devices, logic solvers or test intervals change. If you cannot say where the interval came from, you cannot say whether it still holds.
Proof test interval calculation: the basic relationship
For a low demand SIF, the simplest model treats a dangerous undetected failure as present, on average, for half the proof test interval. For a single channel (1oo1) with a perfect test, PFDavg is λDU × TI / 2, where λDU is the dangerous undetected failure rate from the device FMEDA and TI is the test interval. The relationship is linear, so halving the interval roughly halves PFDavg for a single component.
Rearranged, the maximum interval is T_max = 2 × PFDavg target / λDU. The steps are:
- Take the PFDavg target for the SIF from the safety requirements specification (SRS).
- Divide that target into budgets for the sensor, logic solver and final element subsystems.
- For each subsystem, take λDU from a source you can justify, such as a certified FMEDA or your own field data.
- Calculate the maximum interval for that subsystem, then choose a practical interval at or below the shortest result.
Two cautions apply. First, the target belongs to the whole SIF, so a single transmitter does not get the full budget. Second, redundant architectures need different equations. A 1oo2 PFDavg includes both an independent-failure term and a common-cause term, so the linear rule above does not carry over.
The trap: proof test coverage and mission time
The formula above assumes the proof test finds every dangerous undetected failure and restores the device to as-new condition. Rausand and Lundteigen describe this as not realistic, though sometimes realistic enough. Failures the test cannot reveal may stay hidden for the whole life of the system unless a demand occurs or the device is renewed.
A commonly used approximation adds a second term for those failures. As exida's note on mission time gives it, PFDavg ≈ (PTC × λD × PTI)/2 + ((1 − PTC) × λD × MT)/2. Here PTC is proof test coverage and MT is mission time.
A worked example
The numbers below are illustrative, not data for any real device. Assume a final element with λDU of 4 × 10⁻⁷ per hour and a PFDavg budget of 2 × 10⁻³.
- With a perfect test, T_max = 2 × 2 × 10⁻³ / 4 × 10⁻⁷ = 10,000 hours, about 13.7 months. A 12-month interval gives a PFDavg of about 1.75 × 10⁻³.
- Now assume 90% coverage and a 20-year mission time (175,200 hours). The tested part contributes about 1.6 × 10⁻³. The untested 10% contributes about 3.5 × 10⁻³. The total is roughly 5 × 10⁻³, well over budget.
The second term does not depend on the test interval at all. Testing more often cannot fix it. The levers are better coverage (a different test method), a shorter mission time with scheduled replacement, a better device, or a different architecture. Exida also describes a case where an end user's proof test interval was fixed against a turnaround, and mission time had to be cut significantly to compensate.
Useful life sits behind all of this. IEC 61508-2 states that beyond a device's useful lifetime, most probabilistic calculation results are meaningless. A rule of thumb from FunctionalSafetyEngineer.com is that for each device the proof test interval should be shorter than the mission time, which should be shorter than the useful life.
What the documented basis should contain
An auditor should be able to trace the interval without asking the technician to explain it. A reasonable record for each SIF includes:
- The PFDavg target from the SRS and the budget allocated to each subsystem.
- The λDU values used, with their source (FMEDA, safety manual or plant data) and any adjustment for operating environment.
- The architecture, common-cause factor and the equations or tool version used.
- The proof test coverage claimed for each device, and the test procedure step that justifies it.
- The mission time assumed and the replacement or overhaul plan that supports it.
- The resulting interval, the margin against the target, and the approval.
The record has to stay alive after commissioning. Per iFluids' documentation guide, proof test records should show the procedure revision, result per tested element, any degraded-state finding and corrective action. The same guide notes that verification must be re-examined if results consistently show degraded performance, and that a systematic failure to achieve assumed test coverage invalidates the PFDavg calculation. Any change to a proof test interval should pass through management of change.
Key takeaways
- An inherited interval is an assumption. Calculate it against the SIF's own PFDavg target and document the result.
- For a 1oo1 channel with a perfect test, T_max = 2 × PFDavg budget / λDU. Redundant architectures need their own equations.
- Imperfect proof test coverage adds a term that depends on mission time, not on the interval. Check it before you tighten the schedule.
- Record the failure rate source, coverage claim, mission time and approval, and revisit them when devices, test methods or field results change.
- Treat interval changes as management of change items and re-run the verification.
Where to go next
If your team has intervals it cannot trace, the first step is to pick one SIF and rebuild the calculation from the SRS target. The FS Engineer SIS course covers how to apply IEC 61511 across the safety lifecycle, including the evidence needed to support safety functions. For the people who execute the tests, FS Technician SIS covers testing and restoring a SIS without reducing its designed integrity. Dates are on the course calendar.
