Linkedin-inYoutube
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
      • Assurance of AI-based Tools
    • Physical AI
      • Robotics Safety
      • Assurance of AI-based Tools
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Automotive
    • Physical AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
Let's Talk
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
      • Assurance of AI-based Tools
    • Physical AI
      • Robotics Safety
      • Assurance of AI-based Tools
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Automotive
    • Physical AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
Let's Talk
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
      • Assurance of AI-based Tools
    • Physical AI
      • Robotics Safety
      • Assurance of AI-based Tools
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Automotive
    • Physical AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
logotype
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
      • Assurance of AI-based Tools
    • Physical AI
      • Robotics Safety
      • Assurance of AI-based Tools
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Automotive
    • Physical AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
ISO 26262 Challenges for ADS: Item Definition and HARA
08/07/26
0 Likes

ISO 26262 Challenges for ADS: Item Definition and HARA


This article examines challenges in applying ISO 26262 to SAE Level 4 Automated Driving Systems (ADS) without human fallback, focusing on item definition and controllability within the Hazard Analysis and Risk Assessment (HARA). It also considers functional decomposition, fail-operational design, minimal risk conditions, and end-to-end AI architectures. It was written by a senior SRES safety expert with nearly 20 years of automotive engineering and management experience, including functional safety leadership, successful mass-production launches, and involvement in standardization activities related to ISO 26262, ISO 21448, and ISO 8800.

Looking to go deeper? Explore SRES ISO 26262 Functional Safety Training and ISO 21448 SOTIF Training. Need more than training? Learn how our Autonomous Product Development consulting supports the safety and assurance of ADAS and automated driving systems.


Functional Safety and ADS

ISO 26262 was written at a time when Automated Driving Systems (ADS) did not yet exist. Consequently, some of its concepts are difficult to apply directly to SAE Level 4 autonomous vehicles. This blog examines several of these challenges and discusses practical interpretations for ADS development. For the purpose of this discussion, we consider an SAE Level 4 ADS without a human driver as a fallback.

First, we’ll examine the item definition. Then we address an often-discussed aspect in hazard analysis and risk assessment: controllability for ADS. For human-driven vehicles, controllability assumes a capable driver. In an ADS without human fallback, however, this assumption no longer applies, raising fundamental questions about how controllability should be interpreted.

Item Definition

Unlike conventional E/E systems with clearly bounded functions, ADS integrates perception, planning, and control into a virtual driver function. Traditionally, Items as defined by ISO 26262 provide a function to the human driver.

ISO 26262-1:2018 defines:

item

system or combination of systems, to which ISO 26262 is applied, that implements a function or part of a function at the vehicle level

vehicle function

behaviour of the vehicle, intended by the implementation of one or more items, that is observable by the customer

An item provides a vehicle function that manifests observable vehicle behavior by the customer. This mapping is straightforward for functions such as steering, braking, or illumination, all of which support a human driver.

This highlights the challenge:

How can a meaningful item definition be constructed when an ADS does not provide a function to a driver, because the ADS is the driver itself?

On a sidenote, the term “customer” in the definition of vehicle function is arguably vague and should be expected to evolve in future revisions of ISO 26262 (e.g., “road user”).

Let’s explore some possible options for dividing the ADS Item into vehicle functions. We’re assuming the ADS command output is provided to a base vehicle with steering, braking, engine, and body control ECUs. The following illustration only shows signals very selectively for simplicity; its focus is to show the function distribution.

Three ADS item definition proposals showing a virtual driver system, a Sense-Plan-Act architecture, and an Apollo Auto reference architecture

ADS Item Proposal 1 is equivalent to the level 1 abstraction layer in ISO 21448:2022, Figure 9. The complete ADS is abstracted into a system.

ADS Item Proposal 2 is equivalent to the level 2 abstraction layer in ISO 21448:2022, Figure 9. The ADS is shown with the next level of detail, separated into Sense-Plan-Act.

ADS Item Proposal 3 provides further detailed architecture using the Apollo Auto framework as a reference model.

ADS Item Proposal 2 may be most suitable, because – usually – all 3 functions are distinct systems

  • Sense: Perception sensors are commonly a combination of cameras, radar and lidar
  • Plan: High performance compute, which creates trajectories
  • Act: Translates the trajectories into motion commands

Fail-operational capability – the ability to continue operation in the presence of faults – becomes essential for an L4 ADS. In traditional automotive E/E systems, graceful degradation into a non-working state (“fail-safe”) was often sufficient because the driver retained controllability through mechanical steering and braking systems.

For an L4 ADS, the impact of an E/E failure and the resulting hazards must still be analyzed, but the analysis is no longer tied to a single traditional vehicle function such as steering support with a mechanical fallback. Many E/E failures now have the potential to result in loss of the virtual driver altogether if not sufficiently mitigated.

This warrants redundancy patterns in lower requirement levels such as

  • Redundant cameras with overlapping views. Failure of one camera may reduce confidence in object detection in certain regions while still allowing continued operation long enough to pull over safely.
  • Multiple compute platforms that allow continued operation after a hardware failure. In some cases, the vehicle may even complete its mission and return unoccupied to a depot before shutting down.

Beyond reducing E/E failure risk, the characteristics of ADS components are also highly relevant for nominal performance – the domain of ISO 21448, SOTIF. This leads to measures such as:

  • Multiple sensor modalities (e.g., camera, lidar, radar)
  • Combination of long-range and short-range sensing
  • Constraints related to perception latency, sensor fusion latency, and compute performance

What used to be Safe States with focus on the Item and Vehicle Function within the ISO 26262 context are becoming now Minimal Risk Maneuvers (MRM) and Minimal Risk Condition (MRC) such as in-lane stoppage, vehicle pull-over to the side of the road or continue operation. Those are now focused on the vehicle behavior rather than the traditional vehicle functions such as steering or braking.

Safe state as defined by ISO 26262-1:2018

safe state

operating mode, in case of a failure, of an item without an unreasonable level of risk

MRM and MRC as defined by ISO 23793-1:2024

minimal risk manoeuvre

MRM

manoeuvre by an automated driving system while performing the DDT fallback to attain the minimal risk condition

minimal risk condition

MRC

stable, stopped condition to which a user or an automated driving system may bring a vehicle after performing the dynamic driving task fallback in order to reduce the risk of a crash when a given trip cannot or should not be continued

ISO 23793-1:2024 titled “Intelligent transport systems – Minimal risk manoeuvre (MRM) for automated driving” provides a dedicated framework for in-lane and shoulder stoppage of ADS vehicles.

What About End-to-End ADS AI Models?

What about L4 ADS architectures based on end-to-end (E2E) AI models? The alternate term pixel-to-control describes its meaning: One large AI model is directly connected to sensors on one side and providing control outputs such as steering, braking, and accelerating on the other end.

The methodology outlined above remains applicable. The implementation does not necessarily need to mirror the functional decomposition used for the Item Definition and hazard analysis. Even if the ADS is implemented as an E2E AI model, the safety argument can still be structured around capabilities such as perception, planning, control, and resulting vehicle behavior. The safety argument must take into account E/E failures in the underlying systems (computer processing cores, memory, power supplies, sensor hardware, software) that implement the E2E solution.

HARA: Controllability for ADS

The Item Definition serves as an input to the Hazard Analysis and Risk Assessment (HARA), which introduces its own challenges for ADS.

To create the HARA, we identify potential malfunctions of the Item and map those to vehicle-level hazards. Those are combined with operational situations.

To perform the HARA, potential malfunctions of the Item are identified and mapped to vehicle-level hazards. These hazards are then combined with operational situations.

For example:
Unintended excessive vehicle longitudinal deceleration while vehicle is operating on a highway in dry road conditions with a trailing vehicle present.

These hazardous events are evaluated against

  • Severity (S): severity of potential harm
  • Exposure (E): probability of being exposed to the operational situation
  • Controllability (C): ability of the driver or other persons to avoid the harm

This raises a fundamental question for L4 ADS: what do we do with controllability when there is no driver?

Controllability as outline in ISO 26262 3-6.4.3.8:

The controllability of each hazardous event, by the driver or other persons involved in the operational situation shall be estimated based on a defined rationale for each hazardous event. […]

One possible argument is that electronics can control a vehicle far better than humans in terms of reaction time and the ability to react based on precise physical measurements. However, this argument is based on the wrong premise. Controllability in ISO 26262 is meaningful for systems such as SAE L1 Automatic Emergency Braking (AEB), where the system assists a human driver. This reasoning no longer applies to ADS operating without human fallback. An L4 ADS does not contribute to the controllability of a driver – it is the driver.

Returning to the ISO 26262 definition of controllability, as the driver is removed from the definition, only “other persons involved in the operational situation” remain. In the absence of a driver, this includes passengers, pedestrians, cyclists, and other road users.

The ISO 26262 controllability scale ranges from:

  • C0: controllable in general
  • C1: simply controllable
  • C2: normally controllable
  • C3: difficult to control or uncontrollable

How controllable is an L4 ADS-equipped vehicle for surrounding road users? A passenger may be able to change the destination or request a stop but generally has no immediate control over the driving action itself. Therefore, a reasonable default assumption is that controllability of vehicles with ADS should initially be assessed as C3, because the vehicle behavior is typically uncontrollable by road users.

Nevertheless, C3 should not become a blanket assumption for every hazardous scenario. For example, a following vehicle may still retain some controllability in avoiding a rear-end collision. Controllability therefore remains scenario-dependent, even for ADS.

Another important distinction is that the consequences of E/E failures can vary significantly depending on vehicle occupancy. In conventional passenger cars, a human is always present – the driver at minimum-. This assumption no longer holds for ADS. Passenger vehicles may operate empty while repositioning to a depot or traveling to pick up occupants. Likewise, an autonomous truck may transport goods without anyone present in the cabin. The more scenario-dependent presence of road users impact both the harm model and the controllability considerations.

The controllability assumptions for traditional ECUs responsible for steering, braking, propulsion, or other vehicle actuation functions do not necessarily change simply because they are integrated into an L4 ADS-equipped vehicle. When performing the HARA for these systems, it is often appropriate to assess controllability as though the ADS were the “driver,” analogous to the human driver in a conventional vehicle.

Future considerations of FuSa for ADS

The approach described above provides a practical interpretation of the functional safety item and controllability challenge for ADS. Different organizations may apply different methodologies as there is no guidance from existing standards. Future revisions such as ISO 26262 Edition 3 or adjacent technical specifications may eventually provide more standardized guidance.

Need support applying functional safety to ADS? Explore our Autonomous Product Development consulting to learn how SRES supports organizations in developing functional and technical safety concepts, performing HARA, building safety cases, and defining verification and validation strategies.


Have insights or questions? Send us an email at info@sres.ai or leave a comment below—we welcome thoughtful discussion from our technical community.

Interested in learning more about our approach? Explore why teams choose SRES training and how we support organizations with consulting for automotive and physical AI applications.


SRES SafeStack | August 2026

08/03/26
SRES SafeStack | August 2026

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Insight Categories

  • Functional Safety46
  • Responsible AI31
  • Robotics & Physical AI11
  • Autonomous Systems24
  • Cybersecurity7
  • Electric Mobility3
  • Videos14
  • News22
Most Recent
  • ISO 26262 Challenges for ADS: Item Definition and HARA
    ISO 26262 Challenges for ADS: Item Definition and HARA
    08/07/26
  • SRES SafeStack | August 2026
    SRES SafeStack | August 2026
    08/03/26
  • From UCAs to Test Scenarios: Building a Coherent Validation Pipeline for AVs
    From UCAs to Test Scenarios: Building a Coherent Validation Pipeline for AVs
    07/28/26
  • SRES Fireside Chat: Validation and Data in AI-Driven Systems
    SRES Fireside Chat: Validation and Data in AI-Driven Systems
    07/22/26
  • Comparing ISO/IEC TR 5469 and ISO/IEC TS 22440
    Comparing ISO/IEC TR 5469 and ISO/IEC TS 22440
    07/21/26
logotype
  • Company
  • Careers
  • Contact Us
  • info@sres.ai
  • 265 Dillon Ridge Rd
    Ste C PMB 505
    Dillon, CO 80435

Services

Automotive

Physical AI

Responsible AI

Training

Resources

Insights

Video

Legal

Privacy Policy
Cookie Policy
Terms & Conditions
Training Terms & Cancellation Policy
Accessibility
Consent Preferences

© Copyright 2026 SecuRESafe, LLC. All rights reserved.

Linkedin Youtube