When should I choose IEC 62061 over ISO 13849 for machine safety?

Choose IEC 62061 when the safety-related parts of the control system (SRP/CS) are implemented with complex electrical/electronic/programmable systems and you need a Safety Integrity Level (SIL) approach traceable to IEC 61508. IEC 62061 (specific to machinery) mandates quantitative PFH calculations, systematic capability evidence, and software lifecycle measures aligned with IEC 61508/62061. Use ISO 13849-1:2015 when SRP/CS can be expressed as discrete safety functions using performance level (PL) methodology, categories (B, 1–4), MTTFd and diagnostic coverage (DCavg) calculations. Practically, choose 62061 for safety PLC architectures where manufacturer PFHd data and SIL claims exist (e.g., Siemens S7‑1500F, Rockwell GuardLogix); choose 13849 for modular relay-based or SRP/CS designs using validated building blocks (e.g., Pilz PNOZmulti, safety relays). Always start with ISO 12100 risk assessment to decide required risk reduction.

How do SIL (IEC 62061) and PL (ISO 13849) relate — can you convert one to the other?

SIL and PL use different metrics: IEC 62061/61508 uses PFHd and systematic capability to assign SIL 1–3, while ISO 13849 uses categories, MTTFd bands, and diagnostic coverage to assign PL a–e. There is no officially mandated one‑to‑one conversion; however, industry guidance offers approximate equivalences (e.g., SIL1 ≈ PL b–c, SIL2 ≈ PL c–d, SIL3 ≈ PL d–e). Conversions must be treated as approximations — a valid compliance decision requires quantitative PFHd calculations (IEC 62061) or MTTFd/DCavg/category analysis (ISO 13849-1:2015). Best practice: perform the standard-specific calculation using vendor data (PFHd, MTTFd, DC) from products such as Siemens S7‑1500F, Pilz PSS controllers, or certified safety relays, and document the rationale rather than relying solely on mapping tables.

What are the verification and validation differences between IEC 62061 and ISO 13849?

IEC 62061 imposes a software and systems lifecycle aligned with IEC 61508:2010 — formal V&V for programmable electronics, requirements traceability, software unit testing, integration testing, and tool qualification for safety-related development. It requires PFHd proof and systematic capability evidence. ISO 13849-1:2015 focuses on architecture, diagnostics, MTTFd and DCavg calculations and allows use of validated SRP/CS building blocks; V&V emphasis is on functional testing, diagnostic tests and proof tests. For software in ISO 13849 designs, you still need appropriate development practices, but IEC 62061 demands more rigorous software safety lifecycle artifacts. For either standard, third‑party assessment (TÜV, Dekra) and manufacturer data (PFHd, MTTFd, DCavg) are frequently used to substantiate verification.

How do I perform the risk assessment to determine required SIL or PL for a safety function?

Begin with ISO 12100 risk assessment: identify hazardous events, estimate severity, frequency/exposure and probability of avoidance. For ISO 13849, use the risk graph or quantitative reduction to derive required PL (ISO 13849‑1:2015), taking into account MTTFd bands (Low 3–30 years, Medium 30–100, High >100) and DCavg. For IEC 62061, translate the risk assessment into required SIL by quantifying necessary PFH reduction using IEC 61508 criteria and IEC 62061 guidance. Determine safety function response time and diagnostic/proof-test intervals (e.g., stop category, STO/SS1 timing), then select architecture (redundancy, voting) and components whose PFHd/MTTFd data meet the target. Document assumptions, input data, and calculations; use vendor PFHd/MTTFd data and simulation tools (e.g., exida, TÜV tools) for verification.

Can safety PLCs like Siemens S7‑1500F or Rockwell GuardLogix be used to meet IEC 62061 and ISO 13849 requirements?

Yes — safety PLCs such as Siemens S7‑1500F (Safety Integrated), Rockwell GuardLogix, Pilz PSS 4000, and Beckhoff TwinSAFE are designed for both IEC 62061 and ISO 13849 implementations. To use them you must: (1) obtain vendor PFHd and MTTFd/DCavg data and documented systematic capability; (2) perform system‑level calculations per the chosen standard (PFHd for IEC 62061; MTTFd, DCavg and category for ISO 13849); (3) follow manufacturer application constraints (diagnostics, wiring, redundant I/O); and (4) carry out required validation tests. Many vendors publish safety manuals and certified data sheets (e.g., Siemens Safety Documentation, Rockwell Safety Manual). System-level compliance is the user’s responsibility — component-certified products simplify but do not replace system calculations and documentation.

How do I calculate MTTFd and diagnostic coverage (DCavg) for ISO 13849 performance level calculations?

MTTFd is derived from component dangerous undetected failure rates (λDU): MTTFd = 1/λDU (expressed in years). Use manufacturer failure rate data (ISO 13849‑1 recommends using EN 60812/IEC 61508 data tables or vendor data) and sum contributions for series components. DCavg (average diagnostic coverage) is calculated as DC = λD / (λD + λDU) where λD is the detected dangerous failure rate and λDU is the undetected dangerous failure rate. ISO 13849‑1:2015 requires classifying MTTFd into Low (3–30 y), Medium (30–100 y), High (>100 y) and computing PL from category, MTTFd band and DCavg. Perform component‑level calculations, then aggregate per the standard’s rules. When vendor data are unavailable, consider conservative assumptions or third‑party failure data (e.g., exida, IEC 61508 tables).

What measures mitigate common‑cause failures (CCF) to achieve PL e or SIL 3?

To reach high integrity (PL e / SIL 3), you must address Common‑Cause Failures (CCF) via architectural diversity, physical separation, independent diagnostics, and independent power paths. Use redundant architectures (1oo2, 1oo3 with voting, 2oo3) and combine diversity (different manufacturers, technologies) to reduce β‑factor exposure. Perform a documented CCF analysis (e.g., β‑factor modeling per IEC 61508 guidance or fault‑tree analysis) and apply measures such as separate routing, separate PLCs, diverse sensors (optical + safety mat), and distinct software toolchains. Typical β assumptions range from 0.01 (low) to 0.1 (higher) in machinery; justify the selection. Standards require evidence that independence measures reduce CCF risk — include test plans, proof‑test intervals, and manufacturer data to substantiate the architecture.

Is third‑party certification required for IEC 62061 or ISO 13849 compliance and which bodies provide it?

Neither IEC 62061 nor ISO 13849 mandate third‑party certification as a legal requirement, but independent certification (TÜV SÜD, Dekra, SGS, UL) is widely recommended for market acceptance and to validate safety claims. Certification provides an audit of the risk assessment, calculation files (PFHd/MTTFd, DCavg), design architecture, software lifecycle artifacts (for IEC 62061/61508), and verification evidence. Many vendors supply certified components (SIL/PL data) from these bodies — e.g., Pilz controllers and Siemens safety modules often carry TÜV or UL documentation. For high-risk applications or customer contractual requirements, third‑party assessment is frequently required; for lower risk, internal competence with well‑documented evidence may suffice.

IEC 62061 vs ISO 13849: Which Functional Safety Standard?

Functional Safety for Machinery

Functional safety ensures that safety-related control systems—such as emergency stops, light curtains, safety interlocks, and safety-rated controllers—reduce risk to an acceptable level across the entire machine lifecycle. In the European Union both EN ISO 13849-1 and EN IEC 62061 are harmonized standards under the Machinery Directive (2006/42/EC) and therefore provide presumption of conformity when applied correctly. Both standards aim for equivalent safety outcomes but apply different methodologies, quantitative metrics, and lifecycle obligations, so choice of standard should follow the system technology, complexity, and any customer or sector-specific requirements [1][2][4].

ISO 13849-1: Performance Levels

ISO 13849-1 specifies the design and assessment of the Safety-Related Parts of Control Systems (SRP/CS) using the concept of Performance Levels (PL). PLs range from PL a (lowest) to PL e (highest) and reflect the probability that a safety function will perform correctly in a dangerous situation. Determination of achieved PL requires consideration of:

Category (B, 1, 2, 3, 4) — architectural classification based on structure, diagnostics, and fault tolerance;
MTTFd (Mean Time To Dangerous Failure) — typically expressed in three bands (Low: 3–10 years, Medium: 10–30 years, High: >30 years) used to quantify component reliability;
DCavg (Average Diagnostic Coverage) — percent of dangerous failures detected by diagnostics;
Measures against Common Cause Failure (CCF) and appropriate diagnostics, redundancy, and diversity.

ISO 13849-1 is technology-neutral and well suited for systems combining electrical, mechanical, hydraulic, and pneumatic components. It provides pragmatic, component-based rules for deriving PL, and ISO 13849-2 defines verification and validation methods (testing, inspection and assessment). The standard includes specific guidance on Safety Requirements Specification (SRS) content and measurable criteria for stop and restart behaviours [2][3].

Key numerical relationships

ISO 13849-1 maps PL requirements to estimated tolerable average probability of dangerous failure per hour (PFHd). These mappings are approximate and intended to allow comparison with SIL targets from IEC 62061, but designers must always perform a full risk assessment and calculation rather than rely solely on table lookups [1][3].

IEC 62061: Safety Integrity Levels

IEC 62061 is a machinery-specific adaptation of IEC 61508 and applies primarily to electrical/electronic/programmable control systems. It defines Safety Integrity Levels (SIL 1, SIL 2, SIL 3) for safety functions using probabilistic metrics such as PFHd (probability of dangerous failure per hour) for continuous/high demand modes, plus architectural requirements including Hardware Fault Tolerance (HFT) and Safe Failure Fraction (SFF). The 2021 revision (EN IEC 62061 Ed. 1.2) expanded guidance on software lifecycle, EMC, diagnostics (Annex E), failure rates (Annex C), and reliability calculation methods (Annex K), improving alignment with ISO 13849-1 and IEC 61508 practices [2][4].

When IEC 62061 is preferred

Systems dominated by programmable electronics, complex control software, or safety PLCs where SIL targets (up to SIL 3) may be demanded;
Applications that must interface with process industry functional safety (IEC 61511) or when customers explicitly require SIL compliance;
Robotics, collaborative robots, or machine cells where systematic software faults and complex diagnostics necessitate a full functional safety lifecycle.

IEC 62061 requires a full safety lifecycle, including specification, software development controls, verification and validation activities, and maintenance procedures. The machinery-specific nature of the standard makes it effective for software-intensive safety-related electronic control systems and for achieving high integrity (up to SIL 3) when required [2][4].

Which Standard Should You Use?

Both EN ISO 13849-1 and EN IEC 62061 are valid routes to meet the Machinery Directive in the EU. Selection depends on the technology mix, complexity, and contractual or sector constraints:

Choose ISO 13849-1 when the safety function spans mechanical, hydraulic, pneumatic and electrical components, when implementation is based on discrete safety components or relay-based systems, or when you require a pragmatic, component-level method up to PL e for less software-intensive designs [2][3].
Choose IEC 62061 for complex programmable electronic systems, software-dominated controllers, or where SIL-based targets (e.g., SIL 2 or SIL 3) are specified by the customer or industry (process, robotics). IEC 62061 aligns directly with IEC 61508 and is the logical choice for systems requiring a formal software lifecycle and rigorous probabilistic PFHd calculations [2][4].
Hybrid approach: After the 2021 revisions both standards improved alignment and allow subsystem reuse — e.g., a SIL 2 electronic subsystem can be evaluated and reused within an ISO 13849 assessment when documented and validated appropriately. Always document the Safety Requirements Specification (SRS) and perform the required verification and validation per the chosen standard [2][1].

Decision criteria checklist

Is the safety function primarily electronic/software? → IEC 62061 preferred.
Does the system include significant non-electrical elements? → ISO 13849-1 preferred.
Does the customer or sector mandate SIL? → Use IEC 62061 / IEC 61508 route.
Is rapid component-based verification important for the machine builder? → ISO 13849-1 often offers easier project-level implementation.

Risk Assessment Process

Both standards start from the same risk assessment foundation (ISO 12100) and follow similar stages: hazard identification, risk estimation (severity, exposure/frequency, probability of avoidance), allocation of required safety performance (PLr or SIL), design of safety measures, demonstration that the achieved PL/SIL meets or exceeds the requirement, and validation of the complete safety system through testing and documented evidence [2][3].

Allocation and calculation

ISO 13849-1: Use the risk estimation to derive a required Performance Level (PLr). Determine architecture category, estimate MTTFd and DCavg for components, and calculate achieved PL. Verification follows ISO 13849-2 testing and documentation guidance [3][2].
IEC 62061: Use the risk estimation to allocate a required SIL. Select architecture with required HFT and SFF, perform PFHd calculations using failure rate data and diagnostic coverage models, and provide lifecycle evidence (software development records, validation results) typically required by IEC 61508-derived practices [2][4].

Key Technical Facts and Specification Tables

The following table summarizes commonly used PFHd ranges and approximate PL–SIL correspondences. These mappings are approximate guidance only; designers must derive exact PFHd or PL from component data and the full assessment.

Metric / Level	IEC 62061 (SIL)	ISO 13849-1 (PL)	Approximate PFHd (1/h)
Highest	SIL 3	PLe	10⁻⁸ to 10⁻⁷ (typical target for SIL3/PLe)
High	SIL 3	PLd	10⁻⁷ to 10⁻⁶
Medium	SIL 2	PLc	10⁻⁶ to 10⁻⁵
Low	SIL 1	PLb / PLc	10⁻⁵ to 10⁻⁴
Lowest (typical)	N/A	PLd (lower bound references)	10⁻⁴ to 10⁻³

Note: PL–SIL correspondence is approximate and depends on architecture, diagnostics, common cause controls, and component failure rate data. The 2021 revisions of both standards improved the clarity on equivalence and subsystem transferability [1][2][3].

Architecture and fault metrics

IEC 62061 explicitly requires consideration of HFT and SFF and links SIL claims to software lifecycle controls originating from IEC 61508. ISO 13849-1 uses Categories (e.g., Category 3 requires single-fault tolerance and diagnostics; Category 4 requires diagnostics and capability to withstand multiple faults without loss of the safety function) and relies on MTTFd and DCavg to derive PL. Designers should target high diagnostic coverage (DC > 90%) and appropriate diversity/redundancy for higher PL/SIL levels, and implement CCF countermeasures where identical channels or components are used [2][3].

Verification, Validation, and Documentation

Both standards require documented verification and validation commensurate with the required SIL/PL:

ISO 13849-2 provides procedures for verification, testing, and inspection of SRP/CS against the SRS. It includes guidance on diagnostic testing, performance testing and proof testing intervals.
IEC 62061-2 (validation part) specifies lifecycle activities, software verification, unit testing, integration testing and system validation, and is aligned with IEC 61508 requirements for software development and configuration management [2][3].

Essential documentation includes the SRS, block diagrams and architectures, PFHd/PL calculations, proof test strategies, maintenance and inspection schedules, and a traceable record of design decisions and verification activities. For software-intensive safety functions, maintain software requirement specifications, source code version control, static analysis records, and test reports to meet IEC 62061/IEC 61508 expectations [2][4].

Implementation Best Practices

Begin with a thorough ISO 12100-based risk assessment and produce a clear Safety Requirements Specification (SRS) before design starts—both standards make the SRS central to the process [2].
Where possible, choose tried-and-tested components with manufacturer failure rate data and documented PL/SIL claims. Many vendors publish PFHd or PL data for safety PLCs and safety modules to support calculations [1][5].
Apply architectural diversity and diagnostics to mitigate systematic and random failures; design for testability and include proof test intervals determined by PFHd and expected wear-out [2][3].
Integrate cybersecurity considerations for programmable systems. Both standards reference IEC 62443 guidance when applicable; for programmable controllers include secure configuration, authenticated updates, and network segmentation to reduce systematic threats to safety [2].
Use validated tools to perform PL/SIL calculations (e.g., PAScal, manufacturer tools, or safety calculation tools from Siemens/Eaton). Ensure tool qualification where tool outputs affect safety decisions [1][2].
Train engineering teams on the selected standard and on practical topics (e.g., Pilz training courses) to ensure consistent, correctly documented application of the standard [6].

Products, Tools and Examples

Manufacturers increasingly support both methodologies and provide tools and certified components. Examples include:

Vendor / Tool	Example	Certifications / Notes
Pilz	myPNOZ and safety consultancy	Product portfolio Related Platforms Siemens Rockwell Automation ABB Related Services Safety Systems Frequently Asked Questions Need Engineering Support? Our team is ready to help with your automation and engineering challenges. sales@patrion.net Platforms Siemens Rockwell Automation ABB Schneider Electric Mitsubishi Electric Beckhoff Services PLC Programming SCADA & HMI Development Industrial Robotics Motion Control Process Automation System Integration Industries Automotive Manufacturing Food & Beverage Pharmaceuticals Oil & Gas Water & Wastewater Packaging Company Knowledge Base Blog Contact +90 232 332 22 78 sales@patrion.net © 2026 Engineering Service. All rights reserved.

Vendor / Tool

Example

Certifications / Notes

Pilz

myPNOZ and safety consultancy

Product portfolio