Car-road cooperation automatic driving system and safety hazard event triggering condition analysis method

Abstract

This invention discloses a vehicle-road cooperative autonomous driving system and a method for analyzing the triggering conditions of safety hazard events, belonging to the field of autonomous driving technology. The method includes: standardizing the functions of the vehicle-road cooperative autonomous driving system, defining the system design and operating conditions, and analyzing the system decision-making logic process; clarifying system-wide vehicle-level hazards, defining system safety constraints, conducting risk assessments, and establishing a multi-level hierarchical system control structure; identifying potentially dangerous unsafe control behaviors, and identifying system performance limitations and corresponding triggering conditions for hazard events or unsafe control behaviors. Its beneficial effects are: it can accurately identify the triggering conditions and performance limitations of expected functional safety hazards in high-speed ramp cooperative lane merging systems; it can comprehensively and meticulously consider the interaction relationships between system components and software type hazards, thus significantly improving the comprehensiveness of system safety analysis.

Description

Technical Field

[0001] This invention belongs to the field of autonomous driving technology, specifically relating to a vehicle-road cooperative autonomous driving system and a method for analyzing the triggering conditions of safety hazard events. Background Technology

[0002] Vehicle-to-infrastructure (V2I) cooperative autonomous driving systems are collaborative systems that combine vehicles and road infrastructure, enabling information exchange and collaborative operation between vehicles and road infrastructure through vehicle-to-everything (V2X) technology. In recent years, with the widespread application of V2I cooperative autonomous driving technology in intelligent connected environments, the safety issues of V2I cooperative autonomous driving systems have received increasing attention and research. The V2I cooperative autonomous driving safety system encompasses five aspects: passive safety, behavioral safety, information security, functional safety, and intended functional safety. According to ISO 21448, intended functional safety (SOTIF) aims to avoid unreasonable risks of harm due to functional design defects or inadequate implementation through targeted safety design. Due to performance limitations, insufficient specifications, or reasonably foreseeable misuse, intended functional safety issues are gradually emerging, becoming a key challenge restricting the safety assurance of V2I cooperative autonomous driving systems. Failure to effectively and comprehensively identify the triggering conditions of intended functional safety hazards in V2I cooperative autonomous driving systems will seriously impact these systems in intelligent connected environments.

[0003] Traditional safety analysis methods primarily focus on specific hardware or software failures or electronic malfunctions, and heavily rely on expert experience and knowledge. Their analysis of hazardous events and risk triggers is often unclear and incomplete. In contrast, the analysis of triggering conditions for anticipated functional safety hazards mainly utilizes System Theoretical Process Analysis (STPA) to identify these conditions. STPA treats the system as a whole, viewing system safety issues as control problems. Through system analysis, it defines vehicle-level hazards and safety constraints, establishes a system-level hierarchical control structure, identifies unsafe control behaviors, and identifies typical causal scenarios to analyze triggering conditions, thereby preventing hazardous accidents. However, there is currently a lack of applications combining traditional safety analysis methods with STPA for anticipated functional safety analysis of vehicle-to-infrastructure (V2I) autonomous driving systems. Therefore, combining traditional safety analysis methods with STPA for V2I-based autonomous driving systems to analyze the triggering conditions for anticipated functional safety hazards is a pressing issue that needs to be addressed. Summary of the Invention

[0004] The purpose of this invention is to provide a method for analyzing the triggering conditions of a vehicle-road cooperative autonomous driving system and safety hazard events. The main steps include: standardizing the functions of the vehicle-road cooperative autonomous driving system; defining the system's Operational Design Condition (ODC); analyzing the system's decision-making logic process; clarifying the system's vehicle-level hazards and risks assessment; identifying performance limitations and triggering conditions; establishing a multi-level hierarchical control structure for the system; identifying potentially dangerous unsafe control behaviors; tracing the causal origins of hazardous events or unsafe control behaviors; and identifying system triggering conditions. The analysis method provided by this invention can significantly improve the accuracy and comprehensiveness of identifying the triggering conditions of expected functional safety hazards in vehicle-road cooperative autonomous driving systems, thereby solving at least one of the technical problems mentioned in the background art.

[0005] To solve the above-mentioned technical problems, the present invention is implemented as follows:

[0006] On one hand, embodiments of the present invention provide a method for analyzing the triggering conditions of safety hazards in vehicle-road cooperative autonomous driving, comprising the following steps:

[0007] Step 1: Standardize the functions of the vehicle-road cooperative autonomous driving system, define the system design and operating conditions, and analyze the system decision-making logic process;

[0008] Step 2: Identify system-wide vehicle-level hazards and define the corresponding safety constraints; conduct risk assessments based on system functional specifications and safety constraints, initially construct performance limitation and trigger condition tables, and establish a multi-level hierarchical system control structure. The first-level hierarchical control structure models the overall system structure, while the second-level hierarchical control structure refines the modeling of system sub-modules in conjunction with the environment.

[0009] Step 3: Identify potentially dangerous unsafe control behaviors based on the different levels of the system's control structure, and identify system performance limitations and corresponding triggering conditions for hazardous events or unsafe control behaviors.

[0010] On the other hand, the present invention also provides a control structure for implementing the vehicle-road cooperative autonomous driving system, including a first-level hierarchical control structure and a second-level hierarchical control structure. The first-level hierarchical control structure includes a driver module, an HMI system, a vehicle-side module, a roadside module, a cloud module, and an environmental information module, wherein:

[0011] The environmental information module is used to collect environmental information and send the corresponding environmental information to the driver module, the vehicle module, the cloud module and the roadside module respectively;

[0012] The driver module is used to receive environmental information and send driver status information and system control switch information to the HMI system module;

[0013] The HMI system module is used to receive driver status information and system control switch information, and send the system operating status and system switch control information to the vehicle-side module for control.

[0014] The vehicle-side module is used to receive environmental information and send vehicle status information to other road participants in the environmental information module;

[0015] The roadside module is used to receive environmental information and send all vehicle status information in the road segment to the cloud module and the vehicle-side module.

[0016] The cloud module is used to receive and process control information, and then feed back the collaborative decision-making control information of each vehicle to other road participants in the vehicle module and the environmental information module through the roadside module. The vehicle module then feeds back the system operation status and system request information of the vehicle to the driver module through the HMI system module to form a closed-loop control.

[0017] The cloud module also receives environmental information and processes it together with the vehicle status information sent by the roadside module and the vehicle status information and vehicle request information sent by the vehicle terminal module. It then feeds back scheduling information, other vehicle information and road information to the vehicle terminal module and feeds back decision control information of each vehicle to the roadside module.

[0018] The second-level hierarchical control structure analyzes the control architecture of the roadside module, the cloud module, and the vehicle-side module in conjunction with specific environmental conditions.

[0019] Compared with the prior art, the advantages of this invention are as follows:

[0020] 1. This invention provides a method for analyzing the triggering conditions of safety hazard events based on the aforementioned vehicle-road cooperative autonomous driving system. It combines the advantages of Free Automated Assessment (FTA) in easily identifying key failure modes of complex systems, and integrates STPA with FTA methods. Compared with the traditional STPA analysis method, it can accurately identify the triggering conditions and performance limitations of expected functional safety hazard events in the high-speed ramp cooperative lane merging system. Compared with the completely traditional safety analysis method (FTA), it can comprehensively and meticulously consider the interaction relationships between system components and software type hazards, thus significantly improving the comprehensiveness of system safety analysis.

[0021] 2. The proposed functional specifications for vehicle-road cooperative autonomous driving systems provide a basis for constructing vehicle-level hazards, establishing safety constraints, and modeling multi-level hierarchical control structures. They also provide an effective solution for the safety of vehicle-road cooperative autonomous driving technology in intelligent connected environments, reducing potential safety risks of the system.

[0022] 3. Compared to the traditional STPA system-level hierarchical control structure, the proposed multi-level hierarchical control structure defines in detail the information interaction relationships between subsystems, ensuring the accuracy of information flow, improving the overall system responsiveness, and clearly defining the internal components of each subsystem. This facilitates a better understanding of the system's internal operating mechanisms and systematically manages the information interaction relationships between the internal components of each subsystem, ensuring the orderly and controllable flow of information within the system. By constructing a hierarchical and refined control structure, the monitoring and prediction capabilities of system behavior are enhanced, guaranteeing the integrity and comprehensiveness of the system control structure. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein:

[0024] Figure 1 This is a first-level hierarchical control structure diagram of the vehicle-road cooperative autonomous driving system provided by the present invention;

[0025] Figure 2 A hierarchical control structure diagram of the roadside module provided by the present invention;

[0026] Figure 3 This is a hierarchical control structure diagram of the vehicle-side module provided by the present invention;

[0027] Figure 4 A hierarchical control structure diagram of the cloud module provided by this invention;

[0028] Figure 5 A flowchart of the safety hazard event triggering condition analysis method provided by the present invention;

[0029] Figure 6 This is a schematic diagram of system functions in an intelligent connected environment provided by the present invention;

[0030] Figure 7 A decision logic process diagram for the vehicle cooperative merging function provided by the present invention;

[0031] Figure 8 The logical flowchart of the safety hazard event triggering condition analysis method provided by the present invention. Detailed Implementation

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

[0033] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0034] Please see Figure 1 As shown, this embodiment of the invention provides a vehicle-road cooperative autonomous driving system, including a first-level hierarchical control structure and a second-level hierarchical control structure. The first-level hierarchical control structure includes a driver module 1, an HMI system 2, a vehicle-side module 3, a roadside module 4, a cloud module 5, and an environmental information module 6.

[0035] The environmental information module 6 is used to collect environmental information and send the corresponding environmental information to the driver module 1, the vehicle-side module 3, the cloud module 5, and the roadside module 4 respectively.

[0036] The environmental information includes road information, road facility information, target object information, vehicle status information, external weather status information, sensor perception information, and traffic flow information.

[0037] The driver module 1 is used to receive environmental information and send driver status information and system control switch information to the HMI system module 2.

[0038] Specifically, the environmental information received by the driver module 1 includes road information, weather information, road facility information, and target object information.

[0039] The HMI system module 2 is used to receive driver status information and system control switch information, and send the system operation status and system switch control information to the vehicle-side module 3 for control.

[0040] The vehicle-side module 3 is used to receive environmental information and send vehicle status information to other road participants in the environmental information module 6.

[0041] Specifically, the environmental information received by the vehicle-side module 3 includes external weather information, sensor perception information, and other vehicle status information.

[0042] The roadside module 4 is used to receive environmental information and send all vehicle status information of the road section to the cloud module 5.

[0043] The environmental information received by the roadside module 4 includes road segment information, vehicle status information, road facility information, and road participant information.

[0044] The cloud module 5 is used to receive and process control information, and then feed back the collaborative decision-making control information of each vehicle to the vehicle-side module 3 and other road participants in the environmental information module 6 through the roadside module 4. The vehicle-side module 3 then feeds back the system operation status and system request information of the vehicle-side to the driver module 1 through the HMI system 2 module to form a closed-loop control.

[0045] The cloud module 5 also receives environmental information and processes it together with the vehicle status information sent by the roadside module 4 and the vehicle status information and vehicle request information sent by the vehicle terminal module 3. It then feeds back scheduling information, other vehicle information and road information to the vehicle terminal module 3 and feeds back decision control information of each vehicle to the roadside module 4.

[0046] Specifically, the environmental information received by the cloud module 5 includes meteorological information, road condition information, and traffic flow information.

[0047] The second-level hierarchical control structure analyzes the control architecture of roadside module 4, cloud module 5, and vehicle-side module 3 in conjunction with the specific environmental conditions (intelligent connected environment).

[0048] Combined Figure 2As shown, the roadside module 4 includes a roadside perception module 41, a roadside computing module 42, and a roadside communication module 43. The roadside perception module 41 receives environmental information (road segment information, vehicle status information, road facilities, and road participant information) from the environmental information module and vehicle-side perception information and cloud-based perception information from the roadside communication module 43. Then, it sends control information (vehicle position, speed, acceleration, external environment, traffic flow data information, and roadside and vehicle-side collaborative perception information) to the roadside computing module 42. The roadside computing module 42 then sends the control information processed by the roadside edge computing unit (MEC) to the roadside communication module 43. The roadside communication module 43 feeds back the information reception results to the roadside computing module 42, and the roadside computing module 42 feeds back the calculation results to the roadside perception module 41, forming a closed-loop control.

[0049] The roadside communication module 43 communicates with the vehicle-side OBU (On Board Unit) through the roadside communication unit RSU. It receives vehicle decision control schemes, vehicle perception information and collaborative perception information from the vehicle-side module 3 and transmits them to the cloud module 5 in the form of vehicle status information stream. At the same time, it receives collaborative decision control schemes and cloud environment information from the cloud module 5. The information is then transmitted and fed back to the roadside perception module 41 and the vehicle-side module 3 through the roadside communication unit RSU in the roadside communication module 43 to form a closed-loop feedback.

[0050] Combined Figure 3As shown, the vehicle-side module 3 includes a communication module 31, a perception module 32, a decision control module 33, an execution module 34, and sensors 35. The sensors 35 include speed sensors, acceleration sensors, etc., used to receive sensing information (external environmental information, distance, speed, and position of target objects, road environment and road attributes, etc.) and send it to the perception module 32. The perception module 32 simultaneously receives information from the roadside communication unit (RSU). The Unit processes, understands, and fuses data using roadside information and other vehicle status information transmitted through the communication module 31. The decision control module 33 receives positioning perception information output by the perception module 32 and collaborative decision control instructions from the roadside and cloud to select decision strategies, generate path plans, and acquire control instructions. The execution module 34 receives decision information and control instructions from the decision control module 33 and system status execution monitoring information transmitted by the driver through the HMI system, and performs control steering, drive control, and braking control operations. After completing the execution operation, the execution module 34 feeds back the execution status to the communication module 31 and the decision control module 33. The decision control module 33 then feeds back the decision control status to the perception module 32 to form a closed-loop control. At the same time, the decision control module 33 feeds back vehicle-side decision control requests through the communication module 31 to the roadside, cloud, driver, and HMI system, forming a feedback loop for the entire system.

[0051] It should be noted that the sensing module 32 includes millimeter-wave radar and a camera.

[0052] Combined Figure 4 As shown, the cloud module 5 includes an application platform 51, a data receiving and sending module 52, a data processing and calculation module 53, and a database 54. The application platform 51 receives regional cloud information (weather information, high-precision map information, video entertainment information, and road condition information) and transmits it to the data receiving and sending module 52. Simultaneously, the data receiving and sending module 52 also receives perception information from the vehicle and roadside, and sends the regional road segment and vehicle status information stream formed by combining and classifying the information to the data processing and calculation module 53. The data processing and calculation module 53 performs multi-source data fusion processing on the transmitted data to obtain a multi-source fused data set, which is stored in the database 54. The database 54 then feeds back the data processing and calculation results to the data processing and calculation module 53. The data receiving and sending module 53 receives the calculation results and, based on the received information, feeds back collaborative decision control information to the vehicle and roadside, and feeds back the regional vehicle status information stream to the application platform 51, forming an overall system feedback.

[0053] It should be noted that the data processing and computing module 53 includes cloud computing, big data processing, etc.

[0054] Please see Figure 5 As shown, the present invention also provides a method for analyzing the triggering conditions of safety hazards in vehicle-road cooperative autonomous driving based on the aforementioned vehicle-road cooperative autonomous driving system, comprising the following steps:

[0055] Step S1: Standardize the functions of the vehicle-road cooperative autonomous driving system, define the system design and operating conditions, and analyze the system decision-making logic process;

[0056] Step S2: Identify system-wide vehicle-level hazards and define the corresponding safety constraints; conduct risk assessment based on system functional specifications and safety constraint requirements, initially construct performance limitation and trigger condition tables, and establish a multi-level hierarchical system control structure. The first-level hierarchical control structure models the overall system structure, and the second-level hierarchical control structure refines the modeling of system sub-modules in combination with the environment.

[0057] Step S3: Identify potentially dangerous unsafe control behaviors based on different levels of the system's control structure, and identify system performance limitations and corresponding triggering conditions for hazardous events or unsafe control behaviors.

[0058] In step one, the main functions of the vehicle-road cooperative autonomous driving system include the roadside communication unit (RSU) acquiring information about all vehicles within its communication coverage area, the roadside edge computing unit (MEC) performing cooperative decision-making and control of vehicles within the road segment, and vehicles within the road segment executing the decision-making and control information transmitted by the roadside communication unit (RSU).

[0059] Based on the system functional specifications, the system design and operation conditions are defined. The design and operation conditions cover the design and operation domain (ODD), vehicle status, driver and passenger status, and other necessary conditions. The requirements of elements within the system ODC are clarified, and the system design and operation conditions are defined.

[0060] Based on the system functional specifications and system design and operation conditions, the system decision-making logic process is analyzed. First, the sensing end uses a roadside sensing module and a vehicle-side sensing module to jointly sense environmental information. The roadside computing module 42 regulates the system decision-making logic process. Finally, the roadside communication module 43 sends decision control information to vehicles within the roadside communication coverage area.

[0061] In step two, vehicle-level hazards include collisions with vehicles ahead, collisions with obstacles ahead, rear-end collisions with vehicles behind, HMI system failure to process driver takeover information, interruption of roadside communication unit (RSU) communication, and collisions with vehicles within the communication range of the roadside communication unit (RSU).

[0062] Safety constraints are the conditions or behaviors that a system is required to meet in order to prevent hazards from occurring and ultimately prevent losses. Based on the defined vehicle-level hazards, system-level safety constraints can be identified, which mainly include maintaining a minimum safe distance from the vehicle in front, the perception unit identifying obstacles to avoid collisions, the roadside unit (RSU) coordinating decision-making and control of vehicles within the roadside communication coverage area to adjust speed and spacing to prevent unintended control behaviors by the vehicle, the vehicle responding promptly and correctly to driver takeover information, the roadside communication unit (RSU) ensuring normal communication, and vehicles within the roadside communication unit's communication range avoiding collisions.

[0063] Risk assessment determines whether vehicle-level hazards are related to and uncontrollable by expected functional safety, using severity and controllability evaluation. The severity of a hazard and its potential consequences is defined as Severity (S). Unlike the specific S, E, and C levels in ISO 26262, S in SOTIF is limited to 0 and greater than 0. When S is greater than 0, the severity of the hazard is unacceptable; when S equals 0, the severity is acceptable. Controllability (C) assesses the controllability of a hazard and its potential consequences, also taking only 0 and greater than 0 values. When C is greater than 0, the occurrence of the hazard is uncontrollable; when C equals 0, the occurrence of the hazard is controllable. A hazard is considered acceptable only when both S and C are 0. In any other case, the hazard is unacceptable and requires preventative measures. A multi-level hierarchical system control structure is established. The first-level hierarchical control structure models the overall system structure, while the second-level hierarchical control structure refines the modeling of system sub-modules in conjunction with the environment.

[0064] In step three, unsafe control behavior refers to control behavior that causes harm to the entire vehicle under specified conditions and worst-case environments. The specific process is to perform a safety analysis on the control behavior of each controller in the control structure based on the STPA hierarchical control structure and STPA guide words, and identify unsafe control behaviors that cause vehicle-level harm to the system.

[0065] Next, using the Fault Tree Analysis (FTA) method, we analyze from the hazardous events and unsafe control behaviors downwards in an AND-OR manner, considering why unsafe control behaviors occur, why control behaviors are poorly executed or not executed, leading to danger. This yields the risk triggering sources and triggering mechanisms of the hazardous events (triggering sources are elements with specific attributes and characteristics that can cause system performance limitations; triggering mechanisms are the formation of triggering conditions jointly described by triggering modes and triggering factors; triggering modes are the ways in which different working stages of the system are directly affected by triggering sources to form triggering conditions; triggering factors are the key attributes that affect the system's function or performance in different working stages under different triggering modes).

[0066] By analyzing the unsafe control behaviors of vehicle-road cooperative autonomous driving systems in intelligent connected environments, the vehicle-side system structure is refined into perception, decision-making, control, and communication. The "AND" and "OR" relational operators are used to trace the sources of hazards, obtain the causes of unacceptable hazardous events in the risk assessment, and match performance limitations with triggering conditions to analyze and evaluate the performance limitation table and triggering condition table of hazardous events.

[0067] The vehicle-road cooperative autonomous driving method provided by the present invention will be described in detail below with specific embodiments.

[0068] Example

[0069] Combined Figure 6 As shown, the applicability and advantages of this method are illustrated using a high-speed ramp cooperative lane merging system in a vehicle-road cooperative autonomous driving system as an example. First, the function of the high-speed ramp cooperative lane merging system is described. In an intelligent connected environment, vehicle control in the ramp merging area is mainly divided into four regions: upstream of the merging area, the advance lane-changing area, the cooperative merging area, and downstream of the merging area. The details of each of these four regions and their functions are described below.

[0070] 1. The upstream area of ​​the merging zone is located in the starting area of ​​the cooperative merging. The Roadside Communicator (RSU) is responsible for detecting road information, vehicle information, and vehicle service request information within its communication coverage area. Once a vehicle is detected passing on the main road or ramp, the RSU immediately transmits this information to the Roadside Edge Computing Unit (MEC) for further processing and decision-making.

[0071] 2. The advance lane-change zone is located upstream of the merging zone. Its core function is to coordinate lane changes for the main road convoy and calculate the coordinated speed and merging point. After the main road convoy enters the advance lane-change zone, the Roadside Utility Unit (RSU) receives service request information and vehicle status information streams from all vehicles within its coverage area. This information is then transmitted to the Roadside Edge Computing Unit (MEC) to determine whether the convoy located on Main Road 1 needs lane-change processing. The MEC then calculates the coordinated speed and merging point of the vehicles and finally sends the convoy and ramp vehicle decision control information and merging point to the coordinating vehicles via the RSU.

[0072] 3. The cooperative merging zone is a critical area for vehicle speed coordination, platoon spacing adjustment, and merging operations. In this zone, Roadside Units (RSUs) monitor in real time the speed, position, acceleration, and vehicle requests of both platoon and ramp vehicles at any location. The RSUs ensure that cooperating vehicles follow the decision-making and control information they provide, and that drivers avoid abnormal control behaviors (lane changes, arbitrary acceleration / deceleration, overtaking, etc.). Furthermore, the RSUs are responsible for regulating the speed of platoons on the main road and ramp vehicles, creating reasonable gaps at the merging point to ensure that ramp vehicles can merge smoothly and safely.

[0073] 4. The downstream area of ​​the merging zone is the area after the merging operation is completed. In this area, vehicles continue to drive normally based on their own status and the latest decision control information provided by the roadside communication unit (RSU), thereby ensuring smooth and safe traffic flow.

[0074] Design operating conditions refer to the collective term for all conditions applicable to the functional operation of a driving automation system, determined during its design. These include the design operating range, vehicle status, driver and passenger status, and other necessary conditions. Compared to single-vehicle autonomous driving systems, the highway ramp cooperative lane merging system (ODC) has the following requirements: ensuring the normal operation of the roadside module and cloud module sub-functions; having at least two main road lanes; good road surface quality; clear traffic signs; clear and complete lane markings; lane direction of travel on the right; daily rainfall less than 10mm; wind force not exceeding level 4; visibility greater than 2km; no snow or fog; and vehicle functional status meeting system design requirements.

[0075] Design of the decision logic process for a high-speed ramp cooperative lane merging system, such as Figure 7 As shown, based on the characteristics of vehicle operation in the merging zone, the vehicle decision-making logic process in an intelligent connected environment can be summarized into the following steps:

[0076] 1. Obtain vehicle information in the merging area of ​​the ramps;

[0077] 2. Determine whether vehicles on the main road need to change lanes;

[0078] 3. The roadside edge computing unit (MEC) coordinates the decision-making and control of merging vehicles to coordinate their speeds;

[0079] 4. Vehicles on the main road and ramps merge into the main road via the ramps.

[0080] After completing the system function description, the key control actions (system identification of ramp vehicles) are analyzed in conjunction with the specific environment (intelligent connected environment) and STPA guiding words (required but not provided). Then, the severity and controllability of hazardous events are assessed, with the evaluation result being unacceptable (S>0, ramp vehicle speed is high; C>0, high-speed vehicles cannot brake in time to avoid collision). Next, the system control structure is modeled. Initially, the system is divided into six modules: driver module, HMI system, vehicle-side module, roadside module, cloud module, and environmental information module. The roadside module is then further decomposed into a roadside perception module, a roadside communication module, and a roadside computing module.

[0081] The hazard event or an unsafe control behavior in the STPA analysis method is taken as the top event of the FTA analysis method, while performance limitations and triggering conditions are taken as the bottom events of the FTA analysis method. Figure 8 Using the FTA analysis method, when the main road convoy and ramp vehicles merge together, the system failed to identify ramp vehicles as a hazard event for analysis, and a performance limitation table and a trigger condition table were obtained.

[0082] FTA analysis process as follows Figure 8 As shown, when the main road convoy merges with ramp vehicles, the system fails to identify ramp vehicles as the top event in the FTA analysis method. This is first analyzed through driver, roadside, vehicle, and cloud modules. Then, based on the failure of the roadside perception, communication, and computing modules in the second-level hierarchical control structure to identify ramp vehicles as an intermediate event, the roadside perception module is further subdivided into three main components: millimeter-wave radar, lidar, and cameras. Finally, the performance limitations and triggering conditions that may lead to hazardous events are analyzed. Tables 1 and 2 respectively analyze the performance limitations and triggering conditions of the roadside perception module.

[0083] Table 1 System Performance Limitations

[0084] PL-1 Millimeter-wave radar uses low frequency PL-2 Millimeter-wave radar has low resolution PL-3 Millimeter-wave radar has a low detection angle. PL-4 Millimeter-wave radar has too short a detection range PL-5 Millimeter-wave radar has insufficient detection accuracy PL-6 Millimeter-wave radar has too small an operating temperature range PL-7 Millimeter-wave radar is blocked PL-8 Millimeter-wave radar installed in the wrong location PL-9 Low camera sampling frequency PL-10 The camera's sensing ability is reduced due to visibility limitations. PL-11 Camera affected by humidity PL-12 Camera affected by temperature PL-13 Camera pixel count is too low PL-14 Insufficient camera detection range PL-15 The camera is installed in an incorrect location. PL-16 Excessive camera distortion PL-17 The camera has low contrast and is affected by lighting conditions. PL-18 LiDAR is blocked PL-19 …

[0085] Table 2 System Triggering Conditions

[0086]

[0087]

[0088] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0089] Furthermore, it should be noted that the scope of the methods and systems in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. In addition, features described with reference to certain examples may be combined in other examples.

[0090] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A method for analyzing a vehicle-road cooperation automatic driving safety hazard event trigger condition, characterized in that, Includes the following steps: Step 1: Standardize the functions of the vehicle-road cooperative autonomous driving system, define the system design and operating conditions, and analyze the system decision-making logic process. The functions of the vehicle-road cooperative autonomous driving system include the roadside communication unit (RSU) acquiring information about all vehicles within its communication coverage area, the roadside edge computing unit (MEC) performing cooperative decision-making control of vehicles within the road segment, and vehicles within the road segment executing the decision-making control information transmitted by the roadside communication unit (RSU). Define the system design operating conditions, including the design operating conditions covering the design operating scope ODD, vehicle status, and driver and passenger status, clarify the element requirements within the system ODC, and define the system design operating conditions. The analytical system's decision-making logic process includes firstly, the perception end uses a roadside perception module and a vehicle-side perception module to jointly perceive environmental information, then the roadside computing module regulates the system's decision-making logic process, and finally the roadside communication module sends decision control information to vehicles within the roadside communication coverage area. Step two: Identify system-wide vehicle-level hazards and define the corresponding safety constraints. Based on system functional specifications and safety constraints, risk assessments are conducted, performance limitations and trigger condition tables are initially constructed, and a multi-level hierarchical system control structure is established. The first-level hierarchical control structure models the overall system structure, while the second-level hierarchical control structure refines the modeling of system sub-modules in conjunction with the environment. Vehicle-level hazards include collisions with vehicles ahead, collisions with obstacles ahead, rear-end collisions with vehicles behind, HMI system failure to process driver takeover information, roadside unit (RSU) communication interruption, and collisions between vehicles within the RSU communication range. Safety constraints include maintaining a minimum safe distance from the vehicle ahead, the sensing unit identifying obstacles to avoid collisions, the roadside unit (RSU) coordinating decision-making and control to adjust the speed and spacing of vehicles within the roadside communication coverage area to prevent unintended control behaviors by the vehicle, the vehicle responding promptly and correctly to driver takeover requests, the RSU ensuring normal communication, and vehicles within the RSU's communication range avoiding collisions. Step 3: Identify potentially dangerous unsafe control behaviors based on the different levels of the system's control structure, and identify system performance limitations and corresponding triggering conditions for hazardous events or unsafe control behaviors.

2. The method of claim 1, wherein, In step three, unsafe control behaviors refer to control behaviors that cause harm to the entire vehicle under specified conditions and worst-case environments. This includes: conducting safety analysis on the control behavior of each controller in the control structure based on the STPA hierarchical control structure and STPA guide words, and identifying unsafe control behaviors that cause vehicle-level harm to the system.

3. The method of claim 2, wherein, The performance limitations and corresponding triggering conditions of the system for identifying hazardous events or unsafe control behaviors include: Using the fault tree analysis method, we analyze from the hazardous events and unsafe control behaviors downwards in the form of "AND" and "OR", considering why unsafe control behaviors occur, why control behaviors are poorly executed or not executed, and thus leading to danger, thereby obtaining the risk triggering source and triggering mechanism of the hazardous events; By analyzing the unsafe control behaviors of vehicle-road cooperative autonomous driving systems in intelligent connected environments, the vehicle-side system structure is refined into perception, decision-making, control, and communication. The "AND" and "OR" relational operators are used for hazard tracing to obtain the causes of unacceptable hazardous events in risk assessment. Performance limitations are matched with triggering conditions to analyze and evaluate the performance limitation table and triggering condition table of hazardous events.

4. A control structure for a vehicle-road cooperative automated driving system for implementing the method according to any one of claims 1-3, characterized in that, It includes a first-level hierarchical control structure and a second-level hierarchical control structure. The first-level hierarchical control structure includes a driver module, an HMI system module, a vehicle-side module, a roadside module, a cloud module, and an environmental information module, wherein: The environmental information module is used to collect environmental information and send the corresponding environmental information to the driver module, the vehicle module, the cloud module and the roadside module respectively; The driver module is used to receive environmental information and send driver status information and system control switch information to the HMI system module; The HMI system module is used to receive driver status information and system control switch information, and send the system operating status and system control switch information to the vehicle-side module for control. The vehicle-side module is used to receive environmental information and send vehicle status information to other road participants in the environmental information module; The roadside module is used to receive environmental information and send all vehicle status information in the road segment to the cloud module and the vehicle-side module. The cloud module is used to receive and process control information, and then feed back the collaborative decision-making control information of each vehicle to other road participants in the vehicle module and the environmental information module through the roadside module. The vehicle module then feeds back the system operation status and system request information of the vehicle to the driver module through the HMI system module to form a closed-loop control. The cloud module also receives environmental information and processes it together with the vehicle status information sent by the roadside module and the vehicle status information and vehicle request information sent by the vehicle terminal module. It then feeds back scheduling information, other vehicle information and road information to the vehicle terminal module and feeds back decision control information of each vehicle to the roadside module. The second-level hierarchical control structure analyzes the control architecture of the roadside module, the cloud module, and the vehicle-side module in conjunction with specific environmental conditions.

5. The control structure for a vehicle-road cooperative automated driving system according to claim 4, characterized in that, The environmental information collected by the environmental information module includes road information, road facility information, target object information, vehicle status information, external weather status information, sensor perception information, and traffic flow information.

6. The control structure for a vehicle-road cooperative automated driving system according to claim 5, characterized in that, The roadside module includes a roadside perception module, a roadside computing module, and a roadside communication module. The roadside perception module receives environmental information from the environmental information module and vehicle-side perception information and cloud-based perception information from the roadside communication module. Then, it sends control information to the roadside computing module. The roadside computing module then sends the control information, which has been processed by the roadside edge computing unit (MEC), to the roadside communication module. The roadside communication module feeds back the information reception results to the roadside computing module. The roadside computing module then feeds back the calculation results to the roadside perception module, forming a closed-loop control. The roadside communication module communicates with the vehicle-mounted OBU through the roadside communication unit (RSU). It receives vehicle decision control schemes and vehicle perception information from the vehicle-mounted module and collaborative perception information from the roadside perception module, and transmits them to the cloud module in the form of vehicle status information stream. At the same time, it receives collaborative decision control schemes and cloud environment information from the cloud module. The information is then fed back to the roadside perception module and the vehicle-mounted module through the roadside communication unit (RSU) in the roadside communication module to form a closed-loop feedback. 7.The vehicle infrastructure integration autonomous driving system control structure of claim 6, wherein, The vehicle-side module includes a communication module, a perception module, a decision control module, an execution module, and sensors. The sensors receive sensing information and send it to the perception module. The perception module simultaneously receives roadside information and other vehicle status information transmitted from the roadside communication unit (RSU) through the communication module, and performs data processing, scenario understanding, and data fusion. The decision control module receives the positioning perception information output by the perception module and collaborative decision control commands from the roadside and cloud, and performs decision strategy selection, path planning generation, and control command acquisition. The execution module receives decision information and control commands from the decision control module and system status execution monitoring information transmitted by the driver through the HMI system, and performs control steering, drive control, and braking control operations. After completing the execution operation, the execution module feeds back the execution status to the communication module and the decision control module. The decision control module then feeds back the decision control status to the perception module to form a closed-loop control. At the same time, the decision control module feeds back vehicle-side decision control requests through the communication module to the roadside, cloud, driver, and HMI system, forming a feedback loop for the entire system. 8.The vehicle infrastructure integration autonomous driving system control structure of claim 7, wherein, The cloud module includes an application platform, a data receiving and sending module, a data processing and computing module, and a database. The application platform receives regional cloud information and transmits it to the data receiving and sending module. Simultaneously, the data receiving and sending module also receives perception information from vehicle-side and road-side devices, and sends the regional road segment and vehicle status information stream formed by combining and classifying the information to the data processing and computing module. The data processing and computing module performs multi-source data fusion processing on the transmitted data to obtain a multi-source fused data set, which is stored in the database. The database then feeds back the data processing and computing results to the data processing and computing module. The data receiving and sending module receives the computing results and, based on the received information, feeds back collaborative decision-making and control information to the vehicle-roadside devices, and feeds back the regional vehicle status information stream to the application platform, forming an overall system feedback.

Images