PFD Average Calculation: Formula vs Data Quality 

If you have worked as a functional safety engineer on enough projects, you probably used different techniques and formulae in PFD average calculations across your SIFs and SIF elements. You might have relied on dedicated software or simply an Excel sheet. However, the results you obtained were never exactly the same.

The natural question is: why?

The short answer is straightforward: the formula matters less than the data you put into it.

This is not a software problem or a standards problem. It reflects a fundamental truth about what PFD calculations actually produce: a probability estimate. And probability estimates are shaped far more by the quality of your input data than by the technique you use to process it.

Various industry standards, such as ISA-TR84.00.02 and IEC 61508, provide their own methods for calculating PFD averages, including simplified formulae, Fault Tree analysis, and Markov modeling. Each method has its own mathematical assumptions, which can lead to slightly different results even with the same input data.

So, which one is (the most) correct?

If you ask me, the answer is all of them and none of them.

Every one of these formulae and techniques outputs a probabilistic result, not a deterministic value. Despite the complex mathematics involved, the result remains an estimate rather than a certainty. That’s because, whenever we are unsure about the outcome of an event, we talk about the probability of that event. Unlike calculating the volume of a vessel or the flow through a pipe, you cannot measure a probability against physical reality and confirm that one formula got it exactly right. What you can do is ensure that the inputs driving your PFD calculation are as credible and defensible as possible.

Does that mean that functional safety engineering is not much different from running a casino?  

In a way, yes, because Casinos are all about probabilities. If you look at it from the perspective of a casino owner, the business model and profit-making of a casino are based on probabilities following sound statistical data. It must be, because otherwise casinos wouldn’t stay in business for long, and there would be no casinos. The same logic applies here.  

The probability your PFD average calculation produces is only as reliable as the data behind it. Get the data right, and the formula becomes a tool you can trust. Get it wrong, and even the most sophisticated technique will give you a false sense of security. 

The point I am trying to make as a functional safety engineer is this: inputting sound statistical data into your PFD average calculation is far more important than which formula or technique you use. IEC 61511 Clause 11.9.3 reinforces this directly. It requires that all failure rate data used in PFDavg and PFH calculations be: 

The purpose is clear: to prevent unrealistically optimistic failure rates from finding their way into SIL verification calculations and creating a false sense of safety. 

Using overly optimistic failure rate data would yield lower PFDavg or PFH results, suggesting a higher risk reduction than the SIF actually provides. Which in turn would lead to a false sense of safety. 

So, when you have to do all these PFD calculations, always ask yourself the following questions: 

Am I saying that it really doesn’t matter which formula or technique you use to calculate PFD average? No, I am not.  

Focusing on data quality does not mean that method selection is irrelevant. Every technique has constraints, and applying the wrong one for your situation introduces errors that better data cannot fix. 

For example, the simplified equations in ISA-TR84.00.02 cover the most common voting architectures, including 1oo1, 1oo2, 1oo3, 2oo2, 2oo3, and 2oo4. They are practical and widely used, but they rely on the Rare Event Approximation. This approximation can only be used when the failure rate (λ) multiplied by the Testing Interval (TI) is much smaller than 0.1 (i.e., λTI << 0.1). When that condition is not met, the simplified formula will overstate the risk reduction your SIF is actually providing. 

Other techniques carry their own restrictions. Some cannot model configurations in which sensors in a voting architecture have different failure rates. Others require that all voted devices share the same proof test interval. If your SIF design does not match those assumptions, the calculation is misaligned with reality before you have entered a single value. 

The practical approach is first to understand each PFD calculation method’s constraints. Next, select the one that fits your project requirements, architecture, and testing regime while respecting each technique’s limitations. Then focus your effort on the quality of the data going in. These include realistic proof-test coverage, conservative common-cause failure factors, applicable failure-rate data from sources such as OREDA/SINTEF/Faradip, valid Testing Intervals, and proper modeling of voting configurations. 

After enough SIL projects, experienced engineers agree. The gap between different methods usually stems from these input assumptions, not mathematics. 

My advice is simple: get the data foundation right first. Formula selection is secondary. 

One of the more practical problems in SIL verification is that the failure rate data, the calculation method, and the audit trail tend to live in different places. That separation creates exactly the kind of documentation gaps that IEC 61511 Clause 11.9.3 is designed to close. 

IMS SIS (Safety Instrumented Systems) eliminates them by bringing together HAZOP, LOPA, SIF design, and PFDavg calculations in a single, unified environment for functional safety engineers. 

Integrated failure rate libraries (customized, SINTEF, Faradip and/or Shell sites collected), mean that the data feeding your calculations is traceable and documented from the point of entry. Supported voting architectures and calculation methods are built in, and every result links back to its inputs for full lifecycle traceability. When data quality determines whether a PFD average calculation reflects reality, integrating that data into your calculation workflow makes demonstrating compliance significantly easier.