Choose your reading route
eduKateSG · Why Mathematics? · Functional Safety: Probability of Failure on Demand, Proof-Test Coverage and Risk Reduction
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 8–14
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 15–21
Check assumptions
See where design and calibration matter.Route 4 · Chapters 22–28
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 29–46
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important in functional safety? It helps estimate whether a specified safety function may be unavailable when demanded, how proof-test intervals expose hidden failures and what risk reduction a protection layer may support. The calculation belongs inside a governed safety lifecycle.
Did You Know? The familiar PFD average approximation contains a factor of one-half because a hidden failure is assumed to occur, on average, halfway between perfect proof tests.
Full chapter index
Chapters 1–7 · Understand the question
Chapters 8–14 · Reproduce the example
Chapters 15–21 · Check assumptions
Chapters 22–28 · Explore applications
Chapters 29–46 · Study and verify
- Applications and careers
- Guidance for students and parents
- Common misconceptions
- Connection to recent mathematics articles
- Practice questions
- Frequently asked questions
- A reporting checklist
- A final audit
- Useful next reading
- Architecture and voting logic
- Partial-stroke and partial proof tests
- Common-cause sensitivity
- Spurious trips and competing objectives
- Uncertainty and conservative claims
- Independent protection layers
- Student investigation
- Proof-test effectiveness and restoration evidence
- Demand frequency and mode classification
CHAPTER 1 OF 46 · Understand the question
1. Why functional safety needs mathematics
Functional safety concerns the part of overall safety that depends on systems responding correctly to dangerous conditions. Mathematics estimates how often a safety function may be unavailable when demanded, how proof testing changes exposure and how much risk reduction a design may support. These calculations sit inside a safety lifecycle. They cannot replace hazard identification, competent engineering, procedures or independent protection. A single impressive number is never the whole safety case.
Define the initiating condition, sensors, logic, final elements and safe state. A function might detect high pressure, decide to trip and close a valve. Success requires the complete chain to act within the required time. Testing only a sensor or logic solver does not prove the end-to-end function. State environmental, utility and bypass conditions. The probability model must match the actual boundary.
The UK Health and Safety Executive defines functional safety and describes the safety lifecycle: hazard and risk assessment, allocation of risk reduction, specification, design, validation, operation, maintenance, proof testing, modification and decommissioning. Read HSE functional safety guidance. HSE also explains why proof-test frequency and ability to reveal hidden failures affect protective-system failure probability.
A low-demand safety function is called infrequently, so average probability of failure on demand, PFDavg, is a common measure. High-demand or continuous functions are often characterised by dangerous failure frequency or probability per hour. The classification and standard definitions matter. Using PFDavg for a continuously operating control can misrepresent risk. State demand rate, operating mode and applicable standard before choosing an equation.
CHAPTER 5 OF 46 · Understand the question
5. Dangerous detected and undetected failures
Diagnostics may reveal some dangerous failures during operation, allowing repair. Dangerous undetected failures remain hidden until a demand, proof test or other discovery. Separate rates such as lambda_DD and lambda_DU where the model requires them. Diagnostic coverage is not proof-test coverage. A diagnostic can miss systematic errors or final-element problems. Failure classification needs a failure-mode analysis and evidence, not only a database code.
For one simple low-demand channel with constant dangerous undetected failure rate lambda_DU, perfect proof testing at interval T and immediate perfect restoration, a common approximation is PFDavg≈lambda_DU T/2 when probabilities are small. The factor one-half reflects an undetected failure occurring, on average, halfway through the interval. Every word in the assumption list matters. Real architectures often need a fuller model.
| Input or result | Value |
|---|---|
| Dangerous undetected rate | 2e-6 per hour |
| Proof-test interval | 8,760 hours |
| Approximate PFDavg | 0.00876 |
| Approximate RRF | 114 |
| Scope | single simplified channel, ideal assumptions |
Let lambda_DU=2×10^-6 per hour and T=8,760 hours. The simple approximation gives 2×10^-6×8,760/2=0.00876. The reciprocal is an illustrative risk reduction factor of about 114. This is not a claim about any real safety instrumented function. Partial coverage, common cause, repair time, diagnostics, demand and systematic capability can change the result.
RRF is often expressed as the reciprocal of PFDavg for the specified safety function and model. It communicates the factor by which that layer reduces a defined demand risk under assumptions. It is not a general statement that the plant is 114 times safer. Overall risk also includes initiating-event frequency, other protection layers, human factors and consequences. Avoid multiplying dependent layers as if independent.
In the simple model, halving T approximately halves PFDavg. More frequent testing can discover hidden failures sooner, but testing creates workload, bypass time and possible maintenance error. The interval should follow the safety requirements, failure data, coverage and authorised lifecycle process. HSE emphasises procedures, criteria, operating restrictions and competent personnel. Do not select a real interval from a classroom formula.
A proof test may reveal only a fraction of dangerous hidden failures. Partial coverage leaves residual failures accumulating until a more complete test, overhaul or mission end. Model covered and uncovered portions with their own discovery intervals. Coverage needs failure-mode evidence, not a guessed percentage chosen to meet a target. End-to-end tests can reveal interactions that component tests miss, but may carry operational risk.
HSE states that failure probability depends critically on proof-test frequency and ability to detect previously unrevealed failures. It calls for procedures with success criteria, safe performance, operating restrictions and competence, and notes the importance of end-to-end testing. Read HSE control-system proof-testing guidance. Application remains the responsibility of qualified professionals under the relevant legal and standards framework.
IEC 61508 is a foundational functional-safety standard for electrical, electronic and programmable electronic safety-related systems. IEC’s official page for Part 6 notes worked guidance for hardware-failure probability and diagnostic coverage. See IEC 61508-6. The standard must be obtained and applied through competent, authorised practice; an educational summary cannot substitute for its requirements.
A safety integrity level includes quantitative targets in the appropriate mode and constraints on architecture, systematic capability, lifecycle and competence under the applicable standard. Meeting a PFD calculation alone does not establish a SIL claim. Hardware fault tolerance, common cause, software development, verification and management of change matter. Use the exact standard and sector guidance. Avoid advertising a level from a spreadsheet result.
| Assumption | Possible complication |
|---|---|
| Constant dangerous undetected rate | ageing or varying environment |
| Perfect proof test | partial coverage |
| Immediate perfect restoration | repair delay or imperfect repair |
| Independent channels | common-cause failure |
| Low-demand mode | frequent or continuous demand |
Redundant channels may share environment, power, impulse lines, software, maintenance or design. A common cause defeats the independence assumption that makes redundant probabilities multiply. Beta-factor and richer models are used when justified, but parameter evidence is often uncertain. Physical separation and diversity can reduce some causes, not all. Document shared dependencies before calculating architecture benefit.
One-out-of-two, two-out-of-three and other voting structures trade spurious-trip behaviour against dangerous failure probability. The model must include detection, repair, proof testing and common cause. A parallel reliability block diagram can be misleading if the safety success logic differs from service availability. Derive states from the function and validate with fault-tree or Markov methods where appropriate.
Valves, breakers and actuators often dominate dangerous failure probability because they interact with the physical process. A logic-solver self-test cannot reveal every stuck or disconnected final element. Proof tests should address the complete path and realistic trip conditions where safely possible. Record partial strokes, full strokes and discovered failures distinctly. Component data must match service conditions and failure definitions.
A detected failure remains unavailable until restoration and verification. Proof testing may require bypass or shutdown. Include repair and test states in average unavailability when relevant. Temporary compensating measures need authorised procedures. A shorter test interval can reduce latent exposure while increasing time in test or maintenance. Optimisation belongs inside the safety lifecycle and operational constraints.
A low-demand function can still face changing demand frequency after a process modification. Record actual demands and near demands, then review the mode classification and assumptions. A proof test is not necessarily a process demand. If demands become frequent, wear and independence between demand and failure may matter. The safety requirements specification should define the operating mode and review triggers.
Hardware random-failure mathematics does not cover specification mistakes, software faults, incorrect procedures or common design errors completely. Systematic capability relies on lifecycle processes, verification, validation and competence. A very small calculated PFD can create false confidence if the safety function is specified incorrectly. Trace each hazard to a requirement and each requirement to evidence. Quantitative and systematic arguments must coexist.
Failure-rate inputs may come from generic databases, manufacturer data or field experience. Match device, environment, duty and failure definition. Record confidence and censoring. Field data can be biased because proof tests have different coverage or reporting quality. Update estimates carefully without discarding conservative assumptions casually. More decimal places do not create better evidence.
PFD calculations contain parameter, model and coverage uncertainty. Show sensitivity to lambda_DU, T, repair time, common cause and coverage. Monte Carlo methods can propagate distributions, but the chosen distributions need justification. A result near a target requires deeper review than a rounded point estimate. Conservative assumptions should be visible rather than hidden in unexplained safety factors.
Several protection layers reduce risk only if their functions and failures are sufficiently independent. Shared sensors, power, operators or procedures can couple them. An alarm with operator response is not automatically independent of the basic control system. Map dependencies explicitly. Multiplying nominal RRF values without checking independence can overstate protection dramatically.
A safety function in bypass cannot provide its calculated protection. Track bypass start, reason, approval, compensating measures and restoration. Alarm on unauthorised or prolonged bypass. Include proof-test and maintenance bypass exposure in operational review. A design calculation represents intended states; operational discipline determines whether those states exist. Human factors and clear displays matter.
Changing setpoints, logic, instruments, process chemistry or test intervals can alter the safety case. Use a governed change process with hazard review, verification, updated documents and training. A small software edit can invalidate assumptions across several calculations. Preserve version history and configuration. Never reuse a prior PFD report after an unassessed modification.
Validation demonstrates that the installed system meets the safety requirements specification across functions and conditions. It is broader than checking a calculation. Test cause-and-effect, timing, interfaces, fault responses and final action. Record deviations and closure. Independence of review may be required. A passed factory test does not automatically validate the installed process environment.
Use a fictional single-channel system with a constant hidden dangerous-failure rate and perfect annual proof test. Calculate PFDavg and RRF, then halve the interval. Add a coverage gap and explain why the simple formula becomes incomplete. Students learn rates, expected waiting time and reciprocals while also learning that safety engineering requires standards and professionals. Do not use the exercise to set a real test interval.
Create input cells for lambda_DU, T, repair, coverage and common-cause assumptions, with units and sources. Calculate only formulas valid for the stated architecture. Add sensitivity tables and scenario labels. Protect formulas and show revision history. Include a separate lifecycle evidence sheet for hazards, requirements, verification and proof-test procedures. A spreadsheet should support review, not conceal assumptions behind one result cell.
Represent states and transitions explicitly for architectures beyond the simple approximation. Unit-test zero rate, zero interval, single-channel and known analytic cases. Use dimensional checks. Version parameters and source references. Produce contribution and sensitivity reports, not only PFDavg. Independent verification should compare a second method where risk warrants it. Code cannot approve its own safety claim.
Functional safety appears in process plants, machinery, transport, energy, medical technology and other regulated systems. Roles combine mathematics, control, reliability, software, process engineering and safety management. Mathematics supports these pathways but does not guarantee employment or salary. Students should build foundations in probability and systems thinking, then follow current official qualifications and supervised professional practice.
Students should first draw the complete safety function and identify a hidden failure. Reproduce the simple PFD calculation with units, then list the assumptions that make it unsafe to apply universally. Parents can encourage careful language: a risk reduction estimate is not a guarantee. Use fictional systems. The transferable lesson is that mathematics becomes trustworthy when the model boundary, evidence and governance are explicit.
PFDavg is not the probability of an accident. RRF is not a universal safety multiplier. More redundancy is not automatically independent. A component proof test may not test the full function. Diagnostic coverage and proof-test coverage differ. A shorter interval is not free of risk. Meeting a number alone does not establish SIL. Functional safety includes lifecycle, competence and systematic failures.
Read Fault Tree Analysis for system logic, Reliability Block Diagrams for architecture and Preventive Maintenance Optimisation for interval trade-offs. The Mathematics Learning Hub connects probability and systems reasoning.
1. Calculate PFDavg for the worked example. 2. Find the reciprocal RRF. 3. Halve T and recalculate. 4. Explain the T/2 factor. 5. Distinguish low- and high-demand mode. 6. Give one common cause. 7. Explain partial proof-test coverage. 8. Name one systematic failure. 9. Describe bypass evidence. 10. Write a cautious conclusion that does not claim safety certainty.
### Is PFDavg the accident probability? No. It estimates unavailability of a specified safety function on demand under a model.
### Does RRF=100 mean the plant is 100 times safer? No. It applies to the defined layer and assumptions, not overall risk automatically.
### Can this article choose a proof-test interval? No. Real intervals require competent authorised engineering and applicable standards.
### Is redundancy enough? No. Common causes and lifecycle evidence matter.
Define hazard, demand mode, safety function, safe state and architecture. State failure-rate sources, diagnostics, proof-test interval and coverage, repair, common cause and mission time. Show equations, units, uncertainty and sensitivity. Trace requirements to validation and operations. Record bypasses and changes. Cite current HSE and IEC material accurately. Avoid claiming SIL or safe operation from one calculation.
Recalculate 0.00876 and reciprocal 114 with units. Check low-demand assumptions and the small-probability approximation. Inspect coverage, common cause, repair and bypass treatment. Verify architecture logic and failure classifications. Confirm source statements. Remove any operational recommendation, unauthorised interval or sentence that treats PFDavg as accident probability, RRF as universal protection or a calculation as proof of functional safety.
Continue with HSE functional-safety and proof-testing guidance and the applicable IEC 61508 or sector standard through authorised access. Compare with fault trees, Markov reliability, proof-test maintenance and common-cause modelling. The Mathematics Learning Hub links rates, probability, expected time and systems analysis.
A safety function may use one-out-of-two, two-out-of-three or other voting logic. Architecture changes both dangerous failure probability and spurious-trip behaviour. Draw the channels, sensors, logic solver and final elements before calculating. Identify shared utilities, communications and environmental causes that violate independence. Use appropriate standard methods or verified models; multiplying channel probabilities alone is rarely sufficient for a real system.
A partial test may reveal some dangerous hidden failures while leaving others untouched. Split the dangerous undetected failure rate by coverage and apply the relevant test intervals to each portion. Coverage itself has uncertainty and depends on the procedure, device and acceptance criteria. Record what the test exercises end to end. Calling a partial test a proof test without its coverage can overstate risk reduction.
Redundant channels can fail together through shared design, environment, maintenance or power. Parameter models provide one way to represent common cause, but their values need justified evidence. Perform sensitivity analysis because a small common-cause contribution can dominate a highly redundant calculation. Look beyond numerical factors to physical separation, diversity and procedures. Mathematics supports the review; it does not replace engineering judgement or lifecycle controls.
A design that reduces dangerous failure may increase nuisance trips, which can create production loss or hazardous restart behaviour. Track safe and dangerous failure modes separately. Evaluate restart, bypass and operator response, not only trip frequency. The aim is a complete risk decision under the applicable safety lifecycle. It is unsafe to relax a protective requirement merely to improve availability without authorised hazard review.
Failure rates, coverage and repair times are estimates. Present ranges or distributions and show which inputs drive PFDavg. Conservative assumptions can protect against unknowns, but stacking unrelated worst cases may also obscure the real decision. Document the basis for each parameter and update it with relevant evidence under change control. Report the resulting claim at the precision the data support.
Risk reduction may be allocated across prevention, control, alarms and safety instrumented functions. Independence is essential: layers that share sensors, logic, utilities or operators may not provide multiplicative reduction. Define the initiating event and conditional performance of each layer. A layer-of-protection calculation does not certify a system by itself. Qualified teams must apply the current sector rules and validate the complete safety function.
Use a fictional single-channel system only. Recalculate the simple PFDavg example for several proof-test intervals and graph the relationship. Then add hypothetical imperfect coverage to show why one formula is incomplete. List every assumption and write a paragraph explaining why the result cannot select a real interval or establish a safety integrity level. The learning goal is disciplined modelling, units and limitations.
CHAPTER 45 OF 46 · Study and verify
45. Proof-test effectiveness and restoration evidence
A written proof-test procedure should map every step to the dangerous hidden failures it can reveal. Validate detection, measurement accuracy, acceptance criteria, bypass controls and restoration to service. Record as-found and as-left condition, test duration, overdue time and any repair. Analyse proof-test results for recurring mechanisms, but do not automatically convert every discovered fault into a constant failure rate without considering exposure and reporting quality. A successful test is evidence that specified checks passed at that time; it is not proof of perfect protection until the next test. Independent review should confirm that procedures follow the applicable safety requirements and that changes receive authorised management of change. Mathematical coverage factors need this physical and documentary basis before they can support a PFD calculation.
The same hardware can require different reliability measures depending on how often the safety function is demanded and whether it operates continuously. Define a demand from the hazard scenario and use evidence to estimate its frequency. Low-demand PFDavg methods should not be carried into high-demand or continuous operation merely because the formula is familiar. Check the applicable IEC or sector standard for definitions and methods. Explore sensitivity near classification boundaries, and consider whether operating changes have increased demand frequency. A change in process, control strategy or alarm response can alter the classification even when the protective equipment is unchanged. Record the basis and have competent authorised professionals review it.
Extended practice laboratory
Practice case 1: Simple PFD average
Setup: Use dangerous undetected rate 2e-6 per hour and proof-test interval 8,760 hours.
Task: Calculate lambda_DU*T/2.
Checking target: Obtain 0.00876 under the simple assumptions.
Practice case 2: Risk reduction factor
Setup: Use PFDavg 0.00876.
Task: Calculate its reciprocal.
Checking target: Obtain about 114, without claiming the real system achieves it.
Practice case 3: Change the interval
Setup: Halve T in the simple model.
Task: Calculate the new approximation.
Checking target: PFDavg approximately halves only under the same assumptions.
Practice case 4: Coverage gap
Setup: Assume a proof test detects only part of dangerous failures.
Task: Separate detected and undetected portions.
Checking target: Recognise that lambda*T/2 alone is incomplete.
Practice case 5: Demand mode
Setup: Distinguish low-demand operation from continuous/high-demand operation.
Task: Choose the appropriate measure.
Checking target: Do not use PFDavg universally.
Practice case 6: Safety function
Setup: Write cause, trip logic and safe action.
Task: Define success end to end.
Checking target: A component test may not prove the whole function.
Practice case 7: Common cause
Setup: Add one shared failure mechanism.
Task: See why independent channel multiplication fails.
Checking target: Model shared causes explicitly.
Practice case 8: Repair time
Setup: Include proof-test duration and restoration.
Task: Track temporary unavailability.
Checking target: Testing can create operational exposure.
Practice case 9: Bypass control
Setup: Record overrides and inhibitions.
Task: Calculate time in bypass.
Checking target: A calculated design integrity can be defeated operationally.
Practice case 10: Lifecycle evidence
Setup: Link hazard analysis, requirements, design, validation and operations.
Task: Trace each claim.
Checking target: Functional safety is a lifecycle discipline.
Practice case 11: Competence check
Setup: Identify who approves procedures and changes.
Task: Keep calculations under qualified review.
Checking target: An article is not engineering authorisation.
Practice case 12: Write a decision
Setup: State model, rates, interval, coverage and limits.
Task: Report PFDavg and RRF carefully.
Checking target: Never promise safety from one number.