What Is Functional Safety and How Is It Different from Safety Engineering
Safety engineering is a broad discipline. It covers mechanical failure, human error, environmental hazards, organizational processes, and more. Functional safety is a specific slice of that discipline—one that has become disproportionately important as the systems we build have become dominated by software-driven electronics.
Understanding where functional safety starts and stops matters practically. Teams that conflate it with general safety engineering end up applying the wrong tools and the wrong standards. Teams that treat it as purely a compliance checkbox miss the analytical work that makes it useful.
Defining the Terms
Safety engineering in its general form is concerned with preventing harm to people, property, or the environment. It draws from mechanical engineering, human factors, reliability engineering, systems theory, and process safety. A functional analysis of a bridge, a risk assessment of a chemical plant, or an ergonomic review of a cockpit are all safety engineering activities. None of them are necessarily functional safety.
Functional safety has a specific technical definition established in IEC 61508: it is the part of the overall safety of a system that depends on the correct functioning of safety functions implemented in electrical, electronic, or programmable electronic (E/E/PE) systems.
The operative phrase is “correct functioning.” Functional safety is not about whether a system is physically robust against external shocks, or whether operators are trained correctly, or whether a mechanical interlock will hold. It is about whether the software and electronics that implement a safety function behave correctly—and what happens when they don’t.
A mechanical pressure relief valve is a safety measure, but it is not a functional safety concern in the IEC 61508 sense. A software-controlled pressure management system that monitors sensors and activates actuators is. The hazard addressed is the same; the engineering discipline governing the mitigation differs.
Why the Distinction Matters in Practice
In many modern systems—automotive, medical devices, rail, industrial automation—functional safety is the dominant safety concern because software and electronics are the dominant implementation technology. A car’s stability control system, a pacemaker’s stimulation algorithm, a train’s automatic protection system: these are all functional safety systems. Physical redundancy, material properties, and human operator behavior all still matter, but the safety case lives or dies on whether the E/E/PE implementation is correct.
The practical consequence is that functional safety demands a structured requirements and verification process that general safety engineering does not always require. You need to trace from a top-level hazard to a safety goal, from a safety goal to a safety requirement, from a safety requirement to a design element, and from a design element to a test case. That traceability chain is auditable evidence that your system does what it claims to do. Without it, you cannot make a credible safety case.
IEC 61508: The Parent Standard
IEC 61508, published by the International Electrotechnical Commission, establishes the general framework for functional safety of E/E/PE safety-related systems. It applies across industries and covers the full lifecycle: concept, overall scope definition, hazard and risk analysis, overall safety requirements, safety planning, realization, installation and commissioning, validation, and operation.
IEC 61508 introduces two central concepts that all derivative standards inherit:
Safety Integrity Levels (SILs). A SIL is a discrete level (SIL 1 through SIL 4) that specifies a target range for the probability of failure on demand—or, for continuous operation, a failure rate range. Higher SILs demand lower failure probabilities. SIL 4 requires a probability of dangerous failure on demand between 10⁻⁵ and 10⁻⁴; SIL 1 requires between 10⁻² and 10⁻¹. These are engineering targets derived from risk analysis, not quality ratings. A SIL 2 system is not “better” than a SIL 1 system in any general sense—it is designed to achieve greater risk reduction because the hazard it addresses warrants it.
The safety function concept. A safety function is a function implemented by an E/E/PE system that achieves or maintains a safe state for the equipment under control. Identifying safety functions—and assigning each a SIL—is the core analytical output of hazard and risk analysis.
IEC 61508 is intentionally generic. It provides the logic and the vocabulary. Domain-specific standards translate that logic into sector-specific requirements.
The Derivative Standards
ISO 26262 — Road Vehicles
ISO 26262 adapts IEC 61508 for automotive E/E systems. It replaces SIL with ASIL (Automotive Safety Integrity Level), graded A through D, derived from a combination of severity, exposure, and controllability parameters from hazard analysis and risk assessment (HARA). It introduces the concept of the safety goal as the top-level functional safety requirement, and specifies detailed requirements for safety cases, confirmations measures, and independence between safety analysts and designers.
ISO 26262 also formally separates the item definition, the HARA, the functional safety concept, the technical safety concept, and the hardware/software design, creating explicit layer boundaries where requirements must be allocated and traced.
IEC 62304 — Medical Device Software
IEC 62304 governs software lifecycle processes for medical devices. It maps to IEC 61508 but focuses narrowly on software—not the full system. It classifies software into three safety classes (A, B, C) based on the severity of potential harm. Class C software, where failure could cause death or serious injury, demands the most rigorous processes: full traceability, unit-level testing, and systematic verification.
IEC 62304 does not directly address hardware or the broader system safety analysis. It assumes that system-level hazard analysis has been performed (typically under ISO 14971, the risk management standard for medical devices) and that the software classification flows from that analysis.
EN 50128 — Railway Applications
EN 50128 applies to railway control and protection software. It uses SILs directly from IEC 61508 and provides detailed normative requirements for development processes, tools, techniques, and independence levels depending on the SIL of the software. It is notably prescriptive about specific techniques—formal methods, static analysis, structured testing—and specifies which are mandatory versus recommended at each SIL level.
EN 50128 is often paired with EN 50129 (safety-related electronic systems for railways) and EN 50126 (reliability and safety specification), forming the CENELEC suite for railway functional safety.
Functional Safety Concepts in Practice
Across all these standards, a common analytical pattern emerges:
- Identify hazards at the system level. What can go wrong? What are the potential consequences?
- Assess risk using some combination of severity, probability, and controllability to determine the required risk reduction.
- Define safety goals or safety functions that achieve the required risk reduction. Assign an integrity level to each.
- Derive functional safety requirements from the safety goals. These are behavioral requirements on the system.
- Allocate requirements to system elements—hardware, software, mechanical elements, operating procedures. Specify which elements are responsible for achieving which safety functions.
- Verify and validate that each allocated requirement is met.
This is a hierarchical decomposition and allocation problem. The safety goal is abstract (“the vehicle shall not exceed safe lateral acceleration during normal operation”). The functional safety requirement is more concrete (“the stability control function shall activate within 50 ms of detecting a stability hazard”). The hardware and software requirements are more concrete still. At each layer, the requirements must be traceable to the layer above.
The failure mode that recurs across functional safety programs is losing this traceability. Requirements get reworded in translation. Allocations get made informally, in meeting notes, and never captured in the system of record. Tests get written against the implementation, not against the stated requirements. The safety case then rests on informal understanding rather than auditable evidence.
How Modern Tools Support Functional Safety Requirements Management
The requirements management challenge in functional safety is not just about storing requirements. It is about managing a structured network of safety goals, safety functions, requirements at multiple abstraction levels, and their allocation to specific system elements—and keeping that network consistent as designs change.
Document-based tools—spreadsheets, Word documents, even some legacy requirements management platforms—handle this poorly. They can store text, but they cannot enforce or surface relationships. When a safety goal changes, there is no automated way to identify which derived requirements and allocations are affected. When a design element is modified, there is no immediate visibility into which safety functions depend on it.
Graph-based requirements tools handle this structure directly. Flow Engineering, built specifically for hardware and systems engineering teams, represents requirements, safety goals, and their relationships as a connected graph rather than a flat document hierarchy. When a safety goal is modified, the impact propagates through the graph, surfacing all downstream requirements and allocated elements that may need review. Safety functions can be linked to the hardware and software items responsible for implementing them, creating the allocation traceability that standards like ISO 26262 and EN 50128 require.
Flow Engineering also supports AI-assisted requirements derivation—starting from a safety goal and generating candidate functional safety requirements for engineer review, which reduces the blank-page problem in early functional safety concept phases. This is not automation of the safety analysis itself; the hazard analysis and risk assessment still require engineering judgment. But the translation from safety goal to structured requirement set is a step where AI assistance meaningfully reduces cycle time.
For teams working across multiple derivative standards simultaneously—an automotive supplier building medical-grade driver monitoring systems, for instance—the ability to map a single safety artifact to multiple standard frameworks in the same tool is a practical advantage over maintaining parallel document sets.
Practical Starting Points
If you are building or certifying a system under any of these standards, three things are worth establishing early:
Clarify the boundary. Define explicitly which elements of your system are safety-related E/E/PE elements and which are not. This determines what standard applies to what, and prevents both under-scoping (missing safety-critical elements) and over-scoping (applying SIL 3 rigor to a non-safety-critical subsystem because someone was not sure).
Establish the safety goal layer first. Safety goals are the outputs of hazard analysis. They are the commitments your system is making. Derive functional safety requirements from them, not the other way around. Writing requirements first and then trying to map them to safety goals inverts the process and produces incoherent safety cases.
Build traceability infrastructure before you need it. The audit artifact most commonly missing at certification reviews is not the requirements themselves but the evidence that requirements are connected—to the goals above them, to the design elements below them, and to the test cases that verify them. Establishing this infrastructure at the start of a program, in a tool that can maintain and surface it, is far less costly than reconstructing it before a certification review.
Functional safety is demanding precisely because the systems it governs are systems where incorrect behavior can kill people. The standards that govern it are not bureaucratic obstacles; they are codified lessons from programs that failed. Understanding what functional safety actually requires—and separating it clearly from the broader safety engineering landscape—is the prerequisite for meeting those requirements with confidence rather than anxiety.