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.

Content

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).

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)

¹Automated1 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 outside².

²External: 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 FDIS³ (Final Draft International Standard) was released in May 2021 and the IS was released in August 2021.

³Stage 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 others⁴.

⁴Integrators: 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.

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_6⁵ (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).

⁵FS 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.

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 5.2.5.2)

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).

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.

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 model⁶.

⁶Meta-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」にどう対応すべきか

E.V
Marketing Communications team