SIL Verification: How to Prove Your Safety Function Actually Achieves Its Target

SIL determination tells you what integrity a safety function needs. SIL verification proves the system you actually built delivers it. They are separate exercises producing separate deliverables, and the gap between them is where a surprising number of functional safety programs come apart.

The pattern is consistent. An operator commissions a SIL determination study, receives targets for each safety instrumented function, builds the system, and assumes the job is done. At assessment the question arrives: show the calculation proving this loop reaches SIL 2. Frequently nobody has done one.

 

What Verification Actually Calculates

For a low demand mode function, verification calculates the average probability of failure on demand, or PFDavg, across the entire safety loop: sensor, logic solver, and final element. That figure is compared against the band for the target SIL. A SIL 2 function must achieve a PFDavg between 0.01 and 0.001, which corresponds to a risk reduction factor between 100 and 1,000.

 

Target SIL	PFDavg Band (low demand)	Risk Reduction Factor
SIL 1	0.1 to 0.01	10 to 100
SIL 2	0.01 to 0.001	100 to 1,000
SIL 3	0.001 to 0.0001	1,000 to 10,000
SIL 4	0.0001 to 0.00001	10,000 to 100,000

 

For functions operating in high demand or continuous mode the metric changes to probability of dangerous failure per hour rather than per demand, which matters because applying the wrong mode to a function is a straightforward way to produce a calculation that looks rigorous and is wrong.

 

The Three Things Verification Has to Satisfy

Reaching the PFD band is necessary but not sufficient. IEC 61511 requires three conditions, and a function failing any one of them does not meet its target regardless of how good the arithmetic looks.

• Random hardware failure. The calculated PFDavg falls within the band for the target SIL, using defensible failure rate data for every device in the loop.
   
• Architectural constraints. The loop meets the required hardware fault tolerance. A single sensor with no redundancy has structural limits regardless of how reliable that sensor is individually.
   
• Systematic capability. Each device is certified or justified as suitable for the target SIL, covering design process rather than failure rate.

Architectural constraints are the condition most often overlooked, and the one most likely to force a design change rather than a paperwork correction.

 

What Drives the Number

• Device failure data. Manufacturer figures from IEC 61508 certified devices carry independent verification. Generic database figures or internal estimates need documented justification, and assessors do examine the source.
   
• Voting architecture. Moving from a single sensor to a two out of three arrangement changes the calculation substantially, and it is the usual remedy when a loop falls short.
   
• Proof test interval. PFDavg is an average over the test interval, so shortening the interval improves the figure. This is why proof test procedures and intervals cannot be set independently of the SIL calculation.
   
• Proof test coverage. A test that exercises only part of the function leaves undetected failures accumulating. Coverage below 100 percent has to be reflected in the calculation.
   
• Common cause failure. Redundant channels sharing a process connection, a power supply or a calibration procedure are not fully independent, and the beta factor accounts for it.

 

The finding that turns paperwork into a shutdown Verification presents as a documentation gap: the calculation simply needs doing. Then the recalculation shows the installed architecture cannot reach the target, and the remedy is added redundancy, a different device, or a materially shorter proof test interval. That is a design change with a maintenance window attached, and it is the single most common reason functional safety remediation programs overrun their schedule.

 

Where Verification Goes Wrong

• Failure data with no traceable source. A PFDavg figure is only as defensible as the numbers behind it.
   
• Proof test interval assumed rather than committed. A calculation assuming annual testing fails if the maintenance schedule says three-yearly.
   
• Final element omitted. Valves and actuators typically dominate loop PFD, and a calculation covering only sensor and logic solver is not a loop calculation.
   
• Architectural constraints checked after the fact. Checking them at design stage costs nothing; checking them at verification can invalidate the build.
   
• No traceability to the hazard scenario. A SIL target that cannot be traced back through determination to a documented scenario fails at functional safety assessment even when the verification arithmetic is sound.

 

Why Choose Arista Cyber

Arista Cyber delivers SIL verification as part of a connected lifecycle rather than as an isolated calculation, because verification quality depends almost entirely on what precedes it.

We verify against the hazard scenarios that produced the target, so traceability exists from the outset rather than being reconstructed for an assessor. Where verification shows a shortfall, we can redesign the architecture, revise the proof test regime, or revisit SIL determination if the target itself is not supportable. And because our practitioners are TUV Rheinland certified, the competence behind the calculation is documented, which IEC 61511 requires in its own right.

 

Next Steps

If you hold SIL targets but no verification calculations, that gap will surface at your next assessment. Explore our functional safety services, read about the difference between determination, verification and validation, or contact the Arista Cyber team.

 

Common Questions

 

What is the difference between SIL determination and SIL verification?

Determination sets the target by assessing risk, usually through LOPA, and answers how much risk reduction the function must provide. Verification proves the system as built achieves it, through calculation of PFDavg, architectural constraints and systematic capability. They are separate deliverables, and holding one does not mean you hold the other. Our guide to determination, verification and validation covers all three.

Can we do SIL verification ourselves?

Technically yes, and many operators use commercial calculation software. The difficulty is not the arithmetic but the inputs: selecting defensible failure data, applying architectural constraints correctly, setting a realistic common cause factor, and committing to a proof test regime the maintenance organization will actually deliver. Assessors examine those judgements more closely than the calculation itself.

How often does SIL verification need to be redone?

Whenever anything in the loop changes: a device replaced with a different model, a proof test interval revised, an architecture modified, or the SIL target itself changed by a revised hazard study. Verification is also revisited during functional safety assessment at the relevant lifecycle stages, and any finding raised there flows back into the calculation.

 

Do you have SIL targets but no verification calculations? Arista Cyber delivers SIL verification traceable from hazard scenario to installed loop, with TUV Rheinland certified practitioners. Book a Free Consultation