What Is Functional Safety (FuSa)? Standards, Lifecycle, and Where Programs Fail

When the UK’s Health and Safety Executive (HSE) looked into what caused the 2005 Buncefield oil depot explosion, it traced the failure to two safety functions that didn’t work. A tank gauging system had been failing intermittently for months, and the independent high-level switch designed to shut things down was inoperable. Neither problem had been tracked or addressed, and Tank 912 eventually overflowed, ignited, and produced one of the largest peacetime explosions in Europe.

Functional safety exists to stop this kind of failure, where Electrical, Electronic, and Programmable Electronic (E/E/PE) safety-related systems behave in ways that put people at risk. The discipline connects hazard identification to risk reduction through defined engineering processes and verifiable evidence. This guide covers what functional safety requires, how its lifecycle works, the standards that govern it across industries, and where compliance programs commonly fail.

What Is Functional Safety (FuSa)?

Functional safety is part of overall safety, and it depends on E/E/PE safety-related systems working correctly. IEC 61508, the cross-industry base standard, defines requirements for these systems with the goal of reducing unacceptable risk from system malfunctions. The scope covers the sensor, the control logic, the communication path, the final actuator, and any safety-related actions taken by a human operator.

The line between functional safety and general product safety comes down to which hazards belong in each analysis. A railway level crossing barrier is a useful example, where the control logic that lowers it as a train approaches is a functional safety concern, while the barrier’s resistance to vehicle impact is governed by material properties and structural design. Every safety function then carries two categories of requirements, the function requirements that describe what it does (drawn from hazard analysis) and the integrity requirements that describe how reliably it performs (drawn from risk assessment).

The Role of Functional Safety in Reducing System Risk

Functional safety reduces risk by requiring that safety functions bring equipment to a safe state when hazardous conditions are detected. In automotive engineering, that risk reduction belongs in the control system design itself, decided alongside the architecture rather than added on later.

How Functional Safety Reduces Hazards to Acceptable Levels

Each identified hazard runs through the same sequence. Hazard and risk analysis determines how much risk reduction is needed to reach tolerable levels, and safety functions are then specified to deliver that reduction. A Safety Integrity Level (SIL) or Automotive Safety Integrity Level (ASIL) is assigned to each function based on how much reduction it has to provide.

Development, verification, and validation requirements scale with that rating. A brake system rated ASIL D carries different engineering obligations than a lower-criticality function, because the integrity target dictates the rigor.

Where Functional Safety Failures Cause the Most Damage

The consequences of functional safety breakdowns are well documented across regulated industries. The Takata airbag recall, the largest automotive recall in U.S. history, stemmed from propellant degradation that ruptured inflators during deployment and has been linked to dozens of U.S. deaths and hundreds of injuries.

In medical devices, the Therac-25 radiation therapy machine dropped its predecessor’s hardware safety interlocks and relied entirely on software safety. Major radiation overexposure accidents followed, and the Food and Drug Administration (FDA) eventually declared the device defective and ordered Atomic Energy of Canada Limited (AECL) to notify sites, investigate the failures, and submit a corrective action plan.

In each case the evidence chain was incomplete or disconnected from the engineering decisions that drove the design. The failure modes were identifiable from the artifacts already in place, but nothing tied them together into a picture an engineer could act on before the harm occurred.

How Regulators Evaluate Functional Safety Evidence

Regulators don’t only look at final artifacts when evaluating safety evidence. In aerospace, development assurance guidance requires teams to demonstrate that their software assurance processes have no unresolved deficiencies affecting certification objectives.

Auditors can request evidence that issues found during development were formally tracked and closed. Medical Device Reporting helps regulators and manufacturers identify potential device problems and informs investigations, corrective actions, or recalls. ISO 26262 requires verification and validation activities throughout development and specifies defined work products that auditors can check against.

Functional Safety Standards by Regulated Industry

Each regulated industry applies functional safety through domain-specific standards adapted from IEC 61508. The classification systems across these standards aren’t numerically equivalent, and treating them as interchangeable is a direct compliance error.

IEC 61508 as the Cross-Industry Foundation for Functional Safety

IEC 61508 covers safety-related systems built around electrical, electronic, or programmable electronic devices. Its two core concepts are the safety lifecycle and Safety Integrity Levels.

SIL ratings run from SIL 1 (lowest) to SIL 4 (highest), and each corresponds to a quantified probability of dangerous failure. At SIL 4 in low-demand mode, the required failure rate represents a substantially greater risk-reduction target than the lower bands.

ISO 26262 and ASIL Ratings in Automotive Functional Safety

ISO 26262 is the automotive adaptation of IEC 61508 principles. It covers electrical and electronic systems in series production road vehicles, and later editions broadened the vehicle classes while excluding mopeds. ASIL ratings come out of Hazard Analysis and Risk Assessment, which combines three parameters.

1. Severity (S): How serious the harm could be if it occurs, up to life-threatening or fatal outcomes.
2. Exposure (E): How often the hazardous situation arises during normal operating conditions.
3. Controllability (C): How readily the driver or system can avoid the harm once the hazard appears.

The resulting scale runs through Quality Management (QM, meaning no functional safety requirements), then ASIL A, B, C, up to ASIL D as the most stringent classification. ASIL and SIL are assessed separately and can’t be directly correlated.

Functional Safety Standards Across Medical Devices and Aerospace

IEC 62304 defines lifecycle processes for medical device software development, including Software as a Medical Device (SaMD). It defines three software safety classes graded by the severity of possible harm, with Class A covering no possible injury and Class C covering possible serious injury or death. IEC 60601-1, the overarching medical electrical equipment safety standard, explicitly refers to IEC 62304 for software lifecycle requirements.

DO-178C governs airborne software through five Development Assurance Levels (DAL). Level A, associated with catastrophic failure conditions, carries substantially stricter independence requirements than lower levels like Level D, even though it adds only a small number of additional objectives compared with Level B. The standard was developed jointly by the Radio Technical Commission for Aeronautics (RTCA) Special Committee 205 and the European Organisation for Civil Aviation Equipment (EUROCAE) Working Group 71, and it uses its own DAL system rather than SIL ratings.

How the Functional Safety Lifecycle Works

IEC 61508 defines a safety lifecycle covering concept, development, operation, and decommissioning, with verification and functional safety assessment in every phase. The lifecycle maps to the V-Model, where each development phase on the left has a corresponding verification and validation activity on the right.

Run Hazard Analysis and Risk Assessment

Hazard Analysis and Risk Assessment (HARA) is the starting point for the entire lifecycle, and its outputs set the rigor for everything that follows. Those outputs are the safety goals and their SIL or ASIL ratings, assigned based on how much risk reduction each function has to provide.

A typical run identifies hazards using a Hazard and Operability Study (HAZOP) with structured guidewords like “no flow” or “high pressure,” evaluates component failure modes through Failure Modes and Effects Analysis (FMEA), and uses Fault Tree Analysis (FTA) to trace top-level hazards down to contributing faults for higher-criticality classifications. Doing this work early enough to inform the architecture is what keeps the expensive rework off the schedule, since hazards uncovered after the architecture is locked in often force changes to ratings and safety mechanisms.

Determine SIL and ASIL Targets

SIL determination uses methods defined in IEC 61508, with options that include fully quantitative probability calculations, semi-quantitative approaches like Layer of Protection Analysis (LOPA), and qualitative risk graphs. The right method depends on how well the failure modes can actually be quantified.

Once a target SIL is assigned, the design has to satisfy three checks. The probability of dangerous failure must fall within the SIL band, the hardware fault-tolerance rules for that band must be met, and the process evidence must demonstrate development capability, with the third check existing because software systematic failures can’t be quantified probabilistically the way hardware failures can.

Verify, Validate, and Assemble the Safety Case

The V-Model traces every hazard down through safety goal, functional safety requirement, technical requirement, implementation, and verification. Verification confirms the system was built correctly, while validation confirms the right system was built in the first place.

A functional safety case ties these together with three elements that work in concert. The safety requirements describe what must be safe, the safety arguments connect those requirements to evidence, and the evidence itself includes work products like FMEA and FTA results, test reports, traceability matrices, configuration management records, and residual risk assessments.

Common Functional Safety Compliance Challenges

Teams that know the standards inside out can still struggle to produce audit-ready evidence on demand. The day-to-day discipline of keeping the evidence chain connected across years of development is where programs underestimate the work, even when the documentation looks clean at every snapshot.

Disconnected Requirements and Safety Evidence

When safety requirements, design artifacts, test cases, and risk items live in disconnected systems, the evidence chain that every standard requires can’t be maintained as work happens. It ends up getting reconstructed in the weeks before an audit, often by people who weren’t in the room when the original decisions were made.

Aerospace guidance explicitly addresses this by allowing auditors to ask for evidence that process deficiencies found during development were formally tracked and closed. A package assembled retroactively can rarely show that paper trail with the granularity an auditor expects.

Late-Stage Hazard Discovery and Rework Cycles

Software-related recalls in regulated industries frequently surface defects introduced or missed during post-production change management rather than gaps in the original design pass. Inadequate management of changes after release tends to be a recurring driver. DO-178C’s front-loaded rigor aims to head off that pattern by forcing more decisions up front.

Detailed requirements discipline pushes those decisions earlier and reduces deferred questions. That up-front work cuts down missing requirements and the rework that drives most late-stage hazard discovery.

Multi-Standard Compliance and Audit Readiness

Teams building products that span multiple regulatory domains face compound documentation obligations. An automotive semiconductor supplier may need to satisfy ISO 26262, IEC 61508, and Automotive SPICE (ASPICE) at the same time.

ISO 26262 compliance has also become a supply chain qualification factor, putting substantial process documentation obligations on suppliers alongside Original Equipment Manufacturers (OEMs). Aerospace teams using model-based development workflows face additional evidence work under DO-178C’s DO-331 supplement, which adds to the documentation load.

How Jama Connect® Supports Functional Safety

Jama Connect® is a requirements management and verification platform built for engineering teams in regulated industries like automotive, medical, and aerospace. For functional safety work, it maintains Live Traceability™ across hazards, safety requirements, design artifacts, tests, and verification evidence, so the chain regulators expect stays current as the design changes.

That live trace chain is what addresses the disconnected-systems problem most safety programs run into, since suspect link management surfaces the impact of every change as designs evolve. Pre-built industry frameworks aligned with ISO 26262, IEC 61508, and IEC 62304 give safety teams a starting compliance workflow rather than an empty template, and Jama Connect also holds TÜV SÜD validation for safety-related development.

Keeping the Functional Safety Evidence Chain Live

Functional safety programs succeed when hazard analysis, engineering decisions, verification, and change control stay connected across the entire development cycle. Maintaining the evidence chain continuously is what lets a team walk into an audit with the trace already in place. The same continuous habit also makes regulatory updates and supplier changes easier to absorb when they come.

Jama Connect is a requirements and risk management system that keeps safety requirements, hazards, design artifacts, and verification evidence linked as designs evolve, so the trace chain regulators expect stays current instead of getting rebuilt under deadline. Teams ready to put that chain in place can start a free 30-day trial of Jama Connect.

Frequently Asked Questions About Functional Safety

What is the difference between functional safety and general product safety?

Functional safety covers hazards from how a system behaves, while general product safety covers hazards in the physical design itself. The metal strength of a pressure relief valve is a product safety concern, while the control logic that opens it under pressure is a functional safety concern governed by IEC 61508.

How do ASIL and SIL ratings differ in practice?

IEC 61508 sets SIL targets quantitatively using probability-of-failure measures, while ISO 26262 sets ASIL ratings qualitatively through a risk graph of severity, exposure, and controllability. The two systems aren’t numerically equivalent, so a component qualified for one scheme doesn’t automatically satisfy the other.

Is functional safety required for software-only systems?

Yes, every major standard has dedicated software provisions, including IEC 61508-3, ISO 26262 Part 6, IEC 62304, and DO-178C. Software failures can’t be quantified probabilistically like hardware ones, so the standards rely on process rigor, which Jama Connect helps safety teams maintain across requirements and verification.

What does a functional safety case need to include?

A safety case combines three elements, the safety requirements, the arguments connecting those requirements to evidence, and the evidence itself, including hazard analysis records, FMEA and FTA results, the traceability matrix, test reports, configuration records, and tool qualification artifacts. Keeping all of it linked as one live trace chain is the workflow that Jama Connect supports — safety teams can start a free trial to put that chain in place.

This article was authored by Mario Maldari and published on May 15, 2026.