Hierarchical security requirement index determination and verification method, device and medium

Abstract

The application discloses a layered security requirement index determination and verification method, device, vehicle and storage medium. The security requirement index determination method comprises the following steps: determining an initial whole-vehicle-level security requirement index of an automatic driving system; performing index decomposition on the initial whole-vehicle-level security requirement index based on each subsystem in the automatic driving system to obtain a system-level security requirement index of the automatic driving system; and performing index decomposition on the system-level security requirement index based on each component in the automatic driving system to obtain a component-level security requirement index of the automatic driving system. The security requirement index determination method can decompose the system-level security requirement index and the component-level security requirement index that meet the expected functional safety, so that the decomposed security requirement index can be directly applied to a project instance, and the applicability of the security requirement index of the automatic driving system is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle safety, and more particularly to a method, device, vehicle, and readable storage medium for determining and verifying safety requirements indicators based on hierarchical levels. Background Technology

[0002] With the rapid development of advanced electronic, communication and information technologies, a new generation of automotive technology innovation oriented towards intelligence and connectivity is unfolding worldwide. It is particularly important to improve functional safety, expected functional safety and information security through reasonable safeguard technologies.

[0003] Before developing the software and hardware for an autonomous driving system, it is necessary to propose the Safety of the Intended Functionality (SOTIF) for each component to the software and hardware development departments. Currently, in SOTIF development, engineers use various safety analysis methods, such as fault tree analysis and causal chain analysis, to identify the performance limitations and triggering conditions of the autonomous driving system, and propose safety requirements indicators based on these. While existing autonomous driving standards specify the analysis process for safety requirements indicators and provide explanations for the methods mentioned, they do not quantify and decompose these indicators. This makes the designed safety requirements indicators unsuitable for direct application in project development, reducing the applicability of the safety requirements indicators for autonomous driving systems.

[0004] Therefore, improving the applicability of safety requirements indicators for autonomous driving systems has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method, device, vehicle, and readable storage medium for determining and verifying security requirements indicators based on hierarchical levels, which solves the problem that the security requirements indicators designed by related technologies are not suitable for direct use in project instance development.

[0006] Firstly, this application provides a method for determining security requirement indicators based on hierarchical levels, the method comprising:

[0007] A first safety requirement indicator for the autonomous driving system is determined, wherein the first safety requirement indicator is a vehicle-level safety requirement indicator corresponding to the autonomous driving system; based on each subsystem in the autonomous driving system, the first safety requirement indicator is decomposed to obtain the subsystem failure rate corresponding to each subsystem; based on the subsystem failure rates corresponding to all subsystems, a system-level second safety requirement indicator corresponding to the autonomous driving system is determined.

[0008] The aforementioned hierarchical safety requirement indicator determination method sets initial vehicle-level safety requirement indicators, decomposes system-level safety requirement indicators based on each subsystem's initial vehicle-level safety requirement indicators, and then decomposes component-level safety requirement indicators based on each component. This decomposes system-level and component-level safety requirement indicators that meet the expected functional safety requirements, allowing the decomposed safety requirement indicators to be directly applied to project examples and improving the applicability of safety requirement indicators for autonomous driving systems.

[0009] Secondly, this application also provides a method for verifying security requirement indicators, the method comprising:

[0010] The system acquires initial vehicle-level safety requirement indicators, system-level safety requirement indicators, and component-level safety requirement indicators corresponding to the autonomous driving system; based on the system-level safety requirement indicators and the component-level safety requirement indicators, it determines the target vehicle-level safety requirement indicators to be verified for the autonomous driving system; it performs safety verification on the target vehicle-level safety requirement indicators based on the initial vehicle-level safety requirement indicators; if the target vehicle-level safety requirement indicators pass the safety verification, it is determined that the autonomous driving system meets the safety requirements.

[0011] The aforementioned safety requirement index verification method determines the target vehicle-level safety requirement index to be verified based on system-level and component-level safety requirement indices, and performs safety verification on the target vehicle-level safety requirement index based on the initial vehicle-level safety requirement index. Since component-level safety requirement indices constitute the target vehicle-level safety requirement index, verifying whether the target vehicle-level safety requirement index meets the safety requirements can indirectly verify whether the component-level safety requirement identification meets the safety requirements, thereby improving the reliability of the autonomous driving system under the safety requirement index.

[0012] Thirdly, this application also provides a computer device, which includes a memory and a processor;

[0013] The memory is used to store computer programs;

[0014] The processor is configured to execute the computer program and, when executing the computer program, implement the hierarchical security requirement indicator determination method or security requirement indicator verification method as described above.

[0015] Fourthly, this application also provides a vehicle, the vehicle including a memory and a processor;

[0016] The memory is used to store computer programs;

[0017] The processor is configured to execute the computer program and, when executing the computer program, implement the hierarchical security requirement indicator determination method or security requirement indicator verification method as described above.

[0018] Fifthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the hierarchical security requirement indicator determination method or security requirement indicator verification method described above. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic block diagram of the structure of a computer device provided in an embodiment of this application;

[0021] Figure 2 This is a schematic block diagram of the structure of a vehicle provided in an embodiment of this application;

[0022] Figure 3 This is a schematic flowchart illustrating a hierarchical method for determining security requirement indicators provided in an embodiment of this application.

[0023] Figure 4 This is a schematic flowchart illustrating the sub-steps of decomposing initial vehicle-level safety requirements indicators according to an embodiment of this application.

[0024] Figure 5 This is a schematic diagram of a system-level event sequence diagram provided in an embodiment of this application;

[0025] Figure 6 This is a schematic flowchart illustrating the sub-steps of index decomposition based on a system-level event sequence diagram, as provided in an embodiment of this application.

[0026] Figure 7 This is a schematic flowchart illustrating the sub-steps of decomposing system-level security requirement indicators according to an embodiment of this application;

[0027] Figure 8 This is a hardware and software architecture diagram of a positioning system provided in an embodiment of this application;

[0028] Figure 9 This is a fault tree analysis diagram provided in an embodiment of this application;

[0029] Figure 10 This is another fault tree analysis diagram provided in the embodiments of this application;

[0030] Figure 11 This is a schematic flowchart of a security requirement indicator verification method provided in an embodiment of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0033] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0034] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0035] With the development of science and technology and the application of artificial intelligence, autonomous driving technology has developed rapidly and been widely used. Based on the level of vehicle driving automation, the existing SAE J3016 standard divides driving automation into six levels, namely L0-L5: No Automation (L0), Driver Assistance (L1), Partial Automation (L2), Conditional Automation (L3), High Automation (L4), and Full Automation (L5). As the level of driving automation increases, the degree of human involvement in driving activities decreases. This poses a significant challenge to the safety of autonomous driving systems. Researchers have conducted extensive work on ensuring that autonomous driving systems are safer than those driven by ordinary drivers.

[0036] Functional safety is primarily responsible for ensuring that the safety indicators of the vehicle's electronic and electrical systems meet the requirements of the ISO 26262 standard, while expected functional safety needs to consider the safety indicators that may be affected by insufficient expected functions or human misuse, in order to meet the requirements of the ISO 21448 standard.

[0037] Currently, the analysis of expected functional safety for autonomous driving is mainly based on standards such as ISO 21448 and ISO 26262. Commonly used analysis methods include System-Thermal Process Analysis (STPA), Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and Event Tree Analysis (ETA). While relevant standards for autonomous driving specify the analysis process for expected functional safety and provide explanations for the methods mentioned, they lack a complete analytical framework that extends from vehicle-level safety requirements to system-level safety requirements and then to component-level safety requirements. Furthermore, the analysis of safety requirements cannot be quantitatively decomposed. Therefore, existing vehicle-level safety requirements are not suitable for direct application in project development, reducing the applicability of safety requirements for autonomous driving systems.

[0038] To address this, this application provides a hierarchical method, device, vehicle, and readable storage medium for determining and verifying safety requirement indicators. This method involves setting initial vehicle-level safety requirement indicators, decomposing system-level safety requirement indicators based on each subsystem's initial vehicle-level safety requirement indicators, and then decomposing component-level safety requirement indicators based on each component. This process yields system-level and component-level safety requirement indicators that meet expected functional safety requirements, allowing the decomposed safety requirement indicators to be directly applied to project examples and improving the applicability of safety requirement indicators for autonomous driving systems.

[0039] Furthermore, the hierarchical safety requirement indicator determination method in this application embodiment does not require engineers to analyze qualitative safety requirements or determine specific quantitative indicators based on their experience. This can effectively improve the efficiency of indicator decomposition and the accuracy of safety requirement indicators for autonomous driving systems.

[0040] It should be noted that, in the embodiments of this application, the safety requirement index refers to the safety index that meets the expected functional safety requirements.

[0041] In some embodiments, the hierarchical security requirement indicator determination and verification method provided in this application can be applied to computer devices.

[0042] For example, the computer device can be a server or a terminal. In this embodiment, the computer device can be a standalone electronic device or an electronic device deployed in a vehicle. The server can be a standalone server or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal can be an electronic device such as a smartphone, tablet, laptop, or desktop computer.

[0043] Please see Figure 1 , Figure 1 This is a schematic block diagram of the structure of a computer device 100 provided in an embodiment of this application. Figure 1 In the computer device 100, there are a processor 1001 and a memory 1002, wherein the processor 1001 and the memory 1002 are connected by a bus, such as an Inter-integrated Circuit (I2C) bus or any applicable bus.

[0044] The memory 1002 may include a storage medium and internal memory. The storage medium may be a volatile storage medium or a non-volatile storage medium. The storage medium may store an operating system and a computer program. The computer program includes program instructions, which, when executed, cause the processor 1001 to execute any of the hierarchical security requirement indicator determination method or security requirement indicator verification method in the embodiments of this application.

[0045] The processor 1001 provides computing and control capabilities to support the operation of the entire computer device 100.

[0046] The processor 1001 can be a Central Processing Unit (CPU), but it can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0047] The processor 1001 is used to run a computer program stored in the memory 1002, and performs the following steps when executing the computer program:

[0048] The initial vehicle-level safety requirements for the autonomous driving system are determined. These initial vehicle-level safety requirements are preset indicators that enable the autonomous driving system to meet the expected functional safety requirements. Based on each subsystem of the autonomous driving system, the initial vehicle-level safety requirements are decomposed to obtain the system-level safety requirements. Based on each component of the autonomous driving system, the system-level safety requirements are decomposed to obtain the component-level safety requirements.

[0049] In one embodiment, when determining the initial vehicle-level safety requirements of the autonomous driving system, the processor 1001 is used to:

[0050] Acquire real driving data of the vehicle operating within a preset operating design domain; perform hazard event statistics on the real driving data to obtain hazard event occurrence data of the vehicle; based on the preset safety margin, determine the initial vehicle-level safety requirement indicators according to the hazard event occurrence data.

[0051] In one embodiment, when the processor 1001 decomposes the initial vehicle-level safety requirement indicators based on the various subsystems of the autonomous driving system to obtain the system-level safety requirement indicators of the autonomous driving system, it is used to implement:

[0052] At least one functional scenario corresponding to the autonomous driving system is identified as the current functional scenario. Based on the current functional scenario, risk assessment and vehicle function analysis are performed on the initial vehicle-level safety requirement indicators to obtain the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario. The system-level event sequence diagram of the autonomous driving system under the current functional scenario is obtained. Based on the system-level event sequence diagram, the indicators are decomposed according to the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario to obtain the system-level safety requirement indicators of each subsystem under the current functional scenario.

[0053] In one embodiment, when the processor 1001 performs risk assessment and vehicle function analysis on initial vehicle-level safety requirement indicators based on the current functional scenario to obtain the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario, it is used to:

[0054] A risk assessment is conducted on the controllability, severity, and scenario elements in the current functional scenario to obtain the risk assessment results corresponding to the current functional scenario. Based on the risk assessment results corresponding to the current functional scenario, the remaining risk acceptance indicators corresponding to the current functional scenario are determined. Based on the remaining risk acceptance indicators corresponding to the current functional scenario, the vehicle functional safety requirement indicators corresponding to the current functional scenario are determined, wherein the vehicle functional safety requirement indicators are less than or equal to the remaining risk acceptance indicators.

[0055] In one embodiment, the subsystems of the autonomous driving system are a positioning system, a perception system, a planning system, and a control system; the processor 1001, when implementing the decomposition of indicators based on the system-level event sequence diagram, the risk assessment results corresponding to the current functional scenario, and the vehicle functional safety requirements indicators to obtain the system-level safety requirements indicators of each subsystem under the current functional scenario, is used to achieve the following:

[0056] Based on the risk assessment results corresponding to the current functional scenario, the initial event in the system-level event sequence diagram is determined; based on the vehicle functional safety requirement indicators corresponding to the current functional scenario, the vehicle functional safety requirement indicators of the initial event are determined; based on the probability of a hazardous event occurring in each subsystem of the system-level event sequence diagram, the vehicle functional safety requirement indicators of the initial event are decomposed to obtain the probability of hazardous events occurring in each subsystem; based on the probability of hazardous events occurring in each subsystem, the system-level safety requirement indicators of each subsystem under the current functional scenario are determined.

[0057] In one embodiment, when the processor 1001 determines the initial event in the system-level event sequence diagram based on the risk assessment result corresponding to the current functional scenario, it is used to:

[0058] Obtain vehicle-wide hazard events from the risk assessment results corresponding to the current functional scenario; determine the events preceding the hazard based on the vehicle-wide hazard events; and determine the initial event based on the events preceding the hazard.

[0059] In one embodiment, the system-level safety requirement indicators of the autonomous driving system include the probability of occurrence of hazardous events corresponding to each subsystem; when the processor 1001 decomposes the system-level safety requirement indicators based on each component of the autonomous driving system to obtain the component-level safety requirement indicators of the autonomous driving system, it is used to implement:

[0060] Each subsystem is identified as the current subsystem in turn; the target fault tree analysis diagram corresponding to the current subsystem is determined, which includes the triggering conditions corresponding to the components that cause the current subsystem to have a hazard event; the probability of occurrence of the hazard event corresponding to the current subsystem is decomposed according to the triggering conditions corresponding to the components to obtain the component-level safety requirement indicators corresponding to the current subsystem.

[0061] In one embodiment, when determining the target fault tree analysis diagram corresponding to the current subsystem, the processor 1001 is used to implement:

[0062] Obtain the initial fault tree analysis diagram corresponding to the current subsystem; based on the Bayesian network, overlay scene elements on the initial fault tree analysis diagram to obtain the initial fault tree analysis diagram after scene element overlay; determine the target fault tree analysis diagram based on the initial fault tree analysis diagram after scene element overlay.

[0063] In one embodiment, processor 1001 is used to implement:

[0064] Obtain the initial vehicle-level safety requirements, system-level safety requirements, and component-level safety requirements for the autonomous driving system; determine the target vehicle-level safety requirements to be verified for the autonomous driving system based on the system-level and component-level safety requirements; perform safety verification on the target vehicle-level safety requirements based on the initial vehicle-level safety requirements; if the target vehicle-level safety requirements pass the safety verification, then the autonomous driving system is determined to meet the safety requirements.

[0065] In one embodiment, the component-level safety requirement indicators include a first probability that the i-th subsystem in the j-th functional scenario meets the k-th triggering condition, and a second probability that the component experiences performance limitations when the i-th subsystem in the j-th functional scenario meets the k-th triggering condition; the system-level safety requirement indicators include the probability of a hazard event occurring in the i-th subsystem in the j-th functional scenario when the component meets the triggering condition; the processor 1001, when determining the target vehicle-level safety requirement indicators to be verified for the autonomous driving system based on the system-level and component-level safety requirement indicators, is used to implement:

[0066] The vehicle functional safety requirements for each functional scenario are calculated based on the first probability, the second probability, and the probability of occurrence of the hazardous event. Based on the vehicle functional safety requirements for all functional scenarios, the target vehicle-level safety requirements are determined.

[0067] In one embodiment, the processor 1001 is also configured to implement:

[0068] From the functional scenario database corresponding to the autonomous driving system, obtain the position, heading, and speed of the i-th subsystem under the j-th functional scenario; based on the circular error of the position, the circular error of the heading, and the circular error of the speed, determine the probability of occurrence of a hazardous event in the i-th subsystem under the j-th functional scenario.

[0069] In one embodiment, the target vehicle-level safety requirement indicators include vehicle functional safety requirement indicators corresponding to multiple functional scenarios, and the initial vehicle-level safety requirement indicators include the remaining risk acceptance indicators corresponding to each functional scenario; when implementing the safety verification of the target vehicle-level safety requirement indicators based on the initial vehicle-level safety requirement indicators, the processor 1001 is used to implement:

[0070] The vehicle functional safety requirement indicators for each functional scenario are compared with the remaining risk acceptance indicators. If the vehicle functional safety requirement indicators for all functional scenarios are less than or equal to the corresponding remaining risk acceptance indicators, then the target vehicle-level safety requirement indicators are determined to have passed the safety verification.

[0071] In other embodiments, the hierarchical safety requirement index determination and verification method provided in this application can also be applied to vehicles. Vehicles can set initial vehicle-level safety requirement indexes, decompose system-level safety requirement indexes based on each subsystem, and then decompose component-level safety requirement indexes based on each component. This decomposes system-level and component-level safety requirement indexes that meet the expected functional safety requirements, allowing the decomposed safety requirement indexes to be directly applied to project examples, thus improving the applicability of the safety requirement indexes of autonomous driving systems.

[0072] For example, a vehicle can be a vehicle equipped with an Autonomous Vehicle System (ADS). An autonomous driving system refers to a system composed of hardware and software capable of continuously performing all dynamic driving tasks, regardless of any limitations imposed by operating conditions. For instance, an autonomous driving system is a system composed of hardware and software capable of continuously performing some or all of the dynamic driving tasks.

[0073] Please see Figure 2 , Figure 2 This is a schematic block diagram of the structure of a vehicle 200 provided in an embodiment of this application. Figure 2 In the vehicle 200, there are a processor 2001 and a memory 2002, wherein the processor 2001 and the memory 2002 are connected by a bus, such as an Inter-integrated Circuit (I2C) bus or any applicable bus.

[0074] The memory 2002 may include a storage medium and internal memory. The storage medium may be a volatile storage medium or a non-volatile storage medium. The storage medium may store an operating system and a computer program. The computer program includes program instructions, which, when executed, cause the processor 2001 to execute any of the hierarchical security requirement indicator determination methods or security requirement indicator verification methods in the embodiments of this application.

[0075] The processor 2001 provides computing and control capabilities to support the operation of the entire vehicle 200.

[0076] The processor 2001 can be a Central Processing Unit (CPU), but it can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0077] The following detailed description, in conjunction with the accompanying drawings, outlines some embodiments of this application. Unless otherwise specified, the following embodiments and features described herein can be combined with each other. Please refer to... Figure 3 , Figure 3 This is a schematic flowchart illustrating a hierarchical security requirement indicator determination method provided in an embodiment of this application. Figure 3 As shown, the method for determining security requirements based on hierarchical levels may include steps S10 to S30.

[0078] Step S10: Determine the initial vehicle-level safety requirements of the autonomous driving system. The initial vehicle-level safety requirements are preset indicators that enable the autonomous driving system to meet the expected functional safety requirements.

[0079] For example, initial vehicle-level safety requirements indicators for an autonomous driving system can be determined, wherein the initial vehicle-level safety requirements indicators are preset indicators that enable the autonomous driving system to meet expected functional safety.

[0080] It should be noted that, in this embodiment, real driving data of ordinary drivers can be collected from a natural driving database first. The frequency of dangerous events such as collisions and rear-end collisions occurring during the driving process can be statistically analyzed based on this real driving data. Finally, an initial vehicle-level safety requirement index can be set based on the frequency of such events occurring during the driving process. The following will provide a detailed explanation of how to determine the initial vehicle-level safety requirement index.

[0081] In some embodiments, determining the initial vehicle-level safety requirements for an autonomous driving system may include: acquiring real driving data of the vehicle operating within a preset operation design domain; performing hazard event statistics on the real driving data to obtain hazard event occurrence data for the vehicle; and determining the initial vehicle-level safety requirements based on a preset safety margin and the hazard event occurrence data.

[0082] For example, real-world driving data of a vehicle operating within a predefined Operational Design Domain (ODD) can be obtained from a natural driving database. Hazardous events can then be statistically analyzed from this real-world driving data to obtain data on the occurrence of hazardous events related to the vehicle. The Operational Design Domain plays a crucial role in autonomous driving and typically includes factors such as geographical location, road type, speed range, weather, and time.

[0083] For example, hazardous event occurrence data may include the frequency of hazardous events such as collisions and rear-end collisions involving ordinary drivers while driving, the distance between hazardous events, and so on. For instance, hazardous event occurrence data may include the following:

[0084] D 基准 = Distance between hazardous events, F 基准 = Frequency of hazardous events per kilometer (events / km).

[0085] For example, initial vehicle-level safety requirements can be determined based on a preset safety margin and hazard event occurrence data. The preset safety margin can be set according to actual conditions, and its specific value is not limited here. In this embodiment, based on the requirement that the autonomous driving system is safer than a human driver when operating within the same ODD, it is proposed that the autonomous driving system should meet a 50% safety margin. For example, D 基准-SF =D 基准 ×150%, F 基准-SF =F 基准 ×150%.

[0086] For example, the occurrence data of hazardous events after increasing the safety margin are used as the initial vehicle-level safety requirement index. This initial vehicle-level safety requirement index can be expressed as λ: one hazardous event occurs every X kilometers, or the frequency of hazardous events occurring per kilometer is X (events / km).

[0087] The above embodiments, by determining the initial vehicle-level safety requirements based on the occurrence data of hazardous events according to a preset safety margin, can ensure that the autonomous driving system has safer indicators than ordinary human drivers, thereby improving the reliability and safety of the initial vehicle-level safety requirements.

[0088] Step S20: Based on each subsystem in the autonomous driving system, the initial vehicle-level safety requirement indicators are decomposed to obtain the system-level safety requirement indicators of the autonomous driving system.

[0089] For example, an autonomous driving system may include subsystems such as a positioning system, a perception system, a planning system, and a control system. Based on the positioning system, perception system, planning system, and control system, initial vehicle-level safety requirements can be decomposed to obtain system-level safety requirements for the autonomous driving system.

[0090] In some embodiments, the initial vehicle-level safety requirements can be decomposed based on different functional scenarios to obtain the system-level safety requirements for each subsystem under each functional scenario. These functional scenarios can be obtained by combining different vehicle functions and operating scenarios. For example, vehicle functions may include following, lane changing, and parking functions, etc.; operating scenarios may include driving in an area, autonomous vehicle safety operation, and sunny daytime conditions, etc. Functional scenarios may include, but are not limited to, inability to follow the vehicle in front in the lane, excessively rapid deceleration while following the vehicle in the lane, and loss of braking when external vehicles or obstacles intrude into the lane, etc. The following will use the following function as an example to illustrate how to decompose the initial vehicle-level safety requirements.

[0091] Please see Figure 4 , Figure 4This is a schematic flowchart illustrating the sub-steps of decomposing initial vehicle-level safety requirements indicators according to an embodiment of this application. Figure 4 As shown, step S20 may include steps S201 to S204.

[0092] Step S201: Sequentially determine at least one functional scenario corresponding to the autonomous driving system as the current functional scenario.

[0093] For example, at least one functional scenario corresponding to the autonomous driving system can be sequentially identified as the current functional scenario. For instance, the functional scenario in the autonomous driving system where the system cannot slow down to follow the vehicle in front within the lane can be identified as the current functional scenario.

[0094] Step S202: Based on the current functional scenario, conduct a risk assessment of the initial vehicle-level safety requirements and analyze the vehicle functions to obtain the risk assessment results and vehicle functional safety requirements corresponding to the current functional scenario.

[0095] In this embodiment, hazard analysis and risk assessment (HARA) can be performed on the initial vehicle-level safety requirements. It should be noted that the purpose of hazard analysis and risk assessment is to identify and classify hazards caused by malfunctions in relevant items, and to formulate safety objectives to prevent hazardous events from occurring or to mitigate the severity of hazards, thereby avoiding unreasonable risks. Hazard analysis refers to analyzing the impact of various potential hazards and accidents on the vehicle and passengers. Risk assessment refers to identifying and evaluating the controllability, severity, and scenario elements under different functional scenarios to obtain risk assessment results.

[0096] In some embodiments, based on the current functional scenario, risk assessment and vehicle function analysis are performed on the initial vehicle-level safety requirement indicators to obtain the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario. This may include: conducting risk assessments on the controllability, severity, and scenario elements in the current functional scenario to obtain the risk assessment results corresponding to the current functional scenario; determining the remaining risk acceptance indicators corresponding to the current functional scenario based on the risk assessment results; and determining the vehicle functional safety requirement indicators corresponding to the current functional scenario based on the remaining risk acceptance indicators, wherein the vehicle functional safety requirement indicators are less than or equal to the remaining risk acceptance indicators.

[0097] It should be noted that the residual risk acceptance criterion refers to the acceptance standard for hazardous behaviors or hazardous events. The specific calculation process for the residual risk acceptance criterion can be found in the calculation process required by the ISO 21448 standard, and will not be elaborated here.

[0098] For example, the risk assessment results and remaining risk acceptance indicators corresponding to the current functional scenario are shown in Table 1:

[0099] Table 1

[0100]

[0101]

[0102] For example, as shown in Table 1, the remaining risk acceptance metric for the current functional scenario is one dangerous collision every 73,000 kilometers.

[0103] For example, the vehicle functional safety requirement index corresponding to the current functional scenario is determined based on the remaining risk acceptance index. The vehicle functional safety requirement index is less than or equal to the remaining risk acceptance index. For instance, when the remaining risk acceptance index is one dangerous collision every 73,000 kilometers, the vehicle functional safety requirement index is also one dangerous collision every 73,000 kilometers.

[0104] For example, the functional safety requirements index for a vehicle can be expressed as λ. MF00j MF00j represents the j-th functional scenario. Here, λ represents the vehicle functional safety requirement index for all functional scenarios. MF00j The sum does not exceed the initial vehicle-level safety requirement index λ, that is

[0105]

[0106] The above embodiments, by conducting risk assessments and vehicle function analyses on initial vehicle-level safety requirement indicators based on different functional scenarios, can obtain risk assessment results and vehicle functional safety requirement indicators corresponding to different current functional scenarios. Subsequently, indicators can be decomposed based on the risk assessment results and vehicle functional safety requirement indicators corresponding to different current functional scenarios to obtain system-level safety requirement indicators for each subsystem under different functional scenarios.

[0107] Step S203: Obtain the system-level event sequence diagram of the autonomous driving system in the current functional scenario.

[0108] For example, an EvenSequence Diagram (ESD) of the autonomous driving system in the current functional scenario can be obtained. It should be noted that ESD is a visual graphical method for describing the sequence of related events. In this embodiment, ESD can be used to describe the system-level event sequence of the vehicle in different functional scenarios.

[0109] Please see Figure 5 , Figure 5This is a schematic diagram of a system-level event sequence diagram provided in an embodiment of this application. For example... Figure 5 As shown, a system-level event sequence diagram can include whether the positioning system, sensing system, planning system, and control system need to take action, and the probability that failure to take action may lead to a hazardous event.

[0110] Step S204: Based on the system-level event sequence diagram, decompose the indicators according to the risk assessment results and vehicle functional safety requirements indicators corresponding to the current functional scenario to obtain the system-level safety requirements indicators of each subsystem under the current functional scenario.

[0111] For example, after obtaining the system-level event sequence diagram of the autonomous driving system in the current functional scenario, the system-level safety requirement indicators of each subsystem can be obtained by decomposing the indicators based on the risk assessment results and vehicle functional safety requirements corresponding to the current functional scenario. The following will explain in detail how to decompose the indicators based on the system-level event sequence diagram.

[0112] Please see Figure 6 , Figure 6 This is a schematic flowchart illustrating the sub-steps of index decomposition based on a system-level event sequence diagram, as provided in an embodiment of this application. Figure 6 As shown, step S204 may include steps S2041 to S2044.

[0113] Step S2041: Based on the risk assessment results corresponding to the current functional scenario, determine the initial event in the system-level event sequence diagram.

[0114] For example, the initial event in the system-level event sequence diagram can be determined based on the risk assessment results corresponding to the current functional scenario.

[0115] In some embodiments, determining the initial event in the system-level event sequence diagram based on the risk assessment results corresponding to the current functional scenario may include: obtaining a vehicle hazard event from the risk assessment results corresponding to the current functional scenario; determining the event preceding the hazard based on the vehicle hazard event; and determining the initial event based on the event preceding the hazard.

[0116] For example, in Table 1, for the functional scenario of being unable to slow down to follow the vehicle in front within the lane, a vehicle-wide hazard event can be obtained, such as being unable to slow down to follow the vehicle in front within the lane. Then, a time-backtracking analysis is performed based on the vehicle-wide hazard event to obtain the event before the hazard occurred, such as the vehicle stopping within the lane. Finally, the initial event is determined from the event before the hazard occurred, for example, the initial event is the vehicle stopping within the lane.

[0117] Step S2042: Determine the vehicle functional safety requirements for the initial event based on the vehicle functional safety requirements corresponding to the current functional scenario.

[0118] For example, after determining the initial event in the system-level event sequence diagram, the vehicle functional safety requirement indicators for the initial event can be determined based on the vehicle functional safety requirement indicators corresponding to the current functional scenario. For instance, the vehicle functional safety requirement indicators corresponding to the current functional scenario can be used as the vehicle functional safety requirement indicators for the initial event.

[0119] Step S2043: Based on the probability of a hazardous event occurring in each subsystem of the system-level event sequence diagram, the vehicle functional safety requirement index of the initial event is decomposed to obtain the probability of hazardous events occurring in each subsystem.

[0120] For example, such as Figure 5 As shown, based on the probability of a hazardous event occurring in each subsystem of the system-level event sequence diagram, the steps for decomposing the vehicle functional safety requirements index of the initial event are as follows: First, determine whether the positioning system can accurately know its own pose. If this determination is not correct, the probability of a vehicle-wide hazardous event being triggered is P. E1 That is, the probability of a hazardous event occurring in the positioning system is P. E1 If the perception system fails to detect a vehicle stopping and slowing down ahead in time, the probability of this causing a catastrophic event is P. E2 That is, the probability of a harmful event occurring in the sensing system is P. E2 If the decision-making system fails to make a safe decision, the probability of a vehicle-wide hazard event occurring is P. E3 That is, the probability of a harmful event occurring in the decision-making system is P. E3 If the control system fails to make a safe decision, the probability of a hazard event affecting the entire vehicle is P. E4 That is, the probability of a hazardous event occurring in the control system is P. E4 If all subsystems can perform the corresponding operations, then all subsystems are functioning normally.

[0121] The relationship between the probability of occurrence of hazardous events corresponding to each subsystem and the vehicle functional safety requirements index for the initial event is as follows:

[0122]

[0123] In formula (2), the sum of the probabilities of occurrence of hazardous events corresponding to the positioning system, sensing system, planning system, and control system is less than or equal to the vehicle functional safety requirement index λ of the initial event. MF001 Wherein, λ MF001This indicates the vehicle functional safety requirement index under the first functional scenario, namely the vehicle functional safety requirement index under the functional scenario where the vehicle cannot follow the vehicle in front to slow down within the lane.

[0124] Step S2044: Determine the system-level security requirements for each subsystem under the current functional scenario based on the probability of occurrence of the hazardous events corresponding to each subsystem.

[0125] For example, after obtaining the occurrence probability of hazardous events corresponding to each subsystem, the system-level security requirement index for each subsystem in the current functional scenario can be determined based on the occurrence probability of hazardous events corresponding to each subsystem. For instance, the occurrence probability of hazardous events corresponding to each subsystem can be determined as the system-level security requirement index for each subsystem in the current functional scenario. Here, the system-level security requirement index can be represented as P. Ei .

[0126] In the above embodiments, by decomposing indicators based on the risk assessment results corresponding to the current functional scenario and the vehicle functional safety requirements indicators based on the system-level event sequence diagram, the system-level safety requirements indicators of each subsystem under different functional scenarios can be obtained.

[0127] Step S30: Based on each component in the autonomous driving system, decompose the system-level safety requirement indicators to obtain the component-level safety requirement indicators of the autonomous driving system.

[0128] In some embodiments, after decomposing the initial vehicle-level safety requirement indicators to obtain the system-level safety requirement indicators of the autonomous driving system, the system-level safety requirement indicators can be decomposed based on each component in the autonomous driving system to obtain the component-level safety requirement indicators of the autonomous driving system.

[0129] For example, components can be components of various subsystems within an autonomous driving system. For instance, based on components in a positioning system, the system-level safety requirement indicators corresponding to the positioning system can be decomposed to obtain component-level safety requirement indicators for the positioning system. Similarly, based on components in a perception system, the system-level safety requirement indicators corresponding to the perception system can be decomposed to obtain component-level safety requirement indicators for the perception system.

[0130] Please see Figure 7 , Figure 7 This is a schematic flowchart illustrating the sub-steps of decomposing system-level security requirement indicators according to an embodiment of this application. Figure 7 As shown, step S30 may include steps S301 to S303.

[0131] Step S301: Sequentially identify each subsystem as the current subsystem.

[0132] For example, each subsystem can be sequentially identified as the current subsystem. In this embodiment, a positioning system will be used as an example to illustrate how to decompose the system-level security requirement indicators corresponding to the positioning system based on the components of the positioning system.

[0133] Step S302: Determine the target fault tree analysis diagram corresponding to the current subsystem. The target fault tree analysis diagram includes the triggering conditions corresponding to the components that cause the current subsystem to experience a hazardous event.

[0134] It should be noted that fault tree analysis is a method that represents system risks and events in a tree structure to analyze the reliability and security of a system. In this embodiment, a fault tree analysis graph can be used, combined with the known software and hardware architecture of each subsystem, to decompose the system-level safety requirements of the positioning system, sensing system, planning system, and control system into the software and hardware that cause system-level hazards, thereby obtaining component-level safety requirements. The following will take the positioning system as an example, and based on the known software and hardware architecture of the positioning system, use a fault tree analysis graph to decompose the system-level safety requirements of the positioning system into component-level safety requirements.

[0135] Please see Figure 8 , Figure 8 This is a hardware and software architecture diagram of a positioning system provided in an embodiment of this application. Figure 8 As shown, the hardware components in the positioning system may include, but are not limited to, lidar, monocular camera, real-time kinematic (RTK) positioning, inertial measurement unit (IMU), wheel speedometer (WHEEL), etc.; the software components in the positioning system may include, but are not limited to, laser positioning, semantic positioning, integrated positioning, track estimation, inertial navigation system (INS), etc.

[0136] For example, a target fault tree analysis diagram corresponding to the positioning system can be obtained. The target fault tree analysis diagram includes the triggering conditions corresponding to the components that cause the current subsystem to experience a harmful event.

[0137] The triggering conditions may include at least one of the following: lidar hardware failure, camera hardware failure, inertial measurement unit hardware failure, wheel speedometer hardware failure, differential positioning hardware failure, timestamp failure, trajectory estimation failure, laser positioning failure, semantic positioning failure, and combined positioning failure. It can be understood that a triggering condition refers to a condition that causes a component to experience a performance limitation (PL).

[0138] Please see Figure 9 , Figure 9 This is a fault tree analysis diagram provided in an embodiment of this application. For example... Figure 9 As shown, Figure 9 This is a fault tree analysis diagram of a hazardous event caused by the failure of the vehicle positioning system (failure of the following function) leading to brake loss and a rear-end collision. The causes of the hazardous event can be divided into two categories: global positioning detection failure and local positioning detection failure. These can be further analyzed from two perspectives: insufficient sensor hardware performance and limitations of the fusion algorithm. From the perspective of global positioning detection failure, the triggering conditions for the components leading to the hazardous event in the current subsystem can include LiDAR hardware failure, camera hardware failure, inertial measurement unit hardware failure, wheel speedometer hardware failure, differential positioning hardware failure, timestamp failure, trajectory estimation failure, LiDAR positioning failure, semantic positioning failure, and combined positioning failure, etc. From the perspective of local positioning detection failure, the triggering conditions for the components leading to the hazardous event in the current subsystem can include LiDAR hardware failure, inertial measurement unit hardware failure, trajectory estimation failure, and LiDAR positioning failure, etc.

[0139] Among them, the types of LiDAR hardware failures (not shown in the figure) can be divided into: LiDAR being affected by weather, resulting in high noise in the original point cloud, rain, fog, dust, etc. Camera hardware failures can be divided into: excessive camera distortion leading to mismatch with the calibration object; insecure camera mounting leading to mismatch with the calibration object; camera being affected by lighting, leading to mismatch with the calibration object; alternating light and dark conditions (tunnel entrance); direct sunlight (sunlight, speed camera flash, reflections, etc.); driving in backlight; low light intensity at night. Inertial Measurement Unit (IMU) hardware failures can be divided into: no IMU output; IMU result initialization failure; IMU result jump exceeding the threshold; IMU result frame rate too low. Wheel speed meter hardware failures can be divided into: wheel speed result slippage; wheel speed result delay; wheel speed result stuttering; wheel speed result jump. Differential positioning hardware failures can be divided into: obstruction by buildings, resulting in RTK results not being received in time, such as in tunnels, gates, etc. Timestamp failures can be categorized as follows: timestamp jump in inertial measurement unit (INS) results, excessive difference in INS timestamps, timestamp rollback in INS results, and failure to refresh INS timestamps. Track extrapolation failures can be categorized as follows: no fixed solution in INS results, false fixed INS results, and excessive positioning deviation. Laser positioning failures can be categorized as follows: mismatch in laser positioning, and weather conditions such as rain, fog, and dust affecting laser radar recognition. Semantic positioning failures can be categorized as follows: mismatch in semantic positioning, and unsuitable lighting conditions affecting camera recognition. Combined positioning failures can be categorized as follows: non-convergence of multi-fusion positioning results and excessive deviation in combined positioning results.

[0140] In some embodiments, determining the target fault tree analysis diagram corresponding to the current subsystem includes: obtaining the initial fault tree analysis diagram corresponding to the current subsystem; performing scene element overlay on the initial fault tree analysis diagram based on a Bayesian network to obtain the initial fault tree analysis diagram after scene element overlay; and determining the target fault tree analysis diagram based on the initial fault tree analysis diagram after scene element overlay.

[0141] It should be noted that, in performing fault tree analysis, this application embodiment takes into account the complexity of elements in the scenario and can use Bayesian networks to simplify the scenario in the fault tree analysis diagram. At the same time, since some scenario elements are also triggering conditions that cause component performance limitations, the introduction of Bayesian networks can generate different dangerous scenarios, simplify calculations, and facilitate the calculation of component-level safety requirement indicators.

[0142] For example, for a positioning system, an initial fault tree analysis diagram corresponding to the positioning system can be obtained, and then, based on a Bayesian network, scene elements can be superimposed on the initial fault tree analysis diagram to obtain an initial fault tree analysis diagram after scene element superposition.

[0143] Scene elements can be vehicle elements or other elements besides vehicle elements, such as road elements, traffic infrastructure, environment, digital information, etc.

[0144] Please see Figure 10 , Figure 10 This is another fault tree analysis diagram provided in an embodiment of this application. For example... Figure 10 As shown, a Bayesian network can be used to overlay scene elements onto the initial fault tree analysis graph to obtain a new initial fault tree analysis graph with overlaid scene elements. For example, the probabilities of scene elements appearing in different levels of rain and fog are: 60% in no rain / fog weather, 30% in light rain / fog, and 10% in moderate rain / fog. The probabilities of different light intensities are: 10% in low light, 80% in normal light, and 10% in strong light. Due to camera performance limitations caused by strong light and moderate rain, the probability P of triggering these conditions is... TC Let P be the probability of the scene elements strong light and moderate rain overlapping, which trigger the condition. The strong light event and the moderate rain event are two independent events, and their probabilities are assumed to be: strong light P(A) = 10%, moderate rain P(B) = 10%. Then the probability of the camera triggering the condition due to performance limitations is P. TC =P(A∩B)=P(A)×P(B)=1%. By using Bayes' theorem, weather scene elements can be superimposed into the calculation of trigger conditions, simplifying the calculation process and eliminating the need for separate analysis of weather scene elements in HARA analysis.

[0145] The above embodiments, by overlaying scene elements on the initial fault tree analysis graph based on Bayesian networks, can generate different dangerous scenarios, improve the diversity of scenarios, and simplify calculations, making it easier to calculate component-level safety requirement indicators.

[0146] Step S303: Decompose the probability of occurrence of the hazard event corresponding to the current subsystem according to the triggering conditions corresponding to the component to obtain the component-level security requirement index corresponding to the current subsystem.

[0147] For example, after obtaining the triggering conditions corresponding to the components that cause the current subsystem to have a harmful event, the probability of the harmful event occurring in the current subsystem can be decomposed according to the triggering conditions corresponding to the components to obtain the component-level security requirement indicators corresponding to the current subsystem.

[0148] Among them, the component-level security requirement indicators include: the first probability that the current subsystem in the j-th functional scenario meets the k-th triggering condition, and the second probability that the component experiences performance limitations when the current subsystem in the j-th functional scenario meets the k-th triggering condition.

[0149] For example, in a positioning system, when decomposing the probability of occurrence of a hazardous event corresponding to the current subsystem based on the triggering conditions of the component, the decomposition can be performed using Bayes' theorem:

[0150]

[0151] In formula (3), P TC,k P represents the first probability, where the positioning system fails to slow down to follow the vehicle in front within the lane, under the functional scenario of satisfying the k-th trigger condition. PL|TC,k This represents the second probability, P, of a positioning system experiencing performance limitations when the k-th trigger condition is met, in a scenario where the system cannot follow the vehicle in front and slow down within the lane. TC This indicates the probability of a scene element appearing.

[0152] The above embodiments, by setting initial vehicle-level safety requirements, decompose system-level safety requirements based on each subsystem's initial vehicle-level safety requirements, and then decompose component-level safety requirements based on each component, achieve the decomposition of system-level and component-level safety requirements that meet the expected functional safety requirements. This allows the decomposed safety requirements to be directly applied to project examples, improving the applicability of the safety requirements for autonomous driving systems.

[0153] In this embodiment, after obtaining the system-level safety requirement indicators and component-level safety requirement indicators, it is also necessary to verify these indicators to determine whether the vehicle-level safety requirement indicators of the autonomous driving system meet the expected functional safety requirements. The verification of the safety requirement indicators will be described in detail below.

[0154] Please see Figure 10 , Figure 10 This is a schematic flowchart illustrating a security requirement indicator verification method provided in an embodiment of this application. Figure 10 As shown, the security requirement indicator verification method may include steps S401 to S403.

[0155] Step S401: Obtain the initial vehicle-level safety requirements, system-level safety requirements, and component-level safety requirements corresponding to the autonomous driving system.

[0156] For example, the initial vehicle-level safety requirement index λ of the autonomous driving system can be obtained, and the system-level safety requirement index P can be obtained through index decomposition. Ei and component-level security requirements (P) TC,k ,P PL|TC,k Among them, the initial vehicle-level safety requirement index λ and the system-level safety requirement index P Ei and component-level security requirements (P) TC,k ,P PL|TC,k The results can be obtained from the hierarchical security requirement index determination method in the above embodiments, which will not be elaborated here.

[0157] Step S402: Based on the system-level safety requirement indicators and component-level safety requirement indicators, determine the target vehicle-level safety requirement indicators to be verified for the autonomous driving system.

[0158] For example, formulas (1), (2), and (3) above can be summarized to establish the relationship between vehicle-level safety requirements, system-level safety requirements, and component-level safety requirements:

[0159]

[0160] In formula (4), P TC,k,i,j P represents the first probability that the i-th subsystem in the j-th functional scenario satisfies the k-th triggering condition. PL|TC,k,i,j P represents the second probability that a component will experience performance limitations when the i-th subsystem in the j-th functional scenario meets the k-th triggering condition. Ei,j|PL The system-level security requirement indicators include the probability of a hazard event occurring in the i-th subsystem under the j-th functional scenario when the component meets the triggering conditions.

[0161] In some embodiments, determining the target vehicle-level safety requirement indicators to be verified for the autonomous driving system based on system-level safety requirement indicators and component-level safety requirement indicators may include: calculating the vehicle functional safety requirement indicators for each functional scenario based on a first probability, a second probability, and the probability of occurrence of a hazardous event; and determining the target vehicle-level safety requirement indicators based on the vehicle functional safety requirement indicators for all functional scenarios.

[0162] For example, the first probability, the second probability, and the probability of the occurrence of the hazardous event can be substituted into formula (4) for calculation to obtain the vehicle functional safety requirement index for each functional scenario, i.e., the index in formula (4). Then, the target vehicle-level safety requirements will be determined based on the vehicle functional safety requirements indicators under all functional scenarios.

[0163] It should be noted that, in this embodiment, since the triggering conditions are mainly composed of scenarios such as extreme weather and harsh environments, the first probability P of the triggering conditions occurring can be obtained by analyzing operational scenario data. TC,k,i,j The second probability P of a component experiencing performance limitations can be obtained by performing fatigue tests on the component when the corresponding triggering conditions occur. PL|TC,k,i,j When a component meets the triggering condition, the probability P of a hazardous event occurring in the i-th subsystem under the j-th functional scenario is... Ei,j|PL The occurrence of hazardous events is usually due to insufficient precision of components. Therefore, a relationship can be established between component precision and the probability P of a hazardous event. Ei,j|PL The mathematical relationship between them can then be used to determine the probability P of a hazardous event occurring based on the precision of the components. Ei,j|PL The following will use a positioning system as an example to illustrate how to determine the probability P of a hazardous event occurring in the positioning system when the components meet the triggering conditions, based on the accuracy of the components. Ei,j|PL .

[0164] In some embodiments, the position, heading, and speed of the i-th subsystem in the j-th functional scenario are obtained from the functional scenario database corresponding to the autonomous driving system; the probability of occurrence of a hazardous event in the i-th subsystem in the j-th functional scenario is determined based on the circular error of position, the circular error of heading, and the circular error of speed.

[0165] In positioning systems, positioning-related hazardous events are caused by insufficient positioning accuracy. Positioning accuracy can be measured using the Circular Error Probable (CEP), which is a two-dimensional discrete distribution of positioning data obtained from multiple measurements, with the antenna's actual position as the center and a radius of deviation from the center of a specific value. In the scenario where the triggering condition occurs, the vehicle's positioning accuracy can be evaluated using the CEP of position, heading, and speed. The lower the positioning accuracy, the higher the probability of a hazardous event occurring in the positioning system. Therefore, in this embodiment, when calculating the probability of a hazardous event occurring in the positioning system, the CEP of position, heading, and speed can be used as evaluation indicators. Based on specific data in the functional scenario database, the boundary CEP that leads to a hazardous event in the positioning system is identified. Subtracting the boundary CEP from the overall CEP yields the probability of a hazardous event occurring when the triggering condition occurs.

[0166] For example, the probability P of a hazardous event occurring Ei,j|PL It can be calculated using the following formula:

[0167] P Ei,j|PL =1-CEP 边 (5)

[0168] In formula (5), CEP 边 This represents the probability error of the boundary circle.

[0169] For example, when determining the probability of a hazardous event occurring in the i-th subsystem under the j-th functional scenario based on the circular probability error corresponding to position, the circular probability error corresponding to heading, and the circular probability error corresponding to speed, the boundary circular probability error (CEP) can be determined first based on these three parameters. 边 Then, the boundary circle probability error (CEP) is calculated. 边 Substituting into formula (5) above, the probability P of the occurrence of the hazardous event is calculated. Ei,j|PL .

[0170] In some embodiments, the boundary circle probability error (CEP) can be determined by selecting the indicator among position, heading, and speed that has the most direct impact on the occurrence of a hazardous event in the current functional scenario. 边 For example, if location has the most direct impact on the occurrence of a hazardous event, then the circular probability error corresponding to that location can be determined as the boundary circular probability error (CEP). 边 For example, if speed has the most direct impact on the occurrence of a hazardous event, then the circular probability error corresponding to speed can be determined as the boundary circular probability error (CEP). 边 .

[0171] In other embodiments, the circular probability error (CEP) can be obtained by weighting and averaging the circular probability errors corresponding to position, heading, and velocity based on a preset weighting formula. 边 The weights of each indicator can be set according to the actual situation, and the specific values ​​are not limited here.

[0172] The above embodiments determine the probability of a hazardous event occurring in the i-th subsystem under the j-th functional scenario by using the circular probability error corresponding to the position, the circular probability error corresponding to the heading, and the circular probability error corresponding to the speed. This enables the determination of the probability of a hazardous event based on various indicators affecting positioning accuracy, thereby improving the accuracy of determining the probability of a hazardous event.

[0173] For example, after calculating the vehicle functional safety requirement indicators for each functional scenario based on the first probability, the second probability, and the probability of the hazardous event, the target vehicle-level safety requirement indicators can be determined based on the vehicle functional safety requirement indicators for all functional scenarios. For instance, the vehicle functional safety requirement indicators for all functional scenarios can be determined as the target vehicle-level safety requirement indicators. The target vehicle-level safety requirement indicators can be expressed as follows:

[0174] Step S403: Perform safety verification on the target vehicle-level safety requirements based on the initial vehicle-level safety requirements.

[0175] It should be noted that since the target vehicle-level safety requirements include vehicle functional safety requirements corresponding to multiple functional scenarios, and the initial vehicle-level safety requirements include the remaining risk acceptance indicators corresponding to each functional scenario, it is possible to compare the vehicle functional safety requirements corresponding to each functional scenario in the target vehicle-level safety requirements with the remaining risk acceptance indicators corresponding to the corresponding functional scenarios in the initial vehicle-level safety requirements to determine whether the normal functional safety requirements corresponding to the corresponding functional scenarios have passed safety verification.

[0176] In some embodiments, verifying the target vehicle-level safety requirement indicators based on the initial vehicle-level safety requirement indicators may include: comparing the vehicle functional safety requirement indicators corresponding to each functional scenario with the remaining risk acceptance indicators; if the vehicle functional safety requirement indicators corresponding to all functional scenarios are less than or equal to the corresponding remaining risk acceptance indicators, then the target vehicle-level safety requirement indicators are determined to have passed the safety verification.

[0177] For example, for the functional scenario "unable to follow the vehicle in front to decelerate within the lane," the corresponding vehicle functional safety requirement index can be compared with the corresponding remaining risk acceptance index to determine whether the corresponding vehicle functional safety requirement index is less than or equal to the corresponding remaining risk acceptance index. As another example, for the functional scenario "decelerating too quickly while following the vehicle in front," the corresponding vehicle functional safety requirement index can be compared with the corresponding remaining risk acceptance index to determine whether the corresponding vehicle functional safety requirement index is less than or equal to the corresponding remaining risk acceptance index.

[0178] For example, if all functional scenarios correspond to vehicle functional safety requirements indicators that are less than or equal to the corresponding remaining risk acceptance indicators, then the target vehicle-level safety requirements indicators are determined to have passed safety verification.

[0179] Understandably, since the overall vehicle functional safety requirements are composed of component-level and system-level safety requirements, when all overall vehicle functional safety requirements are less than or equal to the corresponding remaining risk acceptance indicators, it indicates that both component-level and system-level safety requirements are reasonable and meet expected functional safety. Similarly, the target overall vehicle safety requirements for an autonomous driving system are composed of overall vehicle functional safety requirements corresponding to all functional scenarios. When all overall vehicle functional safety requirements corresponding to all functional scenarios are less than or equal to the corresponding remaining risk acceptance indicators, it indicates that the target overall vehicle safety requirements are also reasonable and meet expected functional safety.

[0180] Step S404: If the target vehicle-level safety requirement indicators pass the safety verification, then the autonomous driving system is determined to meet the safety requirements.

[0181] For example, after verifying the target vehicle-level safety requirements based on the initial vehicle-level safety requirements, if the target vehicle-level safety requirements pass the safety verification, then the autonomous driving system is determined to meet the safety requirements.

[0182] The above embodiments determine the target vehicle-level safety requirement indicators to be verified based on system-level safety requirement indicators and component-level safety requirement indicators, and perform safety verification on the target vehicle-level safety requirement indicators based on the initial vehicle-level safety requirement indicators. Since the component-level safety requirement indicators constitute the target vehicle-level safety requirement indicators, by verifying whether the target vehicle-level safety requirement indicators meet the safety requirements, it is possible to indirectly verify whether the component-level safety requirement identification meets the safety requirements, which can improve the reliability of the autonomous driving system under the safety requirement indicators.

[0183] The embodiments of this application also provide a computer-readable storage medium storing a computer program, which includes program instructions. The processor executes the program instructions to implement any of the hierarchical security requirement indicator determination methods or security requirement indicator verification methods provided in the embodiments of this application.

[0184] For example, when the computer program is loaded by the processor, it can perform the following steps:

[0185] The initial vehicle-level safety requirements for the autonomous driving system are determined. These initial vehicle-level safety requirements are preset indicators that enable the autonomous driving system to meet the expected functional safety requirements. Based on each subsystem of the autonomous driving system, the initial vehicle-level safety requirements are decomposed to obtain the system-level safety requirements. Based on each component of the autonomous driving system, the system-level safety requirements are decomposed to obtain the component-level safety requirements.

[0186] For example, when the computer program is loaded by the processor, it can perform the following steps:

[0187] Obtain the initial vehicle-level safety requirements, system-level safety requirements, and component-level safety requirements for the autonomous driving system; determine the target vehicle-level safety requirements to be verified for the autonomous driving system based on the system-level and component-level safety requirements; perform safety verification on the target vehicle-level safety requirements based on the initial vehicle-level safety requirements; if the target vehicle-level safety requirements pass the safety verification, then the autonomous driving system is determined to meet the safety requirements.

[0188] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0189] The computer-readable storage medium can be an internal storage unit of the computer device or vehicle described in the foregoing embodiments, such as a hard drive or memory of the computer device or vehicle. The computer-readable storage medium can also be an external storage device of the computer device or vehicle, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD), flash card, etc.

[0190] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for determining security requirement indicators based on hierarchical levels, characterized in that, The method includes: Determine the initial vehicle-level safety requirements for the autonomous driving system, wherein the initial vehicle-level safety requirements are preset indicators that enable the autonomous driving system to meet the expected functional safety requirements. Based on each subsystem of the autonomous driving system, the initial vehicle-level safety requirement index is decomposed to obtain the system-level safety requirement index of the autonomous driving system. Based on each component of the autonomous driving system, the system-level safety requirement indicators are decomposed to obtain the component-level safety requirement indicators of the autonomous driving system. Based on each subsystem of the autonomous driving system, the initial vehicle-level safety requirement indicators are decomposed to obtain the system-level safety requirement indicators of the autonomous driving system, including: At least one functional scenario corresponding to the autonomous driving system is sequentially determined as the current functional scenario; based on the current functional scenario, risk assessment and vehicle function analysis are performed on the initial vehicle-level safety requirement indicators to obtain the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario; a system-level event sequence diagram of the autonomous driving system under the current functional scenario is obtained; based on the system-level event sequence diagram, the indicators are decomposed according to the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario to obtain the system-level safety requirement indicators of each subsystem under the current functional scenario; Based on the system-level event sequence diagram, the indicators are decomposed according to the risk assessment results and vehicle functional safety requirements indicators corresponding to the current functional scenario to obtain the system-level safety requirements indicators of each subsystem under the current functional scenario, including: Based on the risk assessment results corresponding to the current functional scenario, the initial event in the system-level event sequence diagram is determined; based on the vehicle functional safety requirement indicators corresponding to the current functional scenario, the vehicle functional safety requirement indicators of the initial event are determined; based on the probability of a hazardous event occurring in each subsystem of the system-level event sequence diagram, the vehicle functional safety requirement indicators of the initial event are decomposed to obtain the probability of hazardous events occurring in each subsystem; based on the probability of hazardous events occurring in each subsystem, the system-level safety requirement indicators of each subsystem under the current functional scenario are determined. The system-level safety requirements of the autonomous driving system include the probability of occurrence of hazardous events corresponding to each subsystem; the component-level safety requirements of the autonomous driving system are decomposed based on each component of the system, resulting in component-level safety requirements, including: Each of the subsystems is sequentially identified as the current subsystem; a target fault tree analysis diagram is determined for the current subsystem, the target fault tree analysis diagram including the triggering conditions corresponding to the components that cause a hazard event in the current subsystem; the probability of occurrence of the hazard event corresponding to the current subsystem is decomposed according to the triggering conditions corresponding to the components to obtain the component-level safety requirement indicators corresponding to the current subsystem; Determining the target fault tree diagram corresponding to the current subsystem includes: Obtain the initial fault tree analysis diagram corresponding to the current subsystem; based on the Bayesian network, overlay scene elements on the initial fault tree analysis diagram to obtain the initial fault tree analysis diagram after scene element overlay; determine the target fault tree analysis diagram based on the initial fault tree analysis diagram after scene element overlay.

2. The method for determining security requirement indicators based on hierarchical levels according to claim 1, characterized in that, The determination of the initial vehicle-level safety requirements for the autonomous driving system includes: Acquire real driving data of the vehicle operating within a preset operational design domain; The actual driving data is used to statistically analyze hazardous events to obtain hazardous event occurrence data for the vehicle. Based on a preset safety margin, the initial vehicle-level safety requirement indicators are determined according to the occurrence data of the hazardous events.

3. The method for determining security requirement indicators based on hierarchical levels according to claim 1, characterized in that, Based on the current functional scenario, the initial vehicle-level safety requirement indicators are subjected to risk assessment and vehicle function analysis to obtain the risk assessment results and vehicle functional safety requirement indicators corresponding to the current functional scenario, including: A risk assessment is performed on the controllability, severity, and scenario elements of the current functional scenario to obtain the risk assessment result corresponding to the current functional scenario. Based on the risk assessment results corresponding to the current functional scenario, determine the remaining risk acceptance indicators corresponding to the current functional scenario; Based on the remaining risk acceptance indicators corresponding to the current functional scenario, the vehicle functional safety requirement indicators corresponding to the current functional scenario are determined, wherein the vehicle functional safety requirement indicators are less than or equal to the remaining risk acceptance indicators.

4. The method for determining security requirement indicators based on hierarchical levels according to claim 1, characterized in that, The subsystems of the autonomous driving system are a positioning system, a perception system, a planning system, and a control system.

5. The method for determining security requirement indicators based on hierarchical levels according to claim 1, characterized in that, The step of determining the initial event in the system-level event sequence diagram based on the risk assessment results corresponding to the current functional scenario includes: Obtain vehicle hazard events from the risk assessment results corresponding to the current functional scenario; Based on the aforementioned vehicle hazard events, determine the events preceding the occurrence of the hazard; The initial event is determined based on the events preceding the occurrence of the hazard.

6. The method for determining security requirement indicators based on hierarchical levels according to claim 1, characterized in that, The component-level security requirement indicators include: the first probability that the current subsystem in the j-th functional scenario meets the k-th triggering condition, and the second probability that the component experiences performance limitations when the current subsystem in the j-th functional scenario meets the k-th triggering condition.

7. The method for determining security requirement indicators based on hierarchical levels according to claim 1 or 6, characterized in that, The triggering conditions include at least one of the following: lidar hardware failure, camera hardware failure, inertial measurement unit hardware failure, wheel speedometer hardware failure, differential positioning hardware failure, timestamp failure, trajectory estimation failure, laser positioning failure, semantic positioning failure, and combined positioning failure.

8. A method for verifying security requirement indicators, characterized in that, The verification method includes: The initial vehicle-level safety requirement indicators, system-level safety requirement indicators, and component-level safety requirement indicators corresponding to the autonomous driving system are obtained, wherein the initial vehicle-level safety requirement indicators, the system-level safety requirement indicators, and the component-level safety requirement indicators are obtained by the hierarchical safety requirement indicator determination method according to any one of claims 1 to 7. Based on the system-level safety requirement indicators and the component-level safety requirement indicators, the target vehicle-level safety requirement indicators to be verified for the autonomous driving system are determined. The target vehicle-level safety requirements are verified based on the initial vehicle-level safety requirements. If the target vehicle-level safety requirement indicators pass the safety verification, then the autonomous driving system is determined to meet the safety requirements.

9. The method for verifying security requirement indicators according to claim 8, characterized in that, The component-level security requirement indicators include the first probability that the i-th subsystem in the j-th functional scenario meets the k-th triggering condition, and the second probability that the component experiences performance limitations when the i-th subsystem in the j-th functional scenario meets the k-th triggering condition; the system-level security requirement indicators include the probability that a hazard event occurs in the i-th subsystem in the j-th functional scenario when the component meets the triggering condition. The step of determining the target vehicle-level safety requirements for the autonomous driving system to be verified based on the system-level safety requirements and the component-level safety requirements includes: Based on the first probability, the second probability, and the probability of occurrence of the hazardous event, the vehicle functional safety requirement index for each functional scenario is obtained. Based on the vehicle functional safety requirements indicators under all the aforementioned functional scenarios, the target vehicle-level safety requirements indicators are determined.

10. The method for verifying security requirement indicators according to claim 9, characterized in that, The method further includes: From the functional scenario database corresponding to the autonomous driving system, obtain the position, heading and speed of the i-th subsystem under the j-th functional scenario; Based on the circular probability error corresponding to the position, the circular probability error corresponding to the heading, and the circular probability error corresponding to the speed, the probability of occurrence of a hazardous event in the i-th subsystem under the j-th functional scenario is determined.

11. The method for verifying security requirement indicators according to claim 9, characterized in that, The target vehicle-level safety requirement indicators include vehicle functional safety requirement indicators corresponding to multiple functional scenarios, and the initial vehicle-level safety requirement indicators include the remaining risk acceptance indicators corresponding to each functional scenario. The step of verifying the target vehicle-level safety requirements based on the initial vehicle-level safety requirements includes: Compare the vehicle functional safety requirements for each of the aforementioned functional scenarios with the remaining risk acceptance indicators; If all the vehicle functional safety requirement indicators corresponding to the aforementioned functional scenarios are less than or equal to the corresponding remaining risk acceptance indicators, then the target vehicle-level safety requirement indicator is determined to have passed safety verification.

12. A computer device, characterized in that, The computer device includes a processor and memory; The memory is used to store computer programs; The processor is configured to execute the computer program and, in executing the computer program, implement: The method for determining security requirement indicators based on hierarchical levels as described in any one of claims 1 to 7, or The method for verifying security requirement indicators as described in any one of claims 8 to 11.

13. A vehicle, characterized in that, The vehicle includes a processor and a memory; The memory is used to store computer programs; The processor is configured to execute the computer program and, in executing the computer program, implement: The method for determining security requirement indicators based on hierarchical levels as described in any one of claims 1 to 7, or The method for verifying security requirement indicators as described in any one of claims 8 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to implement: The method for determining security requirement indicators based on hierarchical levels as described in any one of claims 1 to 7, or The method for verifying security requirement indicators as described in any one of claims 8 to 11.

Images