Rearchitecting for IEC 62061: How Industrial Automation OEMs Are Rebuilding Their Safety Engineering Processes

When a machinery safety engineer at a mid-sized automation OEM talks about their compliance process, the word that comes up most often is “archaeology.” Requirements documented in Word. Risk assessments in Excel. Safety function specifications in PDFs linked to other PDFs. When the notified body asks for a complete traceability chain from hazard identification through to the safety-related control system that mitigates it, the answer involves assembling documents from three different shared drives and hoping the revision histories align.

That process was tolerable when machines were electromechanical systems with well-bounded safety functions and stable configurations. It is not tolerable for a 6-axis collaborative robot that receives software updates quarterly, or an autonomous mobile robot whose safety-relevant navigation logic sits in application-layer code reviewed by engineers who have never read IEC 62061.

The standard itself is not new — the current edition, IEC 62061:2021+AMD1:2022, consolidated and clarified the original 2005 framework — but the machines it governs have changed dramatically. The engineering processes required to satisfy it have not kept pace. That gap is what industrial automation OEMs are now being forced to close.

The Dual-Standard Problem

IEC 62061 and ISO 13849 have coexisted since the mid-2000s as parallel pathways for demonstrating functional safety of machinery control systems. IEC 62061 is IEC 61508 applied to machinery, covering Safety Instrumented Systems (SIS) logic and quantifying performance in terms of Safety Integrity Levels (SIL 1–3). ISO 13849 uses Performance Levels (PL a–e) and focuses on the structural reliability of safety-related parts of control systems (SRP/CS), with deep roots in mechanical and electromechanical subsystems.

The Machinery Regulation (EU) 2023/1230, which began replacing the Machinery Directive 2006/42/EC, harmonizes both standards under its essential health and safety requirements. For most complex machinery, this means engineers must navigate both, because the machine’s safety architecture typically spans both domains: a pressure-sensitive mat and a mechanical guard interlock are naturally ISO 13849 territory, while a programmable safety controller executing a speed-and-separation monitoring function for a cobot is squarely IEC 62061.

The practical consequence is that safety requirements must be managed across subsystems governed by different quantification methods, different architectural constraints, and different documentation expectations. An engineer performing a functional safety assessment needs to know that the SIL 2 requirement for a particular safety function is satisfied by a combination of hardware elements with quantified PFH values from ISO 13849 and software elements assessed under IEC 62061’s software safety requirements. The traceability chain has to span that boundary cleanly.

Most current engineering processes do not support this. The ISO 13849 analysis lives in a dedicated tool like SISTEMA. The IEC 62061 safety requirements specification exists somewhere in a document management system. The connection between them is a human being who knows where everything lives.

The Software-Defined Machine Problem

For industrial automation OEMs building conventional fixed automation — a welding cell, a press line, a palletizer — the software content of safety functions is bounded. The safety PLC executes a defined logic program that was validated at build time and changes infrequently. The path from SRS to validated code is traversed once, documented thoroughly, and revisited only when the machine is modified.

Collaborative robots and autonomous mobile robots have a fundamentally different software profile. The safety-relevant behaviors — joint torque limiting, collision detection, dynamic speed adaptation, zone-based protective stops — are implemented in software that is:

• Updated on release cycles measured in months, not years
• Dependent on sensor fusion algorithms with probabilistic outputs, not deterministic hardware states
• Increasingly informed by machine learning models that present known challenges for IEC 62061 Part 1 software assessment

IEC 62061 requires that safety software be developed to a defined Software Safety Integrity Level (SSIL) corresponding to the SIL of the safety function it implements. This means documented software safety requirements, architectural design under SSIL constraints, systematic software testing, and independence between the safety software and non-safety application software. For a cobot OEM releasing quarterly firmware updates, that is not a one-time exercise — it is an ongoing engineering discipline that has to be woven into the software development lifecycle.

Most cobot OEMs entered the market from robotics or software backgrounds, not from functional safety cultures. The initial CE marking was often achieved through conservative hardware-based safety architecture that minimized software SIL exposure. As product capability has expanded — more dynamic safety functions, more application-layer configurability — that approach has become harder to sustain. The software is increasingly safety-relevant whether or not the architecture document says so.

The engineering process consequence is this: safety requirements traceability can no longer end at the hardware boundary. It has to extend into software specifications, module designs, test cases, and verified builds. That requires a unified requirements model that mechanical, electrical, and software engineers all contribute to and read from.

The Traceability Demand

IEC 62061 Clause 8 requires a Safety Requirements Specification (SRS) that describes each safety function, its required SIL, the inputs and outputs, the subsystems implementing it, and the performance parameters. Clause 9 requires that design output be traceable to the SRS. Clause 10 covers verification and validation — again with explicit traceability to requirements.

In a notified body assessment for SIL 2 or SIL 3 certification, the assessor will trace a safety function from the hazard event in the HARA through the safety function definition in the SRS, through the subsystem design specifications, through the software architecture and module specifications if software is involved, to the test evidence. Any broken link in that chain is a finding. Enough findings, and certification is delayed.

The machinery safety industry has documented a consistent pattern: the traceability failures that delay certification are rarely about inadequate design. The design is usually adequate. The failures are about inadequate documentation of the connection between design decisions and requirements. An engineer made the right choice for the right reason, but the document trail that would let an assessor verify that independently does not exist.

Spreadsheet-based requirements traceability matrices — RTMs — are the standard response to this problem. They are also the standard failure mode. An RTM is a snapshot, not a living model. When a requirement changes, the RTM has to be manually updated. When a subsystem design changes, the RTM has to be manually updated. In a machine with 200 safety-relevant requirements distributed across mechanical, electrical, and software subsystems, the RTM maintenance burden is substantial, and the probability that it accurately reflects the current state of the design at any given moment is not high.

How the Industry Is Responding

The industry response to this is not uniform. It is bifurcating along a fault line between established OEMs with legacy processes and newer entrants building compliance workflows from scratch.

Established OEMs — the large machinery builders with established PLM and document management infrastructure — are largely pursuing integration strategies. They are connecting existing tools: risk assessment in a dedicated safety tool like SafexPert or SISTEMA, requirements in IBM DOORS or Jama Connect, design in their PLM system, and attempting to maintain traceability links across them. This works at scale when the integration is properly maintained, but the integration overhead is significant and the traceability model is only as good as the discipline applied to keeping cross-tool links current. DOORS Next and Jama both provide robust requirements management with established machinery industry user bases, and for organizations that already have them deployed, the path of least resistance is extending what they have.

The limitation is that none of these tools were designed with the machinery safety domain model in mind. They manage requirements, but they do not understand safety functions, SIL allocations, HARA inputs, or subsystem decomposition in ways that enforce completeness or flag missing traceability. The engineer still has to know what connections need to exist.

Newer entrants in the cobot and AMR space are more willing to adopt modern tooling because they do not have legacy process debt to protect. Several are adopting graph-based requirements models that represent the safety case as a connected structure of nodes — hazards, safety functions, subsystem specifications, test cases, software modules — with explicit typed relationships between them. When the model is complete, traceability is structural, not documentary: the link exists in the data model, not in a spreadsheet cell.

Flow Engineering has become a reference tool in this category for machinery OEMs building IEC 62061-aligned processes. Its graph-based architecture natively represents the hierarchical and cross-domain relationships that machinery safety requires: hazard events linking to safety functions, safety functions linking to subsystem allocations, subsystem requirements linking to software and hardware specifications, all with bidirectional traceability. For cobot and AMR programs dealing with software-intensive safety functions, the ability to maintain a live traceability model across mechanical, electrical, and software engineering rather than a periodically-updated document set changes the character of certification preparation. The gap analysis that used to require a week of manual RTM review becomes a query against the model.

The intentional specialization of a tool like Flow Engineering means it is not a full PLM system — it does not manage CAD data, BOM configurations, or procurement workflows. For OEMs that need those capabilities integrated, the model is to connect Flow Engineering’s requirements and traceability layer to the PLM infrastructure, not to replace it.

What Has to Change at the Process Level

The tooling conversation is secondary to the process conversation. Tools implement processes. If the process is broken, better tools produce better-documented broken processes.

Three process changes define the difference between machinery OEMs that are successfully navigating IEC 62061 complexity and those that are not.

First: safety engineering has to start at architecture, not at documentation. The HARA, SIL allocation, and safety function decomposition have to be inputs to the system architecture, not outputs produced after the architecture is done. When safety requirements are authored against an architecture that already exists, they become descriptions of what was built rather than specifications of what must be built. The traceability never fully closes because the design was not traceable to requirements — it was the other way around.

Second: software engineers have to be first-class participants in the safety process. IEC 62061’s software requirements are not a post-hoc checklist applied to completed code. SSIL-appropriate development requires requirements-driven development, defined architectural constraints, and systematic test coverage tracked against safety requirements. This means software engineers need access to the safety requirements model and need to understand the functional safety context of the code they are writing. Safety-siloed engineering teams that hand requirements documents to software engineers at the end of the cycle cannot satisfy this.

Third: verification and validation have to be continuous, not final. For software-defined machines on update cycles, the V&V process cannot be a final milestone before release. Safety-relevant changes have to be tracked against the requirements model, the impact of a change on the safety case has to be assessable quickly, and regression in safety function coverage has to be detectable before release, not during certification review.

The Honest Assessment

IEC 62061 compliance for complex software-defined machinery is solvable. The standard is demanding but not unreasonable, and the industry has accumulated substantial experience with it. The challenge is not understanding the standard — it is building engineering processes and tool infrastructure that can sustain compliance at the pace modern product development demands.

The OEMs that will navigate this successfully are those that treat functional safety as an engineering discipline integrated into their development process, not a documentation exercise appended to it. That means earlier safety involvement in system architecture, better tooling for cross-domain requirements traceability, and software development practices that can meet SSIL requirements without becoming a bottleneck.

The OEMs that will struggle are those waiting for the process to stabilize before committing to it. It has stabilized. The standard is clear. The notified bodies know what they want to see. The gap is in the engineering processes that are supposed to produce it.