Functional safety is the part of overall safety that depends on automated systems working correctly in response to danger. When a machine, vehicle, or industrial process could harm people, functional safety ensures that electrical, electronic, and software-based systems detect hazardous conditions and bring things to a safe state. It’s not about preventing every possible risk. It’s specifically about making sure the safety-related controls built into a system do their job when it matters.
The concept applies to everything from the anti-lock brakes in your car to the emergency shutdown systems in a chemical plant. If a sensor fails, if software glitches, or if a control circuit degrades, functional safety practices are what determine whether the system still protects people.
How Functional Safety Differs From General Safety
General safety covers every possible source of harm: sharp edges, toxic materials, structural collapse, fire. Functional safety narrows the focus to one specific question: will the active safety systems perform their intended function? A guardrail on a factory walkway is a passive safety measure. The emergency stop system on a robotic arm that halts movement when a worker steps too close is a functional safety measure. The distinction matters because active safety systems involve electronics, sensors, and software, all of which can fail in ways that physical barriers cannot.
This is why functional safety requires its own engineering discipline. You can inspect a guardrail and see whether it’s intact. You can’t look at a circuit board and know whether it will respond correctly to a fault condition three years from now. Functional safety standards exist to provide structured methods for designing, testing, and maintaining these systems so that their reliability can be quantified rather than assumed.
The Foundation: IEC 61508
The international standard IEC 61508 is the backbone of functional safety. Published by the International Electrotechnical Commission, it covers electrical, electronic, and programmable electronic systems (often abbreviated E/E/PE) that perform safety functions. Its second edition, released in 2010, remains the current version, though a third edition is now in the draft voting stage with a proposed stability date of 2028.
IEC 61508 introduces a concept called the safety lifecycle, which maps out every phase a safety system goes through: initial concept, specification, design, installation and commissioning, operation and maintenance, validation, modification, and eventually decommissioning. The standard actually defines three interrelated lifecycles: one for the overall system, one for the E/E/PE hardware, and one for the software. Each lifecycle phase has specific activities, documentation requirements, and verification steps. The goal is to prevent safety gaps from creeping in at any stage, whether during initial design or years later during a routine software update.
Safety Integrity Levels
At the heart of IEC 61508 are Safety Integrity Levels, labeled SIL 1 through SIL 4. These represent how reliably a safety function must perform. SIL 1 is the lowest level of integrity, and SIL 4 is the highest, reserved for situations where failure would be catastrophic. The required SIL for any given safety function is determined by a risk assessment: how severe the potential harm is, how often people are exposed to it, and whether there are other ways to avoid or reduce the danger.
Achieving a higher SIL requires more rigorous design, more redundancy, more thorough testing, and stricter development processes. It’s not just about building better hardware. The standard imposes increasingly demanding requirements on documentation, code review, and verification at every level.
Two Types of Failure
Functional safety standards distinguish between two fundamentally different kinds of failure, and understanding the difference explains much of why these standards are structured the way they are.
Random hardware failures happen because physical components degrade over time. Corrosion, thermal stress, and general wear eventually cause a sensor, relay, or circuit to stop working. These failures are unpredictable in timing but statistically predictable in rate. Engineers can model them using historical failure data and build in redundancy (backup components that take over when one fails) to reduce the risk.
Systematic failures are a different problem entirely. These are caused by mistakes in design, specification, software coding, or operational procedures. A programmer writes logic that doesn’t account for a specific fault condition. A specification is ambiguous, leading to a design that behaves unexpectedly. Software failures always fall into this category. You can’t fix systematic failures by adding a second identical system, because the second system will have the same flaw. Instead, they require rigorous lifecycle activities: structured design reviews, formal testing methods, and careful change management. The higher the SIL, the more demanding these qualitative measures become.
Safe Failure Fraction and Redundancy
One metric that IEC 61508 uses to evaluate hardware is the Safe Failure Fraction, or SFF. This is the proportion of all possible failures that either result in a safe state or are detected by the system’s own self-testing diagnostics. The remaining failures, those that are both dangerous and undetected, are what matter most. A system where 90% of possible failures are either safe or caught by diagnostics has an SFF of 90%.
The standard sets SFF thresholds based on how much redundancy a system has. A simple, non-redundant system with an SFF below 60% can only claim SIL 1 (or in some cases, no SIL at all). Add a layer of redundancy, and the same SFF allows a higher SIL claim. A system with greater than 99% SFF and dual redundancy can achieve SIL 4. This creates a practical trade-off: you can reach higher safety integrity through better diagnostics, more redundancy, or both.
Industry-Specific Standards
IEC 61508 is a generic standard. It provides the framework, but individual industries have developed their own standards that tailor these principles to their specific risks and technologies.
Automotive: ISO 26262
ISO 26262 adapts functional safety for road vehicles. Instead of SIL levels, it uses Automotive Safety Integrity Levels, rated ASIL A (lowest) through ASIL D (highest). Each ASIL is determined by three parameters: how severe an injury would be if a crash occurred, how often the vehicle is in the driving situation where the hazard could arise (exposure), and how easily the driver can control or avoid the situation (controllability). A steering system failure at highway speed scores differently than a seat heater malfunction, and the ASIL rating dictates how rigorous the development process must be. With the rise of advanced driver-assistance systems and autonomous driving, ASIL D requirements now apply to an increasing number of vehicle components.
Process Industry: IEC 61511
Chemical plants, refineries, and other process facilities follow IEC 61511, which was developed as a process-sector implementation of IEC 61508. It focuses on Safety Instrumented Systems, the automated controls that detect dangerous process conditions (a pressure spike, a temperature excursion, a loss of flow) and trigger protective actions like shutting a valve or stopping a pump. The standard covers everything from specifying these systems through their entire operational life, including installation, maintenance, and eventual modification. The emphasis on ongoing operation reflects the reality that process plants run for decades, and safety systems must remain reliable throughout.
Industrial Machinery: ISO 13849
For factory machinery, robots, and manufacturing equipment, ISO 13849-1 takes a slightly different approach. It uses Performance Levels rated PL a (lowest) through PL e (highest) instead of SIL ratings. These are determined by similar risk factors, but the standard is structured around categories of control system architecture, making it more practical for machine builders who are designing safety circuits for specific pieces of equipment rather than entire plant-wide systems.
AI and the Limits of Current Standards
One of the biggest challenges facing functional safety today is artificial intelligence. Traditional safety standards assume that a system’s behavior can be fully specified, verified, and traced back to explicit design decisions. AI systems, particularly those using machine learning, don’t work that way. Their behavior is shaped by training data rather than written specifications, making them difficult to validate using conventional methods.
A 2024 technical report from ISO and IEC (TR 5469) directly addresses this gap. It acknowledges that some mature functional safety standards explicitly forbid the use of AI in safety functions. The report proposes a classification scheme for determining when AI technology can comply with existing standards and outlines a three-stage approach for situations where direct compliance isn’t possible. For safety functions that include machine learning, the report calls for additional focus on proving that the system’s capabilities are sufficient for its intended operating environment. It also extends the traditional catalog of measures for handling systematic failures to cover the unique properties of AI, since AI failures are fundamentally systematic in nature: they stem from data and design choices, not from physical degradation.
The practical implication is that as vehicles, industrial robots, and medical devices increasingly rely on AI for safety-critical decisions, the frameworks governing functional safety are actively evolving. The upcoming third edition of IEC 61508, still in draft, represents part of that evolution.
Why Functional Safety Matters in Practice
For engineers and product developers, functional safety compliance isn’t optional. Regulatory bodies in the EU, North America, and elsewhere require conformance to relevant standards before safety-critical products can be sold or operated. For companies in automotive, industrial automation, medical devices, and energy, functional safety certification is a market requirement.
For anyone working with or around safety-critical systems, the core idea is straightforward: every automated safety function needs to be designed with a known level of reliability, tested against defined failure scenarios, and maintained throughout its entire operational life. The standards exist because intuition and good intentions aren’t enough when electronics and software stand between people and serious harm.