ISO 13849 vs IEC 62061 looks like a choice between Performance Level and Safety Integrity Level. In practice, the real question is broader: which method can demonstrate that the complete safety function will detect an event, command the right response, reach a safe state and keep the machine there?
Catalogues make the decision look deceptively simple. A safety PLC may claim SIL 3 and PL e. A drive with Safe Torque Off may do the same. Yet machines are not control cabinets. A guard switch may depend on a mechanical cam, while the final response may depend on a pneumatic valve, return spring, contactor or brake. If any link fails, the function fails—even when the logic controller performs perfectly.
A certified relay does not stop a machine. The complete safety function stops it.
This is why ISO 13849 is so common in machine building. The decisive advantage is not simply easier calculation or familiarity with Categories B, 1, 2, 3 and 4. It is the ability to assess safety-related control systems that combine electrical, electronic, hydraulic, pneumatic and mechanical technologies in one coherent chain.
ISO 13849 vs IEC 62061 starts with the safety function
Many projects begin in the wrong place. The team selects a light curtain, safety PLC, relay or drive, then writes a safety function around the chosen hardware. The drawing looks impressive: two channels, diagnostics, SIL 3 and PL e. What remains unclear is what the machine must physically do when the hazard appears.
“Opening the guard stops the machine” is a heading, not a specification. Does the application require Safe Torque Off, allowing the motor to coast? Does it require Safe Stop 1, with controlled deceleration followed by torque removal? Is Safe Stop 2 needed so that controlled stopping ends in a monitored standstill? Or must Safe Operating Stop actively maintain and monitor position?
Those responses are not interchangeable. A high-inertia axis may coast dangerously after STO. Aggressive braking may create a different mechanical hazard. A vertical axis may fall when torque disappears. Pneumatic or hydraulic energy may remain stored even after the electrical outputs switch off.
Define the initiating event, required response and safe state first. Choose PL or SIL only after those requirements are clear.
A proper safety requirements specification should define, for each function:
- the event that initiates the function;
- the required machine response, including any stopping sequence;
- the safe state to be reached and maintained;
- the maximum permissible response and stopping times;
- the operating modes in which the function must be active;
- behaviour after a detected fault or loss of energy;
- reset and restart conditions;
- interfaces with other safety and standard control functions.
The required Performance Level, PLr, does not describe what the function must do. It describes how dependably the function must do it. SIL performs a comparable integrity role within the IEC 62061 method. Neither value can rescue a vague or physically inappropriate response.
Bits do not injure people. Energy, movement and inadequate stopping distance do. A safety specification must describe the physical outcome, not merely an output state.
The function boundary does not follow the control cabinet
Block diagrams encourage a tidy input–logic–output model. Reality is less polite. A guard does not send an electrical signal by itself. It first moves a cam, roller, tongue, plunger or coded actuator. Wear, hinge play, incorrect alignment or an inadequate overtravel distance can prevent the switch from changing state even though the guard has opened.
The safety PLC may continue to read two healthy channels. Its diagnostics can be flawless while the input information no longer represents the physical machine. Redundancy inside the cabinet cannot repair poor mechanical actuation outside it.
ISO 13849 treats signal generation as part of the safety-related control system where appropriate. The analysis can therefore begin where a physical event becomes safety information—not merely at the first terminal in the enclosure.
The same principle applies at the output. Switching a PLC output off is only a control decision. The contactor must open the power circuit. The valve spool must move. Pressure must be isolated or exhausted. A brake must develop sufficient holding force. Stored or gravitational energy must be removed, dissipated or restrained.
The boundary runs from the physical event that must be detected to the physical effect that creates and maintains the safe state.
This does not mean every mechanical part belongs in the PL calculation. A standard cylinder will often remain part of the machine actuator rather than the safety-related control system. However, its behaviour may still need validation when demonstrating that the safe state is achieved. If the actuator assembly includes a locking device, rod lock or another element performing a safety subfunction, that element cannot simply be excluded because it is mechanical.
A useful boundary test is straightforward: could failure of this element prevent detection, prevent the required response or prevent the safe state from being maintained? If the answer is yes, the element belongs in the safety argument, whether it contains software or is a machined piece of steel.
A SIL 3 safety PLC does not create a SIL 3 function
A safety PLC certificate establishes the capability of a subsystem under specified conditions. It does not automatically transfer SIL 3 or PL e to sensors, wiring, application software, contactors, valves, brakes or mechanical actuators.
In a typical guard function, the sensor detects the event, the logic processes it and the output subsystem controls the hazardous energy. The logic may work exactly as intended while a welded contactor, jammed valve or incorrectly configured restart prevents the overall function from working.
SIL 3 does not spread through an installation like 24 V DC.
ISO 13849 permits a safety-related control system to be divided into subsystems. A safety PLC is normally the logic subsystem, not the complete safety system. Validated subsystems developed under ISO 13849, IEC 62061, IEC 61508 or relevant product standards may be combined, provided their limitations and interfaces are respected.
The numerical contribution also matters. When known PFH values apply to serial subsystems, their dangerous failure frequencies are added. Suppose the input, logic and output subsystems each have a PFH of 8 × 10−8 per hour. Individually, each value falls within the PL e range. Together:
8 × 10−8 + 8 × 10−8 + 8 × 10−8 = 2.4 × 10−7 per hour
The complete function is now in the PL d PFH range. Three PL e-capable blocks have not produced a PL e function because the chain contains three opportunities for a dangerous failure.
PL e + PL e + PL e does not necessarily equal PL e. Integrity is demonstrated for the complete function, not awarded by component count.
Achieving a high PL is therefore a matter of architecture, diagnostics and disciplined integration. Engineers must control single points of dangerous failure, common-cause failures, systematic faults, software errors and invalid assumptions. Redundancy helps only when the channels are sufficiently independent. Two identical channels exposed to the same contamination, wiring error or power disturbance can fail together very efficiently.
The manufacturer assessed the device. The machine builder must assess the machine-specific application.
One safety function can cross several technologies
Consider a guard-opening function. A mechanical cam operates an electromechanical position switch. The signal reaches a safety relay. The relay removes power from a pneumatic valve coil. A spring returns the valve spool, pressure is exhausted and actuator movement stops. A mechanical brake may then hold a vertical load.
That is one safety function implemented through several technologies. Organisational boundaries do not alter its behaviour. The controls engineer cannot end the analysis at the PLC output while the pneumatic engineer treats the valve as an unrelated process component and the mechanical engineer treats the cam or brake as ordinary hardware.
The machine does not know which department designed the sensor, valve or brake. It only knows whether the complete chain worked.
ISO 13849 fits this reality well because its scope is not restricted by the type of technology or energy used. It provides a familiar framework for dividing the function into input, logic and output subsystems, then examining each subsystem’s contribution to the achieved PL.
This does not mean every spring, roller and bolt receives its own Performance Level. PL applies to the subsystem and ultimately to the complete safety function. Individual components contribute failure modes, reliability data, diagnostic opportunities and architectural constraints.
If a spring must return a valve to its safe position after power loss, the design must consider whether the spring can break, weaken, be installed incorrectly or fail to overcome friction and contamination. If a cam initiates the safety signal, its geometry, fastening and resistance to wear matter. If a brake holds a vertical axis, its ability to develop and retain the required force must be validated.
No electronics does not mean no safety relevance. Technology is secondary; the component’s role in the failure scenario is what matters.
The objective is not to drag all machine mechanics into a PL calculator. It is to identify the elements that generate the safety signal, process it, control energy, perform a safety subfunction or maintain the safe state. That functional boundary produces a defensible analysis without pretending the entire machine is one giant control subsystem.
ISO 13849 works with the data machinery engineers actually receive
Certified electronic subsystems often arrive with PL, SIL, PFH, response time and detailed integration restrictions. Conventional machine components are less uniform. A contactor, position switch, valve or locking mechanism may be documented by B10D, operating-cycle limits, product-standard compliance or manufacturer test data.
ISO 13849 offers practical routes for both situations. A validated subsystem with a declared PL or SIL and PFH can be used as a block without reconstructing its internal reliability model. Mechanically wearing components can be assessed using B10D and the expected number of operations.
B10D is the number of cycles by which 10 percent of a tested component population has failed dangerously. It becomes useful only when combined with the actual operating rate. A valve cycled five times per shift and the same valve cycled every two seconds may share a catalogue number, but they do not have the same application-specific MTTFD.
ISO 13849 is practical not because it asks for less evidence, but because it can build evidence from the data that genuinely exists in machine engineering.
The calculation is only part of the case. Engineers must understand what the manufacturer classifies as a dangerous failure. A valve that still moves but switches too slowly may be dangerous if the safe state must be reached within a specified time. A position switch can have excellent electrical endurance while its mechanical actuator has worn or shifted. A contactor used outside its load conditions cannot borrow a catalogue B10D value without justification.
ISO 13849 also combines quantitative measures with qualitative requirements:
- MTTFD and PFH;
- diagnostic coverage;
- common-cause failure measures;
- Category and fault behaviour;
- basic and well-tried safety principles;
- systematic failure control;
- software lifecycle measures;
- environmental and application conditions;
- validation of specified behaviour.
This matters because not every critical problem can be reduced to a neat failure-rate number. Incorrect cam mounting, unsuitable tubing, contaminated air, bypassed interlocks and a poorly designed manual mode often require design controls, testing and validation rather than another decimal place.
Fault exclusion is not a convenient assumption
Fault exclusion is sometimes treated as a formal way to say that a part is unlikely to fail. That is not enough. The engineer must identify the specific failure mode being excluded and justify why its probability is negligible under the actual loads, materials, dimensions, environment, lifetime and installation conditions.
Fault exclusion is not the absence of analysis. It is one of the most demanding conclusions an analysis can reach.
A general claim that a shaft will not break or a fastener will not loosen is weak. A defensible exclusion identifies the loading direction, stress limits, safety factors, material properties, locking method, inspection requirements and foreseeable misuse. Physics—not confidence—must support the conclusion.
ISO 13849 vs IEC 62061 for pneumatic, hydraulic and mechanical subsystems
The old rule of thumb said that ISO 13849 covered the whole machine while IEC 62061 covered electrical, electronic and programmable electronic systems. That description reflects earlier editions, but it is no longer an accurate statement of the current scope.
IEC 62061:2021 expanded its treatment of machinery safety-related control systems beyond an exclusively electrical interpretation. A safety function containing pneumatic, hydraulic or mechanical subsystems is not automatically excluded from a SIL-based assessment.
Non-electrical technology no longer rules out IEC 62061. It does not, however, remove the need for credible reliability data and a validated subsystem model.
Take an emergency-stop chain consisting of an emergency-stop device, safety PLC, 5/2 valve and pneumatic actuator. Under IEC 62061, the pneumatic section can be treated as an output subsystem. The analysis must determine how failures of the valve, return mechanism, pilot stage, monitoring and any redundant elements contribute to loss of the safety function.
Relevant dangerous failure modes may include:
- the spool sticking in the energised position;
- internal leakage that permits hazardous movement;
- loss of return-spring force;
- blocked exhaust paths;
- pilot-stage failure;
- switching too slowly to meet the required response time.
If the manufacturer supplies validated subsystem PFH data and application restrictions, those values can support the SIL calculation. If not, the project must establish a justified model using component data, testing, architecture, diagnostics, maintenance assumptions and proof-test provisions. If neither reliable data nor a defensible model exists, the subsystem limits the claim for the complete function.
IEC 62061 can bring pneumatics into the safety model. The engineer still has to build a model that deserves to be believed.
This is where practical differences remain. Electronic equipment is often described using approximately constant failure rates and established FIT data. Mechanical and fluid-power components wear with cycles and are strongly affected by contamination, lubrication, pressure, temperature, alignment and maintenance. IEC TS 63394 provides additional guidance for reliability modelling of non-electrical technologies, reflecting the fact that these components do not always behave like electronic hardware.
ISO 13849 has long used B10D, operating cycles, well-tried components, fault behaviour and technology-specific safety principles. The resulting supplier libraries, calculation tools, standard architectures and validation procedures are deeply embedded in machinery practice. IEC 62061 can now cover the same broad technological territory, but available data and established workflows still make ISO 13849 the more natural route for many mixed-technology machines.
A SIL-rated component does not force the complete function onto IEC 62061
A machine may use a SIL 3 safety PLC, a drive with SIL 3-capable STO and a light curtain with a SIL claim limit suitable for SIL 3. That does not mean the complete function must be assessed under IEC 62061.
ISO 13849 permits validated subsystems developed under IEC 62061, IEC 61508, ISO 13849 or relevant product standards to be combined. A function ultimately expressed as PL can therefore include a SIL-rated light curtain, SIL-rated logic, a contactor described by B10D and a pneumatic valve assessed using ISO 13849 methods.
A SIL certificate defines the capability and limits of a subsystem. It does not select the assessment method for the complete machine function.
The certified block must still be used within its stated conditions. These can include specified wiring architectures, proof-test intervals, mission time, diagnostic test frequency, environmental limits, common-cause measures and restrictions on the safety functions implemented.
A drive may provide SIL 3-capable STO, but STO is not automatically the correct response. If the risk assessment requires controlled deceleration before torque removal, SS1 may be necessary. A light curtain may have an excellent integrity claim but still be installed too close to the hazard. A safety PLC may meet SIL 3 internally while application software defeats an interlock in setup mode.
PL and SIL meet at PFH, but they are not identical methods
For high-demand or continuous operation, the familiar correlation is based on PFH ranges:
- PL b and PL c correlate with SIL 1 ranges;
- PL d correlates with the SIL 2 range;
- PL e correlates with the SIL 3 range;
- PL a has no direct SIL correlation.
This does not mean that PL d and SIL 2 are interchangeable labels. They occupy corresponding PFH intervals, but the methods use different architectural, systematic-integrity, software and lifecycle requirements. The probabilistic destination may align while the route to the result remains different.
PL and SIL meet at PFH. They do not become the same engineering method.
A subsystem certified under IEC 62061 or IEC 61508 does not need an invented ISO 13849 Category. Category describes a particular subsystem structure and fault response; it is not another name for SIL. The integrator can normally use the subsystem’s declared PFH, integrity capability, response time and application restrictions without reverse-engineering its internal architecture.
When subsystems are combined, the complete function remains limited by both the capability of the weakest subsystem and the total PFH. The highest certificate in the cabinet does not win a vote.
From ISO 12100 risk assessment to the safety requirements specification
Risk assessments often end with a measure such as “fit an interlocked guard.” That is a valid risk-reduction direction, but it is not yet a designed safety function. It does not identify the movements to stop, the required stopping method, the available stopping time, the treatment of stored energy or the conditions for restart.
ISO 12100 establishes the risk assessment and risk-reduction process. When risk reduction depends on a control-system safety function, the safety requirements specification should translate that decision into engineering requirements that can be designed and validated under ISO 13849 or IEC 62061.
This handover is critical when different people perform the risk assessment, mechanical design, control design and software implementation. Without a formal specification, the instruction to “stop the machine” may mean output de-energisation to one engineer, torque removal to another and complete energy isolation to a third.
The risk assessment does not finish with “install an interlocked guard.” That statement is where detailed safety-function engineering begins.
The safety requirements specification should connect the hazard scenario to the initiating event, machine response, safe state, required PLr or SIL, response time, operating modes, fault response and validation criteria. It is not paperwork added after design. It is the basis on which the design can be judged.
ISO 13849-1:2023 makes this relationship particularly explicit by placing safety-related control system design within the iterative risk-reduction process. Standardization work on ISO 12100 has also pointed toward a more direct integration of risk assessment and safety-function specification. Because revision status can change, project teams should verify the current ISO catalogue and applicable regional adoption before citing a draft or new edition contractually.
The important direction is stable: risk assessment and control-system functional safety are not separate worlds. The engineering chain should remain continuous:
hazard → hazardous situation → risk-reduction measure → safety function → initiating event → response → safe state → PLr or SIL → architecture → verification → validation
Why machinery still uses PL more often than SIL
The answer is not simply that ISO 13849 is easier. Nor is IEC 62061 reserved for unusually complex systems. Both can support sophisticated machinery safety functions, and both demand disciplined specification, design, verification and validation.
ISO 13849 remains prevalent because it fits the shape of real machines. It provides a well-established framework for functions that cross electrical, electronic, pneumatic, hydraulic and mechanical technologies. It also works with the mixture of data engineers commonly receive: PFH and SIL for validated electronic subsystems, PL declarations, B10D for wearing components, MTTFD, diagnostic information, product-standard data and justified fault exclusions.
IEC 62061 can be an excellent choice, particularly where subsystem PFH data, systematic-integrity processes and SIL-oriented engineering tools are already available. It may also align naturally with organisations experienced in IEC 61508-based lifecycle methods. The right choice depends on the function, technologies, available data, competence of the team, customer requirements and validation strategy.
Before choosing the standard, ask four practical questions:
- What must the safety function physically do?
- Which technologies and energy sources are involved from detection to safe state?
- What credible reliability and failure-mode data are available?
- Which method can demonstrate and validate the complete chain without artificial gaps?
That turns ISO 13849 vs IEC 62061 from a debate about preferred acronyms into an engineering decision.
A machine does not stop at the certificate or the safety PLC output. It stops only when the complete safety function reaches and maintains the required safe state.
Choose the method that lets the team prove that outcome. Then document the assumptions, respect every subsystem limitation and validate the physical machine—not merely the logic diagram.