Author: Aimee
The admission system for autonomous vehicles aims to provide legal support, prevent and respond to technological uncertainty challenges and seek the legitimacy of moral ethics for the marketization of autonomous driving. Currently, the research and production of autonomous driving functions have entered the white-hot stage, and each automaker’s investment in this field has also poured a lot of energy and capacity into it, which is also a must for listing. However, for laws and regulations, autonomous driving must obtain the relevant admission license issued by the Ministry of Industry and Information Technology on behalf of the Ministry of Transport to be recognized by the relevant society.
However, autonomous driving admission needs to fully consider all aspects of automotive research and development, most importantly, to ensure sufficient safety during the driving process, which requires fully considering the critical link at the beginning of the design: functional safety and expected functional safety. Failures and faults related to functional safety (usually referring to system-level function and function faults E/E faults) will cause incorrect steering or braking, which is considered the highest risk related to autonomous driving safety (usually can reach ASIL D). Defining safety functions and systems with functions developed based on the ISO PAS 21448 SOTIF method, including the first preliminary architecture, is the first step towards applying functional safety in accordance with ISO 26262 – creating project definitions. This project definition should include the definition of the function, including its dependence on the environment and other projects/vehicles and its interaction with the environment and other projects/vehicles. Based on the project definition, hazard analysis and risk assessment can be carried out to find the fundamental requirements or safety objectives of the function and its related systems. The next step is to develop functional and technical safety concepts.
Expected Functional Safety Analysis Capability for Autonomous Driving
The autonomous driving system must have a basic set of system attributes, which are defined here as functions. The functions necessary to declare the entire system as safe will be discussed below. These functions are divided into Fault Safety Functions (FS) and Fault Degradation Functions (FD). Fault safety functions can provide and implement customer value. Fault safety functions can be terminated because their safety-related unavailability is low enough or covered by fault degradation functions. Even in the event of a fault, fault degradation functions should be performed with a certain level of performance to provide a safe system within a specific time frame until the final minimum risk condition (MRC) is reached and allowed to be shut down. The selection matrix in the table below shows the integrity state of the exported capabilities to demonstrate the traceability of its design principles.
As we know, the design process of expected functional safety needs to solve the functional limitations or defects of the system design itself. We know that the basic principle of the design process of autonomous driving systems is based on the three aspects of perception, decision, and execution.The main issues to be addressed in the perception capability of the autonomous driving system include FS1, FS2, and FS_3 as described below:
FS_1: The localization system should determine its position relative to the Operational Design Domain (ODD). The position should be either inside or outside a specified, location-based ODD.
FS_2: The perception of static and dynamic objects close to the autonomous vehicle should be achieved. The optional preprocessing should provide all target outputs needed by the driving system. The highest priority objects are the entities with collision risks, including both dynamic objects (such as vulnerable road users with respective movement features) and static instances (such as road boundaries, traffic signs and communication signals) as well as obstacles.
FS_3: Prediction of the future behavior of related targets is necessary. It should explain the intentions of related objects to extend the environmental model for future predictions. In other words, it is necessary to predict the future states of the targets to expand the environmental prediction.
However, for the expected functional safety in the perception capability, the following weaknesses in the perception process need to be fully considered:
- Vehicle related reasons: Blind spots caused by the short distance between vehicles or the unorthodox shape of the vehicle.
- Environmental reasons: Unique environments, such as mud obstruction, construction barriers, or underpass tunnels as well as extreme lighting conditions of the sun or night.
- Regulatory reasons: Perception of height limits, bridge height, types of restrictions and other regulatory requirements.
- Target reasons: Perception of special-shaped objects, such as dropped items or parts, rockfall or abnormal protrusions on mountains.
Furthermore, in the decision-making and planning process, the main issue that the system needs to address is FS_4, as described below:
FS_4: Create collision-free and legal driving plans.
To ensure collision-free and legal driving policies, the following regulations should be adhered to:
- Maintain a safe lateral and longitudinal distance from other objects.
- Observe all applicable traffic rules within the ODD.
- Consider potential danger zones where obstructions may block traffic.
- Do not grant passage in case of uncertainty.
- If collision can be avoided without compromising the safety of third parties, traffic rules may be prioritized.
Therefore, for the expected functional safety in planning and decision-making, the following weaknesses in the planning and decision-making process need to be fully considered:
- Vehicle related reasons: Time window planning for vehicle turning, changing lanes, and other manoeuvres.
- Road-related reasons: Road restrictions, bridge alternatives, weight limits etc.
- Environmental reasons: Control vehicle speed under adverse weather conditions such as rain, snow, fog, etc.
- Target reasons: Optimal obstacle-avoidance solutions for complex scenarios based on safety considerations.
Finally, in the control execution process, the system needs to address FS_5 with the following functionality:
FS_5: Correct execution and generation of driving plans
The corresponding driving signals for lateral and longitudinal control should be generated according to the driving plan.When considering the perceptual capabilities needed for expected functional safety, it is necessary to fully consider the following vulnerabilities in the process of control execution:
- Vehicle reasons: vehicle turning, vehicle speed control ability, etc.;
- Road reasons: road speed limit, turning radius, control ability of speed on slopes;
- Environmental reasons: vehicle control ability when turning in environments such as standing water and icy roads;
- Target reasons: ability to affect passenger comfort and driving safety.
As shown in the table below, in the safety assessment process for designing automatic driving access, its safety principles can be traced back to all the functions that need to be implemented. As the expected function development of the automatic driving access process expects the product development responsible to provide the necessary level of evidence for capability verification and confirmation, followed by review by the evaluation group. Therefore, it is necessary to develop a complete logic and principles around the methodology for verifying automatic driving systems.
Analysis of expected functional safety capabilities involved in automatic driving access
Regarding the functional safety and expected functional safety requirements in the section of required capability building in the latest release of the automatic driving access guidelines, we know that many OEMs find it difficult to achieve these requirements, such as:
Here, we can understand that the requirements for automatic driving access include two aspects:
The first is the requirement for enterprises. This refers to the requirement for enterprise capabilities, such as an enterprise’s expected functional safety management process, enterprise safety culture, and document design work in various stages as well as monitoring the entire product lifecycle.
The second is the requirement for the product. That is, following the international and domestic standards in the development process, conducting necessary SOTIF analysis in the product development stage and verifying the SOTIF capability of the product through simulation and vehicle testing methods, and continuing to iterate the SOTIF capability of the product during use.
Based on the requirements for expected functional safety in the entire automatic driving design in “Access”, it is imperative to improve the enterprise’s SOTIF capability. The following diagram shows the SOTIF development, verification, and operation process for enterprises.
Here, we will separately interpret and analyze the expected functional safety development interface management requirements, compliance with expected functional safety management responsibilities and role definitions, supplier plan management, among other regulations. (One (five) enterprises should meet the requirements for expected functional safety development interface management, comply with the responsibilities and role definitions of expected functional safety management, and supplier plan management requirements).### 二(四)应定义驾驶自动化系统预期功能安全相关零部件的接口要求,确保零部件符合对应的预期功能安全设计开发、验证、确认等规定。
In order to ensure that companies meet the requirements for managing and defining the expected function safety development interfaces, the following methods may be used:
-
Companies can establish and maintain a good safety culture, encouraging internal departments to communicate and research expected function safety issues, especially the system design, software development, and function safety analysis – the core departments for expected function safety analysis.
-
Companies should establish a reasonable safety abnormality resolution mechanism based on their own characteristics.
-
Companies should formulate a safety management process and improve the management mechanism, mainly involving the following:
- Provide proof materials for the quality management system;
- Provide reasonable assessment methods for safety management personnel to ensure their competence for related work;
- Detailed records of the contents involved in safety plans, safety test cases, and safety confirmation mechanisms.
- Companies have a post-development process for products:
- Formulate a safety management plan for product production, operation, maintenance, and use;
- Provide review reports for the production site.
-
Companies and suppliers jointly formulate development interface protocols to clarify development requirements.
-
Companies require suppliers to provide safety plans, as well as component-level design specifications and evaluation reports for perception, decision-making, and execution systems.
一(六)企业应满足预期功能安全开发流程要求,符合设计定义、危害识别、功能不足识别、功能改进、验证及确认、安全发布、运行维护等规定,保障车辆不存在因预期功能的不足所导致的不合理风险。
Based on the requirements of the “Admission”, to improve the SOTIF performance of products, we can refer to the expected function safety analysis process shown in the following diagram for expected function safety analysis. The overall process involves setting reasonable functional elements as inputs during the system design phase, identifying whether they are within an acceptable range through hazard and local hazard result analysis. When a functional deficiency is identified, the first step is to check if the scenario is reasonable. If it is reasonable, it is considered to be caused by a design defect of the system itself, and the function should be upgraded and improved immediately. If it is found to be an unreasonable test scenario, then the testing and verification methods should be reconfirmed, and known and unknown scenarios should be verified and explored. Both types of scenarios are assessed for risk. If the risk is low enough, the product can be considered to meet the expected function safety requirements for SOTIF and enter the operation and maintenance phase.
2.1 The expected functional safety standards and design requirements should be met, the potential hazards of expected functions should be identified and evaluated, and reasonable risk acceptance criteria should be established.
This mainly refers to hazard analysis and risk assessment. The main process includes defining related items, defining vehicle-level hazard entries under failure states according to the definitions, forming Hazardous Events in combination with scenarios, evaluating the risks caused by hazards, and finally setting Acceptance Criteria for risks.
Establishing risk acceptance criteria. For the problems in known hazard scenarios, i.e., hazards events with S>0 and C>0, if S=0 or C=0 cannot be achieved even after function modification, it is necessary to define risk acceptance criteria (as the basis for verification target) as the acceptance standard for the hazard scenario.
Where λ represents the average occurrence frequency of hazard behavior events per unit mileage (or unit time); α represents the confidence level; and τ represents the average mileage or time interval (i.e., non-accident mileage or duration) at which the hazard behavior event occurs. For example, when the non-hazardous behavior event mileage reaches 100×104 km, it is believed with a 99% confidence level that the hazard accident rate of the system can reach 4.6×10-6 times/km in the equivalent driving scenario.
2.2 The potential functional inadequacies and triggering conditions (including foreseeable personnel misuse) should be identified and evaluated, and measures such as functional improvement should be applied to reduce the risks related to expected functional safety.
As mentioned above, this requirement mainly identifies functional inadequacies and triggering conditions (specific hazard scenarios) that lead to hazardous events through ODD analysis, accident scenario data analysis, and safety analysis methods. According to the process described in the SOTIF safety analysis standard, it mainly includes obtaining corresponding SOTIF analysis results (functional inadequacies, misuse, triggering conditions) by referring to the required input elements (system design specifications, vehicle-level hazard analyses, risk assessments, risk acceptance criteria) and analyzing them with the ISO PAS 21448 SOTIF safety analysis method strategy.
The safety analysis methods mentioned here can be summarized as including STPA, FMEA, and FTA. At the same time, based on existing analysis and accumulated experience, an expected functional safety scenario library is formed, and simulation tests (usually including SIL and HIL tests) are established in advance to facilitate the identification of all triggering conditions and reduce SOTIF risks through subsequent vehicle (including site and road) testing.
It should be noted here that for improvement in cases of insufficient functionality, misuse, or errors caused by triggering conditions, improvements can be made in the following aspects:
-
Enhancing system capabilities, such as computing power and algorithm efficiency;
-
Adding diverse redundancy technologies, such as perception fusion, execution-side redundancy, and power redundancy;
-
Clearly stating functional conditions limitations, such as specifying the ODD range;
-
Predictive driver intervention, control strategy and prompt strategy;
-
Warning drivers through user manuals to reduce the occurrence of system misuse.
Summary
The admission of autonomous driving imposes high requirements on enterprises in the development and design of expected functional safety, which requires enterprises to continuously improve their safety analysis and design capabilities at the beginning of design to ensure that they can meet regulatory and market sales requirements during the testing and validation process of autonomous driving design and development. This safety analysis and design capability can be analyzed and designed from a deeper level by enterprises combining their own capabilities and establishing an improved scenario library, adding safety analysis processes, combining test tools, collecting market feedback, and continuously improving their autonomous driving SOTIF analysis capabilities, in addition to referring to the SOTIF standard.
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.