Assigning a target safety integrity level to a safety function is only half the job. Once a loop is designed - a sensor, a logic solver, and a final element wired together - someone has to prove that this specific combination of hardware actually reaches the SIL it was asked to deliver. SIL verification is that proof: a quantitative roll-up of the loop's failure probabilities and architecture. This guide explains what the calculation checks, how the loop's contributions add up, and why verification is distinct from defining a SIL or from any single reliability metric.
SIL Verification in one line: SIL verification is the loop-level calculation that confirms a designed safety instrumented function - its sensor subsystem, logic solver, and final element - together achieve the target SIL assigned to it. It sums each subsystem's average probability of failure on demand, applies architectural constraints such as hardware fault tolerance and safe failure fraction, and uses reliability data for each device to arrive at the loop's achieved SIL, which is then compared against the target.
A safety instrumented function is a chain, and a chain fails on demand if any of its parts fails to act. In practice that means the loop's overall probability of failure on demand is dominated by the sum of the average probabilities of its three subsystems: the sensor part that detects the hazard, the logic solver that decides, and the final element that takes action. Verification calculates each subsystem's contribution and adds them into a total for the loop, then checks whether that total falls inside the numerical band that corresponds to the target SIL.
The final element subsystem - a shutdown valve, its solenoid, and actuator - is very often the largest single contributor, because valves sit still for long periods and carry a high proportion of dangerous undetected failures. The sensor subsystem contributes according to its own failure rates and any voting, and the logic solver, being a well-diagnosed programmable device, usually adds the smallest share. Seeing where the number comes from is half the value of the exercise: it tells the designer which subsystem to improve if the loop falls short.
The inputs to this roll-up are the reliability data for each device - dangerous failure rates, the split between detected and undetected failures, the proof-test interval, and the diagnostic coverage. Change any of those and the number moves. Extending the proof-test interval, for instance, lets more undetected failures accumulate between tests and pushes the probability up, which is why the test interval is an explicit input to the verification rather than an afterthought.
A loop can hit the right probability figure and still fail verification, because SIL is not decided by probability alone. There is a second, architectural gate that limits how much integrity you are allowed to claim from a given hardware arrangement, expressed through hardware fault tolerance and safe failure fraction. Hardware fault tolerance asks how many dangerous faults a subsystem can suffer and still perform its safety function - a single valve has none, a redundant pair has one. Safe failure fraction describes what proportion of a device's failures are either safe or detected rather than dangerous and hidden.
Together these constraints cap the SIL a subsystem may be credited with, independent of its calculated probability. The intent is to prevent an over-optimistic reliability number from letting a fragile single-channel arrangement claim a very high integrity level. If the architecture does not meet the constraint for the target SIL, the designer must add redundancy or improve diagnostics regardless of how good the raw probability looks. Verification therefore has two verdicts running side by side: does the number make the target band, and does the architecture meet the constraint for that band.
Only when both tests pass is the loop verified. If either fails, the design changes - a redundant sensor, a second valve, better diagnostics, or a shorter proof-test interval - and the whole calculation is repeated. That iteration is the heart of verification: it is not a one-time sign-off but a design loop that continues until the achieved SIL genuinely meets, and can be shown to meet, the target.
Verification sits between two neighbouring ideas it is easy to confuse it with. Defining a safety integrity level is about what the levels mean and what risk reduction each represents. The probability of failure on demand is a single metric - one number describing one subsystem or loop. Verification is neither of those on its own; it is the loop-level roll-up that gathers the sensor, logic solver, and final element contributions, applies the architectural constraints, and produces the achieved SIL for the whole function. It uses those component ideas without redefining them.
Verification is also distinct from allocation, its front-end counterpart. Allocation assigns the target SIL to the function before any hardware is chosen; verification checks, after the design exists, whether the chosen hardware meets that target. Allocation sets the goal, verification confirms the goal is met - target versus achieved. A design that passes verification is one whose achieved SIL is at least as high as the allocated target.
The reliability assumptions behind a verification are not frozen at design time - they can be checked against how the equipment actually behaves in service. Proof-test results, valve stroke times, and spurious-trip history from the field either confirm the failure-rate assumptions or expose that a device is degrading faster than the data predicted. Where those results are captured as SCADA tags, a cloud platform such as Merobix makes the field record visible to the reliability engineer, so a verification done on paper can be revisited against what the loop is really doing in the plant rather than left as a static calculation.
Allocation is the front-end step that assigns a target SIL to each safety function based on the risk reduction it must provide, before any hardware is selected. Verification is the back-end check that the hardware actually chosen achieves that target, done by calculating the loop's failure probability and checking its architecture. In short, allocation sets the target and verification confirms the achieved result meets it.
The calculation sums the average probability of failure on demand of the sensor, logic solver, and final element subsystems, using each device's dangerous failure rates, the split between detected and undetected failures, the diagnostic coverage, and the proof-test interval. It then applies architectural constraints - hardware fault tolerance and safe failure fraction - that cap the SIL the architecture may claim. Both the probability and the architecture must satisfy the target for the loop to verify.
The final element - typically a shutdown valve with its solenoid and actuator - sits idle for long stretches and carries a high share of dangerous undetected failures that only a proof test reveals. Those hidden failures accumulate between tests and contribute the largest slice of the loop's failure probability. That is why partial and full stroke testing of the valve, and the test interval chosen, have such a strong effect on whether a loop passes verification.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.