A Safety Instrumented Function that has never been verified is an assumption wearing the shape of a safeguard. Assigning a target SIL during hazard and risk assessment tells you what level of risk reduction the process needs — it says nothing about whether the sensors, logic solver, and final elements you actually installed can deliver it. SIL verification is the calculation step that closes that gap: it takes failure rate data, architecture, diagnostic coverage, and proof test interval for a specific SIF and proves, with a number, that the achievable PFDavg meets or beats the target set in the Safety Requirements Specification. Skip it, or let it drift out of date after a valve substitution or a proof test interval change, and the SIL rating on your P&ID becomes a label nobody has actually checked. This guide walks through how PFDavg verification, proof test interval selection, and bypass management work together under IEC 61511 — and where most U.S. process facilities lose the thread between design intent and operating reality.
Is Your SIL Verification Still Valid, or Just Filed?
Connect PFDavg calculations, proof test records, and bypass logs into one system that flags the moment a SIF's verification no longer matches what's actually installed and running.
What SIL Verification Actually Proves — and What It Doesn't
SIL determination and SIL verification are two different exercises that get confused constantly, and the confusion is where compliance gaps start. SIL determination happens during hazard and risk assessment — it answers "how much risk reduction does this scenario need," and the output is a target SIL assigned in the SRS. SIL verification happens afterward, during detailed design, and it answers a completely different question: "does the SIF I have actually specified achieve that target." Verification is not a single number lookup. It rests on three separate constraints that all have to be satisfied independently — the architectural constraint (hardware fault tolerance against IEC 61511 Table 5), the systematic capability of each component, and the calculated PFDavg or PFH for the loop as designed. A SIF can pass the PFDavg calculation comfortably and still fail verification on architectural constraint if the sensor or final element doesn't have the redundancy the standard requires for that SIL and that device type.
For low-demand SIFs — the majority of process safety loops in U.S. oil and gas and chemical facilities, where the protection function is called on less than once a year — verification centers on PFDavg, the average probability that the function fails to act when a demand occurs. Teams that book a demo of iFactory's functional safety module are usually trying to solve the same underlying problem: their PFDavg calculations exist in a spreadsheet built once during commissioning, and nothing in their plant systems checks whether field conditions still match the assumptions that spreadsheet was built on.
PFDavg Calculation Tracking
Maintain live PFDavg calculations for every SIF, built from λDU, diagnostic coverage, common cause beta factor, and proof test interval — not a one-time spreadsheet frozen at commissioning.
Architectural Constraint Checks
Confirm hardware fault tolerance and component type against IEC 61511 Table 5 requirements for every sensor, logic solver, and final element in the loop.
Proof Test Interval Management
Track the proof test interval each PFDavg calculation depends on, and flag any SIF where actual test execution is drifting from the schedule the verification assumed.
Bypass & MOC Audit Trail
Log every bypass activation with justification, authorization, and compensating measures, and trigger a re-verification flag whenever a Management of Change event touches a verified SIF.
The Variables That Actually Drive a PFDavg Calculation
PFDavg is not one input — it is a function of six factors working together, and getting any one of them wrong changes the answer enough to put a SIF on the wrong side of its SIL boundary. The dominant term is almost always the dangerous undetected failure rate, λDU, expressed in failures per hour and typically tracked in FIT (failures in 10⁹ hours) for individual components. Diagnostic coverage reduces the practical impact of λDU by converting some dangerous failures into dangerous-but-detected (λDD) failures that trigger an alarm instead of sitting hidden until the next proof test. Architecture and redundancy — whether a sensor is 1oo1, 1oo2, or 2oo3 — change how a single component failure propagates to the loop level. Common cause failure, modeled with a beta factor, accounts for the reality that redundant components sharing a power supply, an impulse line, or an installation environment do not fail completely independently. And the proof test interval sets the ceiling on how long a dangerous undetected failure can sit in the field before it's caught — a longer interval directly raises PFDavg for the same hardware. Teams evaluating their own SIF inventories often book a demo specifically to see how sensitive their existing PFDavg numbers are to proof test interval assumptions that may no longer reflect what's actually being executed in the field.
| SIL Level | Required PFDavg (Low Demand) | Risk Reduction Factor | Typical Architecture | Verification Priority |
|---|---|---|---|---|
| SIL 1 | ≥ 10⁻² to < 10⁻¹ | 10 to 100 | 1oo1 acceptable for most device types | Standard |
| SIL 2 | ≥ 10⁻³ to < 10⁻² | 100 to 1,000 | 1oo1 or 1oo2 depending on systematic capability | High |
| SIL 3 | ≥ 10⁻⁴ to < 10⁻³ | 1,000 to 10,000 | Redundant architecture typically required (1oo2, 2oo3) | Critical |
| SIL 4 | ≥ 10⁻⁵ to < 10⁻⁴ | 10,000 to 100,000 | Rarely used in process industry; high redundancy mandatory | Critical |
From SRS Target to Documented Verification: The IEC 61511 Workflow
SIL verification under IEC 61511 follows a defined sequence, and skipping or compressing any step is exactly where calculations stop matching reality. The standard does not treat this as a one-time gate passed at commissioning — Clause 12 requires the calculation to be revisited whenever the design basis changes, which means the workflow below has to run again, not just the first time a SIF is engineered.
Pull the Target From the SRS
Confirm the target failure measure — PFDavg for low demand, PFH for high or continuous demand — that hazard and risk assessment assigned to this specific SIF in the Safety Requirements Specification.
Build the Loop From Sensor to Final Element
Document every component in the SIF — transmitter, logic solver channel, solenoid, shutdown valve — with manufacturer failure rate data, architecture, and diagnostic coverage for each.
Calculate PFDavg and Check Architectural Constraints
Run the PFDavg calculation against the proposed proof test interval, then independently confirm hardware fault tolerance and systematic capability meet IEC 61511 Table 5 for the target SIL.
Document the Verification Record
Record calculation methods, data sources, and the proof test interval the result depends on — this record is what an auditor or PHA revalidation team will request first.
Re-Verify on Management of Change
Treat any valve substitution, logic solver firmware update, or proof test interval change as a trigger for re-verification — the original calculation no longer applies once any input has changed.
"Our PFDavg spreadsheets were accurate the day they were built, but nobody could tell us if a proof test interval had slipped or a bypass had gone unlogged six months later. With iFactory tracking verification status against actual proof test execution, we caught two SIFs operating outside their assumed test interval before our next PHA revalidation — not after an auditor found it."
Where SIL Verification Quietly Goes Stale in Operating Plants
A verification calculation does not expire on a calendar date — it expires the moment any of its underlying assumptions stop being true, and most plants have no system that would tell them when that happens. Understanding these failure points before the next PHA revalidation cycle is far less expensive than discovering them during an incident investigation.
The PFDavg calculation assumes a specific proof test interval. When tests slip due to scheduling conflicts, the actual PFDavg is silently higher than the documented value.
A bypass activated for maintenance and left in place past its compensating measure window leaves the SIF unprotected without anyone tracking the elapsed exposure time.
A like-for-like-looking valve or transmitter swap can carry a different failure rate or diagnostic coverage, invalidating the original PFDavg without anyone recalculating it.
Firmware updates or logic changes to the safety PLC can alter systematic capability assumptions that the original verification record never anticipated.
PFDavg spreadsheets, proof test logs, and bypass records living in separate systems make it impossible to see at a glance whether a SIF's verification still holds.
Beta factor assumptions for redundant components sharing power, impulse lines, or environment are rarely revisited after commissioning, even as field conditions change.
Closing these gaps requires connecting verification math to field execution, not just better record-keeping. Functional safety leads regularly book a demo to see how their current SIF inventory holds up against live proof test and bypass data.
Bypass Management: The Most Common Way Verified SIFs Become Unprotected
Bypassing a safety function is sometimes genuinely unavoidable — proof testing a transmitter often requires driving it beyond its trip point, and replacing a failed solenoid means the loop cannot hold its normal signal during the physical work. IEC 61511 does not prohibit bypass; it requires that every bypass be justified, authorized, time-bound, and compensated by an alternative protection measure for as long as the SIF is degraded. The discipline problem shows up when a bypass authorized for a two-hour proof test is still active three shifts later because nobody tracked the clock, or when an operator applies a bypass without the documented authorization the procedure requires.
What Disciplined Bypass Management Requires Under IEC 61511
Every bypass logged with the specific maintenance or proof test activity requiring it, not a generic "maintenance" entry.
A defined expected duration with automatic escalation if the bypass remains active past its authorized window.
An alternative safeguard — additional operator monitoring, a temporary procedure — documented for the duration the SIF is degraded.
Recurring bypasses on the same SIF reviewed as a signal of an underlying reliability or design problem, not treated as routine.
Expert Review: Why Verification Records Need to Live Where the Plant Actually Operates
In two decades of functional safety auditing across U.S. refining and petrochemical sites, the finding I write up most often is not a bad PFDavg calculation — the engineering teams that build these calculations are generally rigorous. The finding is a verification record that was correct on the day it was signed and has had no system checking it against reality since. A proof test interval gets pushed back a quarter during a turnaround crunch and nobody flags that the PFDavg the SIF was verified against assumed the original schedule. A bypass gets applied for a transmitter swap and closed out two days late because the work order took longer than planned, and there is no log forcing anyone to notice the SIF sat exposed. None of this shows up as a calculation error. It shows up as a gap between the document in the file and the equipment actually running in the field, and that gap is exactly what an incident investigation or a PHA revalidation team will find first. The plants that handle this well are not the ones with the most sophisticated PFDavg software — they are the ones where proof test execution, bypass activation, and management of change all feed back into the same verification record automatically, so the SIL rating on the P&ID means what it says today, not what it meant at commissioning.
Connect Your SIL Verification to What's Actually Running
Deploy a platform that ties PFDavg calculations, proof test schedules, and bypass authorization into one continuously updated functional safety record — built for U.S. process safety teams operating under IEC 61511.
A SIL Rating Is Only as Reliable as Its Last Verification
SIL verification is the step that turns a target risk reduction number into a defensible engineering claim about a specific, installed Safety Instrumented Function — and that claim only holds for as long as the proof test interval, architecture, and component data behind it remain true. The work does not end when the calculation is filed. It continues every time a proof test runs late, a bypass stays active longer than planned, or a component gets swapped without anyone asking whether the PFDavg still holds. Facilities that treat verification as a living record — one that connects to actual proof test execution and bypass history rather than a spreadsheet frozen at commissioning — are the ones whose SIL ratings still mean something when an auditor, a PHA team, or an incident investigator asks to see the evidence.
SIS SIL Verification — Common Questions Answered
What is the difference between SIL determination and SIL verification?
SIL determination sets the target risk reduction during hazard and risk assessment; SIL verification is the later calculation step that proves the actual designed SIF meets that target.
What PFDavg is required for SIL 2 under IEC 61511?
SIL 2 requires a PFDavg between 10⁻³ and below 10⁻², corresponding to a risk reduction factor of roughly 100 to 1,000 for low-demand safety functions.
Why does the proof test interval matter to a PFDavg calculation?
A longer interval allows dangerous undetected failures to sit hidden longer before discovery, which directly raises the calculated PFDavg for the same hardware.
When does a SIF need to be re-verified under IEC 61511?
Re-verification is required whenever Management of Change affects the design basis — a component substitution, logic solver firmware update, or proof test interval change.
How does iFactory support ongoing SIL verification and bypass tracking?
iFactory connects PFDavg calculations to actual proof test execution and bypass activation records, flagging any SIF where field conditions no longer match the verified assumptions.
