IEC 62061, IEC 61508 and validating safety functions

ISO 13849-1 is not the only route to a functionally safe machine. IEC 62061, Safety of machinery: Functional safety of safety-related control systems, expresses reliability as safety integrity levels (SILs) rather than performance levels, and it descends from IEC 61508, the basic functional safety standard for electrical, electronic and programmable electronic systems used across industries. Engineers working on robots meet all three: ISO 13849-1 for most machine safeguarding, IEC 62061 for complex programmable systems and drives, and IEC 61508 behind the safety-rated components they buy, such as safety PLCs, drives with safe torque off and robot controllers with safety-rated monitoring. This lesson explains the SIL approach, compares it with performance levels, and then covers what both standards require after design: verification, validation, periodic testing and management of modifications. It ends with the open problem of machine learning in safety functions.

IEC 61508 in brief

IEC 61508, first published in the late 1990s with its second edition in 2010 and a third edition in preparation at the time of writing, sets out a safety life cycle from concept through hazard and risk analysis, safety requirements, design, installation, operation, modification and decommissioning. It introduces four safety integrity levels, SIL 1 to SIL 4, each corresponding to a target range of failure measures. For safety functions demanded frequently or continuously, as on machines, the measure is the average frequency of dangerous failure per hour (PFH). For low-demand functions, such as emergency shutdown in a chemical plant, it is the average probability of failure on demand (PFDavg). Machinery almost always uses the high-demand or continuous mode.

IEC 61508 also requires measures against systematic failures, which are failures caused by errors in specification, design, manufacture or software rather than random hardware failures. A SIL claim therefore combines a quantitative target for random failures, architectural constraints that require a minimum level of fault tolerance or diagnostics, and qualitative requirements on development processes whose rigor increases with SIL. Component manufacturers who certify a safety PLC or drive to IEC 61508 provide a safety manual stating the SIL capability, the PFH of the component and the conditions of use, such as proof-test intervals and required diagnostics. System designers must follow those conditions, or the claim does not carry over.

IEC 62061: SIL for machinery

IEC 62061 applies the IEC 61508 approach to machinery, and its 2021 edition extended its scope from electrical systems to safety-related control systems of all technologies, which brings it closer to ISO 13849-1. Many companies choose one standard for consistency, often ISO 13849-1 for simpler functions and IEC 62061 for complex programmable systems, and the two standards' authors have worked to make the results comparable.

The required SIL is determined from a matrix rather than a risk graph. The severity of the consequence (Se) is scored from 1 for reversible injury needing first aid to 4 for irreversible injury such as death or the loss of an eye or arm. A class value (Cl) is the sum of three scores for the probability of harm: frequency and duration of exposure (Fr), probability of occurrence of the hazardous event (Pr) and possibility of avoiding or limiting harm (Av). The intersection of Se and Cl in the standard's matrix gives the required SIL or indicates that other measures are sufficient.

Building subsystems to a SIL

In IEC 62061 a safety function is decomposed into subsystems, such as sensing, logic and actuation, and the PFH values of the subsystems are added, just as PFHd values are added in ISO 13849-1. Each subsystem must also satisfy architectural constraints, which limit the SIL that can be claimed based on its hardware fault tolerance (HFT) and safe failure fraction (SFF). HFT is the number of faults a subsystem can tolerate without losing the function: a single channel has HFT 0, a redundant pair HFT 1. SFF is the fraction of failures that are either safe or dangerous but detected.

For subsystems built from components rather than bought as certified units, IEC 62061 gives simplified formulas for four basic architectures. For a redundant subsystem with diagnostics, the common cause failure factor \( \beta \), typically between 1 and 10 percent depending on the measures taken against common causes, often dominates the result. A simplified form of the formula for two identical channels, each with dangerous failure rate \( \lambda_D \), diagnostic coverage DC, diagnostic test interval \( T_2 \) and proof-test interval or lifetime \( T_1 \), is shown below.

# PFH of a two-channel subsystem with diagnostics (IEC 62061 style, simplified)
import math
HOURS_PER_YEAR = 8760
def lam_from_mttfd(years):
    return 1 / (years * HOURS_PER_YEAR)
def pfh_redundant(lam, dc, t2_h, t1_h, beta):
    indep = (1 - beta) ** 2 * (lam ** 2 * dc * t2_h + lam ** 2 * (1 - dc) * t1_h)
    ccf = beta * lam
    return indep + ccf, indep, ccf
def sil(pfh):
    for name, hi in [("better than the SIL 3 band", 1e-8), ("SIL 3 range", 1e-7), ("SIL 2 range", 1e-6), ("SIL 1 range", 1e-5)]:
        if pfh < hi:
            return name
    return "no SIL"
lam = lam_from_mttfd(50)                       # each channel: MTTFd 50 years
for beta in (0.10, 0.05, 0.02):
    total, indep, ccf = pfh_redundant(lam, dc=0.99, t2_h=8, t1_h=20 * HOURS_PER_YEAR, beta=beta)
    print(f"beta {beta:4.0%}: PFH = {total:.2e}/h  (independent {indep:.1e}, common cause {ccf:.1e})  {sil(total)}")

beta  10%: PFH = 2.36e-07/h  (independent 7.4e-09, common cause 2.3e-07)  SIL 2 range
beta   5%: PFH = 1.22e-07/h  (independent 8.3e-09, common cause 1.1e-07)  SIL 2 range
beta   2%: PFH = 5.45e-08/h  (independent 8.8e-09, common cause 4.6e-08)  SIL 3 range

With high diagnostic coverage, the output shows that the independent failures, which need both channels to fail, contribute far less than common cause failures at every beta shown. Halving \( \beta \) by better separation, diversity and environmental protection roughly halves the total. This is the quantitative reason why both ISO 13849-1 and IEC 62061 insist on measures against common cause failure, and why diverse redundancy, such as one channel using a mechanical switch and the other a non-contact sensor, is valued.

Verification and validation

Verification checks that each design step meets the requirements of the previous step; validation checks that the finished safety function meets the safety requirements specification in the real machine. ISO 13849-2 covers validation for ISO 13849-1 designs, and IEC 62061 contains equivalent requirements. Both expect a validation plan written before validation starts, identifying the functions, requirements, methods, criteria, people and their independence, and the documents to be produced.

ISO 13849-2 contains annexes listing faults to consider for mechanical, pneumatic, hydraulic and electrical components, and the conditions under which a fault may be excluded, such as a welded contact in a switch with positive opening contacts. Every fault exclusion must be justified and documented, because excluded faults are invisible to the calculation; a long list of unjustified exclusions is a common reason assessors reject designs.

Validation is not a one-time event. Periodic testing confirms that safety functions still work: daily or shift checks of light curtains with a test rod, regular stopping time measurements, and proof tests at intervals stated in component safety manuals. Brake wear, loosened mounts and changed robot programs can all lengthen stopping times. Modifications to safety functions, including software changes in safety PLCs, should go through management of change, with impact analysis and revalidation of affected functions, and versions of safety software should be controlled and checksummed so that unauthorized changes are detectable.

Machine learning in safety functions

Current machinery safety standards assume that safety-related software is specified, designed and tested in ways that make its behavior predictable. Machine-learned perception, such as a neural network that detects people in camera images, does not fit easily: its behavior is defined by training data rather than explicit requirements, its failure modes are hard to enumerate, and its performance can degrade when conditions differ from its training. ISO/IEC TR 5469:2024, Artificial intelligence: Functional safety and AI systems, describes the challenges and suggests approaches, but it is a technical report rather than a requirements standard.

In practice, robot designers keep machine learning outside the certified safety function or wrap it inside a safety-rated envelope. A mobile robot may use learned perception to plan efficient paths among people, while a certified laser scanner with a protective field enforces a stop if anything gets too close, regardless of what the learned system believes. A manipulator may use learned grasping while safety-rated speed, zone and force limits bound its motion. This architecture is sometimes called a safety cage or simplex architecture. Regulators are beginning to address the gap directly. The EU Machinery Regulation, discussed in lesson 5, lists machinery and safety components with fully or partially self-evolving behavior using machine learning to ensure safety functions among the categories that need third-party conformity assessment. Standards committees are drafting requirements for AI in safety functions, so engineers should expect this area to change quickly.