ISO 26262: Ensuring Functional Safety in Automotive Systems

Origins and Purpose

ISO 26262 was first published in 2011 as an adaptation of IEC 61508, the generic functional safety standard for E/E systems. Recognizing the unique challenges and requirements of the automotive industry, ISO 26262 provides a structured approach to ensure that automotive systems perform safely under both normal and fault conditions. The standard aims to mitigate risks associated with system failures, thereby protecting vehicle occupants, other road users, and the environment.​

Scope and Applicability

The standard applies to all activities during the safety lifecycle of automotive systems, including:

• Management of functional safety
• Concept phase
• System, hardware, and software development
• Production, operation, service, and decommissioning
• Supporting processes​

ISO 26262 covers passenger cars, trucks, buses, and motorcycles, excluding mopeds. It addresses potential hazards caused by malfunctioning behavior of E/E safety-related systems, including their interactions.

1. Production, operation, service, and decommissioning

2. Supporting processes

3. Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis

4. Guidelines on ISO 26262

5. Guidelines on application of ISO 26262 to semiconductors

6. Adaptation of ISO 26262 for motorcycles​

Each part addresses specific aspects of functional safety, providing detailed requirements and guidance for implementation

Functional Safety

Functional safety refers to the absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems. It involves identifying potential hazards, assessing associated risks, and implementing measures to mitigate these risks to acceptable levels.

🚦 What Is Functional Safety?

Functional Safety is the part of overall system safety that depends on a system or equipment operating correctly in response to its inputs, including the detection of faults and ensuring the system either continues operating safely or transitions to a safe state when a fault is detected.

In the automotive context (as per ISO 26262):

Functional safety is the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical and/or electronic systems.

🧩 Functional Safety vs. Overall Safety

• Overall Safety includes functional safety, but also covers mechanical, chemical, thermal, and environmental safety.
• Functional Safety specifically targets failures in E/E (electrical/electronic) systems, especially those controlled by software.

Example: Airbags deploying at the wrong time is a functional safety issue, whereas poor crash resistance due to weak materials is a general safety concern.

🚗 Why Is Functional Safety Important in Automotive?

Modern vehicles depend heavily on sensors, ECUs (Electronic Control Units), and software to perform critical tasks like:

• Braking (ABS, AEB)
• Steering (EPS, lane keeping)
• Acceleration control
• Battery management in EVs
• ADAS and autonomous driving features

A single failure in any of these systems could result in loss of control, crashes, injuries, or fatalities.

⚙️ Core Principles of Functional Safety

1. Fault Tolerance

Design systems that detect, isolate, and recover from faults.

2. Fail-Safe or Fail-Operational

• Fail-Safe: System shuts down or transitions to a safe state.
• Fail-Operational: System continues operating safely despite certain faults.

3. Hazard Analysis and Risk Assessment (HARA)

Identify potential hazards from malfunctioning behavior, evaluate risk (Severity, Exposure, Controllability), and assign ASIL levels.

4. Safety Lifecycle

From concept to decommissioning, all stages must consider safety:

• Phase: Concept – Functional Safety Focus: Hazard analysis, item definition
• Phase: System/Hardware/Software – Functional Safety Focus: Requirements allocation, design, testing
• Phase: Production & Operation – Functional Safety Focus: Safe installation, diagnostics, field monitoring
• Phase: Decommissioning – Functional Safety Focus: Safe retirement of system components

5. Safety Goals and Requirements

Each hazard leads to a safety goal, which is decomposed into Functional Safety Requirements (FSRs) and Technical Safety Requirements (TSRs).

🧠 Functional Safety by Example

Scenario: An adaptive cruise control (ACC) system accelerates and decelerates based on the distance to the car in front.

What Could Go Wrong?

• Radar sensor misreads distance.
• Software delay in braking command.
• Hardware fault in the braking actuator.

Functional Safety Measures:

• Redundancy: Backup sensors or brake controls.
• Diagnostic Checks: Self-tests, heartbeat signals.
• Safety Mechanisms: If sensor fails, disable ACC and alert driver.

🛡️ Functional Safety Techniques

Architectural Tactics:

• Redundancy (replicated hardware/software)
• Diversity (different implementations performing the same task)
• Watchdogs (monitor execution timing or output)
• Fail-safe states (stop vehicle safely)
• Graceful degradation (reduce functionality safely)

Safety Analysis Tools:

• FMEA (Failure Modes and Effects Analysis)
• FTA (Fault Tree Analysis)
• STPA (System-Theoretic Process Analysis)

🌐 Functional Safety Beyond Automotive

Although ISO 26262 is specific to automotive, functional safety applies across industries:

• Automotive – ISO 26262
• Industrial – IEC 61508
• Railways – EN 50126/50128/50129
• Medical Devices – IEC 62304
• Aviation – DO-178C, ARP4754

Safety Lifecycle

ISO 26262 defines a safety lifecycle that encompasses all phases of a product’s life, from initial concept to decommissioning. This lifecycle ensures that safety is considered at every stage, promoting a systematic approach to risk management.

🧭 What is the Safety Lifecycle?

The Safety Lifecycle defines a series of phases and activities that must be followed to manage functional safety systematically.

In ISO 26262, the Safety Lifecycle applies to all electrical and/or electronic (E/E) systems in road vehicles, and spans:

• Concept
• Development
• Production
• Operation
• Service
• Decommissioning

Each phase includes specific processes, work products, and safety considerations tailored to the maturity level of the product or system.

🧩 Safety Lifecycle Phases in ISO 26262

Here’s a breakdown of the phases defined in the ISO 26262 Safety Lifecycle:

1. Concept Phase ISO 26262-3

🧠 Focus: Identify potential hazards early.

• Item Definition: Define system boundaries, functionality, interfaces.
• Hazard Analysis and Risk Assessment (HARA): Evaluate hazards, assess severity/exposure/controllability.
• Safety Goals (SGs): Define high-level safety objectives based on hazards.
• ASIL Assignment: Classify safety goals based on risk.
• Functional Safety Concept: Propose safety mechanisms to achieve SGs.

✅ Output: Safety goals, ASILs, and the foundation for detailed requirements.

2. Product Development Phase

a) System-Level Development ISO 26262-4

🔧 Focus: Derive Functional Safety Requirements (FSRs) from safety goals.

• System Design: Functional and technical architecture.
• Allocation of FSRs to hardware/software components.
• Preliminary Safety Analysis (e.g., FMEA, FTA).

b) Hardware-Level Development ISO 26262-5

⚙️ Focus: Develop safe hardware architecture and components.

• Hardware Safety Requirements
• Safety Architecture (redundancy, diagnostics, watchdogs)
• Hardware Metrics (e.g., SPFM – Single Point Fault Metric)
• Failure Rate Analysis

c) Software-Level Development ISO 26262-6

💻 Focus: Implement safe, verified software systems.

• Software Safety Requirements
• Architecture Design (modular, fault-contained zones)
• Verification Activities (static analysis, unit tests)
• Tool Qualification (if tools impact safety)

🛑 Each development level must maintain traceability from safety goals down to implementation and test cases.

3. Production and Integration ISO 26262-7

🏭 Focus: Ensure safe manufacturing and integration of components.

• Manufacturing process control
• Hardware/software integration testing
• Validation against safety goals

4. Operation, Service, and Maintenance ISO 26262-7

🛠️ Focus: Ensure the system remains safe throughout its use.

• Field monitoring
• Error logging and diagnostics
• Updates and patches
• Service procedures (safe replacement, calibration)

5. Decommissioning Phase

♻️ Focus: Safe removal of components from service.

• Data erasure (especially for connected systems)
• Safe disassembly
• Hazard containment (e.g., for batteries)

🔁 Iterative and Cyclical Nature

The Safety Lifecycle is not strictly linear—phases may iterate or loop back due to:

• Design changes
• Fault discovery
• New safety insights
• Regulatory feedback

This makes the lifecycle adaptive and robust, supporting continual safety validation and improvement.

🗂️ Supporting Activities (ISO 26262-8)

• Configuration Management: Track changes over the lifecycle.
• Change Management: Ensure safety is preserved after modifications.
• Verification and Validation (V&V): Confirm that safety requirements are met.
• Tool and Library Qualification: Ensure development tools don’t introduce new risks.

📌 Key Concepts Across All Phases

• Concept: Traceability – Each safety requirement must link back to a safety goal.
• Concept: ASIL Tailoring – Safety efforts must match ASIL classification.
• Concept: Documentation – Safety case, test plans, analysis reports must be recorded and maintained.
• Concept: Independence – Certain tasks must be reviewed by independent teams (especially for ASIL D)

Automotive Safety Integrity Levels (ASILs)

ASILs are risk classifications assigned to safety goals, reflecting the severity of potential hazards. There are four ASILs: A (lowest) to D (highest), with an additional QM (Quality Management) level for non-safety-related functions. The determination of ASILs is based on three factors:​

• Severity (S): Potential impact of a hazard.
• Exposure (E): Probability of the operational situation occurring.
• Controllability (C): Ability of the driver to prevent the hazard.​

The combination of these factors determines the ASIL, guiding the necessary safety measures.

🚦 What is ASIL?

Automotive Safety Integrity Level (ASIL) is a risk classification system defined by the ISO 26262 standard. It’s used to quantify the safety criticality of an automotive function, specifically related to potential hazards that can arise from E/E (electrical/electronic) system malfunctions.

ASIL defines how stringent the development process needs to be for that function to ensure adequate risk mitigation.

🧮 ASIL Categories

ASIL is categorized into four levels of increasing safety requirements:

• ASIL Level A – Lowest degree of hazard – Criticality: Low
• ASIL Level B – Moderate hazard – Criticality: Moderate
• ASIL Level C – Significant hazard – Criticality: High
• ASIL Level D – Highest degree of hazard (most critical) – Criticality: Very High

There’s also a fifth classification:

• QM (Quality Management) – Not safety-related, but subject to standard quality control.
• QM implies that no special safety requirements are needed beyond standard quality management practices.

⚖️ How ASIL is Determined: The SEvE Process

ASIL levels are determined through Hazard Analysis and Risk Assessment (HARA), which evaluates hazards using three key factors:

1. Severity (S) – How severe are the consequences?

2. Exposure (E) – How often might the situation occur?

3. Controllability (C) – How easily can the driver control or mitigate the event?

The ASIL is derived using this 3-dimensional analysis, often represented as a lookup table (Severity, Exposure, Controllability → ASIL).

Example: Scenario: Sudden unintended braking on a highway.

• Severity: S3 (Could cause fatal crash)
• Exposure: E4 (Occurs frequently)
• Controllability: C3 (Difficult for driver to control)
• ASIL Result: D

🛠️ ASIL’s Role in Development

1. Tailoring Development Processes

ASIL affects every stage of product development:

• Requirements Specification
• Architecture and Design
• Verification & Validation
• Testing

The higher the ASIL, the more rigorous and formal the development process becomes. For example:

• Activity: Safety Analysis – ASIL A Basic FMEA / ASIL DFMEA + FTA
• Activity: Code Verification – ASIL A Code review / ASIL D Static analysis + formal methods
• Activity: Hardware Design – ASIL A Basic redundancy / ASIL D Fault-tolerant + monitoring
• Activity: Testing – ASIL A Unit testing / ASIL D Full traceable test coverage (MC/DC)

2. ASIL Decomposition

In complex systems, achieving ASIL D across all components might be overkill or impractical. ISO 26262 allows ASIL decomposition, where a high-ASIL safety goal is split into redundant lower-ASIL requirements under strict independence criteria.

Example:

A braking system might decompose a safety goal into two independent paths:

• One component at ASIL B
• Another component at ASIL C → Together, they satisfy the original ASIL D requirement.

🔄 ASIL Reuse and Tool Qualification

• Reused Software/Hardware: Components from earlier projects must show compliance to the required ASIL or be requalified.
• Tools (e.g., compilers, simulators): Must be qualified for use in ASIL-rated development depending on their impact and confidence level.

🚗 Real-World ASIL Examples

• Function: Infotainment System – Typical ASIL: QM
• Function: Rear-view Camera – Typical ASIL: ASIL A/B
• Function: Automatic Emergency Braking (AEB) – Typical ASIL: ASIL C/D
• Function: Electric Power Steering – Typical ASIL: ASIL D
• Function:Airbag Deployment System – Typical ASIL: ASIL D
• Function: Adaptive Cruise Control – Typical ASIL: ASIL C

🤝 ASIL and Cooperation in Modern Vehicles

• As highlighted in the attached research paper, traditional ISO 26262 focuses on individual vehicle systems. However, in cooperative driving scenarios like platooning, one vehicle’s malfunction can affect others.
• This reveals a critical gap — a function may be ASIL A in a solo vehicle but should be ASIL D in a cooperative context. Researchers suggest extending ASIL determination to account for system-of-systems effects in collaborative architectures.

🧩 Summary

• ASIL provides a risk-based framework for ensuring functional safety in automotive systems.
• It is central to ISO 26262, influencing how products are developed, tested, and maintained.
• Determining ASIL involves evaluating Severity, Exposure, and Controllability.
• Higher ASILs demand more rigorous processes, tools, and validation.
• In the era of cooperative driving, ASIL concepts are evolving to handle multi-vehicle dependencies.

HARA is a critical process in ISO 26262, conducted during the concept phase to identify potential hazards and assess associated risks. The steps involved include:​

1. Item Definition: Describing the system or function under consideration.

2. Hazard Identification: Determining potential hazards resulting from system malfunctions.

3. Risk Assessment: Evaluating hazards based on severity, exposure, and controllability.

4. ASIL Determination: Assigning ASILs to safety goals based on risk assessment.

5. Safety Goals: Establishing objectives to mitigate identified risks.​

This structured approach ensures that safety considerations are integrated early in the development process.

System-Level Development

At the system level, safety requirements are derived from safety goals and allocated to various system elements. This phase involves architectural design, interface definition, and validation planning to ensure that the system meets safety objectives.​

Hardware-Level Development

Hardware development focuses on designing components that meet safety requirements. Key activities include:​

• Hardware Safety Requirements: Defining specifications for hardware components.
• Failure Modes and Effects Analysis (FMEA): Identifying potential failure modes and their effects.
• Fault Tree Analysis (FTA): Analyzing the probability of system-level failures.
• Hardware Metrics: Evaluating diagnostic coverage and failure rates.​

These analyses ensure that hardware components contribute to overall system safety.​

Software-Level Development

Software development involves implementing safety requirements through coding and validation. Activities include:​

• Software Safety Requirements: Translating system-level requirements into software specifications.
• Software Architecture Design: Structuring software components to meet safety objectives.
• Verification and Validation: Testing software to ensure

Following system-level, hardware-level, and software-level development, the Production Phase is where validated designs are transformed into physical automotive products. This phase ensures that all manufacturing, assembly, and integration activities preserve the functional safety established during the design stages.

The Production Phase is governed by ISO 26262 Part 7, which emphasizes the importance of process control, equipment validation, and traceability in producing safety-compliant components and systems.

The key objective of the Production Phase is to maintain the integrity of safety requirements during the transition from development to physical realization. The safety performance proven in simulated or prototype environments must remain consistent, repeatable, and robust in mass production.

🔍 Key Activities in the Production Phase

✅ 1. Production Planning

• Define and document all manufacturing processes needed for each safety-relevant item.
• Include quality assurance processes, calibration protocols, and safety checks specific to ASIL-rated components.
• Specify production equipment, including automation, manual assembly, and inspection stations.
• Develop training programs to ensure production personnel understand the importance of safety-relevant processes.

🔧 For high ASIL levels (e.g., ASIL D), even minor assembly tasks must follow validated procedures with defined tolerances and traceable records.

✅ 2. Process Validation

• Validate manufacturing and assembly processes to confirm they consistently meet safety requirements.
• Use capability studies, pilot builds, and pre-production runs to identify process variability or failure risks.
• Evaluate measurement systems to ensure the precision and accuracy of inspections (Gage R&R).

✅ 3. Configuration and Change Management

• Maintain a configuration management system to control versions of safety-relevant hardware and software.
• Implement a change control process: any change in material, supplier, process, or equipment must be assessed for its impact on functional safety.
• Ensure changes are approved and validated before implementation, especially for ASIL-rated items.

✅ 4. Monitoring and Inspection

• Apply in-line testing, end-of-line (EOL) testing, and process monitoring to detect non-conformities in real-time.
• For ASIL C and D components, include additional safety checks such as: Voltage and continuity tests, Calibration of sensors and actuators, Functional testing of software-controlled ECUs
• Use automated test benches and traceable measurement systems to log and verify safety-critical behavior.

✅ 5. Documentation and Traceability

Maintain comprehensive production records:

• Serial numbers and batch IDs
• Inspection and test results
• Software version installed on each ECU
• Calibration data for safety sensors

Use this information to trace issues back to root causes during failures or field incidents.

✅ 6. Packaging and Delivery Controls

• Ensure that packaging and handling procedures protect safety-critical components during transport.
• Include electrostatic discharge (ESD) protection, temperature monitoring, and secure shipping protocols.
• Use unique identifiers and barcodes for traceable logistics and installation tracking.

📤 Output of the Production Phase

• Deliverable: Verified Safety-Critical Products- -Components manufactured according to safety specs
• Deliverable: Test and Inspection Reports – Evidence of successful validation and quality checks
• Deliverable: Configuration and Version Control – Documentation of hardware/software versions and updates
• Deliverable: Traceability Data – Full record of production process and component tracking

The Decommissioning Phase is the final stage in the ISO 26262 Safety Lifecycle. It ensures that safety-critical automotive systems and components are safely retired, removed from service, and disposed of, while preserving both environmental integrity and human safety.

While most functional safety efforts focus on preventing risks during system operation, the decommissioning phase addresses risks that may arise when a vehicle or system reaches the end of its operational life.

🎯 Purpose of the Decommissioning Phase

The primary goals of the decommissioning phase are to:

• Safely remove and deactivate safety-critical components.
• Prevent unintentional use of obsolete or degraded systems.
• Protect people, the environment, and assets during disassembly, storage, and disposal.
• Ensure no residual risks are introduced through dismantling or recycling.
• Fulfill regulatory, environmental, and data protection requirements.

🔍 Key Activities in the Decommissioning Phase

✅ 1. Identification of Safety-Relevant Components

• Mark or tag all parts that have safety-related functions, especially those associated with ASIL B, C, or D levels.
• Ensure dismantlers, recyclers, and service teams are aware of the safety roles of certain ECUs, sensors, or actuators.

Example: Battery management systems in EVs, airbags, and ADAS controllers.

✅ 2. Safe Power-Down and Isolation

• Define procedures for electrical isolation of high-voltage systems.
• Ensure software and hardware components are de-energized safely, avoiding any risk of residual energy release (e.g., from capacitors or HV batteries).

This is especially critical in hybrid or electric vehicles (HEVs, BEVs), where power systems may retain energy after shutdown.

✅ 3. Data Sanitization and Privacy Protection

• For systems with connectivity, location services, or driver profiles, data must be securely erased.
• ECUs, infotainment systems, and telematics modules may contain: personal data, driving history. diagnostic logs

ISO 26262 recommends secure data deletion mechanisms, particularly when functional safety intersects with cybersecurity (ISO/SAE 21434).

✅ 4. Dismantling and Removal Procedures

• Define how to remove safety-critical parts without triggering hazardous conditions.
• Use standardized tools and safety protocols during disassembly to prevent: electrical shocks, airbag deployment, release of pressurized gases

Document removal procedures in the service and maintenance manuals for certified technicians.

✅ 5. Disposal and Recycling

• Follow environmental regulations (e.g., EU End-of-Life Vehicle Directive, or local equivalents) for the safe disposal of materials like: lithium-ion batteries, printed circuit boards (PCBs), embedded sensors
• Ensure safety features (e.g., accelerometers, pressure vessels) are rendered inoperable before recycling.

✅ 6. Documentation and Compliance

Maintain records of decommissioning activities:

• Serial numbers of removed safety ECUs
• Proof of secure data deletion
• Chain of custody for hazardous components

Provide manufacturers and authorities with proof of safe disposal for auditing purposes.

🧩 Integration with Safety Lifecycle

While it is the last phase, decommissioning must be planned during the early lifecycle stages. For example:

• Architectural designs should include shutdown sequences and safe state transitions.
• Service documentation must include deactivation and removal procedures.
• Tools and equipment used for disassembly must be validated for safety.

🧠 Decommissioning Phase Overview

• Component Identification – Locate and tag safety-critical parts for controlled handling
• Safe Shutdown – Disable systems without triggering hazards
• Data Sanitization – Securely erase personal or operational data from ECUs
• Disassembly – Remove components using safe, documented methods
• Recycling and Disposal – Comply with environmental and material-specific regulations
• Documentation and Compliance – Log and certify the decommissioning process

Real-World examples for an autonomous vehicle:

• ECUs handling AI-based object detection may store historical video data and learning weights.
• Decommissioning must ensure the data is irrecoverably deleted, and the ECU is either securely recycled or returned to the OEM.
• The LIDAR and radar systems, if not properly shut down, may emit radiation during dismantling — a hazard to workers.