Skip to content
SILProof
My SIFs Join free
Home/Knowledge Hub/Failure data for SIL verification

Verification · Technical

Failure data for SIL verification

A verification result is only as defensible as the data behind it. Failure rates must match the device, application, environment, failure-mode definitions and calculation model.

Engineering guide11 min readUpdated 10 October 2026Published by SILProof Engineering

In brief

What to carry into the engineering work

  • Keep the device boundary, revision, units and failure classification with every data value.
  • Use device-specific evidence where possible and justify generic or field data against the application.
  • Diagnostics and common-cause assumptions need evidence; they are not tuning factors.

Failure-rate categories

λSU
Safe undetected failure rate.
λSD
Safe detected failure rate.
λDU
Dangerous undetected failure rate; normally the main low-demand PFDavg driver.
λDD
Dangerous detected failure rate, subject to the stated diagnostic and restoration assumptions.

Use the strongest applicable source

  1. Device-specific safety manual and FMEDA information for the actual hardware and revision.
  2. Justified prior-use or field-return data with a defined population, service and confidence basis.
  3. Recognised generic industry data for screening or when its application conditions are defensible.

Do not silently mix rates from different classifications, units or operating assumptions.

Units and boundaries

FIT means failures per 109 device-hours. Record whether a published number is per device, channel, assembly or function. Confirm the dangerous-failure definition, diagnostic test interval, proof-test assumptions and whether external components are included.

λ [per hour] = FIT × 10−9

Diagnostics and common cause

Diagnostic coverage may move part of the dangerous failure rate from undetected to detected only when the claimed diagnostic actually detects the relevant failure modes within the assumed interval. Redundant channels also require a common-cause model such as the β-factor approach; the β value needs an engineering basis, not a convenient default.

Data review checklist

  • Manufacturer, model, hardware and firmware revision.
  • Source document, issue date and page or table reference.
  • Service conditions and device boundary.
  • Failure categories, units and confidence basis.
  • Diagnostic, proof-test and repair assumptions.
  • Reason the data is applicable to the project device.

Primary references

  1. IEC — Overview of IEC 61508 and functional safety
  2. IEC 61511-1 — process-industry SIS framework and requirements
  3. ISA — ISA-84 series of standards

Use the applicable edition and national adoption. Project specifications and controlled procedures may add requirements.

Continue

Related guides

PFDavgLow-demand probability of failure, SIL bands and the SILProof algebraic and Markov basis.Proof testing and restoration assumptionsConnect proof-test interval, coverage, diagnostics and repair assumptions to a procedure that can actually be executed.Engineering basis and review guideUnderstand scope, assumptions, engine methods and the checks needed before relying on a result.