What Is Functional Safety (FuSa)?
Functional safety is the part of overall safety that depends on the correct functioning of a system in response to its inputs. A system is functionally safe when it behaves correctly under both normal operation and identifiable fault conditions—and when failures that do occur are detected and handled in a way that prevents harm.
The definition is worth unpacking precisely because engineers conflate functional safety with general product safety. They are not the same thing. A brake pad that wears down below specification is a material degradation problem. A brake-by-wire system that misinterprets a sensor signal and applies the brakes at highway speed is a functional safety problem. The first involves physics. The second involves the behavior of an E/E (electrical/electronic) system in response to an input. Functional safety disciplines address the second category.
The practical consequence: functional safety governs software, firmware, and electronic hardware in systems where a malfunction can cause injury, death, environmental damage, or significant economic harm. It is not optional in most regulated industries. It is the engineering discipline that turns “safe enough” from a judgment call into a defensible, auditable claim.
The Root Standard: IEC 61508
IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems, is the foundational generic standard. Published by the International Electrotechnical Commission, it covers the entire safety lifecycle—from hazard and risk analysis through system design, implementation, verification, validation, and eventual decommissioning.
IEC 61508 introduced Safety Integrity Levels (SIL) as the quantitative and qualitative mechanism for expressing how much integrity a safety function requires. There are four levels:
| SIL | Probability of dangerous failure on demand (low demand) | Probability of dangerous failure per hour (high/continuous demand) |
|---|---|---|
| 1 | 10⁻² to 10⁻¹ | 10⁻⁶ to 10⁻⁵ |
| 2 | 10⁻³ to 10⁻² | 10⁻⁷ to 10⁻⁶ |
| 3 | 10⁻⁴ to 10⁻³ | 10⁻⁸ to 10⁻⁷ |
| 4 | 10⁻⁵ to 10⁻⁴ | 10⁻⁹ to 10⁻⁸ |
SIL determines how much rigor must be applied to design, coding practices, testing, and independent verification. A SIL 1 function requires systematic approaches to avoiding failure. A SIL 4 function requires formal methods, exhaustive testing strategies, and levels of independence between development and verification that reshape how you staff and structure a project.
The critical point is that SIL is assigned to functions, not components. The same physical relay might support a SIL 1 function in one system and a SIL 3 function in another. The standard does not tell you what to build. It tells you how rigorously to prove that what you built is correct.
Sector Standards Derived from IEC 61508
IEC 61508 is deliberately generic. It applies to any E/E system in any industry. The trade-off is that it requires interpretation. To reduce that interpretive burden, industry sectors have developed their own standards that inherit IEC 61508’s principles but apply them to domain-specific architectures, failure modes, and development practices.
Automotive: ISO 26262
ISO 26262, Road Vehicles — Functional Safety, was first published in 2011 and substantially revised in 2018. It replaces the generic SIL with Automotive SIL (ASIL), which runs from ASIL A (least stringent) through ASIL D (most stringent), with an additional designation of QM (Quality Management) for functions where no safety integrity requirement beyond standard quality processes applies.
ASIL is determined through a risk assessment process called HARA (Hazard Analysis and Risk Assessment), which evaluates three parameters:
- Severity (S0–S3): How serious are the potential injuries?
- Exposure (E0–E4): How frequently is the driver in a situation where the hazard could occur?
- Controllability (C0–C3): Can the driver or others avoid the harm if the malfunction occurs?
ASIL D is roughly equivalent to IEC 61508 SIL 3 in terms of rigor. ISO 26262 covers the entire item development lifecycle—system, hardware, and software—and includes specific requirements for functional safety management, safety culture, and competence of personnel. It is the dominant standard for automotive OEMs and Tier 1 suppliers globally.
Medical Devices: IEC 62304
IEC 62304, Medical Device Software — Software Life Cycle Processes, governs software embedded in or used by medical devices. It classifies software into three safety classes:
- Class A: No injury or damage to health is possible.
- Class B: Injury is possible but not serious.
- Class C: Death or serious injury is possible.
Class C software carries requirements comparable to SIL 2–3: documented software development planning, requirements analysis with traceability to system requirements, architecture design, unit implementation and testing, integration testing, and system testing—all with maintained and verifiable records.
IEC 62304 operates alongside IEC 60601-1 (electrical safety) and is typically assessed in conjunction with ISO 14971 (risk management). The FDA also references IEC 62304 in its guidance documents, making it de facto mandatory for software in US-regulated medical devices.
Process Industry: IEC 61511
IEC 61511, Functional Safety — Safety Instrumented Systems for the Process Industry Sector, applies to Safety Instrumented Systems (SIS) in oil and gas, chemical, and petrochemical facilities. It maps directly to IEC 61508 SIL levels and covers the full lifecycle of a SIS: concept, scope, hazard and risk analysis, allocation of safety functions to protection layers, SIS design, installation, commissioning, validation, operation, and modification.
IEC 61511 is notable for its focus on the entire protection layer architecture. A functional safety claim in process industries is rarely about a single piece of software—it involves sensors, logic solvers, final control elements, and their interactions. The standard requires probabilistic calculations (typically PFD—Probability of Failure on Demand) to demonstrate that the overall SIS meets its target SIL.
Aerospace: DO-178C and ARP4754A
Aviation uses a parallel framework with different terminology. DO-178C, Software Considerations in Airborne Systems and Equipment Certification, defines five Design Assurance Levels (DAL):
| DAL | Failure condition category | Example |
|---|---|---|
| A | Catastrophic | Flight control software |
| B | Hazardous | Engine control |
| C | Major | Autopilot engagement |
| D | Minor | Passenger information |
| E | No safety effect | In-flight entertainment |
DAL A software requires the most rigorous development and verification processes, including 100% modified condition/decision coverage (MC/DC) in testing, formal reviews of all artifacts, and extensive traceability from requirements through code to test results.
ARP4754A, Guidelines for Development of Civil Aircraft and Systems, addresses the system-level equivalent of DO-178C—it covers how aircraft systems are developed, including functional hazard assessment and the allocation of DALs to system functions and components. Together, DO-178C and ARP4754A form the framework that regulators like the FAA and EASA use to evaluate airworthiness of software-containing systems.
What All These Standards Have in Common
Despite different terminology and sector-specific provisions, every functional safety standard shares the same structural logic:
- Identify hazards and estimate risk. What can go wrong, how often, and how bad?
- Define safety goals. What must the system guarantee to reduce risk to tolerable levels?
- Assign integrity levels. How rigorously must each safety function be developed and verified?
- Derive safety requirements. Translate safety goals into specific, verifiable system, hardware, and software requirements.
- Design to requirements. Implement architectural and design measures that satisfy those requirements.
- Verify and validate. Prove that the implementation satisfies requirements and that requirements satisfy safety goals.
- Maintain traceability throughout. Every requirement must be traceable from hazard to design to test evidence.
Step 7 is where most programs encounter serious operational difficulty—and it is where the discipline intersects most directly with requirements engineering tooling.
The Requirements Management Challenge in Functional Safety
Functional safety is not primarily a technology problem. It is a documentation and traceability problem backed by engineering substance. Certification assessors—whether TÜV SÜD auditing an ISO 26262 program or an FAA DER reviewing DO-178C compliance—are looking for evidence that:
- Every identified hazard led to a safety goal.
- Every safety goal led to one or more functional safety requirements.
- Every functional safety requirement was allocated to a system, hardware, or software element.
- Every allocated requirement was tested or otherwise verified.
- The verification result is linked back to the requirement it covers.
In a simple system, you might be able to track this in a spreadsheet. In any realistic product—a vehicle with 100+ ECUs, a Class C medical device with thousands of software units, a flight control system with hundreds of DO-178C objectives—a spreadsheet becomes an active liability. Requirements change. Tests are updated. Design decisions are revised. Keeping a manual Requirements Traceability Matrix (RTM) consistent across those changes is both a full-time job and a significant source of compliance risk.
The traditional toolchain for managing this problem is dominated by IBM DOORS and DOORS Next, Polarion, and Jama Connect. These are legitimate, capable tools with deep installed bases in regulated industries. DOORS in particular has decades of deployment in automotive and aerospace programs and carries integrations with major simulation and verification environments. Jama Connect has a clean web interface and solid review workflow support. Polarion integrates requirements and ALM in a single platform that many teams find useful.
The limitations of these tools tend to cluster around the same issues: they are document-centric or structured around folder hierarchies that do not naturally represent the graph structure of a safety case; they require significant administrative overhead to configure and maintain; and their AI capabilities are largely retrofitted rather than native to the underlying data model.
How Modern Tools Handle Functional Safety Requirements
The underlying structure of a functional safety case is a directed graph. Hazards point to safety goals. Safety goals point to safety requirements. Safety requirements point to design elements. Design elements point to test cases. Test cases carry pass/fail results. If any edge in that graph is broken—a requirement without a covering test, a design element without a traced requirement—you have a compliance gap.
Tools that model requirements as nodes in a graph rather than rows in a document or items in a folder hierarchy make that structure visible, queryable, and auditable in ways that document-centric tools cannot match.
Flow Engineering is built on exactly this graph-native model. It is designed for hardware and systems engineering teams working in regulated domains, and its traceability architecture reflects the structure that functional safety standards actually require. Safety requirements, hazard records, design specifications, verification results, and test cases can all exist as linked nodes with typed relationships—the kind of relationships that map directly to the traceability chains auditors look for.
Where Flow Engineering is particularly relevant to functional safety programs is in the application of AI to requirements quality. Functional safety requirements must be unambiguous, complete, and verifiable—qualities that are easy to state and hard to enforce across a large requirement set authored by multiple engineers over months or years. Flow Engineering applies AI analysis at the requirement level to surface ambiguity, missing verification criteria, and inconsistencies that would otherwise surface during a certification audit at the worst possible time.
The platform is also built for the cross-disciplinary nature of functional safety work. A single ASIL D function in an automotive program involves system engineers who own the HARA, hardware engineers who own the hardware safety requirements, software engineers who own the software safety requirements, and test engineers who own the verification evidence. Flow Engineering’s model supports that multi-stakeholder workflow without forcing all of it through a single document or review queue.
It is worth being direct about scope: Flow Engineering is not a one-stop certification tool. It does not generate compliance documentation in formats pre-approved by specific notified bodies, and it does not replace the domain expertise required to conduct a HARA, assign ASILs correctly, or make architecture decisions that satisfy SIL targets. What it replaces is the manual, fragile, spreadsheet-based RTM and the ad hoc link management that causes programs to discover traceability gaps during third-party audits rather than during development.
Practical Starting Points
If you are beginning to engage with functional safety—whether starting a new program or auditing an existing one—four things determine most of your early decisions:
1. Identify which standard applies. The sector determines the standard. If you are building automotive E/E systems, ISO 26262 applies. If you are writing software for an IEC 60601 medical device, IEC 62304 applies. If your system crosses sectors (a medical robot with autonomous navigation, for instance), you may need to engage multiple standards and document how conflicts are resolved.
2. Complete the hazard analysis before doing anything else. Every downstream decision—SIL/ASIL/DAL assignment, architecture choices, testing rigor—flows from the hazard and risk analysis. Starting software development before the HARA is complete is a common program management error that creates expensive rework.
3. Set up traceability infrastructure before the requirement set grows. It is dramatically easier to establish a traceability model with 50 requirements than with 5,000. The tool choice matters less than the decision to model relationships explicitly from the start.
4. Plan for change. Requirements in safety-critical programs change—because the hazard analysis is updated, because the system architecture changes, because a supplier changes a component. Your traceability infrastructure needs to make the impact of a requirement change visible immediately, not discoverable after the fact during a review.
Functional safety is one of the most demanding disciplines in systems engineering precisely because it requires that rigor be applied consistently, documented completely, and defensible to an external assessor who did not build the system. The standards exist not to create bureaucracy but because the cost of getting it wrong is measured in lives. The engineering teams that execute it well treat requirements traceability not as a compliance overhead but as a core engineering practice—because in functional safety, the two are the same thing.