Industrial Automation Is Finally Getting Serious About Functional Safety

For decades, industrial safety meant physical separation. You put a cage around the robot. You interlocked the gate. If the machine could not reach the human, the human could not be harmed. The logic was simple, the standards were well-understood, and the safety case was essentially a checklist.

That era is ending faster than most manufacturing organizations expected.

Collaborative robots — cobots — are designed to share workspace with people. Autonomous mobile robots navigate factory floors without fixed paths or barriers. AI-driven process control systems make real-time decisions that affect pressure, temperature, flow, and machine state. None of these technologies fit comfortably inside the traditional machine guarding paradigm, and all of them are becoming mainstream simultaneously.

The result is an acceleration of IEC 61508 and IEC 62061 adoption across industrial automation that would have been difficult to predict five years ago. Safety engineers who spent careers applying EN 954-1 category tables are now being asked to demonstrate Safety Integrity Levels. Engineering managers who never needed a formal hazard analysis are discovering that their customers, their insurers, and their regulators now expect one.

This is not a compliance exercise. It is a genuine capability gap — and closing it is harder than it looks.

What Changed and Why It Changed Now

The shift has three drivers that arrived roughly simultaneously.

First, collaborative robot deployments crossed a threshold. When cobots were a niche product in a handful of industries, the installed base was small enough that incidents were rare and regulatory pressure was modest. By 2025, cobots represented a significant and rapidly growing share of new robot installations globally. The incident data that regulators need to justify tighter enforcement has been accumulating. ISO/TS 15066 had already established the technical framework for cobot safety — contact force and pressure limits, speed and separation monitoring — but it pointed back to the underlying IEC 62061 and ISO 13849 machinery safety infrastructure. Following ISO/TS 15066 correctly now requires substantive engagement with those standards.

Second, autonomous mobile robots moved out of controlled warehouses and into complex shared environments. Early AMR deployments were largely in e-commerce fulfillment centers with relatively predictable traffic patterns. The technology is now being deployed in automotive assembly plants, pharmaceutical manufacturing, and food production environments where the operating context is far more variable and the consequence of an unexpected interaction is more severe. This environmental complexity breaks the assumptions that made simplified safety approaches acceptable.

Third, AI-driven control systems began moving from advisory roles to actuating roles. A system that recommends a process adjustment is a decision-support tool. A system that executes a process adjustment autonomously — changing setpoints, modulating valves, initiating shutdowns — is a safety-relevant control system, and it needs to be treated as one.

Regulators have noticed. The EU Machinery Regulation, which replaces the Machinery Directive and applies from January 2027, explicitly addresses AI-enabled machinery and integrates more directly with the EU AI Act’s risk classification framework. The regulatory window that allowed manufacturers to defer systematic functional safety work is closing.

The Safety Case Problem for Autonomous Systems

Traditional machine safety is essentially deterministic. A physical guard either prevents access or it does not. An interlock either breaks the circuit or it does not. The failure modes are mechanical and electrical, they are well-characterized, and the standards provide conservative design rules that translate risk reduction requirements into specific design constraints. You can assess a Category 3 PL d architecture by examining its components and their redundancy arrangement. The analysis is labor-intensive but it is not ambiguous.

Autonomous systems introduce irreducible uncertainty at the behavioral level. A cobot running a force-limited operation does not have a fixed safety boundary — its safety depends on the interaction between its force monitoring system, the geometry of the contact, the mass and rigidity of the object or person being contacted, and the response time of its protective stop function. A risk assessment has to consider the full envelope of foreseeable interactions, not just the nominal case. That requires probabilistic thinking that EN 954-1’s category approach never demanded.

AMRs compound this. The hazard analysis for an AMR operating in a shared environment must account for object detection reliability across lighting conditions, sensor occlusion, software prediction failures, and human behavioral variability. The system’s safety functions — detecting obstacles, computing safe speed profiles, executing emergency stops — are implemented in software, which means they fall under IEC 61508 Part 3’s requirements for software safety integrity. This is genuinely difficult territory for organizations that have never built safety-classified software.

The fundamental difference is this: fixed automation safety is about eliminating exposure. Autonomous system safety is about demonstrating that the probability of a hazardous event, given the full distribution of operating conditions, is acceptably low. These are different engineering problems. The second one requires a formal safety case with quantified claims, and IEC 61508’s Systematic Capability and Hardware Fault Tolerance requirements are the scaffolding for building that case.

What Industrial Automation Is Borrowing from Automotive

The automotive industry solved a version of this problem beginning with ISO 26262’s publication in 2011 and its subsequent revision. Autonomous vehicle programs pushed the discipline further. Industrial automation engineers are now actively borrowing from that body of practice, and three elements are transferring with particular traction.

Hazard Analysis and Risk Assessment (HARA). ISO 26262’s HARA process — evaluating severity, exposure, and controllability to derive Automotive Safety Integrity Levels — maps reasonably well to the industrial context when translated through IEC 61508’s risk parameters. The disciplined structure of HARA, with its explicit documentation of hazardous events, their operating situations, and the rationale for ASIL assignment, is more rigorous than the risk graph and risk matrix approaches that many industrial manufacturers were using. Industrial teams are adapting the HARA methodology rather than adopting it wholesale, substituting SIL for ASIL and adjusting the exposure categories for industrial duty cycles, but the structural discipline carries over.

Safety Concept Architecture. ISO 26262’s distinction between the item level safety concept and the system level technical safety concept — cascading from hazardous events through safety goals to functional safety requirements to technical safety requirements — provides a decomposition framework that works in industrial contexts. Industrial machinery has always required functional safety requirement documentation in principle; in practice, many organizations maintained this traceability informally or not at all. Automotive practice enforces it structurally, and industrial teams that have worked with automotive suppliers are internalizing that discipline.

Software safety process. IEC 61508 Part 3 specifies software safety requirements, but it is abstract enough that organizations have significant latitude in implementation. ISO 26262 Part 6 is more prescriptive about software development methods, design guidelines, and verification measures at each ASIL. Industrial software teams working on AMR navigation stacks and AI-enhanced control systems are finding ISO 26262 Part 6’s method tables more actionable than IEC 61508’s software tables, and they are using them as a reference even when the formal certification path runs through IEC 61508.

The borrowing from aerospace is less direct but visible in one specific area: the safety argument structure. Aerospace’s Goal Structuring Notation (GSN) and Claims, Arguments, Evidence (CAE) frameworks are appearing in industrial safety cases for AI systems where the certification authority needs to evaluate an argument about system behavior rather than simply audit compliance with a checklist. We will return to this point.

The Standards Gap for AI-Driven Industrial Systems

IEC 61508 Edition 2 was published in 2010. IEC 62061 Edition 2 was published in 2021 and made meaningful progress on software safety requirements, but it was not written with machine learning or neural network-based control in mind. Neither standard has a coherent answer for a control system whose behavior emerges from training data rather than explicit specification.

The gap is real and the standards bodies know it. The IEC is developing guidance specifically addressing AI in functional safety contexts, and IEC 62443 (industrial cybersecurity) is increasingly referenced alongside functional safety standards because AI systems create attack surfaces that interact with safety functions in ways the base standards do not address. But formal standards take years to develop and the technology is deployed now.

The industry is responding with four approaches, used in combination.

Architectural containment. Keep the AI in an advisory role and implement safety functions in certified, non-AI components. The AI system recommends; a certified SIL-rated output stage actuates. This preserves SIL compliance by isolating the AI from the safety-classified control path. It is conservative and it limits what AI can contribute to real-time safety decisions, but it is architecturally sound and it passes current certification scrutiny.

Assurance case methods. Borrow the argument-based approach from aerospace. Rather than claiming conformance to a checklist, construct an explicit safety argument: here is the hazard, here is the safety claim about the system’s behavior, here is the evidence (testing, formal analysis, operational monitoring data) that supports the claim. IEC 61508 does not prohibit this approach; it does not specify it either. Several notified bodies are accepting well-structured GSN-based safety cases for AI components operating in lower SIL contexts.

Complementary technical standards. Reference emerging technical specifications that address AI-specific concerns. ISO/IEC TR 5469 (AI functional safety) is a technical report, not a normative standard, but it provides vocabulary and a framework that notified bodies can use to evaluate AI safety arguments. DIN SPEC 92004 on AI components in safety-related systems is similarly useful as a reference framework in European contexts. These documents give certifiers something to evaluate against when the base standards are silent.

Operational monitoring and field validation. Accept more conservative initial deployment constraints and use operational data to progressively refine the safety case. This is analogous to how aerospace handles type certification extensions — the initial certificate is conservative, and field experience generates evidence that supports relaxation of operating limitations. It requires a monitoring infrastructure and a disciplined process for incorporating operational data into the safety case, but it is increasingly accepted as a framework for AI systems where pre-deployment testing cannot fully characterize behavior across the operational design domain.

Building the Competency

Understanding the standards is necessary but not sufficient. The organizations that are making genuine progress on functional safety capability share a common pattern: they changed their engineering process, not just their documentation.

Functional safety requires that hazardous events be traced from the system level through every design decision that addresses them, down to component selection and verification evidence. This is a requirements and traceability problem before it is a certification problem. Organizations that treat safety requirements as a separate parallel documentation effort — produced after the design is done to satisfy a certification audit — consistently struggle. The safety requirements need to drive design decisions, which means they need to be accessible and connected to the design artifacts throughout development.

This is where modern requirements tooling becomes relevant. Traditional document-based requirements management — Word documents, spreadsheets, PDF exports — cannot maintain meaningful traceability across a complex safety case. The linkages between hazardous events, safety functions, safety requirements, design elements, and verification records need to be actively maintained and queryable, not manually reconstructed for each review.

Tools like Flow Engineering, built specifically for hardware and systems engineering teams, implement the kind of graph-based traceability that functional safety requires natively — connecting safety requirements to design elements and verification evidence in a structure that reflects the actual architecture of the safety case rather than imposing a document hierarchy on top of it. The ability to navigate from a SIL requirement to every design decision it constrains, and to every piece of verification evidence that closes it, is what the difference between a functional safety argument and a functional safety document. For teams building AMR navigation systems or AI-assisted process controllers under IEC 61508, having that connected model is not a luxury — it is what makes the safety case maintainable as the design evolves.

The competency-building challenge is also a talent challenge. Functional safety engineers with industrial automation domain knowledge and software safety depth are scarce. The organizations moving fastest are not waiting for the talent market to supply them — they are investing in training for existing engineering staff and hiring from adjacent industries, particularly automotive Tier 1 suppliers where ISO 26262 practice is embedded.

Honest Assessment

Industrial automation’s engagement with functional safety is real and accelerating, but it is uneven and frequently incomplete. Large robot OEMs and AMR manufacturers with exposure to automotive or semiconductor customers are further along. Smaller machine builders, system integrators, and end-user manufacturers who are deploying autonomous systems without a clear regulatory trigger are still largely in the awareness phase.

The standards gap for AI is genuine. The approaches currently available — architectural containment, assurance case methods, complementary standards, operational monitoring — are workable but require engineering judgment that the standards themselves do not supply. Notified bodies vary in how they evaluate AI safety cases, and that inconsistency creates uncertainty for manufacturers trying to plan certification programs.

The positive development is that the functional safety discipline that automotive developed under competitive and regulatory pressure over the past fifteen years is available to industrial automation without having to be reinvented. The concepts, the methods, and increasingly the tools are transferable. The hard part is the organizational work: changing how engineering teams think about system behavior, failure, and risk — and building the process infrastructure to turn that thinking into demonstrable, auditable safety cases.

That work is underway. It is not finished. And for the autonomous industrial systems deploying today, the clock is running.