A Safety Instrumented Function (SIF) claiming SIL 2 performance without documented verification of its architectural constraints and systematic capability violates the core requirements of IEC 61511-1:2016 Clause 3.2.72, regardless of individual component SIL ratings. The distinction matters: SIL determination establishes the required risk reduction target through Process Hazard Analysis, while SIL verification mathematically proves the implemented architecture delivers that target. Bureau Veritas UK identifies that assessment must cover both determination and verification phases to ensure the safety function will perform as promised under IEC 61508 requirements.
Over the past decade, functional safety engineers have increasingly encountered projects where purchased SIS panels carry SIL 2 or SIL 3 nameplate ratings, yet the as-built system fails to meet target PFDavg values due to architectural choices made during detailed design. The verification step catches these mismatches before startup. ISA course EC54 addresses detailed design issues and hands-on system analysis modeling specifically to close this gap between target SIL and demonstrated performance. [S1]
The verification calculation must account for three interdependent factors: the probability of dangerous failure on demand (PFDavg) or probability of dangerous failure per hour (PFH) depending on whether the SIF operates in low-demand or high-demand mode, the architectural constraints governing minimum safe failure fraction and maximum dangerous undetected failure rates, and the systematic capability of the subsystem based on prior development process assessment. ABB's SIL methodology documentation specifies that architectural constraints and systematic capability must both be taken into account when performing this verification. [S2]
What SIL Verification Actually Proves: The IEC 61508 Definition
IEC 61508 defines SIL verification as a demonstration that for each SIF, the target SIL as derived from SIL determination has been met in accordance with the requirements of IEC 61508/IEC 61511. This is not a theoretical exercise—it requires quantifying the Safety Requirement Specification (SRS) parameters against the as-built architecture. The Safety Requirements Specification per IEC 61511-1:2016, Clause 3.2.72, is the specification that includes the functional requirements for the SIFs and the corresponding safety integrity levels, forming the baseline against which verification calculations are performed. [S1]
The Four SIL Levels: Risk Reduction Targets and Quantitative Thresholds
Safety Integrity Levels range from SIL 1 (lowest risk reduction) to SIL 4 (highest risk reduction), with each level specifying maximum allowable probability of dangerous failure. SIL requirements for hardware safety integrity are based on probabilistic analysis of the device—specifically, to achieve a given SIL, the device must meet targets for maximum probability of dangerous failure and minimum safe failure fraction per IEC 61508 Part 2. The concept of dangerous failure must be rigorously defined for the system in question, normally in the form of requirement constraints whose integrity is verified throughout system development. [S3]
For low-demand mode SIFs (typical batch processes), the PFDavg thresholds are approximately 10^-1 for SIL 1, 10^-2 for SIL 2, 10^-3 for SIL 3, and 10^-4 for SIL 4. High-demand and continuous mode SIFs use PFH thresholds starting at 10^-2 per hour for SIL 2. These numeric targets are what the verification calculation must demonstrate the architecture achieves with stated confidence intervals, accounting for proof test intervals and repair times specified in the SRS.
Verification Methodology: Step-by-Step Architecture Analysis
The SIL verification workflow proceeds through five structured phases beginning with SRS document review, proceeding through subsystem architectural analysis, then PFDavg or PFH calculation, followed by architectural constraint verification, and concluding with systematic capability confirmation. A competent Control Engineer must verify the design including an analysis of the SIS architecture and setting of appropriate proof test intervals per IChemE guidance on SIL determination and verification practice. [S4]
The SRS defines proof test intervals, repair time assumptions, diagnostic test intervals, and the target SIL for each identified SIF. These parameters directly drive the PFDavg calculation using either simplified equations from IEC 61508 Part 6 or more detailed Markov modeling for complex architectures. SOR Controls Group's SIL quick guide emphasizes that verification must verify that each instrument utilized in the system as well as each instrument's parts such as sensors, logic solvers and integral components will work safely—the component-level verification aggregates to the SIF-level claim. [S6]
Architectural Constraints: Hardware Fault Tolerance and Safe Failure Fraction Requirements
IEC 61508 defines strict architectural constraints for each SIL level that constrain subsystem selection regardless of calculated PFDavg values. The standard mandates minimum hardware fault tolerance (HFT) for each SIL level and minimum safe failure fraction (SFF) ranges that define what percentage of failures must be safe or detectable-and-safe. These architectural limits are non-negotiable even if probabilistic calculations suggest the architecture meets the target—architectural constraints and systematic capability must both be satisfied independently. [S2]
For a single-channel architecture to claim SIL 2, the components must demonstrate SFF exceeding 90% and the architecture must be designed for systematic capability corresponding to SIL 2. For SIL 3 applications, architectures typically require 1oo2 (one-out-of-two) or equivalent redundancy to meet both PFDavg targets and hardware fault tolerance requirements.
Systematic Capability: Closing the Process Safety Gap
Hardware reliability calculations alone do not constitute complete SIL verification. Systematic capability addresses whether the development process for each subsystem was sufficiently rigorous to provide confidence that systematic failures (software bugs, design errors, incorrect specifications) will not defeat the safety function. IEC 61508 Part 3 and IEC 61511 Part 3 define systematic capability requirements by SIL level, typically assessed through prior certification evidence, development process audits, or systematic capability analysis of the subsystem supplier. [S3]
A PLC claiming SIL 2 capability based solely on hardware PFDavg calculations but lacking documented systematic capability assessment for its firmware development process fails the systematic capability leg of the verification. This is a common pitfall in retrofitted SIS installations where new I/O modules are added to existing pressure transmitters or industrial valve assemblies without re-evaluating the integrated systematic capability claim.
Proof Test Interval Optimization and Verification Recalculation Triggers
The SRS specifies initial proof test intervals, but SIL verification must confirm these intervals are consistent with the calculated PFDavg achieving the target SIL. If proof test intervals are extended beyond the SRS values without recalculation, the architecture may fall below target SIL. Conversely, shorter proof test intervals reduce PFDavg and can move an architecture from borderline SIL 2 to comfortably meeting SIL 2 requirements. [S4]
Proof test procedures themselves must be validated—the test must detect dangerous undetected failures with the coverage factor assumed in the PFDavg calculation. A proof test that only checks for open-circuit output without verifying the final element achieves its safety position will overstate the actual dangerous failure detection coverage, invalidating the verification calculation. This coverage factor must be documented in the verification report and traced to the actual proof test procedure.
Common Verification Failure Modes and Mitigation Strategies
Three categories of SIL verification failures appear consistently in functional safety audits: architectural constraint violations where the selected subsystem SFF or HFT does not meet the required SIL level even if PFDavg calculation suggests compliance, systematic capability mismatches where the integrated system includes subsystems with lower systematic capability than the target SIL, and calculation input errors where proof test intervals, diagnostic intervals, or repair times used in the verification differ from the SRS or actual operating conditions. [S5]
For flow meter applications in safety service, the sensor selection must be evaluated for both the probability of dangerous failure contribution and the safe failure fraction of the sensor/transmitter assembly. SIL verification must trace the complete signal chain from sensor through transmitter to logic solver input, not merely evaluate individual components. [S5]
When verification identifies a gap between target SIL and achievable architecture, options include selecting higher-reliability components, adding redundancy (transitioning from 1oo1 to 1oo2D architecture), reducing proof test intervals, improving diagnostic coverage through more frequent diagnostic tests, or adjusting the target SIL through updated hazard and risk assessment. Each option carries different cost and maintenance implications that must be evaluated against the risk reduction requirements established during SIL determination.
Documentation Requirements and Verification Report Structure
A complete SIL verification report must document the SRS baseline, the as-built architecture with part numbers and firmware versions, the PFDavg or PFH calculation with all input parameters, the architectural constraint verification against IEC 61508 Part 2 tables, the systematic capability evidence for each subsystem, the proof test procedure references and coverage factors, and a statement of compliance or non-compliance against each target SIL in the SRS. [S6]
The verification report should be subject to independent technical review by a functional safety engineer with competencies in IEC 61508 and IEC 61511 before being submitted to the safety instrumented system end user or regulatory authority. Bureau Veritas offers comprehensive SIL assessment services including both SIL determination and SIL verification to help organizations ensure the effectiveness of their Safety Instrumented Systems (SISs).
Trackable verification status: the verification report should be marked with revision control, with re-verification triggered by any architecture change, firmware update to servo motor drives or PLC modules, proof test interval modifications, or changes to the process chemistry that alter hazard scenarios. Quarterly proof test records should be reconciled against the verification report assumptions to catch any drift from the validated configuration.