Operational Impact of Unverified Safety Instrumented Functions
Burner management systems (BMS) prevent catastrophic furnace explosions by controlling fuel-air ratios, purge sequences, and flame monitoring. When these systems fail to operate on demand, the consequences range from unplanned shutdowns costing hundreds of thousands in lost production to explosions that destroy assets and endanger personnel. The problem is not whether your BMS was designed to a Safety Integrity Level—it almost certainly was—but whether you can prove it still meets that SIL rating after installation, modification, or years of service.
SIL verification answers a single question: does this instrumented system achieve the required probability of failure on demand? Without documented verification, you operate on assumptions rather than evidence. Operators face regulatory scrutiny, insurers question coverage, and most critically, the actual risk reduction may be far below what process hazard analysis assumed.
Standards Framework for BMS SIL Verification
The functional safety lifecycle for burner management systems is governed by IEC 61511, which defines requirements for safety instrumented systems in the process industries. This standard mandates verification at multiple lifecycle phases, not just at initial design.
NFPA 85 provides specific requirements for burner management systems, including interlocks, flame safeguard supervisory systems, and fuel train components. While NFPA 85 establishes functional requirements and does not itself use the SIL framework, its requirements are typically integrated with IEC 61511 for SIL quantification.
ISA-TR84.00.02 provides guidance on determining SIL requirements and on methodologies for calculating probability of failure on demand (PFD), complementing the quantitative methods in IEC 61508-6. This technical report bridges the gap between theory and field implementation, particularly for common process industry architectures.
IEC 61508 serves as the parent standard, establishing the fundamental concepts of hardware fault tolerance, systematic capability, and architectural constraints. Equipment manufacturers typically certify components to IEC 61508, while system integrators verify complete loops to IEC 61511.
What SIL Verification Actually Measures
Probability of Failure on Demand
SIL verification quantifies the average probability that a safety function will fail when a process demand occurs. This metric—PFDavg—accounts for random hardware failures across the entire safety loop: sensors, logic solvers, and final elements.
Each SIL rating corresponds to a PFDavg range:
-
- SIL 1: ≥ 10⁻² to < 10⁻¹
- SIL 2: ≥ 10⁻³ to < 10⁻²
- SIL 3: ≥ 10⁻⁴ to < 10⁻³
Components of Verification
SIL verification encompasses three distinct analyses:
A 1oo2 (one-out-of-two) voting arrangement provides single-fault tolerance for safety but lower availability (any single channel failure can cause a spurious trip). A 2oo3 (two-out-of-three) arrangement also provides single-fault tolerance for safety while reducing spurious trips, but requires more complex diagnostics and proof testing.
Systematic capability assessment evaluates whether components were designed and manufactured with processes appropriate to the target SIL. Prior use justification (per IEC 61511-1 Clause 11.5.3) requires documented evidence of suitability in similar operating conditions and is not a simple shortcut; certified devices simplify this step significantly.
Quantitative reliability calculation determines PFDavg using failure rate data, proof test intervals, diagnostic coverage, architectural constraints, and common-cause failure beta factors. This calculation reveals whether the design meets the target SIL numerically.
Common Verification Pitfalls in Field Installations
Ignoring Field Wiring and Terminations
Design calculations often assume perfect installation. Field reality introduces junction boxes with mixed signal types, cable trays with electromagnetic interference sources, and terminations made during turnarounds under time pressure. These factors degrade diagnostic coverage and introduce common-cause failures not captured in theoretical models.
Verification must account for actual installation practices. If your design assumes 90% diagnostic coverage but field wiring prevents online diagnostics from detecting shorts, your effective coverage drops substantially, degrading the calculated SIL.
Inadequate Proof Test Procedures
The proof test interval appears in the denominator of PFD calculations—longer intervals increase PFDavg. But the proof test must actually detect dangerous failures. Many facilities perform functional tests that confirm the system trips but never validate individual channel integrity, sensor calibration drift, or partial valve stroke response.
A proof test procedure that omits critical failure modes provides false confidence. Your verification calculation assumed comprehensive testing; partial testing invalidates those assumptions.
Ignoring Systematic Failures
Quantitative SIL verification calculates random hardware failures but cannot quantify systematic failures—design errors, software bugs, specification mistakes, or maintenance errors. IEC 61511 requires systematic capability assessment precisely because these failures often dominate real-world safety system performance.
Configuration errors in BMS logic represent a significant systematic failure mode. Incorrect purge timers, bypassed interlocks, or reversed sensor logic will not appear in PFDavg calculations but will cause failure on demand.
Verification Workflow for Existing Systems
Step 1: Define Safety Functions and SIL Targets
Extract each safety instrumented function from your process hazard analysis or layer of protection analysis. For a fired heater, typical functions include:
- Master fuel trip on low furnace draft
- Master fuel trip on loss of all burner flames
- Purge sequence enforcement before ignition
- Fuel valve closure on high furnace temperature
- Individual burner trip on loss of flame
Each function has an assigned SIL target based on required risk reduction.
Step 2: Document As-Built Architecture
Field verification requires as-built documentation, not design intent. Walk down the installation and document:
- Actual sensor types, locations, and mounting
- Wiring routing, separation, and grounding
- Logic solver configuration and firmware version
- Final element types, actuator configurations, and fail-safe states
- Proof test procedures actually performed
Discrepancies between design and as-built configuration are common and often significant.
Step 3: Obtain Component Reliability Data
Collect failure rate data for each component. Certified safety devices include manufacturer-provided failure rates (lambda_d for dangerous failures, lambda_s for safe failures, lambda_dd for dangerous detected failures). For non-certified components, use industry databases or conservative estimates.
Document the source of all failure rate data. Verification calculations are only as credible as the underlying data.
Step 4: Calculate PFDavg for Each Function
Use established formulas from ISA-TR84.00.02 or equivalent tools. For a simple 1oo1 architecture:
PFDavg = (λ_du × TI) / 2
Where λ_du is the dangerous undetected failure rate and TI is the proof test interval.
For redundant architectures, calculations become more complex, incorporating beta factors for common-cause failures and diagnostic coverage factors.
Step 5: Compare Against Target SIL
If calculated PFDavg falls within the target SIL range, the function passes verification. If not, identify which contributors dominate the PFD:
- Long proof test intervals
- Low diagnostic coverage
- High component failure rates
- Insufficient redundancy
Illustrative Scenario: Furnace Draft Transmitter Loop
The following is an illustrative example to demonstrate verification principles.
Consider a master fuel trip function based on furnace draft measurement. The SIL target is SIL 2 (PFDavg < 0.01).
As-designed architecture: 1oo2 draft transmitters (one-out-of-two voting, single-fault tolerant) feeding a certified SIL 3 logic solver, with two fuel shut-off valves arranged in series (2oo2 for the trip function — both must close, no fault tolerance in the final element).
Field walkdown reveals:
- One transmitter was replaced with a non-certified unit after failure
- Proof test procedure tests only one transmitter at a time, never simultaneously
- Final element partial stroke testing was disabled due to nuisance trips
Corrective actions:
- Replace non-certified transmitter or re-verify with conservative failure rates
- Revise proof test to validate simultaneous transmitter operation
- Implement partial stroke testing with proper configuration to prevent nuisance trips
- Consider reducing proof test interval to 9 months
Practical Verification Checklist
Use this checklist for BMS SIL verification projects:
Documentation Review
- [ ] Safety requirement specification defines each SIF and target SIL
- [ ] Process hazard analysis or LOPA documents risk reduction requirements
- [ ] As-built drawings reflect actual installation
- [ ] Proof test procedures documented for each SIF
Component Assessment
- [ ] All safety-critical components identified with tag numbers
- [ ] Failure rate data obtained from manufacturers or databases
- [ ] Systematic capability confirmed (prior use or certification)
- [ ] Diagnostic coverage factors documented
Architecture Verification
- [ ] Voting arrangements confirmed (1oo1, 1oo2, 2oo3, etc.)
- [ ] Hardware fault tolerance meets SIL requirements
- [ ] Common-cause failure potential assessed (beta factors)
- [ ] Field wiring and separation verified
Calculation and Analysis
- [ ] PFDavg calculated for each SIF using documented methodology
- [ ] Proof test interval justified and achievable
- [ ] Sensitivity analysis performed on key parameters
- [ ] Results compared against target SIL for each function
Systematic Failure Assessment
- [ ] Configuration logic reviewed for errors
- [ ] Bypass and override procedures evaluated
- [ ] Management of change procedures adequate for safety systems
- [ ] Competency of maintenance personnel confirmed
Documentation and Approval
- [ ] Verification report prepared with calculations and assumptions
- [ ] Deviations from target SIL documented with risk assessment
- [ ] Operations and maintenance informed of proof test requirements
- [ ] Re-verification schedule established for future modifications
Maintaining Verification Over Time
SIL verification is not a one-time activity. IEC 61511 requires revalidation when:
- Safety instrumented functions are modified
- Components are replaced with non-identical parts
- Proof test intervals change
- Operating conditions exceed original design basis
- Periodic review cycles occur (typically every five years)
Establish a management of change procedure that triggers re-verification. A seemingly minor component replacement can invalidate previous verification if failure rates or diagnostic capabilities differ.
Maintain a verification register documenting the current SIL status of each safety function. This register should include calculation date, key assumptions, proof test interval, and next scheduled review.
Moving Forward with Confidence
SIL verification transforms your burner management system from a collection of interlocks into a quantified risk reduction measure. The verification process frequently reveals gaps between design intent and field reality—gaps that represent real safety vulnerabilities.
Start with your highest-consequence safety functions. If process hazard analysis identified scenarios with potential for multiple fatalities or catastrophic asset loss, verify those SIL 3 functions first. Document what you find, quantify the actual performance, and close gaps systematically.
Engage your instrumentation and controls group, operations personnel, and maintenance leads in the verification process. They understand field realities that design engineers may miss. Their buy-in ensures proof test procedures will actually be performed as documented.
If calculated PFDavg exceeds target SIL, resist the temptation to simply extend proof test intervals on paper. Address root causes: improve diagnostics, add redundancy where cost-justified, or implement more frequent testing. The goal is actual risk reduction, not paperwork compliance.
Schedule verification reviews in advance of regulatory inspections or insurance audits. Proactive verification demonstrates management commitment to functional safety and typically reveals issues while time exists for orderly correction rather than emergency response.
Browse the full Reliability section for more.