Author: Aimee
Problems in the traditional electronic and electrical field can be solved through functional safety. However, with the development of autonomous driving technology and the implementation of algorithms, image recognition, and other content, ensuring the absence of faults in the system is no longer sufficient to meet the safety requirements of autonomous driving. Due to the high complexity of the autonomous driving system itself, our designed features may have limitations or defects, which further leads to the occurrence of safety accidents. The concept of SOTIF (Safety Of The Intended Functionality) attempts to solve these problems.
The expected standard for SOTIF in the industry is ISO/PAS 21448, which is mainly used to cope with more complex systems and working conditions in the field of driving assistance/autonomous driving. Different from functional safety, if the function failure is caused by related EE architecture failure or hardware failure, it falls into the category of functional safety (ISO 26262). If it is caused by design limitations of some systems, such as the misidentification of sensors or the driver’s misoperation, leading to incorrect interpretation of some scenarios, it falls into the category of SOTIF (ISO/PAS 21448).
This series of articles will introduce how the three domains of SOTIF, functional safety, and network security can work together and how to combine them to create a reliable system.
Firstly, this article introduces each domain and derives reliable autonomous driving functions from a safety premise. Then, it provides elements that can be used to achieve these expected functional safety designs. Finally, by introducing a universal logical architecture to combine all the elements to ensure the completeness of the expected functional safety design.
Legal Framework for Autonomous Driving Cars
In 2018, the Ministry of Industry and Information Technology of the People’s Republic of China issued the “National Automobile Industry Internet Standard System (Intelligent Connected Vehicles) Construction Guide,” to comprehensively strengthen top-level design and enhance the intelligent and interconnected R&D process of autonomous driving cars. The second version of the ISO 26262 general standard for functional safety is mature, and the changes include a more stringent design of the whole vehicle structure and functional architecture to support more complex automotive electronic systems. The newly released ISO/PAS 21448 standard specifies the development process for analyzing, verifying, and confirming non-fault scenarios and system use cases, which is commonly referred to as the expected functional safety development process. However, ISO/PAS 21448 is mostly biased towards L1 and L2 advanced driving assistance systems. In practical applications, this standard needs to be expanded to L3 and even L4 applications.Implementing safety standards ISO/PAS 21448, ISO 26262, and ISO/SAE 21434 allows for their procedures and methods to be combined. The development of ISO/PAS 21448 aims to address risks and severity levels caused by intended functions, including foreseeable misuse. Risks caused by E/E system failures are addressed using functional safety of established global ISO 26262 standards, while risks caused by intentional manipulation are evaluated from a security perspective of ISO/SAE 21434. These standards complement each other and are primarily used to define design risks for autonomous driving systems, empowering engineering teams with the ability to design safe mechanisms and enhance expected functionalities to mitigate identified risks. Based on the needs of the development organization, it is possible to independently develop the necessary standard content and consider the interdependencies between such standards in this process.
Existing standards do not provide solutions for some of the most problematic topics in autonomous driving systems, such as ensuring the safety of artificial intelligence (with the most relevant algorithms originating from the fields of machine learning and neural networks), human factors and psychology, and the technical capabilities of sensing devices used as inputs for autonomous driving systems. However, applying security-related use cases can ensure the necessary security levels. These analyses systematically assess the potential hazards caused by intended use and foreseeable misuse in functional descriptions. In addition to a secure design and development process, testing and verification are also ensured in an iterative manner. This process requires expert assessment, security analysis, and phased testing. Different standards support this process based on their scope.
Principles of expected functional safety design of autonomous driving
When activating the function of autonomous driving vehicles, risks based on functionality and system boundaries should be evaluated. Performance limitations (such as those imposed by sensors) can lead to malfunctioning behavior, which may lead to dangerous situations. Development standards help developers manage the complexity of the system, estimate potential risks, and take appropriate measures. Finally, available standards are used to establish a sufficient correlation between the safety and usability of the system.
For most applications, using ISO 26262 for usability has limitations. Designing a secure system is a process of balancing risk and application usability. When the risk is too high, the system design would be too conservative, and its system usability will become very low (security mechanisms that achieve sufficient integrity may compromise usability objectives), which will not be able to provide a safer and more comfortable customer experience. Conversely, if the design criteria for system security are too lenient, the system’s security may not meet the necessary level, but the system’s usability can be guaranteed. As shown in the figure below:
Therefore, from an analytical perspective, it will become increasingly important to design scene-based system behaviors to address system security issues and to design powerful and secure systems through the analysis of use cases and scenarios, thereby enhancing technical capabilities.
Usability is mainly affected by limitations in ODD, which can also result in overly conservative, complex, or flawed security design mechanisms and flawed system design. Diversity in patterns and redundant sensors may be insufficient. Poor human-machine interface design due to environmental factors and the resulting confusion of patterns or automation may also impair safety (the interdependence between vehicles). Ultimately, this evolves into a security concept that defines security mechanisms supporting security goals.
Deriving automated driving capabilities from the security analysis domain
To derive functionality from the reliability domain, the different international legal frameworks for autonomous vehicles must first be outlined to identify requirements beyond the 12 principles. These functionalities cover SOTIF (safety of the intended functionality) and functional safety for addressing human factors. Security work operates on both logical and technical architectures and provides input requirements for both. As no approved legal or international standardization for vehicle cybersecurity currently exists, this section offers suggestions on security approaches and measures.
Elements of Expected Functional Safety Design
The fundamental concept of SOTIF (safety of the intended functionality) method safety is to introduce an iterative functional development and design process that includes testing and verification, the result of which is declared as safe expected functionality. Some activities can be proven based on a methodology, which demonstrates that these activities are sufficient for developing safe automated driving functionalities.
The method assumes the existence of an area with known scenarios of safe system behavior, while an area of unknown scenarios has potential hazards. In practice, these areas of division are overlapping, as shown in the figure below. The described regions in the figure are defined as follows:
By definition, the remaining white area is safe and unknown.
Expected Functional Development Goals
The goal of automotive development is to reduce the potential for known and unknown potential anomalous behaviors to an acceptable residual risk level. Using the above model, the following development goals can be derived:
The white area is the assumed safe area which is irrelevant to the argument discussed in this paper. Nonetheless, the white area can also be reduced by decreasing area 3 or expanding area 1. Figure 5 visualizes the results by describing the development goals.
The following measures contribute to achieving development goals using this concept. These measures promote continuous iterative updates and process improvement. Since primary evidence can be provided through experimentation testing and validation activities, it is sufficient to prove that the system is safe enough for customers.
1. Area 1 (Strategy):
- Identify potential risks through analysis
- Redefine a system defect by discovery
First, it is necessary to define the functions to be developed and to use risk analysis methods similar to ISO 26262 (but not identical) to analyze function and technical specifications. If vulnerabilities are identified, the function or system will be improved.
2. Area 2 (Strategy):
Test the function system, including its system component implementation as follows:
- Simulate the functions, including their scenarios
- Test system components and the entire system
- Determine where the function or system can be improved in the presence of vulnerabilities
- Determine the basis for accepting residual risk
3. Area 3 (Strategy):
Validate the function system:
Reduce Area 3 to an acceptable level, for example, through endurance testing, driving testing, and simulation testing.
Expected Functionality Test Validation
Comprehensive system safety validation requires not only testing but also work such as quality audits during the development process or the implementation of technical analyses to design reliable systems. These together form the safety argument of an autonomous driving system. The assumed analysis of the car-to-car aspect of expected functional safety is roughly the same as for L0-L2 systems (see ISO 26262), but the complexity has increased.
Firstly, all requirements derived from safety through the design strategy need to be verified to have been fulfilled. This step ensures that known solutions are covered and the system operates effectively as expected. Therefore, the focus of validation is on easily tested requirements and sound safety checks that can be performed through the design process for systems that have been integrated into production vehicles for decades. For example, the drive-by-wire system uses a set of verifiable measures (such as redundant throttle pedal position sensors and redundant microprocessors running redundant software) to prevent unnecessary positive torque at the wheels. To conform to the designed principles and verifiable safety requirements, effective design and testing measures are needed for modern autonomous driving systems to ensure safe output.
As shown in the figure above, iterative testing may prompt improvements in function design, leading to new verification requirements. By addressing known unsafe conditions, this iterative process can improve confidence in safety and reduce its area.
SummaryThe article mainly discusses the safety strategy of unexpected functions related to autonomous driving, covering a comprehensive analysis from basic concepts, objectives, architecture, standards, and testing scope. The purpose is to lay a foundation for the analysis of the difficult points in the next section of the autonomous driving access process. This allows readers to have a deep and clear understanding of the key difficulties of expected function safety and provide necessary support for the design process of autonomous driving, supporting the smooth access of products.
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.