Proof testing a safety loop resets its hidden dangerous failures back toward zero, so the more often you test, the lower the average probability of failure. But testing is not free: every test costs labor, may require a shutdown or a bypass, and can itself trigger a spurious trip. Proof-test interval optimization is the engineering exercise of finding the longest interval you can run while still meeting the target integrity level, balancing integrity against cost and nuisance trips. This page is about that tradeoff and how to solve it, not about how a proof test is performed.
Proof-test interval optimization in one line: Proof-test interval optimization is the process of choosing the longest interval between proof tests that still keeps a safety loop's average probability of failure within its target integrity level. Because PFDavg rises with the interval, shortening it improves integrity but raises cost and spurious-trip exposure, so the goal is to solve for the maximum interval that meets the target rather than testing as often as possible.
For a device whose dangerous failures are only revealed by testing, the average probability of failure on demand scales, to a good approximation, with the test interval: roughly half the dangerous-undetected failure rate multiplied by the interval. The physical picture is simple. A hidden dangerous failure can occur at any time between tests, sits undetected until the next test finds it, and so the loop's unavailability grows steadily across the interval and is cut back at each test. A shorter interval means a smaller sawtooth and a lower average.
That would argue for testing constantly, except that testing has real costs on the other side of the ledger. Each proof test consumes maintenance labor and often requires taking the function offline, bypassing it, or forcing the process into a special state, all of which carry operational cost and risk. Worse, many proof tests exercise the final element, and every such exercise is an opportunity for a spurious trip that shuts down production for no safety reason. Testing too often can therefore make a plant less reliable overall, not more safe.
So the interval is genuinely a two-sided optimization. Test too rarely and the loop drifts out of its integrity target; test too often and you burn money, invite spurious trips, and accumulate wear from the testing itself. The optimal interval is the longest one that still lands the loop's PFDavg at or below the ceiling for its target level, which is a very different objective from testing as frequently as you can manage.
The core calculation runs backward from the requirement. You know the target integrity level and therefore the maximum allowable PFDavg. You know the dangerous-undetected failure rate for each element from its failure data. Rearranging the relationship between PFDavg and the interval lets you solve for the largest interval that keeps the loop under its ceiling, treating the interval as the unknown rather than assuming it. In a loop with several elements, each contributes to the total, so the interval that works is the one that keeps the sum within the target.
Diagnostics and partial testing change the arithmetic in your favor. Online diagnostics convert some dangerous-undetected failures into dangerous-detected ones, which are caught continuously rather than only at a proof test, shrinking the term that grows with the interval. Partial-stroke testing of a valve exercises part of its failure population frequently and cheaply without a full trip, so it lets the full proof test, the expensive one that needs the valve to actually close, be spaced further apart while still keeping the overall average in range.
Two cautions keep the optimization honest. First, a proof test rarely reveals every dangerous failure, so an imperfect test leaves a residual term that does not reset and limits how far the interval can safely be stretched. Second, the interval must stay within the device's useful life; you cannot lengthen a proof-test interval past the point where the constant-failure-rate assumption itself breaks down. A defensible interval respects both the target ceiling and these physical limits.
An optimized interval is only as good as the assumption that the tests actually happen on schedule and that the failure data behind them is real. Both of those are records questions. If proof tests slip, or if the failures they find are never captured, the interval you calculated no longer matches the loop's true behavior, and the integrity you claim is fiction. Keeping the test schedule and its results visible is what makes an optimized interval trustworthy in practice.
A cloud SCADA platform helps by logging when each proof test and partial-stroke test occurred, what it found, and whether any element failed, building the operating record that both proves compliance and refines future interval decisions. When the recorded failure history diverges from the failure rates the optimization assumed, that is a signal to revisit the interval rather than let it drift, and having the history in one place makes the divergence visible instead of hidden.
Because Merobix reads field devices into a single browser-based view and retains their history, it turns the proof-test schedule from a spreadsheet nobody trusts into a live record that maintenance and reliability engineers share. That record is the evidence a longer interval rests on: it shows the tests were done, shows what they revealed, and gives engineers the confidence to hold or adjust the interval on data rather than caution alone.
It lowers the average probability of failure on demand, but not without cost. More frequent testing raises labor and downtime cost and increases the chance of a spurious trip, especially when the test exercises the final element. Testing too often can reduce overall plant reliability, so the goal is the longest interval that still meets the target integrity level, not the shortest possible one.
Partial-stroke testing exercises part of a valve's failure population frequently and cheaply, without forcing a full closure or a trip. By catching some dangerous failures between full proof tests, it reduces the term that grows with the interval, which lets the expensive full proof test be spaced further apart while the loop's average still stays within its target.
No. Two limits apply. An imperfect proof test leaves a residual failure term that never resets, capping how far the interval can safely stretch. And the interval must stay inside the device's useful life, because past that point the constant-failure-rate assumption behind the whole calculation breaks down. A defensible interval respects both limits, not just the target ceiling.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.