eSOL Blog

Delivering Safety of Automobiles Through Standards: SaFAD Beyond ISO 26262, and the Role of Software Platforms

Jan 31, 2022 8:23:12 AM

Eleven automobile-related companies released a paper named "Safety First for Automated Driving" (SaFAD) on July 2, 2019. 

The document summarizes widely known safety by design, and verification and validation (V&V) methods of SAE L3 and L4 automated driving. This summary, explains the document, is required for maximizing the evidence of a positive risk balance of automated driving solutions compared to the average human driving performance.

1. SaFAD paper


Cover of SaFAD paper (Click to access PDF file of SaFAD paper)

The interesting part of this definition is that it doesn’t target “zero fault”, but a safer driving than the average human. While zero accidents are impossible anyway and targeting fewer accidents often means increasing costs, such a target is a fair compromise to reduce accidents that are caused today by the average human driver and are therefore accepted already to some degree by society. For example, in Europe annual road accidents causing deaths in 2020 remain between 18 and 85 per million residents depending on a country. The main root cause remains human error despite the introduction of countless driver assistance systems.


  1. SaFAD paper
  2. Typical standards related to automobile safety
  3. ISO 20077 Road Vehicles - Extended vehicle (ExVe) methodology
  4. ISO/SAE 21434 Road Vehicles - Cybersecurity engineering
  5. SAE J3061_201601 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems (2016-01-14)
  6. Safety First for Automated Driving-Overview (SaFAD)
  7. References

After the publication of the SaFAD paper, its ISO version ISO/TR 4804:2020 was published in December 2020. A Technical Report (TR) is, by definition in ISO/IEC Directives Part 1, a collection of informative data that doesn’t contain normative elements (contrary to an International Standard (IS), which does). Standardization in ISO is not only driven by the industry, but by other stakeholders like consumer groups for example. These groups can voice their needs and opinions too, especially with regard to “what is an acceptable risk and what is not”. This is one of the most difficult questions to answer, and seeking standardization is one of the best ways for society to find an agreement.

Before we get into these documents, we need to clarify the underlying basis, which are mainly safety standards that have been previously developed and established.

2. Typical standards related to automobile safety

First, let's check the typical standards related to automobile safety. There are many of these, and the main ones are summarized in ISO/PAS 21448: 2019 Table 1 (which includes some additions).


Cause of hazardous event

ISO 26262


Cyber Security



E/E System failures





Performance limitations or insufficient situational awareness, with or without reasonably

foreseeable misuse





Reasonably foreseeable misuse, incorrect HMI

(e.g. user confusion, user overload)




See also European statement of principle on the design of Human-Machine Interface (HMI)

Hazards caused by the system technology




Specific standards

External factor

Successful attack exploiting vehicle security





ISO 21434 or SAE J3061

Impact from active Infrastructure and/or vehicle to vehicle communication, external devices

and cloud services.




See also ISO 20077:2017 Extended vehicle (ExVe)

Impact from car surroundings (other users, ISO

“passive” infrastructure, environmental conditions: weather, Electro-Magnetic Interference...)





1) ISO/PAS 21448: Road Vehicles – Safety of the intended functionality (SOTIF), but up to Level 2 defined in the Levels of Driving Automation in SAE J3016.

Table 1: Typical standards related to automobile safety and their coverage
Source: ISO/PAS 21448:2019, Table 1 (reformulated by the author)

ISO 26262 Road vehicles - Functional safety

ISO 26262 is a functional safety standard for automobiles that was first published in 2011; a revised version, sometimes called the “second edition”, dates from 2018.

This standard covers only the definition of "functional safety" (ISO 26262-1:2018 Clause 3.67) and "Absence of unreasonable risk due to hazards caused by malfunctioning behavior of Electrical/Electronic systems". It covers physical casualties caused by malfunctions of the electrical and electronic systems of automobiles, which could affect the intended behavior and lead to unintended behavior.

The SaFAD paper states the following about ISO 26262 in sec. 2.1.4
(ISO/TR 4804 has its summary in clause 5.2.2):

  •  "The first edition of ISO 26262 was created based on the knowledge of state-of-the-art systems in automotive industries (such as steering, braking and airbag systems, etc.) and does not adequately address very complex and distributed systems. Furthermore, there is no clear methodology that covers the need for availability to uphold safety.
  • The second edition resolves some of these issues but fails to address many others. Thus, interpretations are needed, and some of the issues that should be resolved include:
    • Addressing the gaps in the first and second editions of ISO 26262 to devise solutions for availability requirements
    • Missing automotive architecture models in ISO 26262, e.g. for failure rates estimation as described in other standards such as IEC 61508
    • Exiting and reused architecture elements are designed with fail-safe behavior. Thus, the new system designs should create fail-operational or fail-degraded behavior
    • Decomposition of the given architecture elements to achieve the required ASIL
    • Definition of the functional and architecture elements necessary to achieve the required ASIL."

ISO/PAS 21448: 2019 Road Vehicles - Safety of the intended functionality (SOTIF)

This was published as a Publicly Available Specification (PAS) in 2019 as a supplement to ISO 26262. On the aspect of systems, it covers lack of consideration for performance limits and situations, reasonably foreseeable misuse and inappropriate HMI (e.g., user confusion and overload) As for external factors, the PAS lists influences from the surroundings of the vehicle e.g., other users, passive infrastructure, environmental conditions such as weather and EMI.

Safety of the intended functionality (SOTIF) is defined as "there is no unreasonable risk of hazards due to functional deficiencies in the intended functionality or reasonably foreseeable misuse by humans" (ISO/PAS 21448: 2019 Clause 3.10).

For this purpose, and according to ISO 26262, the following activities must be carried out in parallel with the safety life cycle:

  1. Description of functional and system specifications (intended functionality content) (Clause 5)
  2. Identification and evaluation of hazards caused by the intended functionality (Clause 6)
  3. Identification and evaluation of triggering events in driving scenarios that initiate system responses that can lead to hazardous events (Clause 7).
  4. Functional modifications to reduce SOTIF related risks (Clause 8)
    Here ends the left side of the V-model development process.  
  5. Definition of the verification and validation strategy (Clause 9)
    Here starts the right side of the V-model development process.
  6. Verification of the SOTIF (Clause 10)
  7. Validation of the SOTIF (Clause 11)
  8. SOTIF Release (Clause 12)
However, the current version targets driving automation level 1 and level 2 as defined in SAE J3016_2016091(=no autonomy in the systems), and therefore it is necessary to consider additional measures for level 3 and above (ISO/PAS 21448: 2019 Clause 1 scope). Also, although this document has a description of the framework, it does not provide more specific criteria as the SaFAD paper does.

1Automated1 driving level in SAE J3016: The next versions of J3016_201806 and J3016_202104 have been published after J3016_201609 referenced in ISO/PAS 21448, but there is no major change in the definition of the level of driving automation.

3. ISO 20077 Road Vehicles - Extended vehicle (ExVe) methodology

Part 1 was published in 2017 and Part 2 was published in 2018 to ensure safe and secure access to vehicle data from the outside2.

2External: Active V2X communication (to infrastructure, to other vehicles), external devices, cloud services

4. ISO/SAE 21434 Road Vehicles - Cybersecurity engineering

It is a cyber security standard for automobiles. Its FDIS3 (Final Draft International Standard) was released in May 2021 and the IS was released in August 2021.

3Stage Code: Refer to the ISO website. The development of ISO usually follows the following flow (though some items may be omitted): PWI (Preliminary Work Item) ⇒ NP (New Work Item Proposal) ⇒ WD (Working Draft) ⇒ CD (Committee Draft) ⇒ DIS (Draft International Standard / Enquiry Draft) ⇒ FDIS (Final Draft International Standard) ) ⇒ IS (International Standard).

The SaFAD paper also discusses the need to balance security and safety, and in particular that the behavior of active safety mechanisms must be deterministic (section 2.1.5); in addition we must consider availability (section 2.1.2).

This balance between security and safety is possibly one of the most challenging topics in the actual development field, and it isn’t only limited to security-related topics: an easier example may be found in safety aspects. For example, some people might say: “a watchdog reset disturbs realization of fail-degraded behavior and also can be an attack vector to disable security measures, so such a watchdog reset is not an option”. But the important question of “who will monitor the monitoring mechanism and how?” is forgotten. Such trade-off decisions over multiple mutually contradicting problems are difficult to make, and experts in every field bring forth their own minute arguments. There are no ‘almighty’ solutions, of course.

Those who act as "integrators" of experts’ verdicts may apply some conflict resolution protocol such as prioritization, which may be reusable (because of difference of the contexts), or which doesn’t exist yet. Standards such as SOTIF and advice from other integrators can help, but at the end, the integrators have to reach to a conclusion – often through a trial-and-error process. People with 20/20 hindsight may then provide better solutions, but such an outcome is unavoidable. We have to live with an open mindset; be willing to correct wrong decisions from the past; and be ready to learn from the problems, as well as sharing them with others4.

4Integrators: Some people simply say that integrators should be versatile, but they need time to develop, and there are few ways to nurture or teach them.

In the first place, it is questionable whether everything can be fulfilled by single fighter (Figure 1 shows the ideal “requirements” to AUTOSAR-based ECU software integrators who are also expected to deal with new technologies and requirements; actually the author received these requirements from various experienced people through various projects, but obviously impossible to fulfill them by single person). That is why a system like the CCB (Change Control Board) is necessary. However, if the members don't display responsible behavior (with the cancellation of the project as one of the options), there will be "no real responsible decisions".


Figure 1: What does an "ideal" integrator look like? 
Source: Created by the author, 2020

5. SAE J3061_201601 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems (2016-01-14)

This recommended practice was published in 2016 and provides guidance for vehicle cybersecurity (note: an updated version J3061_202112 was published very recently). It was created and expanded based on existing practices implemented or reported in industry, government, and conference proceedings. It is intended for use in the vehicle industry as well as for other cyber-physical vehicle systems (e.g., commercial and military vehicles, trucks, buses).

This recommended practice establishes a set of overarching guiding principles for cybersecurity as it relates to cyber-physical vehicle systems including:

  • Defining a complete cybersecurity process framework for the full product lifecycle
  • Providing information on some common tools and methods used in development, verification, and validation
  • Providing basic guiding principles for vehicle system cybersecurity
  • A basis for further standards development activities

6. Safety First for Automated Driving-Overview (SaFAD)

The Safety First for Automated Driving-Overview (SaFAD) paper was released to the public on July 2, 2019. SOTIF only covered SAE's autonomous driving level 2 and provided just the framework. However, the paper proposes measures to achieve Level 3 and Level 4 with some more concrete form.

SaFAD Overview and Chapter 1

Chapter 1, "Introduction & Motivation”, presents the following “Twelve Principles” of autonomous driving (sec. 1.3.2). SaFAD does not number each principle, so we have numbered it for convenience in Table 2. And “PSC_nn” appears in ISO/TR 4804. In the ISO version, better categorization was introduced: PSC_01 to PSC_05 are for automated vehicles and related aspects, PSC_06 to PSC_08 are for automated driving systems, and PSC_09 to PSC_12 for human factors.

SaFAD Principles Principle (sec.1.3.2 in SaFAD/clause 4.4.3 in ISO/TR 4804) 

1. Safe Operation (PSC_05)

1a. Dealing with Degradation

If a safety-related function or system component falls into a dangerous state (e.g., failure), the automated driving system (ADS) transitions to a safety condition/state while keeping the system in equilibrium for the operator. Ensuring a sufficient time frame for safe control transitions

1b. Fail-Operational (limited to the safety-related function or component)

The loss of safety-related functions or system components shall not lead to a safety-related situation

2. Operational Design Domain


2a. ODD Determination

As soon as system limits that restrict the safe functionality of the automated system are recognized, the system shall react to compensate or shall issue a driver takeover request with a sufficient time frame for the takeover

2b. Manage Typical Situations

The ADS must consider the situations that are generally expected in ODD and address possible risks

3. Vehicle Operator-Initiated Handover


Activation and deactivation of the ADS requires explicit instructions from the operator with a high degree of confidence in its intention

4. Security


When providing an automated driving system, steps shall be taken to protect the automated driving system from security threats

5. User Responsibility




To promote safety, the user’s state (i.e. state of alertness) must be suitable for a responsible takeover procedure. The system should be able to recognize the user’s state and keep them informed about their responsibilities concerning the required user‘s task. It should also be able to inform the respective operator about safety-relevant driving situations in unmanned driving services. MODE AWARENESS The automated function must ensure that the currently active driving mode can be recognized explicitly and unmistakably at any time. In addition, a change in driving mode must be clearly apparent to the user as well.

5a. Responsibility

The aspects of the driving task which remain under the user’s responsibility must be clear to the user.

5b. Mode Awareness

The automated function must ensure that the currently active driving mode can be recognized explicitly and unmistakably at any time. In addition, a change in driving mode must be clearly apparent to the user as well.

6. Vehicle-Initiated Handover


6a. Minimal Risk Condition

If the vehicle operator does not comply with a takeover request, the automated driving system must perform a maneuver to minimize risk, resulting in a minimal risk condition. This maneuver depends on the situation and the current performance of the automated driving system.

6b. Takeover Requests

Vehicle-initiated handovers shall be clearly understandable and manageable for the vehicle operator.

7. Interdependency Between the Vehicle Operator and the ADS


The overall evaluation of system safety needs to take effects on the driver due to automation into account, even when they occur immediately after the period of automated driving has ended and when a direct link to the automated driving part of the journey can be drawn.

8. Safety Assessment


Verification and validation shall be used to ensure that the safety goals are met so as to reach a consistent improvement of the overall safety.

9. Data Recording


Automated vehicles shall record the relevant data pertaining to the status of the automated driving system when an event or incident is recognized in manner that complies with the applicable data privacy laws.

10. Passive Safety


10a. Crash Scenarios

The vehicle layout should accommodate modifications to crash scenarios resulting from vehicle automation.

10b. Alternative Seating Positions

Occupant protection shall be ensured even when the customer has new uses for the interior that are made possible through automated driving systems.

11. Behavior in Traffic


11a. Manners on the Road

The behavior of the automated function needs to not only be easy-to-understand for surrounding (vulnerable) road users, but also predictable and manageable.

11b. Conforming to rules

The applicable traffic rules are to be taken into account by the automated driving system. The above principle “User Responsibility“ describes the remaining user responsibilities.

12. Safe Layer


The automated driving system shall recognize system limits, especially those that do not allow the safe transition of control to the vehicle operator, and react to minimize the risk.

Table 2: The Twelve Principles in SaFAD paper
Source: SaFAD paper section 1.3.2 (corresponding to ISO/TR 4804:2020 clause 4.4.3)

SaFAD Chapter 2

This chapter "Systematically Developing Dependability to Support Safety by Design," requires fail-safe and fail-degraded behavior for autonomous driving. It explains dependable capabilities (FS_1 to FS_7 and FD_1 to FD_65 (section 2.1 and 2.2.1), shown here in Table 3, along with specific elements for implementing them (section 2.2.2) and the overall picture of its general logical architecture (section 2.3 Figure 26).

5FS is an abbreviation for fail-safe capabilities, and FD is an abbreviation for fail-degraded capabilities. In addition, FD_7 also appears in Figure 33 later, but unfortunately, there is no explanation in the text.




Determine location


Perceive relevant static and dynamic objects in proximity to the automated vehicle


Predict the future behavior of relevant objects


Create a collision-free and lawful driving plan


Correctly execute and actuate the driving plan


Communicate and interact with other (vulnerable) road users


Determine if specified nominal performance is not achieved


Ensure controllability for the vehicle operator


Detect when degraded performance is not available


Ensure safe mode transitions and awareness


React to insufficient nominal performance and other failures via degradation


Reduce system performance in the presence of failure for the degraded mode


Perform degraded mode within reduced system constraints

Table 3: SaFAD-Fail-safe and fail-graded capabilities required for autonomous driving
Source: SaFAD paper section 2.1 and 2.2.1 (corresponding to ISO/TR 4804:2020 clause

It is not easy to design an argumentation scheme for achieving safety from scratch. It requires construction of a framework of arguments for acquiring this attribute, architectural elements to implement it, and the overall structure. However, with this basic framework, it will be relatively easy to build various supporting frameworks (e.g., to support automation of conventions and arguments).

Note that, ISO version changed FD_6 a bit (actually SaFAD version of FD_6 specifies measures somehow too specific).

SaFAD Chapter 3 and Chapter 4

Chapter 3 is "Verification and Validation” (V&V).

Section 3.1 shows the "functional design iteration process" like here in Figure 2 as a SOTIF-specific V&V activity, that runs in parallel with traditional V&V activities (QM, or safety-related but up to SAE Level 2).

functional design

Figure 2: Iterative process of functional design
Source: SaFAD paper sec. 3.1, added and created based on Figure 29

Through this iterative process, the scenario is to improve safety by advancing the response to known unsafe scenarios. Of course, that doesn't mean zero risk:

"100% reliability of the system and 100% confidence in a given level of reliability are not possible due to the complexity and time variance of the system and the corresponding uncertainties. Thus, there will remain some small risk of crashes. The concept of residual risk. has already been accepted for a long time now (see the rollout of airbags or new medicines)."

The idea of ​​residual risk has already been accepted for many years (as seen in the introduction of airbags or new drugs to the market, for example), but not always - especially in some Asian countries. As written here, it suggests that there is a certain acceptance of residual risks but the development team must be motivated to reduce the risk as much as possible while knowing that zero risk is not achievable. Therefore, in section 1.2, "the positive risk balance in relation to the average driver profile" is referred to as a candidate of the starting point and overall goal.

Section 3.2 lists the five items as key challenges for V&V of L3 and L4 systems, shown here in Table 4.




Statistical demonstration of system safety and a positive risk balance without driver interaction


System safety with driver interaction (especially in takeover maneuvers)


Consideration of scenarios currently not known in traffic


Validation of various system configurations and variants


Validation of (sub) systems that are based on machine learning

Table 4: SaFAD—Five major challenges to achieve Level 3 and Level 4 autonomous driving.
Source: SaFAD paper section 3.2 (corresponding to ISO/TR 4804:2020 clause 6.3)

Section 3.3 provides a variety of information about the V&V approach, 3.4 on the quantity and quality of the tests, and 3.5 on the simulation.

Also, section 3.6 describes element-by-element V&V. For example, the power supply should be redundant, and it has been said that tests for each individual power supply system are sufficient for systems up to level 2, but for levels 3 and above, additional power switching operations can be tested. Specific measures such as necessary are also shown.

In section 3.7, the use on site is explained on a certain number of pages.

Chapter 4 mentions that the V&V process and additional details based on the content of the SaFAD paper are currently being developed for ISO. As mentioned before, the "ISO/TR 4804 Road vehicles - Safety and cybersecurity for automated driving systems - Design, verification and validation methods", which is already published, represents a good example.

How to approach platforms and standards as seen from the concept of SaFAD

Now various standards which provides conceptual aspects and guidelines are available. But for real projects, they have to be translated and broken down into concrete activities and work products (materialization and embodiment of highly abstracted concepts and guidelines).

Here, also standards may help us. In general, more concrete and effective approaches can be demonstrated if some standard architecture for the "Applications" were given, especially for the non-competitive domains. In AUTOSAR, unfortunately Application Interfaces (AI) of the AUTOSAR Classic Platform (CP) are not really often used nor successful for long time, and while AUTOSAR AP provides some, but only for very limited area.

However, logical and physical architectures can be envisioned (and further developed into design patterns and standards) outside of AUTOSAR and for various architectural layers. For example, the "AD/ADAS Vehicle Control Interface Specification Ver.1.0 (ST-AVI-1)" was proposed and released to the public on the JASPAR website on March 13, 2020 by the JASPAR AD/ADAS Vehicle Control IF WG. The specification later became supported in AUTOSAR R20-11 for CP in 2020, too. This kind of outcome may also serve as such a “basis”. And, if similar outcomes were to happen in the future, the number of standardized mechanisms that can be provided by software platforms (including tool assistances) would, by default, increase.

At the same time, however, it quickly becomes apparent that it is not enough to just create or choose an "assumption" on interfaces.

In general, there are various options for architectural design, such as breaking down of requirements, allocation of requirements to architectural elements and identification of interfaces to realize the system. Furthermore, the same applies to its more meta-architectural hierarchy model6.

6Meta-architectural hierarchical model: For example, when breaking down the entire mobility system to a single piece of software, one might consider the following hierarchical structure (this is just an example, in practice a thinned down version would be used).

  • Overall mobility system
  • Mobility system "characters/elements" (e.g. vehicle, infrastructure, traffic participants)
  • Vehicle system domain
  • Vehicle ECU
  • Subsystems in ECU (e.g. processor)
  • In processor (e.g. virtual machine, a collection of virtual hardware and software in a processor)
  • Clusters in the software
  • Modules of the software (e.g. SW-C and BSW in AUTOSAR CP)
  • Components in modules of software

As for the last item, "components in software modules," for example, the need for further breakdown to standalone software and the appropriate configuration will differ greatly between RTOS and CRC library functions (depending on the type of module near the final "end"). Therefore, it is difficult to set a uniform standard, but it will be possible to define it on a case-by-case basis as the final "end" is materialized.

On top of these "assumptions" such as the meta-hierarchical model and the actual architectural structure, "concrete" design assets will be built, and they will be expanded by standardizing and sharing design patterns, etc.

But as mentioned earlier, there may be many architecture possibilities. If the "assumptions" need to develop that architecture remain state-of-the-art or at least still alive, we can draw on our invested development efforts over an extended period. However, if those "assumptions" are no longer relevant – for example, because standards are updated or new ones are introduced – then much of the investment made in a development platform can end up being wasted, as assets such as source code or software in the loop test bench become unusable. Standards and standardization remain an abstract yet essential basis for the development of relevant majority assumptions into which long-term investment can then be made.

7. References

[1] European Commission: Press release, 20 April 2021

[2] ISO 26262: 2018 Road vehicles - Functional safety (all parts)

[3] ISO/PAS 21448: 2019 Road Vehicles - Safety of the intended functionality (SOTIF)

[4] Safety First for Automated Driving (SaFAD paper) (2019-07)

[5] Japanese source: Ministry of Land, Infrastructure, Transport and Tourism Automobile Bureau Automobile Safety Technical Guidelines (2018-09-12)

[6] ACEA Strategy Paper on Connectivity (2016-04)

[7] Japanese source: Ito: European trends regarding the utilization of automobile data JARI Research Journal (2018-05-01)

[8] Japanese source: Autonomous Driving Business Study Group Cyber ​​Security Measures for Autonomous Driving Systems (2019-06-26)

[9] AVs: Bringing Standards Together for Safety, EE Times Asia (2020-04-21)


Based on the original article by Tsuyoshi Sakurai (in Japanese): 自動車の“安全”を考える、ISO 26262の先にある「SaFAD」にどう対応すべきか


Marketing Communications team