Functional Safety with IEC 61508: SIL, PFD, Safety Instrumented Systems and Safety PLC Architecture

A pressure transmitter that fails “high” is an annoyance. One that fails “stuck at normal” while a reactor climbs toward its relief setpoint is a catastrophe, and nothing in the process data will tell you which one you own. Functional safety is the discipline of putting a number on that difference: it asks how likely a safety function is to fail dangerously when called upon, and it demands evidence for the answer rather than good intentions.

The reference framework is IEC 61508, and the industry vocabulary built on it (SIL, PFD, SIF, SIS, HFT, SFF) is now showing up in places that used to ignore it, from cloud-connected edge gateways to digital twins that mirror safety logic. The standard is also moving, with a third edition in the pipeline. This article gives you the working model: how a Safety Integrity Level is assigned, how a PFD is calculated for 1oo1, 1oo2 and 2oo3 architectures with runnable code, what a safety instrumented system actually contains, and how a safety PLC achieves its claims inside.

What this covers: the standards landscape, the SIL and PFD maths, voting architectures and common cause, SIS design, safety PLC internals and safe communication, failure modes in practice, and a checklist for engineers who must defend a safety case.

Context and Background

IEC 61508, titled “Functional safety of electrical/electronic/programmable electronic safety-related systems”, is the generic, sector-independent standard. Its second edition dates from 2010 and has seven parts: general requirements (Part 1), hardware and system requirements (Part 2), software requirements (Part 3), definitions (Part 4), example methods for determining safety integrity levels (Part 5), guidelines on applying Parts 2 and 3 including worked reliability formulas (Part 6), and an overview of techniques and measures (Part 7). Most engineers meet it second-hand, through derived standards.

Those derivatives matter more day to day. IEC 61511 covers safety instrumented systems for the process industry and targets the user (the plant owner and integrator). IEC 62061 and ISO 13849 cover machinery. ISO 26262 covers road vehicles, EN 50126/50128/50129 cover rail, and IEC 62304 covers medical device software. IEC 61508 is aimed at the manufacturer of components and subsystems, such as a logic solver, a transmitter or a valve actuator, which is why you see “SIL 3 capable” on certificates for safety PLCs.

The standard is in transition. According to the 61508 Association’s standards-development page, an Edition 3 Committee Draft had been published and commented on, with a Committee Draft for Vote expected in early 2026 and availability anticipated in early 2027. Separately, drafts labelled FprEN IEC 61508-2:2026 and -3:2026 have appeared in standards catalogues; I have not verified their exact status, so treat any claim that Edition 3 is already in force as unconfirmed. On the process side, the IEC webstore lists an “IEC 61511:2026 SER” bundle dated 10 July 2026, which packages the existing parts (61511-1:2016+AMD1:2017, -2, -3 and the technical reports) rather than a new technical edition. Until you see a published Edition 3, design to the 2010 text and 61511 Edition 2.

Why does this belong on an IoT and digital twin site? Because the boundary between control and safety is being redrawn. Soft PLCs, virtualised control and cloud analytics are encroaching on plants where a single dangerous undetected failure has legal consequences. If you build the architectures described in our guide to PLC scan cycles and IEC 61131-3 determinism, you will recognise the timing budget concerns that safety layers inherit. The cybersecurity side, where an attacker can defeat a safety function without any random hardware fault, is covered in the IEC 62443 zones and conduits primer and the EU CRA, NIS2 and IEC 62443 compliance mapping.

What “functional” means

The word is deliberate. Functional safety is not about making a pump casing thick enough; it is about whether an active function (detect overpressure, close valve) performs correctly in response to a hazard. Safety is achieved by the correct operation of a protective system, so the standard attacks three failure classes: random hardware failures (quantified with probabilities), systematic failures (design, specification and software errors, addressed by process rigour), and common cause failures (one root cause defeating redundant channels).

Everything else in the standard, from SIL tables to lifecycle phases, is machinery for managing those three classes at a level proportional to the risk.

The Reference Architecture: From Hazard to Safety Integrity Level

The functional safety workflow runs from hazard and risk assessment, through allocation of a target SIL to each safety function, to design, verification of the achieved PFD or PFH, validation and operation. A SIL is a bounded probability of dangerous failure per demand or per hour, plus process and architecture rules, not a property of a single device.

IEC 61508 defines a safety lifecycle: concept, scope, hazard and risk analysis, overall safety requirements, allocation, realisation, installation, validation, operation and maintenance, modification, decommissioning. The point of the lifecycle is traceability. Each safety requirement must descend from a hazard, and each design decision must trace back to a requirement.

Figure 1: The functional safety lifecycle, showing how a hazard becomes a SIL target, a design, a verified PFD and an operating proof-test regime.

Figure 1 compresses the lifecycle into the loop that engineers actually iterate: assess the hazard, set a target, design to it, verify the numbers, and then keep the claim alive through proof testing and management of change. The feedback arrow from operation to risk assessment is not decoration. A modified process, a new operating mode or a changed demand rate invalidates the original assumptions.

Safety Integrity Levels and the numbers behind them

A SIL is one of four discrete levels. For a function operating in low demand mode (called on no more than about once per year in the 2010 edition) the metric is the average probability of dangerous failure on demand, PFDavg. For high demand or continuous mode it is the average frequency of dangerous failure per hour, PFH.

SIL	PFDavg (low demand)	Risk reduction factor	PFH (high demand or continuous), per hour
1	10^-2 to < 10^-1	10 to 100	10^-6 to < 10^-5
2	10^-3 to < 10^-2	100 to 1,000	10^-7 to < 10^-6
3	10^-4 to < 10^-3	1,000 to 10,000	10^-8 to < 10^-7
4	10^-5 to < 10^-4	10,000 to 100,000	10^-9 to < 10^-8

The risk reduction factor (RRF) is simply 1/PFDavg, which is why SIL 3 is the “thousand-fold” level. Note the decade structure: each step costs roughly an order of magnitude in dangerous failure probability, and typically a large jump in engineering effort, because SIL 3 and above force diverse redundancy, rigorous software techniques and independent assessment.

Why does the demand mode distinction matter? In low demand mode, the safety function sits idle, so the dominant risk is a hidden failure that is only revealed at demand or at proof test. In high demand or continuous mode, the function is exercised so often that an undetected fault is found quickly, and the relevant question becomes how often a dangerous failure occurs per unit time. Machine guarding, an emergency stop on a press, and a vehicle braking function live on the PFH side. A relief-style shutdown on a vessel lives on the PFDavg side. Some functions straddle the boundary and need careful treatment, and the Intertek explainer on demand modes is a good primer on the distinction.

How a target SIL is assigned

The standard does not prescribe one method; Part 5 offers examples. In process plants the common techniques are:

Risk graph (calibrated). Qualitative: severity of consequence, exposure frequency, probability of avoiding the hazard, and demand rate combine to read off a SIL. Fast, conservative, and prone to over-specification.
Layer of Protection Analysis (LOPA). Semi-quantitative: start with an initiating event frequency, apply independent protection layers (IPLs) with credited PFDs, compare the mitigated event frequency to a tolerable frequency, and the gap defines the required risk reduction for the safety instrumented function.
Quantitative risk assessment. Full fault and event trees. Used for the highest consequence scenarios.

A LOPA example makes this concrete. Suppose an initiating event (cooling water loss) has a frequency of 0.1 per year, the tolerable frequency for the consequence is 10^-5 per year, and the basic process control system and operator response together are credited with a PFD of 0.1. The required additional PFD is 10^-5 / (0.1 × 0.1) = 10^-3, so the safety function needs a PFDavg of 10^-3 or better. That sits at the boundary between SIL 2 and SIL 3, so a conservative engineer designs to SIL 3 or revisits the credit for other layers. These numbers are illustrative, not drawn from any specific facility.

One discipline matters here: an IPL must be independent of the initiating event and of other layers. If the basic process control system causes the demand and is also credited as a protection layer, the credit is invalid. This is the same independence principle that makes the security zoning in IEC 62443 relevant to safety, an idea we return to later.

SIL is a system property, not a device property

Vendors certify a transmitter as “SIL 2 capable” or a logic solver as “SIL 3 capable”. That label means the product can be used in a safety function claiming up to that SIL if the architecture, proof test, diagnostics and process conditions meet the safety manual. The SIL of the function is established by the whole chain: sensor subsystem, logic solver subsystem, and final element subsystem. A SIL 3 logic solver wired to a single non-redundant valve with a poor proof test regime does not give a SIL 3 function.

Each subsystem must satisfy three independent constraints, and all must hold:

Probabilistic: the calculated PFDavg or PFH of the combined function lies within the target band.
Architectural: the hardware fault tolerance (HFT) and safe failure fraction (SFF) meet the table limits for that subsystem type (Route 1H), or a proven-in-use justification (Route 2H) is made.
Systematic: the product and its development process meet the required systematic capability (SC) for the claimed SIL, covering specification, design, software, change control and competence.

The second and third constraints are the ones most often forgotten by teams who treat SIL verification as a spreadsheet exercise. A beautifully low PFD calculation does not rescue a subsystem whose architectural constraints fail. We take each in turn.

Deeper Analysis: PFD Calculations, Voting Architectures and Common Cause

PFDavg for a single channel (1oo1) is approximately the dangerous undetected failure rate multiplied by half the proof test interval. Redundancy (1oo2, 2oo3) squares the independent failure terms, but a beta-factor common cause term usually dominates and sets the practical floor.

Failure rates and the four-way split

Every component failure rate λ is decomposed by consequence and detectability. λSD and λSU are safe detected and safe undetected; λDD and λDU are dangerous detected and dangerous undetected. Only λDU drives low-demand PFD, because a dangerous failure that diagnostics catch can be repaired or can trigger a safe state before a demand arrives.

The safe failure fraction is the share of failures that are not dangerous undetected:

SFF = (λSD + λSU + λDD) / (λSD + λSU + λDD + λDU)

and diagnostic coverage is DC = λDD / (λDD + λDU). A device with a high DC converts dangerous failures into detected ones, which is why intelligent transmitters with internal comparison, stuck-detect and loop-current monitoring achieve high SFF at low cost.

The simplified equations

The following are the widely used simplified forms for low demand mode, from the style of IEC 61508-6 Annex B, assuming perfect proof tests, negligible repair time effects, and a single common test interval TI. They are the starting point, not the full treatment (the standard’s formulas add the diagnosed-failure terms with mean time to restoration).

Architecture	Simplified PFDavg	Fault tolerance	Notes
1oo1	λDU · TI / 2	HFT 0	Any dangerous undetected fault defeats the function
1oo2	((1-β) λDU)² · TI² / 3 + β λDU · TI / 2	HFT 1	Either channel can trip; spurious trips rise
2oo2	λDU · TI	HFT 0	Both must agree to trip; fewer spurious trips, worse safety
2oo3	((1-β) λDU)² · TI² + β λDU · TI / 2	HFT 1	Majority voting; good safety and availability

The notation MooN means M channels out of N must demand the safe action for the voted output to act. 1oo2 therefore trips on either channel, which is safe but spurious-trip-prone; 2oo3 trips when any two agree, tolerating one dangerous failure and one spurious signal.

A worked example with illustrative numbers

Take a pressure transmitter with an illustrative λDU of 2 × 10^-6 per hour (2,000 FIT) and a yearly proof test, TI = 8,760 hours.

1oo1: PFDavg = 2e-6 × 8,760 / 2 = 8.76 × 10^-3. That is SIL 2 territory by the PFD band, ignoring the architectural constraints.
1oo2 with β = 5%: the independent term is (0.95 × 2e-6)² × 8,760² / 3 ≈ 9.2 × 10^-5, while the common cause term is 0.05 × 2e-6 × 8,760 / 2 = 4.38 × 10^-4. The total is about 5.3 × 10^-4, which lands in the SIL 3 band.
2oo3 with β = 5%: the independent term is about 2.8 × 10^-4 and the common cause term remains 4.38 × 10^-4, for roughly 7.2 × 10^-4, also SIL 3 band.

Two lessons jump out. First, redundancy bought an order of magnitude here, not the many orders the naive square would suggest, because the common cause term is more than four times the independent term in the 1oo2 case. Second, cutting β from 5% to 2% in the 1oo2 case drops the total to about 2.7 × 10^-4, slightly better than a 40% cut in λDU would give (about 3.0 × 10^-4). The cheapest PFD improvement is often separation, diversity and independent power and wiring, not a better component.

Figure 2: Voting architectures, showing why the common cause path (beta factor) bypasses channel redundancy and dominates PFD.

Figure 2 draws what the equations hide: the common cause path is a single arrow that skips the voting logic. Anything that shares a root cause (the same impulse line plugging, the same firmware bug, the same power supply, the same maintenance error, the same calibration mistake) lives on that arrow.

Proof testing, coverage and mission time

The PFD formulas assume failures accumulate linearly until the proof test, which resets the clock. Real proof tests are imperfect. If a test only detects a fraction PTC (proof test coverage) of dangerous undetected failures, the residual (1 – PTC) accumulates until a later, more complete test or until the end of the mission time. A common simplified correction for a 1oo1 channel is:

PFDavg ≈ PTC · λDU · TI / 2 + (1 – PTC) · λDU · MT / 2

where MT is the mission time (the interval between “as good as new” restorations, such as a full overhaul or replacement). With PTC = 90%, TI = 1 year and MT = 10 years using the transmitter above, the first term is 7.9 × 10^-3 and the second is 8.8 × 10^-3, which together almost double the perfect-test result. This is the single most common optimism in spreadsheet SIL verification. A partial stroke test of a valve, which exercises perhaps a fraction of the failure modes, is a diagnostic that reduces λDU credit but does not equal a full stroke proof test.

Proof test interval, then, is not a free parameter. Doubling it from one year to two doubles the 1oo1 PFD, which can drop a function out of its SIL band, and every extension needs a justified change under management of change.

Architectural constraints: HFT and SFF

Even with a perfect PFD, the standard limits the SIL you can claim from a subsystem by its hardware fault tolerance and safe failure fraction. Route 1H applies to Type B elements (complex devices such as a microprocessor-based transmitter, where failure modes are not fully defined) with the following maximum SIL:

SFF	HFT 0	HFT 1	HFT 2
< 60%	not allowed	SIL 1	SIL 2
60% to < 90%	SIL 1	SIL 2	SIL 3
90% to < 99%	SIL 2	SIL 3	SIL 4
≥ 99%	SIL 3	SIL 4	SIL 4

I reproduce this from the 2010 edition’s Route 1H table for Type B; confirm it against the standard before using it in a compliance document, since the full table also covers Type A elements and the allowed use of proven-in-use data under Route 2H. HFT of N means N+1 faults can cause loss of the function. A 1oo2 structure has HFT 1.

The practical reading: a single-channel (HFT 0) transmitter with 95% SFF can support SIL 2 at most, regardless of how pretty its PFD is. To reach SIL 3 with such a device you either add a second channel, or use a certified device with SFF above 99%, or justify proven-in-use under Route 2H. Our earlier discussion of a safety function’s three constraints is exactly this: PFD, architecture and systematic capability, each independently capable of vetoing a claim.

Runnable code: a SIF PFD calculator

The Python below computes simplified PFDavg for common architectures, adds the imperfect proof test term, and assembles a full safety instrumented function (sensor, logic, final element) by summing subsystem contributions. All numbers are illustrative, not from a datasheet.

from dataclasses import dataclass

HOURS_PER_YEAR = 8760.0

@dataclass
class Subsystem:
    name: str
    arch: str              # "1oo1", "1oo2", "2oo3", "2oo2"
    lam_du: float          # dangerous undetected, per hour, per channel
    beta: float = 0.05     # common cause fraction (undetected)
    ti_h: float = HOURS_PER_YEAR      # proof test interval in hours
    ptc: float = 1.0       # proof test coverage 0..1
    mt_h: float = 10 * HOURS_PER_YEAR # mission time in hours

def pfd_perfect(arch, lam, beta, ti):
    if arch == "1oo1":
        return lam * ti / 2
    if arch == "2oo2":
        return lam * ti
    ind = ((1 - beta) * lam) ** 2 * ti ** 2
    ccf = beta * lam * ti / 2
    if arch == "1oo2":
        return ind / 3 + ccf
    if arch == "2oo3":
        return ind + ccf
    raise ValueError(arch)

def pfd_avg(s: Subsystem) -> float:
    covered = pfd_perfect(s.arch, s.lam_du * s.ptc, s.beta, s.ti_h)
    # residual undetected-by-test failures accumulate over mission time
    residual = pfd_perfect(s.arch, s.lam_du * (1 - s.ptc), s.beta, s.mt_h)
    return covered + residual

def sil_band(pfd: float) -> str:
    if pfd < 1e-5:  return "better than SIL 4 band"
    if pfd < 1e-4:  return "SIL 4"
    if pfd < 1e-3:  return "SIL 3"
    if pfd < 1e-2:  return "SIL 2"
    if pfd < 1e-1:  return "SIL 1"
    return "no SIL"

sif = [
    Subsystem("pressure transmitters", "2oo3", 2e-6, beta=0.05, ptc=0.95),
    Subsystem("safety PLC logic",      "1oo1", 2e-8, ptc=0.99),
    Subsystem("shutdown valve",        "1oo1", 6e-7, ptc=0.80),
]
total = 0.0
for s in sif:
    p = pfd_avg(s)
    total += p
    print(f"{s.name:24s} {s.arch}  PFDavg={p:.2e}")
print(f"SIF total PFDavg={total:.2e} -> {sil_band(total)}  RRF={1/total:,.0f}")

Run it and you will see the final element dominate, which is typical: valves and actuators, being mechanical, have the highest λDU and the weakest proof test coverage. That is why experienced practitioners often say that a SIL 3 logic solver is the least of your problems. Improving final element PFD usually means a second valve (1oo2), partial stroke testing with credible coverage, or fewer demands through a better process design.

Figure 3: A safety instrumented function as a loop of three subsystems, each carrying a share of the total PFD budget.

Safety Instrumented Systems and Safety PLC Architecture

A safety instrumented system (SIS) is the set of sensors, logic solver and final elements that implements one or more safety instrumented functions, kept independent of the basic process control system. A safety PLC is the logic solver, certified to a SIL and built with redundant, self-checking processing channels.

SIS versus BPCS: why independence is the first rule

IEC 61511 requires the SIS to be separated from the basic process control system (BPCS) so a fault in one cannot defeat the other. The reasoning mirrors the LOPA independence rule: if the same controller both runs the process and protects it, a single systematic fault defeats both layers. In practice, separation means separate logic solvers, separate (or at least diversely wired) I/O, and strictly controlled communication. Read-only data from the SIS to the BPCS and historian is normal; writes into the SIS from the control side should be forbidden or heavily guarded.

A digital twin that mirrors SIS states for operator training, what-if analysis or analytics should be a one-way consumer. If a twin or optimisation layer, such as the ones discussed in our piece on model predictive control and digital twins, can write setpoints, it must write to the BPCS, and the SIS limits must stay outside its authority. An MPC that respects constraints is a good control layer, not a protection layer.

Anatomy of a safety instrumented function

A safety instrumented function (SIF) has exactly one hazard it prevents and one SIL target. Its parts are:

Sensor subsystem: transmitters or switches, often 1oo2 or 2oo3, with dedicated impulse lines or tappings so one blocked line does not blind all channels.
Logic solver: the safety PLC or a relay or solid-state system, running the cause-and-effect logic, with voting, trip delays and diagnostics.
Final element subsystem: shutdown valves, solenoids, motor contactors or drives with safe torque off; often the largest PFD contributor.
Supporting items: power supplies, barriers, network components in the safety path, and bypass or override facilities, each of which must be inside the calculation or justified as outside.

The SIL of the function is assessed from the whole path. Two sensors and one valve is not a “SIL 3 function” just because the logic solver is SIL 3 certified.

Inside a safety PLC

A safety PLC achieves its integrity with hardware redundancy and diagnostics inside one box. Common architectures are:

1oo2 (dual channel): two processors execute the same logic and a comparator checks outputs; a mismatch drives a safe state. Strong on safety, with limited availability benefit.
1oo2D (dual channel with diagnostics): each channel carries its own diagnostics, so a detected failure can degrade to a running 1oo1 on the healthy channel rather than tripping. This helps availability without sacrificing the safety claim.
2oo3 (triple modular redundancy): three channels with majority voting, used in high-availability applications such as turbine protection and offshore.
Lockstep or diverse cores: two cores run in lockstep with cycle-by-cycle comparison, or two diverse processors run different code compiled from the same specification to break systematic faults.

Figure 4: Safety PLC architecture, with two channels, a comparator and watchdog, a safe output stage, and a safety protocol riding a black channel.

Figure 4 shows the pieces that earn the certificate: independent channel execution, a comparator, a hardware watchdog that can cut the outputs independently of software, and test-pulse capable input and output stages that catch stuck-at faults. Memory has ECC or double storage with signatures, and program flow is monitored. These measures are what push diagnostic coverage above 99% so the SFF and HFT table is satisfied for the logic subsystem.

Software has its own rules. Part 3 of IEC 61508 prescribes techniques that scale with the SIL: structured design, defensive programming, coding standards, restricted language subsets, coverage-based testing, and independent verification. In PLC practice this means programming in a certified limited-variability language, normally function block diagram or ladder logic using certified safety function blocks (emergency stop, two-hand control, muting) rather than free-form structured text. It is the opposite of the flexibility that makes standard PLC programming productive, and it is deliberate. Our coverage of IEC 61131-3 and LLM-generated PLC code discusses why generated code in the safety path needs verification evidence that a language model cannot supply by itself.

Safe communication: the black channel

Modern safety PLCs exchange safety data with remote I/O, drives and other controllers over standard industrial networks. The enabling idea is the black channel principle, described in the IEC 61784-3 profile family: the safety layer assumes the underlying network can corrupt, delay, repeat, reorder, insert or lose messages, and it detects all of those at the endpoints. Each safety message carries a sequence number or counter, a time expectation (watchdog), a connection identifier and a strong CRC. A violation drives the receiving node to its safe state.

PROFIsafe (on PROFINET and PROFIBUS), CIP Safety (on EtherNet/IP), FSoE (Fail Safe over EtherCAT) and openSAFETY all follow this pattern. The benefit is that the Ethernet switches, cables and gateways need not be certified, and the safety integrity of the transport is quantified by a residual error rate or a PFH contribution that the vendor publishes in the safety manual. The cost is that your safety response time now includes network cycle times, safety watchdog timeouts and device processing, and your PFH budget includes the communication share.

Response time is where determinism arguments from the standard PLC world return. The safety function response time must be shorter than the process safety time, the interval between a hazardous event beginning and a hazard actually occurring. A common engineering rule of thumb is to keep the SIF response time to a fraction of the process safety time (often half or less) to leave margin. Treat that as a design heuristic rather than a requirement of the standard. Summing sensor response, input filtering, safety PLC scan, network watchdog and valve stroke time usually shows that the valve closure time dominates in process plants, while the network and scan dominate in machinery.

Security, Systematic Failures and What Goes Wrong

Functional safety assumes accidental faults; it does not by itself defend against a malicious actor who reaches the logic solver. Security and safety must be assessed together, because an attack that disables a safety function produces exactly the dangerous failure the SIL calculation says is improbable.

Where functional safety and cybersecurity meet

The 2017 Triton (TRISIS) malware incident, in which attackers targeted a Schneider Electric Triconex safety controller at a Middle East petrochemical facility, is the canonical demonstration that safety systems are attack targets. The reported outcome was an inadvertent shutdown when the safety controller entered a failed state, which was how the intrusion was noticed. The takeaway is not a story about one vendor; it is that a SIL claim with no security argument is incomplete.

IEC 61511 Edition 2 added a requirement to assess the security risk of the SIS, and IEC 61508 Edition 3 drafts are widely reported to strengthen the security link, though I have not verified clause-level detail. The practical architecture is the one from IEC 62443: place the SIS in its own zone, control conduits strictly, keep engineering workstations and programming access under tight authentication, and use hardware key switches or equivalent controls on safety CPUs to block remote program changes. Our guides on OPC UA security policies and certificate trust lists and the zones and conduits model describe the controls that sit on the boundary. The technical report IEC TR 63069 addresses the framework for combining safety and security in industrial automation; check its current edition before citing it.

Common failure modes in real SIS projects

Optimistic proof tests. The PFD calculation assumes 100% coverage, but the actual procedure tests the transmitter’s span and skips the impulse line, or cycles the valve without verifying tight shutoff. Coverage should be justified from failure mode analysis, and the PFD recalculated with it.
Common cause by design. Redundant transmitters on one tapping, a shared junction box, one power supply, one cable tray, one calibration technician, one firmware version. The beta factor of 5% is a placeholder; the real number depends on how well these are separated, and beta scoring tables in IEC 61508-6 give a structured way to defend it.
Bypasses that become permanent. A maintenance bypass left enabled turns a 1oo2 into a 1oo1 or a nothing. Bypass management needs alarms, time limits and administrative controls, and the PFD for the bypassed state should be known.
Demand rate drift. The LOPA assumed one demand per decade; the process now runs harder and sees one per year. Low demand mode assumptions can quietly cross into high demand territory, which changes the metric entirely.
Spurious trips and safe-state fatigue. A design with excessive 1oo2 voting and sensitive trip limits produces nuisance shutdowns. Operators then trust the system less, bypass more, and the net risk rises. The “MTTF-spurious” figure deserves the same attention as PFD.
Systematic faults in configuration. Wrong trip setpoint units, a tag mapped to the wrong channel, or a changed scaling range introduced during a modification. These are not random hardware faults and no failure rate covers them; only verification, factory and site acceptance testing, and management of change do.
Treating certificate as proof. A TÜV or exida certificate on a device is evidence for the device under the conditions in its safety manual. Operating temperature, vibration, proof test method and diagnostic configuration all have to match.

Limits of the simplified maths

The formulas shown here are approximations. They ignore repair time and diagnosed failure terms, assume constant failure rates (the exponential model), treat proof tests as instantaneous and uniform, and model common cause with a single beta. Markov models, fault tree analysis, or the full IEC 61508-6 equations handle more cases, including staggered testing, imperfect repair and non-constant rates. For SIL 3 and SIL 4 claims or unusual architectures, use validated tools and have the work reviewed by a competent functional safety engineer. Also note that failure rate data itself carries uncertainty of a factor of two or more across sources such as manufacturer FMEDA reports, the OREDA handbook and generic databases, so a PFD of 4.0 × 10^-4 versus 6.0 × 10^-4 is not a meaningful distinction.

Practical Recommendations

Start from the hazard, not the device. Make the target SIL a documented output of a risk assessment, with every credited protection layer shown to be independent. Then treat SIL verification as three gates passed in order: architectural constraints (HFT and SFF), systematic capability of each product, and finally the probabilistic PFD with defensible inputs. Do not let a low PFD argue past a failed gate.

Spend the budget where the numbers say it matters. In most SIFs the final element dominates PFD and the common cause term dominates the redundant sensor subsystem, so separation, diversity and a credible valve test usually beat buying a higher-rated logic solver. Use safety PLCs for what they are good at: deterministic, diagnosed execution of limited-variability logic, with safe communications to remote I/O, and keep optimisation, analytics and twin synchronisation on the other side of a one-way boundary.

A checklist worth printing:

Hazard and risk assessment recorded; each SIF has one hazard and one target SIL.
IPL independence demonstrated; BPCS credit not claimed where the BPCS is the initiating cause.
Demand mode (low or high) explicitly determined and demand rate recorded.
Architecture meets HFT and SFF limits for every subsystem; SC is adequate for each product.
PFDavg or PFH calculated with documented λDU sources, β rationale, proof test coverage and mission time.
Safety manual conditions of each certified product are met and traceable.
Response time is below process safety time with margin; network watchdog times verified.
Proof test procedures written, with coverage justified, and scheduled in the maintenance system.
Bypass, override and modification procedures controlled; management of change re-checks the SIL.
SIS in its own security zone; remote programming disabled by default; changes authenticated.
Competence and independence of assessors planned for the SIL (functional safety assessment).

Frequently Asked Questions

What is the difference between SIL and PFD?

A PFD (probability of failure on demand) is a calculated number: the average chance that a safety function fails dangerously when called upon. A SIL is a discrete band, one of four, that groups ranges of PFD (or PFH) and also imposes architectural and process requirements. A function with a PFDavg of 5 × 10^-4 falls in the SIL 3 band, but it only earns SIL 3 if the hardware fault tolerance, safe failure fraction and systematic capability also meet the SIL 3 requirements.

What is the difference between IEC 61508 and IEC 61511?

IEC 61508 is the generic, sector-independent standard aimed mainly at manufacturers developing safety-related components such as logic solvers, transmitters and valves. IEC 61511 is the process industry sector standard derived from it, aimed at users and integrators who specify, design, operate and maintain safety instrumented systems. A plant typically buys products certified to IEC 61508 and then demonstrates compliance of the whole safety instrumented function with IEC 61511.

Does SIL 4 get used in industry?

SIL 4 is rare in process and machinery applications. Its PFDavg band of 10^-5 to 10^-4 usually demands extensive redundancy, diverse technologies, and demanding systematic measures, and most risk assessments avoid it by redesigning the process to reduce the hazard, adding independent layers, or changing the design so a lower SIL suffices. It appears more often in sectors like rail signalling. If a risk assessment seems to demand SIL 4 from a single function, reconsider the inherent safety of the design.

What is the difference between low demand and high demand mode?

Low demand mode applies when a safety function is called on infrequently, at most about once per year in the 2010 edition of IEC 61508, so the metric is PFDavg. High demand or continuous mode applies when demands are more frequent or the function acts continuously, so the metric is PFH, dangerous failures per hour. The distinction determines the formulas, how diagnostics are credited, and how a dangerous fault is detected, so classifying the mode wrongly invalidates the entire calculation.

Can a standard PLC be used for a safety function?

Generally not for SIL-rated functions. A standard PLC lacks the diagnostic coverage, redundancy, and certified systematic development process needed for a SIL claim, and its failure data is unavailable or inadequate. You can use a PLC with certified safety firmware and hardware, sometimes a combined standard and safety controller with separate certified safety tasks, or a dedicated safety PLC. The safety portion must follow the vendor’s safety manual, including a restricted programming environment and verified function blocks.

Is IEC 61508 Edition 3 published yet?

As of the sources I could verify, not conclusively. The 61508 Association reported a Committee Draft stage with a Committee Draft for Vote expected in early 2026 and availability anticipated in early 2027, while catalogues list FprEN IEC 61508-2:2026 and -3:2026 drafts. Check the IEC webstore for the current edition before citing it in a safety case, and keep designing to the 2010 edition until a new one is published and your certification body specifies a transition.

IEC 61508 Functional Safety: SIL, PFD Calculations, Safety Instrumented Systems and Safety PLC Architecture (2026)