EPB Function Safety Note (20) Conclusion: Summary and Outlook of ISO26262

Author: YanZhi Automotive

With the original intention of “providing valuable reference for beginners of ISO 26262 and functional safety”, the “EPB System Functional Safety Notes” series of articles comes to an end.

Due to limitations of the author’s personal level, it is unclear how much the original intention has been achieved. However, there are two certain points: first, during the process of updating this series, the author has gained many new understandings while sorting out the understanding of functional safety; second, although the update process was as rigorous as possible, there are inevitably areas that are worth discussing or even mistakes in the articles. Experienced readers are kindly requested to understand and distinguish them.

As the conclusion of the “EPB System Functional Safety Notes”, the goal of this article is to stand from the global perspective of ISO 26262 and make a connection and summary of the key points in the development of functional safety; at the same time, in the current rapid development of intelligent driving and E/E system architecture, this article points out the limitations of ISO 26262 from a safety perspective and makes prospects.

It should be pointed out in advance that functional safety development activities run through the entire product safety lifecycle (management, development, production, operation, service, and scrapping), with a focus on development processes (including requirement specification, design, implementation, integration, validation, confirmation, and configuration), production processes, service processes, and management processes. However, the series of articles only focus on the development process because this article’s sorting is also based on the development process.

Summary of ISO 26262

1.1. Objectives of Functional Safety

The definition of “Functional Safety” in ISO 26262 is as follows:

absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.

Regarding this definition, some supplements need to be made to obtain a clearer understanding.

First of all, with regard to the “hazards” and “risks” mentioned in the definition, it can be associated with many understandings, such as personal injury caused by vehicle accidents, causing repair and property losses, and information privacy leakage. In functional safety, these two terms are related to “harm,” and an explanation is given:

Harm: Physical injury or damage to the health of persons.

It can be seen that the hazard expected to be avoided by functional safety is specific to the health injury to the driver, pedestrian, or occupants of other vehicles (note: not just the driver).Secondly, the automobile is a complex product that integrates many systems such as mechanical, hydraulic, chemical, and E/E, and the failure of each system can threaten the personal safety of the driver or passengers in surrounding vehicles.

For example, self-ignition of chemical batteries, loss of braking force caused by brake pipe leakage, insufficient strength of the A-pillar during collision, and steering control system failure leading to steering lock, etc. However, not all of these are within the scope of functional safety considerations. The research object of functional safety is only the “E/E system (electronic and electrical system)”.

From this perspective, if the product or vehicle meets the requirements of functional safety, it only means that the safety of the E/E system of the vehicle has been achieved. Other systems also need to meet corresponding safety designs to comprehensively improve the safety of automobiles.

Looking at it from another perspective, if the vehicle achieves the functional safety of the E/E system, can it be said that the E/E system has no safety risks at all? The word “unreasonable” in the definition gives a negative answer to this question.

Just like there is no perpetual motion machine in the world, there is no 100% safe system in the world. Functional safety pursues controlling risks within a reasonable or acceptable range, as shown in the figure below.

1.2 Quantifying the objectives of functional safety

Since functional safety pursues controlling risks within a reasonable range, it is necessary to first provide quantitative indicators for defining “reasonableness” in order to guide the development of functional safety. Quantifying the objectives of functional safety essentially consists of two steps:

• Determine unreasonable risks

• Define the criteria for reducing unreasonable risks to reasonable risks

1.2.1. Determine unreasonable risks

Regarding how to determine unreasonable risks, the EPB Functional Safety Notes (1): Harm Analysis and Risk Assessment (Theoretical Part) provides detailed explanations. Simply put, there are two steps:

Step 1: Determine all the hazards that all abnormal behaviors of the related items’ functions may cause to the entire vehicle

In this process, it is important to note: hazards should be defined based on conditions or behaviors observed at the level of the entire vehicle. Since hazards are defined based on behaviors observable at the level of the entire vehicle, it is necessary to first understand all possible motion behaviors of the vehicle. From the perspective of the overall vehicle dynamics, all the motion behaviors of automobiles can be accurately described using the motion coordinate system shown in the figure below.

In each coordinate system, all possible vehicle performances that may be caused by improper control can also be defined. The thought process is shown in the figure below.

Step 2: Analyze the risk based on the hazards and the scenarios in which they occur during vehicle operation.

This step corresponds to the “Classification of Hazardous Events” category. For example, there is a hazard involving the EPB (Electric Parking Brake) system and braking, where the caliper is erroneously engaged, resulting in unexpected braking of the vehicle. If this hazard occurs on a highway, it is likely to cause casualties. However, if the hazard only occurs when the vehicle is parked at a speed below 10 kph, there is no risk of causing casualties.

Therefore, functional safety needs to comprehensively analyze the risk caused by hazards by taking into account the scenarios in which the hazards occur during vehicle operation. The vehicle operating scenarios can be understood as a combination of the various factors shown in the following figure. In other words, the operating scenario is a combination of the road scenario and the driving scenario, such as “highway + straight-line acceleration” or “highway + straight-line braking”, etc.

After listing all the combinations of related scenarios and hazards, the next step is to classify and filter them to determine which risks are acceptable and which risks are not. ISO 26262 classifies and filters them based on three dimensions:

1. S (Severity): The level of injury that the hazardous event will cause to the driver, passengers, pedestrians or surrounding vehicles.

2. E (Exposure): The probability of the scenario occurring during daily driving.

3. C (Controllability): The probability that the driver or other people at risk can control the hazard to avoid injury.

Based on the comprehensive evaluation of these three dimensions, the Automotive Safety Integrity Level (ASIL) is determined, as shown in the following figure. ASIL D represents the highest safety integrity level and ASIL A represents the lowest safety integrity level. The QM (quality management) level means that ISO 26262 requirements can be met by following the company’s development process alone, without any other special requirements.

1.2.2. Definition of criteria to reduce unreasonable risks to reasonable risks

ISO 26262 requires that a safety objective be established for each hazardous event with an ASIL level.

For example, for the following hazardous event:

We can define a safety objective:

EPB should avoid errors in pressure build-up leading to excessive deceleration → ASIL C

In addition to ASIL levels, safety objectives have other attributes including FTTI, safe state, etc. The process of determining these attributes is the process of determining the safety criteria, which is the quantifiable measure of “reasonableness”.

1.3. Transforming Safety Objectives into Software and Hardware Development Requirements

As the highest-level (vehicle-level) functional safety requirement, safety objectives are actually a product of the conceptual layer. Safety objectives are fully defined without the need to know about the related system architecture, but achieving safety objectives requires relying on system architecture and its elements (such as software and hardware).

In other words, in order to achieve safety objectives, it must be combined with the system architecture to refine safety objectives into more specific functional safety requirements and allocate them to the elements (software and hardware, etc.) in the system architecture. This activity corresponds to the development of functional safety concepts and technical safety concepts, ultimately resulting in software/hardware functional safety requirements.

The process is explained in detail in “EPB Functional Safety Note (7) – EPB Safety Concept Analysis Example”.

In addition, in the process of assigning functional safety requirements to elements in the system, it is often encountered that:

• The functional safety requirement for an element is ASIL D or ASIL C, but only ASIL A or ASIL B can actually be achieved.ISO 26262 opened a “backdoor” called ASIL decomposition to reasonably avoid functional safety development deviations. ASIL decomposition is a cutting method that reduces the ASIL level of functional safety requirements. The core of this method is to decompose a functional safety requirement into two independent requirements and assign them to two or more independent elements (such as software modules, hardware modules, input signals, etc.).

Because these independent elements involved in the decomposition constitute a redundant relationship with each other, from the perspective of the entire system, safety goals will only be violated when these elements fail at the same time. Thus, the safety requirements for each related element involved in the decomposition can be reduced.

EPB Functional Safety Notes (16) – ASIL Decomposition and Key Points describe the key points of decomposition.

After confirming the safety requirements for software and hardware, requirements development and verification must follow the “V model”. ISO 26262’s functional safety requirements for software and hardware development are reflected in each step of the “V model”. In general, the higher the ASIL level, the higher the functional safety requirements for each step.

1.4. Safety Analysis

As previously mentioned, the goal of ISO 26262 is to reduce the risk caused by the abnormal performance of the E/E system’s functions within a reasonable range. The E/E system is composed of the most basic elements, namely software and hardware, and the abnormal performance of the E/E system’s functions is inevitably caused by the abnormal performance of software and hardware.

On the other hand, when the functional safety goals of the E/E system are converted into safety requirements for software and hardware, reducing the risk of the system within a reasonable range means controlling the abnormal performance (failure) of the software and hardware within a reasonable range to meet the corresponding safety requirements.

All failures of software and hardware can be classified into two types:

Random Hardware Failure: Non-expected failures that follow probability distribution during the hardware element’s lifecycle.

Systematic Failure: Failures that are related to a specific cause in a determined way. Eliminating this type of failure requires changes to design or production processes, operating procedures, documents, or other relevant factors (such as software bugs, hardware development manuals).According to the definitions of two types of failures given above, the failure characteristics of software and hardware can be summarized as follows:

• Software: only systemic failures exist.

• Hardware: both systemic and random hardware failures exist.

The different ASIL levels in the safety requirements for software and hardware functionality essentially reflect the degree of stringency with which the elements are required to avoid systemic and random hardware failures. The ability to assist and prove that software and hardware can avoid failure to meet safety requirements requires the help of safety analysis.

In simple terms, the purpose of safety analysis is to use analytical methods to achieve the following three objectives to prove that the product meets the requirements of ISO 26262:

• Failure must be fully identified.

• Systemic failures are effectively avoided.

• Random failures must be controlled within an acceptable range.

The ISO 26262-recommended method for analyzing systemic failures is Failure Mode and Effects Analysis (FMEA), which is comprehensively explained in “EPB Functional Safety Notes (8) – Introduction to FMEA Methodology” and “EPB Functional Safety Notes (9) – Expansion of FMEA Methodology – FMEA-MSR.”

For the analysis of random hardware failures, the method recommended by ISO 26262 is Fault Analysis Tree (FTA). For the failure rate of electronic components, the industry has a unified design specification and measurement indicators. Therefore, FTA is advantageous for electronic products not only for qualitative analysis, but also for quantitative analysis.

This is also an important reason why ISO 26262 recommends FTA. As the relevant content of random hardware failure is not easily understood, the series consists of 5 articles explaining this part in detail. For more information, please refer to the “EPB Functional Safety Notes (10) – EPB Functional Safety Notes (15).”

1.5 Functional Safety Verification and Confirmation

According to the “V-model” development process, after software/hardware requirements implementation, verification is required, and this process is called Functional Safety Verification and Confirmation.

The definitions of verification and validation are very close. In the functional safety national standard GB/T 34590, these two terms are translated as “verification” and “confirmation,” respectively. In fact, looking at these two terms alone may still give readers the impression of overlapping meanings.

The definition on Wikipedia for these two terms is very appropriate:- Verification: Have we achieved the intended result?

• Validation: Are we working towards the right goal?

By understanding the concepts of verification and validation in development, we can explain the following:

• Safety verification: Has the safety requirement for the function been implemented?

• Safety validation: Is the safety requirement for the function correct? That is, can implementing the safety requirement ensure safety?

According to this explanation, safety verification and safety validation belong to two different dimensions.

The safety verification of system/hardware/software-level safety requirements is recorded in sections 4/5/6 of the standard. The purpose of safety validation is:

• Provide evidence that the safety goal and safety criteria for the function are appropriate and suitable.

• Provide evidence that the safety goal is correct, comprehensive and fully achieved at the whole vehicle level.

Therefore, the purpose of “validation” in safety validation is to confirm whether safety goals and corresponding safety criteria are met.

In the article “EPB Functional Safety Note (18)-Functional Safety Verification and Confirmation”, the key points of functional safety verification and validation are explained in detail.

1.6 Functional Safety Assessment

After all functional safety development activities are completed, the product needs to be audited before it can be released for production. “ISO 26262, Part 2, Functional Safety Management” details the audit process and requirements, with the corresponding term being “confirmation measures.”

The main purpose of confirmation measures is to evaluate the functional safety development process and products to confirm whether they meet the requirements of ISO 26262. This evaluation needs to be conducted from three dimensions, as shown in the following figure.

The objects and purposes of the three dimensions are as follows:

In the “EPB Functional Safety Notes (19) – Understanding and Analysis of Confirmation Measures for Functional Safety”, the measures for the above three dimensions are analyzed and explained.

Outlook on ISO 26262

Looking at intelligent driving in 2021, it is undoubtedly a spectacular scene: emerging black technology, large and powerful entertainment screens, highly digitalized intelligent cabins, OTA remote upgrades are almost standard for new models, and ADAS assisted driving functions are becoming more and more abundant and practical. As for the ultimate goal of intelligent driving – autonomous driving, after the market frenzy has gradually cooled down, major manufacturers have redefined their autonomous driving plans. Smart cars are running towards the direction of convenience and liberating drivers.

However, in addition to bringing convenience to drivers, the core vision of smart cars is to reduce traffic accidents and create a better life for humanity. If the safety of drivers cannot be guaranteed while drivers are liberated, I personally think that the emerging black technology on smart cars is more of a luxury than a widespread significance.

The new E/E system and the software and hardware that make up the E/E system support these intelligent driving technologies. From this perspective, functional safety, which is committed to avoiding the failure of E/E systems and causing unacceptable risks, becomes more important.

However, is an E/E system that implements functional safety safe enough?

Let us first look at two recall cases.

1.7. Case 1

On March 19, 2020, due to failures in Autonomous Emergency Braking (AEB) systems, Volvo announced a recall of nearly 740,000 vehicles globally, involving 9 models. The reason for this recall is that in some scenarios, objects cannot be effectively identified, which leads to AEB not working when it is supposed to.

Generally, the AEB detects objects by fusing information from two key sensors: millimeter-wave radar and camera. Due to the Doppler effect, the millimeter-wave radar is not good at identifying static objects, while the detection capability of the camera will decrease in foggy weather or insufficient light. These factors may lead to the failure of correctly identifying objects in some scenarios and triggering AEB.Therefore, this recall was not caused by a system malfunction, but by the limited functionality of the sensor itself, which is not within the scope of ISO 26262. To compensate for this limitation, the expected functional safety SOTIF (Safety of the Intended Functionality) and the ISO 21448 standard were born.

Simply put, SOTIF emphasizes avoiding unreasonable risks due to the limited expected functional performance.

Because the background of SOTIF’s birth is the development of intelligent driving, if classified according to the functional chain of intelligent driving: perception-decision-execution, “functional performance limitations” is reflected in three aspects:

1. Sensor perception limitations leading to scene recognition errors

2. Insufficient deep learning leading to incorrect decision algorithm judgment for scenes

3. Actuator functional limitations leading to deviation from ideal targets

Currently, the ISO 21448 standard for SOTIF has been released in draft version and is scheduled to be officially released in March 2022.

1.8. Case 2

In July 2015, two American white hat hackers successfully invaded the CAN bus network system of a driving JEEP Cherokee SUV and sent incorrect instructions to the engine, gearbox, brakes, steering and other systems, eventually causing the vehicle to overturn on the slope by the side of the road. This case led to a massive recall of Jeeps.

The objects of functional safety and SOTIF research are failures that intelligent driving systems may produce, as well as another type of failure, which is hacker attacks.

To address this situation, information security, which has matured in the internet field, is being applied to automotive development. The higher the intelligence of intelligent driving, the more susceptible it is to attacks by hackers, and the greater the demand for information security.

It should be emphasized that functional safety and SOTIF focus on personal safety, but not all information security issues can lead to personal safety. In other words, in addition to considering personal safety, information security also needs to consider other risks brought by hacker attacks, such as property loss and privacy risks caused by vehicle theft.

# 2020 ISO 21434 Road Vehicle – Cybersecurity Engineering Standard Is Officially Released

The ISO 21434 standard on vehicle information security was formally released in 2020. It is a standard based on SAE J3061 and covers the entire life cycle of a vehicle. It mainly covers security management, project-based network security management, continuous network security activities, relevant risk assessment methods, and network security during road vehicle concept verification, product development, and post-development stages. The industry is still exploring how to implement this standard.

1.9. Outlook

It is foreseeable that with the development of intelligent vehicles, the safety of E/E systems will receive more and more attention. At the same time, ISO 26262 has exposed shortcomings in ensuring the safety of intelligent driving systems. Therefore, the safety of intelligent driving systems will inevitably need to be addressed from the following three aspects at the same time:

• Functional Safety

• Safety of the Intended Functionality

• Cyber Security

These three aspects are not completely independent but mutually influence each other. Therefore, how to better integrate functional safety with the safety of the intended functionality and cyber security is the issue that the industry is considering. It is also the most important direction for the future development of functional safety as the first industry-standard with the most experience.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.