Knowing what PFDavg means is one thing; being able to compute it is another, and it is the computation that tells an engineer whether a designed safety function actually meets its target. This guide is the how-you-work-it-out companion: it shows the simplified formula for the simplest architecture, explains how redundancy and proof-test interval change the number, and walks through how the sensor, logic solver, and final element PFDs add up so a whole safety instrumented function can be checked against its assigned safety integrity level.
PFDavg calculation in one line: PFDavg is calculated from a subsystem's dangerous undetected failure rate and the interval between proof tests. For the simplest single-channel architecture the widely used simplified equation is PFDavg roughly equal to lambda_DU multiplied by the proof-test interval, divided by two. Redundant architectures such as 1oo2 or 2oo3 lower the result, a longer proof-test interval raises it, and the PFDavg of the sensor, logic solver, and final element subsystems are summed to give the whole function's PFDavg, which is then compared against its target SIL band.
The starting point is the simplest architecture, one-out-of-one, meaning a single channel with no redundancy - one sensor, or one valve, standing alone. Its behavior is driven by one failure rate: lambda_DU, the rate of dangerous undetected failures. These are the failures that both prevent the function from acting and stay hidden, revealed only when the function is tested or actually demanded, which is what makes them the dominant contributor to PFD. Detected failures are announced and can be repaired promptly, so they contribute far less; it is the undetected dangerous failures that quietly accumulate.
For a 1oo1 channel the simplified equation is PFDavg approximately equal to lambda_DU multiplied by TI, the proof-test interval, all divided by two. The intuition behind the divide-by-two is straightforward: a dangerous undetected failure can occur at any point during the interval between tests, so on average the channel spends about half the interval in a failed state before the next proof test finds and corrects it. The average unavailability over the whole interval is therefore roughly half the product of the failure rate and the interval length.
This simplified form is an approximation valid when the failure rate and interval are small enough that the product stays well below one, which is the normal case for a competent design. It deliberately omits second-order contributions to stay tractable and is the workhorse equation engineers reach for first. More detailed treatments add terms for the mean time to repair, for failures found by online diagnostics, and for common-cause effects in redundant channels, but the simplified 1oo1 equation is the conceptual core everything else builds on.
Two levers move PFDavg most. The first is the proof-test interval. Because PFDavg scales with the interval in the simplified equation, testing more often directly lowers it - halve the interval and, to first order, you halve the average probability of failure on demand, because a hidden dangerous failure is caught sooner and spends less time undetected. This is why proof-test frequency is one of the main knobs an engineer turns to hit a target: if the math falls short, testing more often is often the cheapest fix, subject to the practical limits of how frequently a function can actually be tested.
The second lever is architecture - adding redundancy. A one-out-of-two arrangement uses two channels where either one can perform the safety action, so the function only fails dangerously if both channels have failed, which is a far less likely event than a single failure and drives PFDavg dramatically lower than a 1oo1 channel with the same devices. A two-out-of-three arrangement, used where nuisance trips must also be limited, likewise fails dangerously only when a sufficient number of its channels fail, again lowering PFD compared with a single channel. Redundancy buys reliability at the cost of more hardware and more complexity.
One caveat is essential when adding redundancy: common-cause failure. Two channels are only as independent as their design allows, and a shared fault - the same miscalibration, the same blocked impulse line, the same environmental attack - can fail both at once, which no amount of redundancy defeats. Realistic PFDavg calculations for redundant architectures therefore include a common-cause term, and ignoring it produces an optimistic number that overstates how much the redundancy actually helps. Proper accounting for common cause is what keeps a 1oo2 calculation honest.
A safety instrumented function is not one device but a chain: a sensor subsystem that detects the hazardous condition, a logic solver that decides, and a final element subsystem - usually a valve - that takes the action. The function fails on demand if any of these three links fails to do its part, so their PFDavg contributions add together. In the standard simplified approach the engineer computes PFDavg for each subsystem separately, using each one's failure rate, architecture, and proof-test interval, and then sums the three to get the PFDavg of the whole loop.
That summed loop PFDavg is the number that gets compared against the target. Each safety integrity level corresponds to a band of PFDavg values, so verification means confirming the total falls within the band required by the SIL assigned to the function. The summation also shows immediately where the weak link is: often the final element dominates, because a valve is a mechanical device with a relatively high dangerous-failure rate, which tells the engineer where added redundancy or more frequent testing will do the most good if the target is missed.
This subsystem-and-sum method is what turns individual device data into a defensible statement that a design meets its integrity target. It ties together everything in the calculation - the per-channel failure rates, the divide-by-two effect of the proof-test interval, the reduction from redundant architecture, and the common-cause caveat - into one loop figure. Merobix is a cloud SCADA platform that reads live tags from field devices over Modbus, DNP3, OPC UA, and MQTT, and while the PFDavg calculation is a design activity, the operational data behind it lives in that layer: recording when proof tests actually happen and when devices are found in a failed state gives engineers evidence to confirm that the proof-test interval assumed in the math is the interval being achieved in the field.
For the simplest single-channel, one-out-of-one architecture, PFDavg is approximately the dangerous undetected failure rate, lambda_DU, multiplied by the proof-test interval, divided by two. The divide-by-two reflects that a hidden dangerous failure can happen anywhere in the interval between tests, so on average the channel is failed for about half that interval before a proof test catches it. This approximation holds when the product of failure rate and interval is small, which is the normal case for a sound design.
PFDavg scales directly with the proof-test interval in the simplified equation, so testing more often lowers it. Halving the interval roughly halves the average probability of failure on demand, because a hidden dangerous failure is discovered sooner and spends less time undetected. This makes proof-test frequency one of the main levers an engineer uses to meet a target - if the calculated PFDavg is too high, testing more frequently is often the most practical way to bring it down, within the limits of how often the function can realistically be tested.
You compute PFDavg separately for each of the three subsystems - the sensor, the logic solver, and the final element - using each one's failure rate, architecture, and proof-test interval, then add the three together. The function fails on demand if any link fails, so their contributions sum to the loop's total PFDavg. That total is then compared against the band of values defined for the function's target safety integrity level, and the summation also reveals which subsystem dominates, which is usually where added redundancy or more frequent testing helps most.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.