This article will be of interest if you have ever tried to demonstrate the probability of failure of a safety function to meet a Safety Integrity Level (SIL) target. A procedure, often known as SIL verification, is used to demonstrate compliance with functional safety standards IEC 61511 (process industry safety applications) or IEC 62061 (machinery safety applications).

PFD = Probability of Failure on Demand

PFH = Probability of Failure per Hour

## The background

Each of the above standards defines random hardware failure performance requirements for safety functions in terms of their **probability of failure (PFD or PFH)**** of a safety function.**

It is tempting to dive straight into each standard and explain everything from first principles. However, that would be beyond the usual remit of a blog article.

To help with the lack of a full background, below are series of questions which should help to introduce the topic for the uninitiated.

Equipment designed for automatically sensing and reacting to hazards can be designed and employed in many different applications in industry.

Typical process industry applications include emergency shutdown/trip systems which prevent potentially dangerous pressure, temperature or level conditions from escalating.

For hazardous machinery, automated safety functions are used to detect human proximity and bring about a safe state to protect workers from harm.

Whatever the application, the owner of the hazard(s) should decide the SIL target for each safety function. This process is known as SIL determination or SIL selection.

To demonstrate that the random hardware target for a can be met by each safety function, a PFD or PFH calculation is required. SIL verification probability of failure calculations provide a be standardised way to compare safety function designs against their target Safety Integrity Level - SIL.

The answer to this is an emphatic NO! Probability of failure calculations are only a part of a much larger picture. However, PFD/PFH calculations are one of the mandatory items for demonstrating SIL targets have been met.

There are two calculation methods due to the different MODES OF OPERATION defined for a safety function; LOW DEMAND MODE and HIGH DEMAND / CONTINUOUS MODE.

Put simply, this is the way (mode) in which a safety function is designed to operate. Examples follow in the definitions for low demand, high demand and continuous modes below.

As the name indicates, this is where the end application of a safety function is expected to be called upon very INFREQUENTLY. The functional safety standards define low demand mode as a **maximum frequency of demands of no greater than once per year**.

An example we can all easily relate to is the airbag in a car steering wheel. This is not regularly demanded, but when it is required, for instance in a serious shunt or crash, we expect the airbag to deploy on a real demand from the collision sensor.

**LOW DEMAND MODE safety functions require a Probability of Failure on Demand - *PFD calculation. These are common in process industry applications.**

*Note: The technically correct term is PFDavg; where "avg" is the abbreviation for "average", as it is an average probability value which is calculated.

This is where a safety function still works on demand, but the **frequency of demands is greater than once per year**.

An example are car brakes. These are very regularly used (demanded) when the vehicle is in operation.

**HIGH DEMAND MODE safety functions require a Probability of Failure per Hour (*PFH) calculation.**

*Note: PFH is more accurately known as PFHD in machinery safety standards IEC 62061 and ISO 13849-1.

Note that the word "demand" does not appear in this case. This type of safety function is continously operating to retain a safe state.

The best example in this case would be automatic driverless steering in a car. If this fails dangerously then there is an immediate hazard. We're all aware that the technology is available, even if it may take some years for it to be allowed

**CONTINOUS MODE safety functions require a Probability of Failure per Hour (*PFH) calculation.**

*Note: PFH is more accurately known as PFHD in machinery safety standards IEC 62061 and ISO 13849-1.

## Preparing for SIL verification probability of failure calculations

At the outset, let's be clear that **probability of failure calculations are far from an exact science**. Just employing numbers does not make the results accurate, especially if the assumptions are incomplete or the underlying data is flawed.

It should be noted that the goal is to ensure that safety functions are designed with an integrity which meets the SIL target. Calculations should be realistic and as conservative as possible.

## Get the safety requirements specification (SRS)

The Safety Requirements Specification (SRS) must be the starting point for any SIL verification probability of failure calculation exercise. The SRS is the reference source for each safety function and provides the vital link back to the hazard and risk analysis.

If completed correctly, the SRS will specify what each safety function must achieve, including what to sense, and what to actuate to achieve or maintain a safe state. The SRS is also the primary reference source for the SIL target and other critical performance factors like required response and reaction time.

In the early stages of design, the SRS may not specify the actual equipment or even the required level of redundancy. It is very common for there to be updates of the SRS following SIL verification.

## SELECT A modelling method AND/or tool

To complete a SIL verification, the user must decide on a calculation method. The most common methods used in industry are shown in the list below.

There are positives and negatives in each case, but usually the higher the integrity requirement (higher SIL), either a more rigorous approach or multiple methods should be adopted.

It is possible to calculate the most common SIL 1 safety function designs using simplified equations which are provided in basic safety standard IEC 61508 part 6.

A good source for typical process industry safety function application equations, RBD and fault trees is the document ISO/TR 12489:2013.

Sadly, very few of the above items are free, so it is wise to choose carefully.

## FIND CONSERVATIVE FAILURE RATE DATA

Failure rates of equipment items are the source information needed for any PFD or PFH calculation. A good reference source for free and paid resources is provided at this blog by Stephen Thomas at the SIS engineer.com website. I would echo many of the sentiments written on his blog about "words of caution" on failure rate data.

## AGREE ALL ASSUMPTIONS

Assumptions have to be made when it gets to the detail of PFD and PFH calculations. It is a good idea to develop a checklist to agree the assumptions that will be needed for the model or tool chosen.

It is difficult to give an extensive list of required assumptions simply due to the many different ways of approaching things.

However, in addition to the items mentioned above , common things that will need to be decided include the following (not an exhaustive list):

## Completing the SIL verification

For a new-build project, completing the SIL verification exercise may involve several stages of calculation, SRS update and re-calculation as the design matures and the selection of equipment items occurs.

For existing safety functions, the calculations can be conducted based upon the actual installed equipment. If there is real field failure rate data available, then that should be used in preference to other data sources.

The conclusion of a SIL verification calculation requires that the resulting PFD or PFH for each safety function meets the target set in the SRS.

The target may be simply a SIL band, in which case the PFD or PFH is technically only required to meet the minimum target in that band. If the target is a numerical value then the PFD or PFH achieved must be LOWER than this value.

The SIL verification exercise is not fully complete until other factors have also been considered, including hardware fault tolerance and systematic capability.