PFH
Measure
Topic overview
Quick facts
PFH quantifies how often a safety function can be expected to fail dangerously, per hour of operation, from random hardware failures. sets banded targets: 1 requires better than 1E-5 dangerous failures per hour, SIL 2 better than 1E-6, SIL 3 better than 1E-7, and SIL 4 better than 1E-8.
It applies to high-demand and continuous-mode functions, which covers essentially all machinery and robotics applications; low-demand process functions use the companion metric PFDavg (average probability of failure on demand) instead.
PFH is computed from component dangerous failure rates, the architecture (single channel, dual channel, voting), diagnostic coverage, common-cause failure factors, and proof test intervals, typically via an feeding architecture formulas or Markov models.
Because it addresses only random hardware failures, PFH says nothing about design errors, specification gaps, or software bugs; those are controlled by the systematic capability requirements that run in parallel.
A subtle but critical point: PFH is necessary but not sufficient for a claim. The architectural constraints (hardware fault tolerance and safe failure fraction, or route 2H) and systematic capability must also be met. A single-channel design with a superb PFH number still cannot claim SIL 3 if it violates the fault-tolerance requirements.
PFH bands per SIL (high demand)
Why PFH matters
PFH numbers flow through the supply chain as hard procurement criteria: integrators sum the PFH of sensor, logic, and actuator subsystems against the loop budget, so a component whose PFH consumes most of the budget is commercially unattractive regardless of its other merits.
For product leaders, the practical consequences are that credible failure-rate data must exist for every safety-relevant component (constraining sourcing), and that late component substitutions can silently break a certified loop calculation. Overstated PFH claims discovered in assessment or after an incident carry serious liability.
How PFH is applied
Quantifying PFH for a function
A reliability or safety engineer performs an on the hardware design: each component's failure rate from a recognized database or manufacturer data is partitioned into safe and dangerous, detected and undetected fractions based on the diagnostic design.
The resulting rates feed the architecture formulas of IEC 61508-6 or ISO 13849, together with common-cause beta factors and the proof or diagnostic test intervals, yielding the subsystem and loop PFH. This happens during detailed design and is updated whenever components or diagnostics change.
Assessors probe the inputs: whether failure rates come from justified sources at the right environmental conditions, whether claimed diagnostic coverage matches diagnostics that actually exist in the design, whether the mission time and proof test assumptions are realistic for how the machine will be maintained, and whether the loop calculation covers the whole chain rather than the logic solver alone.
PFH pitfalls to avoid
Standards related to PFH
PFH is defined and governed by IEC 61508 - the umbrella functional safety standard defining the safety lifecycle, sil levels, and requirements for electrical, electronic, and programmable systems.
PFH vs PFDavg
| Aspect | PFH | PFDavg |
|---|---|---|
| Mode | High demand / continuous | Low demand (<1 demand/yr) |
| Units | Failures per hour | Dimensionless probability |
| Typical domain | Machinery, drives, rail | Process industry SIS |
| SIL 2 band | 1E-7 to <1E-6 /h | 1E-3 to <1E-2 |
| SIL 3 band | 1E-8 to <1E-7 /h | 1E-4 to <1E-3 |
PFH by industry
PFH shapes how industrial machinery teams argue safety - fixed and mobile machinery, packaging lines, and manufacturing equipment.
Ask our team about PFH
PFH: related terms
How each connects to PFH:
SIL appears in the same lifecycle work as PFH and is usually produced or reviewed alongside it.
FMEDA appears in the same lifecycle work as PFH and is usually produced or reviewed alongside it.
Functional Safety is governed by IEC 61508 as well, which is why the two show up together in audits.
Both PFH and Safety Function sit under IEC 61508, so evidence for one usually references the other.
Safe Torque Off is governed by IEC 61508 as well, which is why the two show up together in audits.
Both PFH and FMEA sit under IEC 61508, so evidence for one usually references the other.
Fault Tree Analysis is governed by IEC 61508 as well, which is why the two show up together in audits.
Verification and Validation is governed by IEC 61508 as well, which is why the two show up together in audits.
IEC 61508 connects the two: PFH and Safety Management System are assessed against the same lifecycle.
Functional Safety Plan is governed by IEC 61508 as well, which is why the two show up together in audits.
Both PFH and Functional Safety Engineer sit under IEC 61508, so evidence for one usually references the other.
Safety Manager is governed by IEC 61508 as well, which is why the two show up together in audits.
