Control method and device for autonomous vehicle, equipment and medium

Abstract

The invention provides a control method and device for an automatic driving vehicle, equipment and a medium, and relates to the technical field of artificial intelligence, in particular to the technical field of automatic driving. According to the implementation scheme, in response to monitoring that the autonomous vehicle has a target fault, a target control strategy is determined based on the target fault; and controlling the autonomous vehicle based on the target control strategy, the determination process of the target control strategy comprising: obtaining a directed graph, the directed graph comprising a plurality of hardware nodes and a plurality of function nodes that can be monitored, and further comprising a plurality of first edges for representing a fault propagation relationship between the nodes at the two ends; determining at least one associated function node having a communication path with a target node corresponding to the target fault based on the plurality of first edges; determining the fault severity level of the target node based on the fault severity level corresponding to the at least one associated function node; and determining a target control strategy based on a preset control strategy corresponding to the fault severity level of the target node.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and more particularly to the field of autonomous driving technology, specifically to a control method, apparatus, electronic device, computer-readable storage medium, and computer program product for an autonomous vehicle. Background Technology

[0002] With the rapid development of computer technology and artificial intelligence, autonomous vehicles have shown broad application prospects in various fields such as transportation, military, logistics and warehousing, and daily life. As autonomous driving technology advances, the complexity of autonomous vehicle system architecture continues to increase, with numerous sensors, controllers, and actuators installed within the vehicles. During vehicle operation, these components inevitably experience various malfunctions. To improve the safety of autonomous vehicles, accurate and efficient fault response decision-making mechanisms are crucial.

[0003] Existing fault handling solutions for autonomous vehicles typically employ static fault response strategy configuration mechanisms. Specifically, during the system development phase, engineers assign fixed response strategies to various fault types based on experience. When a fault occurs, the system directly executes the corresponding control strategy based on the pre-set fault-response strategy mapping relationship to ensure vehicle safety. However, this approach of handling each fault in isolation lacks flexibility and is prone to overreacting to minor triggers (e.g., emergency braking due to fluctuations in non-critical sensors) or underreacting to potentially serious risks (e.g., failing to identify the underlying triggers leading to higher-level functional failures), thus affecting vehicle efficiency or safety. Furthermore, this static fault response strategy configuration mechanism cannot characterize the correlation between different faults, lacks dynamic adaptability, and is difficult to optimize and adjust efficiently and accurately during autonomous driving system optimization or software iteration.

[0004] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention

[0005] This disclosure provides a control method, apparatus, electronic device, computer-readable storage medium, and computer program product for an autonomous vehicle.

[0006] According to one aspect of this disclosure, a control method for an autonomous vehicle is provided, comprising: in response to detecting a target fault in the autonomous vehicle, determining a target control strategy based on the target fault; and controlling the autonomous vehicle based on the target control strategy, wherein the target control strategy is determined by: acquiring a directed graph, wherein the directed graph includes a plurality of hardware nodes for representing a plurality of detectable hardware faults in the autonomous vehicle and a plurality of functional nodes for representing a plurality of functional faults in the autonomous vehicle, the directed graph including a plurality of first edges, each first edge representing a fault propagation relationship between nodes at both ends of the first edge; determining at least one associated functional node having a connected path with the target node corresponding to the target fault based on the plurality of first edges; determining a fault severity level of the target node based on a fault severity level corresponding to the at least one associated functional node; and determining the target control strategy based on a preset control strategy corresponding to the fault severity level of the target node.

[0007] According to one aspect of this disclosure, a control device for an autonomous vehicle is provided, comprising: a first determining unit configured to determine a target control strategy based on the target fault in response to detecting a target fault occurring in the autonomous vehicle; and a control unit configured to control the autonomous vehicle based on the target control strategy, wherein the target control strategy is determined using a second determining unit, the second determining unit comprising: an acquiring subunit configured to acquire a directed graph, wherein the directed graph includes a plurality of hardware nodes for characterizing a plurality of detectable hardware faults in the autonomous vehicle and a plurality of functional nodes for characterizing a plurality of functional faults in the autonomous vehicle, the directed graph including a plurality of first edges, each first edge being used to characterize a fault propagation relationship between nodes at both ends of the first edge; a first determining subunit configured to determine at least one associated functional node having a connected path to the target node corresponding to the target fault based on the plurality of first edges; a second determining subunit configured to determine a fault severity level of the target node based on a fault severity level corresponding to the at least one associated functional node; and a third determining subunit configured to determine the target control strategy based on a preset control strategy corresponding to the fault severity level of the target node.

[0008] According to one aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the control method for the autonomous vehicle described above.

[0009] According to one aspect of this disclosure, an autonomous vehicle is provided, including the aforementioned electronic equipment.

[0010] According to one aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the control method of the above-described autonomous vehicle.

[0011] According to one aspect of this disclosure, a computer program product is provided, including a computer program, wherein the computer program, when executed by a processor, is capable of implementing the aforementioned control method for an autonomous vehicle.

[0012] According to one or more embodiments of this disclosure, corresponding control strategies can be adopted based on the actual impact of the monitored vehicle faults on the upper-level functions, thereby improving the safety and reliability of autonomous vehicles.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0015] Figure 1 A schematic diagram of an exemplary system in which various methods described herein may be implemented, according to exemplary embodiments of the present disclosure;

[0016] Figure 2 A flowchart illustrating a control method for an autonomous vehicle according to an exemplary embodiment of the present disclosure is shown; Figure 3 A schematic diagram of a directed graph according to an exemplary embodiment of the present disclosure is shown; Figure 4 A schematic diagram of a directed graph according to another exemplary embodiment of the present disclosure is shown; Figure 5 A schematic diagram of a directed graph according to another exemplary embodiment of the present disclosure is shown; Figure 6 A structural block diagram of a control device for an autonomous vehicle according to an exemplary embodiment of the present disclosure is shown; Figure 7 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0017] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0018] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0019] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. Furthermore, the term "and / or" as used in this disclosure covers any one of the listed items and all possible combinations thereof.

[0020] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0021] Figure 1 A schematic diagram of an exemplary system 100 in which the various methods and apparatus described herein can be implemented according to embodiments of this disclosure is shown. Reference Figure 1 The system 100 includes a motor vehicle 110, a server 120, and one or more communication networks 130 that couple the motor vehicle 110 to the server 120.

[0022] In embodiments of this disclosure, the motor vehicle 110 may include a computing device according to embodiments of this disclosure and / or be configured to perform a method according to embodiments of this disclosure.

[0023] Server 120 may run one or more services or software applications for controlling autonomous vehicles. In some embodiments, server 120 may also provide other services or software applications, which may include non-virtual environments and virtual environments. Figure 1In the configuration shown, server 120 may include one or more components that implement the functions performed by server 120. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. A user of motor vehicle 110 may sequentially interact with server 120 using one or more client applications to utilize the services provided by these components. It should be understood that various different system configurations are possible and may differ from system 100. Therefore, Figure 1 This is an example of a system used to implement the various methods described herein, and is not intended to be limiting.

[0024] Server 120 may include one or more general-purpose computers, special-purpose server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. Server 120 may include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices for servers). In various embodiments, server 120 may run one or more services or software applications that provide the functionality described below.

[0025] The computing unit in server 120 can run one or more operating systems, including any of the aforementioned operating systems and any commercially available server operating system. Server 120 can also run any of a variety of additional server applications and / or middleware applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

[0026] In some implementations, server 120 may include one or more applications to analyze and merge data feeds and / or event updates received from vehicle 110. Server 120 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of vehicle 110.

[0027] Network 130 can be any type of network well known to those skilled in the art, and can use any of a variety of available protocols (including, but not limited to, TCP / IP, SNA, IPX, etc.) to support data communication. By way of example only, one or more networks 130 can be satellite communication networks, local area networks (LANs), Ethernet-based networks, token ring networks, wide area networks (WANs), the Internet, virtual networks, virtual private networks (VPNs), intranets, extranets, blockchain networks, public switched telephone networks (PSTNs), infrared networks, wireless networks (including, for example, Bluetooth, WiFi), and / or any combination of these with other networks.

[0028] System 100 may also include one or more databases 150. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 150 may be used to store information such as audio files and video files. The data repository 150 may reside in various locations. For example, a data repository used by server 120 may be local to server 120, or it may be located away from server 120 and may communicate with server 120 via a network-based or dedicated connection. The data repository 150 may be of different types. In some embodiments, the data repository used by server 120 may be a database, such as a relational database. One or more of these databases may store, update, and retrieve data from and from the database in response to commands.

[0029] In some embodiments, one or more of the databases 150 may also be used by an application to store application data. The databases used by the application may be of different types, such as key-value stores, object stores, or regular stores supported by a file system.

[0030] Motor vehicle 110 may include sensors 111 for sensing the surrounding environment. Sensors 111 may include one or more of the following sensors: a visual camera, an infrared camera, an ultrasonic sensor, a millimeter-wave radar, and a lidar (LiDAR). Different sensors can provide different detection accuracy and range. Cameras may be mounted in front of, behind, or at other locations on the vehicle. Visual cameras can capture the situation inside and outside the vehicle in real time and present it to the driver and / or passengers. In addition, by analyzing the images captured by the visual cameras, information such as traffic light indications, intersection conditions, and the operating status of other vehicles can be obtained. Infrared cameras can capture objects in night vision conditions. Ultrasonic sensors may be mounted around the vehicle to measure the distance of objects outside the vehicle using the strong directionality of ultrasound. Millimeter-wave radar may be mounted in front of, behind, or at other locations on the vehicle to measure the distance of objects outside the vehicle using the characteristics of electromagnetic waves. LiDAR may be mounted in front of, behind, or at other locations on the vehicle to detect the edges and shape information of objects, thereby performing object recognition and tracking. Due to the Doppler effect, the radar device can also measure the speed changes of the vehicle and moving objects.

[0031] The motor vehicle 110 may also include a communication device 112. The communication device 112 may include a satellite positioning module capable of receiving satellite positioning signals (e.g., BeiDou, GPS, GLONASS, and GALILEO) from satellite 141 and generating coordinates based on these signals. The communication device 112 may also include a module for communicating with a mobile communication base station 142. The mobile communication network can implement any suitable communication technology, such as current or emerging wireless communication technologies (e.g., 5G technology) like GSM / GPRS, CDMA, and LTE. The communication device 112 may also have a vehicle-to-everything (V2X) module, configured to enable vehicle-to-the-world communication, for example, vehicle-to-vehicle (V2V) communication with other vehicles 143 and vehicle-to-infrastructure (V2I) communication with infrastructure 144. Furthermore, the communication device 112 may also have a module configured to communicate with a user terminal 145 (including, but not limited to, smartphones, tablets, or wearable devices such as watches) via, for example, a wireless local area network conforming to the IEEE 802.11 standard or Bluetooth. Using the communication device 112, the motor vehicle 110 can also access the server 120 via the network 130.

[0032] The motor vehicle 110 may also include a control unit 113. The control unit 113 may include a processor, such as a central processing unit (CPU) or a graphics processing unit (GPU), or other dedicated processors, that communicates with various types of computer-readable storage devices or media. The control unit 113 may include an autonomous driving system for automatically controlling various actuators in the vehicle. The autonomous driving system is configured to control the powertrain, steering system, and braking system of the motor vehicle 110 (not shown) via multiple actuators in response to inputs from multiple sensors 111 or other input devices to control acceleration, steering, and braking respectively, without human intervention or with limited human intervention. Some processing functions of the control unit 113 can be implemented via cloud computing. For example, some processing can be performed using an onboard processor while other processing can be performed using cloud computing resources. The control unit 113 may be configured to perform methods according to this disclosure. Furthermore, the control unit 113 may be implemented as an example of a computing device on the motor vehicle side (client) according to this disclosure.

[0033] Figure 1 The system 100 can be configured and operated in various ways to enable the application of the various methods and apparatus described in this disclosure.

[0034] With the development of autonomous driving technology, the complexity of autonomous vehicle system architecture is constantly increasing, with numerous sensors, controllers, and actuators installed in vehicles. During vehicle operation, these components inevitably experience various malfunctions. To ensure driving safety, existing fault handling solutions typically employ static fault response strategy configuration mechanisms. Specifically, during the system development phase, engineers bind fixed response strategies to various types of faults based on experience. When a fault occurs, the system directly executes the corresponding control strategy based on the pre-set fault-response strategy mapping relationship to ensure vehicle driving safety. However, this approach of handling each fault in isolation has significant drawbacks: it ignores the complex causal and propagation relationships between vehicle hardware module faults and vehicle functional faults. For example, a low-level sensor fault may lead to the failure of multiple high-level functions, or it may be covered by redundancy mechanisms, thus posing no actual harm. Therefore, this approach is prone to unintended execution of safety strategies, manifesting as overreaction to minor triggers (e.g., emergency braking due to fluctuations in non-critical sensors) or underreaction to potentially serious risks (e.g., failure to identify the underlying triggers causing high-level functional failures), thereby affecting vehicle safety and availability.

[0035] Based on this, this disclosure provides a control method for autonomous vehicles. By constructing a directed graph to model the fault propagation relationship between the underlying physical hardware faults and the upper-level functional faults, it is possible to map the corresponding functional faults of the monitorable hardware faults to the fault severity level. This is equivalent to determining the actual impact range and severity of a specific hardware fault based on the fault propagation path, so as to more accurately determine the response strategy when an autonomous vehicle malfunctions, thereby improving the driving safety of autonomous vehicles.

[0036] Figure 2 A flowchart of a control method 200 for an autonomous vehicle according to an exemplary embodiment of the present disclosure is shown. Figure 2 As shown, method 200 includes: Step S210: In response to detecting a target fault in the autonomous vehicle, determine a target control strategy based on the target fault; and Step S220: Control the autonomous vehicle based on the target control strategy. The target control strategy is determined using the following steps S211-S214: Step S211: Obtain a directed graph, wherein the directed graph includes multiple hardware nodes for representing multiple hardware faults that can be monitored in the autonomous vehicle and multiple functional nodes for representing multiple functional faults in the autonomous vehicle. The directed graph includes multiple first edges, each first edge being used to represent the fault propagation relationship between the nodes at both ends of the first edge. Step S212: Based on multiple first edges, determine at least one associated functional node that has a connected path to the target node corresponding to the target fault; Step S213: Determine the fault severity level of the target node based on the fault severity level corresponding to at least one associated functional node; and Step S214: Determine the target control strategy based on the preset control strategy corresponding to the fault severity level of the target node.

[0037] According to the scheme provided by method 200, a directed graph can be constructed to model the fault propagation relationship between underlying physical hardware faults and upper-level functional faults. This allows for mapping the functional faults corresponding to the monitored hardware faults to their severity levels, essentially determining the actual impact range and severity of a specific hardware fault based on its propagation path. This mechanism solves the strategy arbitration problem caused by the multi-cause-multi-effect nature of fault propagation (i.e., the difficulty in choosing a vehicle control strategy to balance vehicle efficiency and safety), enabling more accurate determination of response strategies when autonomous vehicles malfunction, thus improving the safety of autonomous vehicle operation. Furthermore, this method utilizes a directed graph model to decouple hardware fault information from fault response strategies, reducing system maintenance costs and eliminating the need for manual inspection of underlying hardware configurations during functional module updates or strategy adjustments, saving resources.

[0038] In some examples, monitorable hardware faults refer to abnormal states of various physical components in an autonomous vehicle. Specifically, hardware faults can include, but are not limited to: sensor faults at the perception level, such as abnormal power supply voltage of LiDAR, LiDAR data loss, camera internal module failure, data frame loss or signal interruption of millimeter-wave radar, and damaged ultrasonic radar probes; positioning signal faults at the positioning level, such as lost navigation system receiver signals and inertial measurement unit calibration failure; faults at the execution level, such as steering system faults, braking system faults, and loss of communication between drive motor controllers; and faults at the vehicle's fundamental level, such as processor overload of the onboard computing platform, disconnection of communication links in the onboard Ethernet or CAN bus, and voltage jitter in the power management module. In some examples, multiple hardware nodes in a directed graph can represent hardware faults of different granularities. The propagation relationship between hardware faults can then be represented by the first edge between the hardware nodes. For example, voltage jitter at the vehicle level can further lead to abnormal power supply voltage of LiDAR, which in turn leads to LiDAR data loss. This allows for a more accurate and refined characterization of the correlation between different types of faults in the vehicle.

[0039] Functional failures refer to the malfunction of specific vehicle capabilities or algorithm modules caused by underlying hardware failures or software logic errors. These failures are typically categorized based on the autonomous driving algorithm architecture. For example, in the perception module, functional failures may include loss of forward telephoto perception data, degradation of lateral obstacle detection, and failure of lane line recognition; in the positioning module, they may include unavailability of high-precision positioning or excessive positioning accuracy deviation; and in the planning and control module, they may include trajectory planning timeouts, excessive lateral control deviations, or disabling of automatic lane changing. By treating functional failures as logical nodes in a graph, the impact of hardware anomalies on the vehicle's autonomous driving capabilities can be clearly represented. In some examples, multiple functional nodes in a directed graph can represent functional failures of different granularities. Furthermore, the propagation relationship between functional failures can be represented by the first edge between functional nodes. For example, an abnormal forward perception signal may further lead to the failure of forward perception, thereby more accurately and precisely representing the correlation between different types of failures in the vehicle.

[0040] In some examples, the preset control strategies used to handle faults are determined based on the Minimum Risk Condition (MRC) strategy. Depending on the severity of the fault, the control strategy may include different levels of intervention. For example, for minor faults, the strategy might simply issue a "takeover prompt" or "ignite the malfunction indicator lamp" on the human-machine interface without interfering with vehicle movement; for medium-risk faults, the strategy might be to "limit the vehicle's maximum speed (e.g., 60 km / h)," "disable automatic lane change," or "downgrade to assisted driving mode"; for severe faults, the strategy might be to "gradually decelerate and stop within the current lane," "pull over," or, in an emergency, trigger "emergency braking" to quickly cut off power and lock the brakes.

[0041] In some examples, fault severity levels are a predefined set of discrete levels used to quantify the impact of a fault on driving safety. For instance, fault severity levels can be divided into five levels, L1 to L5, where L1 represents the lowest risk and L5 represents the highest risk. Each fault severity level is bound to a specific preset control strategy. This determination process is typically completed during the system design phase, i.e., by evaluating the worst possible consequences of a function's failure (such as "complete failure of forward perception") (e.g., "inability to recognize obstacles ahead"), defining it as a high-risk level (e.g., L5), and associating it with the most stringent control strategy (e.g., "emergency braking"). In some examples, a multi-level functional node can be constructed in a directed graph. Lower-level functional nodes represent fine-grained functional faults, while higher-level functional nodes represent coarse-grained functional faults, aggregating various functional faults into different types of fault response strategies. For example, a functional fault set node can be set at the top level of the directed graph, with a preset fault severity level for each functional fault set node and mapped to a control strategy for responding to the fault. Then, the corresponding fault severity level for each functional node can be determined based on the connections between other functional nodes and the functional fault set node.

[0042] In one example, the system can define the following level and policy correspondence: Level 1 corresponds to "warning only", which is suitable for faults that do not affect driving, such as a passenger door not being closed properly; Level 2 corresponds to "limiting the maximum speed and prompting for takeover", which is suitable for scenarios where a non-core sensor (such as a rearview camera) fails, and the vehicle still has basic perception capabilities but is no longer complete; Levels 3 and 4 correspond to "planning to pull over" and "planning to stop in the lane", respectively, which are suitable for scenarios where positioning accuracy is reduced and cannot support long-term autonomous driving; Level 5 corresponds to "immediate emergency braking", which is suitable for extreme scenarios that may lead to immediate collision risks, such as complete loss of forward key perception or steering system failure.

[0043] The operation of determining the mapping relationship between the target fault and the target control strategy by dynamically parsing the directed graph in steps S211-S214 can be performed online or offline. In one embodiment, this process can be performed online in real time during vehicle operation; that is, whenever a hardware fault is detected, the system immediately performs real-time path search and severity calculation based on the directed graph. In another embodiment, considering the limitations of onboard computing resources and the extremely high requirements for real-time performance, this logic can also be pre-executed offline (e.g., before system startup or on a cloud server). By offline traversal of all possible hardware nodes, the highest severity level corresponding to each hardware fault is pre-calculated, and the mapping relationship between the target fault and the target control strategy is stored for querying during vehicle operation, eliminating the need for repeated graph traversal calculations and saving online computing resources.

[0044] According to some embodiments, determining the target control strategy corresponding to the target fault in step S210 includes: querying the target fault severity level from the configuration file; and determining the target control strategy based on the preset control strategy corresponding to the target fault severity level. The configuration file includes multiple faults and the fault severity level of each fault. The configuration file is determined as follows: for each hardware node among multiple hardware nodes, at least one associated functional node with a connected path to that hardware node is determined based on multiple first edges; the fault severity level of that hardware node is determined based on the maximum value of the fault severity level corresponding to at least one associated functional node of each hardware node, thus obtaining the fault severity levels of the multiple faults represented by the multiple hardware nodes. Therefore, fault management can be performed using configuration files, improving the real-time response speed of the autonomous driving system. Since the complex graph traversal and logical derivation process is completed offline, the vehicle only needs to perform simple query operations during operation, reducing decision-making delays during vehicle operation and improving vehicle driving safety.

[0045] In some examples, configuration files may be stored in the vehicle controller's memory in data formats such as JSON, XML, or binary files. Their data structure typically contains key-value pairs mapping fault information (e.g., fault codes or fault identifiers) to fault severity levels. During a query, the system retrieves the corresponding record from the file based on the information of the detected target fault, and then reads its associated fault severity level.

[0046] According to some embodiments, the configuration file also includes at least one associated functional node corresponding to each of the multiple faults. Method 200 further includes: in response to a change in the fault severity level corresponding to the target functional node among the multiple functional nodes, updating the fault severity level of the fault corresponding to the target functional node in the configuration file based on the fault severity level change information. Based on this, dynamic association and automatic updating of the underlying hardware fault level and the upper-level functional fault can be achieved. As mentioned earlier, in traditional development models, if the upper-level algorithm optimizes its dependence on certain sensor data (e.g., the perception algorithm no longer strongly relies on LiDAR), engineers need to manually check and modify all associated underlying hardware fault levels, which is prone to omissions or errors. According to the above implementation, since the configuration file is automatically generated based on a directed graph, when the level of an upper-level functional node changes (e.g., downgrades from L5 to L4), the system can automatically update the levels of all underlying hardware faults affected by that functional node in the configuration file in batches through reverse tracing, saving manual maintenance costs while reducing the error rate, thereby improving vehicle driving safety.

[0047] In a specific example, when the forward localization function of an autonomous driving system heavily relies on the perception function of forward millimeter-wave radar data, the hardware node corresponding to a forward millimeter-wave radar fault directly points to the fault node corresponding to the forward localization anomaly. In this case, when the functional node "forward localization anomaly" in the directed graph is defined as Level 5 (highest risk), since the severity level of the hardware fault is based on directed graph analysis, the underlying "millimeter-wave radar fault" will also be mapped to Level 5 in the configuration file. When the vehicle's forward perception fusion algorithm is upgraded, and the vehicle localization function is no longer based solely on forward localization data, the vehicle can still drive safely even when forward millimeter-wave radar data is lost. Therefore, the severity level of the "forward localization anomaly" fault is downgraded to Level 3. Based on this change in fault severity level, the severity level of the "millimeter-wave radar fault" can be updated based on the mapping relationship between "millimeter-wave radar fault" and "forward localization anomaly" recorded in the configuration file, thereby achieving efficient dynamic adjustment of fault configuration information.

[0048] In some examples, step S211 may involve reading from a preset storage location. The construction of a directed graph typically follows a forward design process. For example, firstly, based on the vehicle's physical architecture and circuit diagram, the underlying hardware nodes (such as sensors and actuator interfaces) corresponding to all detectable physical faults are defined. Then, by analyzing the software architecture and data flow, the dependencies of each functional module on the underlying data are determined, thereby defining the mid-level functional nodes and connecting edges. For example, if the perception algorithm needs to use image data from the camera, a directed edge is established between "camera hardware failure" and "perception algorithm input anomaly." Thus, a directed graph can be used to characterize the correlation and propagation relationships between different types of faults in the vehicle, to more accurately assess the scope and severity of each hardware fault, and thereby more accurately determine the vehicle control strategy to address the fault.

[0049] In some examples, step S212 can use path search to determine associated functional nodes with connected paths to the target fault. For example, starting from the hardware node representing the target fault (the target node), a path search algorithm is executed in the directed graph, specifically using a depth-first search or breadth-first search strategy. The path search algorithm traverses the directed edges level by level (for example, starting from the "camera voltage abnormality" node, following the directed edges to find the "image data loss" node, and then continuing upwards to find the "forward sensing failure" node) until there are no further output edges in the graph. All functional nodes traversed on the path are then identified as associated functional nodes corresponding to the target node.

[0050] According to some embodiments, determining the fault severity level of the target node in step S213 based on the fault severity level corresponding to at least one associated functional node includes: determining the fault severity level of the target node based on the maximum value of the fault severity levels corresponding to at least one associated functional node. By using the maximum value principle to determine the fault severity level of the target node, the safety of autonomous vehicle operation can be improved.

[0051] In some examples, other methods can be used to determine the fault severity level of the target node based on the fault severity level corresponding to at least one associated functional node. For example, priority arbitration can be used to determine the level. In one example, if the vehicle is in a low-speed parking scenario, the fault level of parking-related functions may be assigned a higher weight. As another example, a scenario-based dynamic selection strategy can be used to determine which propagation path's fault level to adopt based on the current driving mode (e.g., highway cruising versus low-speed urban driving) to determine the appropriate vehicle control strategy.

[0052] In some examples, after determining the severity level of the target node's fault, the process of determining the target control strategy in step S214 is a direct mapping and matching process. As mentioned earlier, the preset control strategy corresponding to each fault severity level is predefined. The system can maintain a preset strategy table, which defines the specific actions corresponding to each fault severity level. For example, if step S213 calculates that the level of the target hardware fault is L4, the system queries the strategy table, finds the "pull over" instruction corresponding to L4, and sends it to the planning and control module for execution. After receiving the instruction, the planning and control module generates a trajectory for pulling over to the roadside and controls the chassis actuators to complete the parking action, thereby achieving a safe closed loop for the fault and improving the safety of autonomous driving.

[0053] Figure 3 A schematic diagram of a directed graph according to an exemplary embodiment of the present disclosure is shown. Figure 3As shown, this directed graph specifically illustrates the fault propagation logic involving telephoto cameras in an autonomous vehicle perception system. The graph constructs a multi-layered structure where faults propagate from underlying physical hardware or basic logic to upper-level functional failures. Specifically, the graph includes bottom-level hardware nodes, such as node 301 (voltage jitter), node 302 (internal fault of the telephoto camera), and node 304 (telephoto drive logic error). These nodes represent the starting points of fault propagation, i.e., the specific sources of anomalies that the system can directly monitor. The graph also shows mid- and top-level functional nodes, such as node 303 (telephoto camera failure), node 305 (front telephoto data loss), and node 306 (long-range perception failure). Nodes are connected by directed edges (i.e., the first edge), representing the causal propagation relationship of the fault. The specific propagation path is as follows: When voltage jitter (node ​​301) or an internal fault of the telephoto camera (node ​​302) occurs, these hardware-level anomalies directly lead to telephoto camera failure (node ​​303). Furthermore, this component-level failure propagates upwards, resulting in front telephoto data loss (node ​​305). Meanwhile, a long-range telephoto drive logic error (node ​​304), as an embedded software-level fault, can directly lead to the loss of front long-range data (node ​​305) without going through a component failure node. The loss of front long-range data (node ​​305) further propagates to the top-level functional nodes, causing long-range perception failure (node ​​306). Based on this final functional failure node 306, the system can query its corresponding fault severity level (e.g., L4) and determine the appropriate control strategy (e.g., limiting vehicle speed or no longer relying on long-range perception for lane changes). Figure 3 As shown in the directed graph, the system can clearly identify that even low-level voltage fluctuations can eventually lead to failure of high-level long-distance sensing, thus ensuring the accuracy of fault response and system safety.

[0054] According to some embodiments, the directed graph also includes at least one AND gate node. Method 200 further includes: when the directed graph includes a first edge pointing from the target node to the first AND gate node, a first edge pointing from the first hardware node to the first AND gate node, and a first edge pointing from the first AND gate node to the first functional node, in response to detecting that the autonomous vehicle experiences a target fault while a corresponding first fault occurs at the first hardware node, determining the fault severity level corresponding to the first functional node; and in response to determining that the fault severity level corresponding to the first functional node is higher than the target fault severity level, updating the target control strategy based on the corresponding preset control strategy of the first functional node, so as to control the autonomous vehicle using the updated target control strategy. Thus, by setting AND gate nodes in the directed graph, the complex logic of multiple concurrent faults or redundant system failures in autonomous vehicles can be modeled more accurately. In autonomous driving systems, redundant designs (such as dual controllers) are often used to improve reliability. A single point of failure is often insufficient to cause complete system failure. In this case, directly triggering a high-level fault response strategy would lead to overreaction and unnecessary loss of vehicle driving efficiency. Through AND gate modeling, the system only propagates the risk upwards and escalates the fault level when the condition of simultaneous occurrence of the "target fault" and the "first fault" is met (i.e., complete redundancy failure). This can improve vehicle driving safety while avoiding overreaction caused by a single fault, thus improving vehicle driving efficiency.

[0055] An AND gate node represents the logical relationship that "a fault will only propagate when all input conditions are met simultaneously." In directed graph modeling, two functionally redundant sensor nodes can be connected to the input of the same AND gate node, and the output of the AND gate node can be connected to the corresponding functional node. Only when both sensors fail simultaneously will the functional node be considered faulty; if only one fails, fault propagation will be truncated at the AND gate, thus correctly reflecting the protection mechanism of the redundant system. It should be understood that in this case, the solution based on the connected path of directed edges will be truncated by the AND gate. That is, when the target node corresponding to the target fault and the first functional node can only be connected through an AND gate node, no connected path exists between the target node and the first functional node, and the fault severity level of the first functional node will not affect the fault severity level of the target node. Therefore, the above implementation provides a means of monitoring and responding to the concurrent fault relationships represented by AND gate nodes. When concurrent occurrence of the target fault and the first fault is detected, the target control strategy to be executed is updated based on the corresponding fault severity level of the first functional node to improve vehicle driving safety.

[0056] In a specific example, the vehicle's perception system can be equipped with both short-range and long-range radars to jointly cover the area ahead. A target fault could be a short-range radar anomaly (L2), and a primary fault could be a long-range radar anomaly (L2). They are connected via an AND gate to a first functional node, indicating complete forward perception failure (L5). If only a short-range radar anomaly is detected, the AND gate does not activate, and the system may only execute an L2-level strategy (such as reducing vehicle speed). However, if a long-range radar anomaly is detected simultaneously, the AND gate condition is met, the fault propagates upwards, and activates complete forward perception failure; the system will then execute an L5-level strategy (such as emergency braking).

[0057] Monitoring concurrent faults corresponding to AND gate nodes can be done in several ways. In one example, the system can maintain a "currently active fault list" at runtime. Whenever a new fault is reported, the system traverses the AND gate logic in the directed graph, checking whether all input nodes of that AND gate appear in the active list. In another example, a "concurrency relationship table" or "dependency matrix" is pre-generated, recording all combinations of underlying faults required to trigger a specific high-level fault. When a target fault is detected, the system quickly indexes this table, checking whether the first fault associated with the target fault is also active, thus determining whether the concurrency condition is met.

[0058] In some examples, directed graphs may also include other types of logic gate nodes, such as OR gates and NOT gates. OR gates are used to represent relationships where "any trigger can lead to a failure," such as "camera failure" or "radar failure" both leading to "degraded fused perception." NOT gates are used to represent mutually exclusive or enabling relationships, such as a safety mechanism only taking effect when a component "does not fail." By combining these logic gates, the intricate failure dependencies and propagation mechanisms in autonomous driving systems can be accurately described.

[0059] Figure 4 A schematic diagram of a directed graph according to another exemplary embodiment of this disclosure is shown. Figure 4 As shown, Figure 4 As shown, in Figure 3 Building upon the infrastructure shown, this directed graph further illustrates the fault propagation logic of autonomous vehicles in scenarios involving multi-sensor fusion and redundancy design. The graph introduces logic gate nodes (such as AND gates) to model concurrent faults, supporting more accurate risk level assessment.

[0060] Specifically, the diagram illustrates the fault propagation path involving near-field perception. The loss of data from the mid-range camera at node 307 and the loss of data from the wide-angle camera at node 308 represent abnormal states of cameras with different fields of view. Both nodes point to the AND gate at node 309. This AND gate at node 309 indicates that the fault will only propagate further if all its input nodes (i.e., nodes 307 and 308) fail simultaneously. Therefore, near-field perception failure at node 310 is only triggered when data from both the mid-range and wide-angle cameras are lost simultaneously. This reflects the system's redundant design for mid-to-near-field perception: data loss from a single sensor can be compensated for by another sensor, thus preventing a complete loss of perception functionality.

[0061] Furthermore, the directed graph illustrates the impact of different fine-grained functional failures on higher-level functional failures. Both long-range perception failure (node ​​306) and short-range perception failure (node ​​310) are connected to the AND gate at node 311. The output of node 311 points to the top-level node 312, indicating a forward perception failure. In this case, the system only determines a forward perception failure (typically corresponding to the highest fault severity level, such as L5) when both the vehicle's long-range and short-range perception capabilities are simultaneously lost. If only a long-range perception failure (node ​​306) occurs, but short-range perception is normal (node ​​310 is not activated), then the AND gate at node 311 will not conduct, and the fault will not propagate to node 312. In this case, the vehicle may only be in a partially degraded state (e.g., limiting maximum speed) without needing to implement an emergency braking strategy for a complete perception failure. Figure 4 The logic gate model shown can avoid triggering overly aggressive safety strategies due to the failure of a single module, thereby improving vehicle driving safety while maintaining the availability of vehicle functions and improving vehicle driving efficiency.

[0062] According to some embodiments, method 200 further includes: after detecting a target fault, in response to the failure to detect a corresponding fault in a second hardware node in a directed graph, generating a monitoring function early warning message for the second hardware node, wherein the directed graph includes a first edge pointing from the target node to the second hardware node. This enables proactive monitoring and early warning based on a directed graph. By utilizing the propagation relationship from the target node to the second hardware node defined in the directed graph, the system can identify hardware faults that "should have been detected but were not." Specifically, if an upstream fault (target fault) has occurred, theoretically, the downstream node (second hardware node) affected by it should also exhibit abnormalities. If no downstream abnormality is detected, it indicates that the fault monitoring function may be abnormal, or that there is a vulnerability in the fault propagation relationship modeled in the directed graph. In this case, by generating an early warning message, self-monitoring of hardware functions or defects in the directed graph modeling can be achieved, thereby improving the comprehensiveness of the fault management function of autonomous vehicles and ultimately enhancing the safety of autonomous vehicle operation.

[0063] In a specific example, the target node could be millimeter-wave radar data loss (hardware layer failure). In the directed graph, it points to the second hardware node, "Perception Module Radar Reception Timeout". If, during runtime, the vehicle's underlying fault monitoring function has already reported "millimeter-wave radar data loss", but the perception module fails to report a "reception timeout" fault, it indicates that the perception module's timeout detection mechanism has failed. In this case, the system will generate a monitoring function warning, prompting developers to check the perception module's input detection logic.

[0064] According to some embodiments, multiple hardware nodes include at least one root cause node, which is used to characterize a root cause fault that can trigger other faults. Method 200 further includes: when the target node is not a root cause node, in response to the failure to detect a corresponding fault for any first root cause node in the directed graph after detecting the occurrence of a target fault, generating a root cause missing warning message for the target fault, wherein the directed graph includes a first edge pointing from the first root cause node to the target node. By applying the above implementation methods, it is possible to proactively identify the problem of missing root causes in the fault propagation logic represented by the directed graph. It should be understood that due to the complex correlation and propagation relationships between various types of faults in autonomous vehicles, the directed graph may not be able to completely and accurately represent all fault propagation logic, which may result in a situation where a functional abnormality (target fault) is detected, but the underlying layer fails to model its root cause. By performing reverse tracing of the directed graph, if it is found that the faults corresponding to all possible root cause nodes pointing to the current abnormal node have not occurred, it indicates that an unmodeled fault type or fault propagation relationship may have been encountered. By generating root cause missing warning messages, it is possible to help locate the design blind spots of the current fault propagation model, realize the model's self-monitoring and iterative optimization, thereby improving the comprehensiveness of the fault management function of autonomous vehicles and thus improving the safety of autonomous vehicle operation.

[0065] In a specific example, the target node is image quality anomaly. The first root cause nodes pointing to it in the directed graph include unstable camera voltage and camera obstruction. When the system detects an image quality anomaly alarm, but upon inspection finds normal voltage and no obstruction alarm (i.e., all first root cause nodes are not activated), the system determines that the root cause is currently unknown and generates an image anomaly root cause missing warning. This may indicate the presence of an unknown interference source (such as specific electromagnetic interference or extreme lighting), requiring further analysis.

[0066] In a directed graph, root cause nodes are typically defined as nodes with an in-degree of zero, meaning they have no preceding triggering nodes and represent the lowest physical cause in a fault chain. For example, abnormal power supply voltage to a sensor, a physical break in a communication line, or hardware damage to a chip are typical root cause nodes. During the graph model construction phase, by analyzing the physical architecture and signal flow, these most basic hardware failure points can be marked as root cause nodes.

[0067] According to some embodiments, the directed graph also includes at least one second edge, each second edge representing the unverified fault propagation relationship between the nodes at both ends of the second edge. Method 200 further includes: when the target node is not a root cause node, in response to the failure to detect a fault corresponding to any first root cause node in the directed graph after detecting a target fault, and detecting a fault corresponding to a second root cause node in the directed graph that has a target second edge with the target node, generating a verification prompt message for the target second edge. Thus, the second edge can be used to represent the unverified fault propagation relationship, i.e., the weak correlation between different faults. When a known strongly correlated root cause corresponding to the target fault is missing, the system uses the unverified relationship represented by the second edge (weakly correlated edge) for inference, providing a possible explanation direction for faults whose causes cannot be traced. This facilitates further analysis and modeling of potential unverified fault propagation relationships, thereby improving the comprehensiveness of the fault management function of autonomous vehicles and ultimately enhancing the safety of autonomous vehicle operation.

[0068] In a specific example, the target node is image quality anomaly, and no strongly correlated root causes are triggered. At this point, the directed graph contains a second edge (a weakly correlated edge, indicating that high temperature may cause increased noise, but not absolutely) pointing from excessively high ambient temperature (the second root cause node). If the system detects a signal indicating excessively high ambient temperature, it will generate a verification message: the image anomaly may be caused by high temperature. This provides valuable clues for subsequent diagnosis, prompting engineers to verify the specific impact of high temperature on camera performance.

[0069] Figure 5 A schematic diagram of a directed graph according to another exemplary embodiment of this disclosure is shown. Figure 5 As shown, this directed graph further illustrates the potential impact of system-level failures on functional modules and introduces a second edge (i.e., weak correlations between failures, represented by dashed lines in the graph) to characterize the failure propagation relationships to be verified. Specifically, a new system-level failure node, node 313, is added to the graph, representing system lag. When the onboard computing platform experiences resource exhaustion or scheduling delays leading to system lag, it points directly to node 314, where system performance degrades, via a solid line (strong correlation / first edge), signifying a definite failure propagation path.

[0070] Meanwhile, the system lag at node 313 also points, via dashed lines (weak correlation / second side), to the loss of telephoto data before node 305, mid-range camera data before node 307, and wide-angle camera data before node 308. This indicates that system lag does not necessarily lead to the loss of these camera data, but under certain operating conditions (such as excessive CPU load causing image processing thread timeouts), it may be a potential cause of this sensory data loss.

[0071] based on Figure 5The directed graph structure shown in this disclosure allows the control method to handle more complex diagnostic scenarios: Suppose the system detects that nodes 305, 307, and 308 are simultaneously active (i.e., multiple cameras are losing data simultaneously), but no faults are detected in the camera hardware itself (such as abnormal voltage or internal damage). In this case, by checking the weakly correlated edges, if the system finds that node 313 is in a system-stuck active state, it can infer that the root cause of the lost perception data is not sensor hardware damage, but insufficient system resources. By using the unverified relationship represented by the second edge (weakly correlated edge) for inference, possible explanatory directions are provided for faults whose causes cannot be traced. This facilitates further analysis and modeling of potential unverified fault propagation relationships, thereby improving the comprehensiveness of the fault management function of autonomous vehicles and ultimately enhancing the safety of autonomous vehicle operation.

[0072] According to one aspect of this disclosure, a control device for an autonomous vehicle is also provided. Figure 6 A structural block diagram of a control device 600 for an autonomous vehicle according to an exemplary embodiment of the present disclosure is shown. Figure 6 As shown, the device 600 includes: The first determining unit 610 is configured to determine a target control strategy based on the target fault in response to detecting a target fault in the autonomous vehicle; and Control unit 620 is configured to control the autonomous vehicle based on a target control strategy. The target control strategy is determined using a second determining unit, which includes: The acquisition subunit is configured to acquire a directed graph, wherein the directed graph includes multiple hardware nodes for representing multiple hardware faults that can be monitored in the autonomous vehicle and multiple functional nodes for representing multiple functional faults in the autonomous vehicle. The directed graph includes multiple first edges, each first edge being used to represent the fault propagation relationship between the nodes at both ends of the first edge. The first determining subunit is configured to determine at least one associated functional node that has a connected path to the target node corresponding to the target fault based on multiple first edges; The second determining subunit is configured to determine the fault severity level of the target node based on the fault severity level corresponding to at least one associated functional node; and The third determining subunit is configured to determine the target control strategy based on the preset control strategy corresponding to the fault severity level of the target node.

[0073] According to some embodiments, the second determining subunit is configured to determine the fault severity level of the target node based on the maximum value of the fault severity level corresponding to at least one associated functional node.

[0074] According to some embodiments, a first determining unit is configured to query the target fault severity level of a target fault from a configuration file; and to determine a target control strategy based on a preset control strategy corresponding to the target fault severity level. The configuration file includes multiple faults and the fault severity level of each of the multiple faults. A second determining unit is configured to determine the configuration file in the following manner: for each of the multiple hardware nodes, the first determining subunit determines at least one associated functional node with a connected path to the hardware node based on multiple first edges; the second determining subunit determines the fault severity level of the hardware node based on the maximum value of the fault severity level corresponding to the at least one associated functional node of each hardware node, so as to obtain the fault severity levels of the multiple faults represented by the multiple hardware nodes.

[0075] According to some embodiments, the configuration file also includes at least one associated functional node corresponding to each of the multiple faults, and the second determining unit is further configured to: in response to a change in the fault severity level corresponding to the target functional node among the multiple functional nodes, update the fault severity level of the fault corresponding to the target functional node in the configuration file based on the fault severity level change information.

[0076] According to some embodiments, the directed graph further includes at least one AND gate node, and the first determining unit is further configured to: when the directed graph includes a first edge pointing from the target node to the first AND gate node, a first edge pointing from the first hardware node to the first AND gate node, and a first edge pointing from the first AND gate node to the first functional node, in response to detecting that the autonomous vehicle experiences a target fault and a corresponding first fault of the first hardware node at the same time, determine the fault severity level corresponding to the first functional node; and in response to determining that the fault severity level corresponding to the first functional node is higher than the target fault severity level, update the target control strategy based on the preset control strategy corresponding to the first functional node, so as to control the autonomous vehicle using the updated target control strategy.

[0077] According to some embodiments, the control device of the autonomous vehicle further includes a first message generation unit, which is configured to: after detecting a target fault, generate a monitoring function early warning message for the second hardware node in response to the failure to detect a corresponding fault of the second hardware node in the directed graph, wherein the directed graph includes a first edge pointing from the target node to the second hardware node.

[0078] According to some embodiments, the plurality of hardware nodes include at least one root cause node, which is used to characterize a root cause fault that can trigger other faults. The control device of the autonomous vehicle also includes a second message generation unit, which is configured to generate a root cause missing warning message for the target fault in response to the failure to detect a corresponding fault of any first root cause node in the directed graph after the target fault is detected, when the target node is not a root cause node. The directed graph includes a first edge pointing from the first root cause node to the target node.

[0079] According to some embodiments, the directed graph further includes at least one second edge, each second edge being used to characterize the fault propagation relationship to be verified between the nodes at both ends of the second edge, and the second message generation unit is further configured to: when the target node is not a root cause node, in response to not detecting a fault corresponding to any first root cause node in the directed graph after detecting the occurrence of a target fault, and detecting a fault corresponding to a second root cause node in the directed graph that has a target second edge with the target node, generate a verification prompt message for the target second edge.

[0080] According to one aspect of this disclosure, an electronic device is also provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described control method for an autonomous vehicle.

[0081] According to one aspect of this disclosure, an autonomous vehicle is also provided, including the aforementioned electronic devices.

[0082] According to one aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is also provided, wherein the computer instructions are used to cause the computer to perform the above-described control method for an autonomous vehicle.

[0083] According to one aspect of this disclosure, a computer program product is also provided, comprising a computer program, wherein the computer program, when executed by a processor, implements the above-described control method for an autonomous vehicle.

[0084] refer to Figure 7The present invention describes a structural block diagram of an electronic device 700 that can serve as a server or client of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0085] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded into random access memory (RAM) 703 from storage unit 708. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0086] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to device 700. Input unit 706 can receive input numerical or character information and generate key signal inputs related to user settings and / or function control of the electronic device, and may include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 707 can be any type of device capable of presenting information, and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, a hard disk and an optical disk. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0087] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as control methods for autonomous vehicles. For example, in some embodiments, the control methods for autonomous vehicles can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the control methods for autonomous vehicles described above can be performed. Alternatively, in other embodiments, the computing unit 701 can be configured to perform control methods for autonomous vehicles by any other suitable means (e.g., by means of firmware).

[0088] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0089] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0090] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0091] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0092] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0093] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0094] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0095] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of the invention is not limited by these embodiments or examples, but only by the granted claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as the technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.

Claims

1. A control method for an autonomous vehicle, comprising: In response to detecting a target fault in the autonomous vehicle, a target control strategy is determined based on the target fault; as well as The autonomous vehicle is controlled based on the stated target control strategy. The target control strategy is determined in the following manner: Obtain a directed graph, wherein the directed graph includes multiple hardware nodes for characterizing multiple detectable hardware faults in the autonomous vehicle and multiple functional nodes for characterizing multiple functional faults in the autonomous vehicle, and the directed graph includes multiple first edges, each first edge being used to characterize the fault propagation relationship between the nodes at both ends of the first edge. Based on the plurality of first edges, at least one associated functional node with a connected path is determined to be the target node corresponding to the target fault; Based on the fault severity level corresponding to the at least one associated functional node, determine the fault severity level of the target node; and The target control strategy is determined based on the preset control strategy corresponding to the fault severity level of the target node.

2. The method as described in claim 1, wherein, Determining the fault severity level of the target node based on the fault severity level corresponding to the at least one associated functional node includes: The fault severity level of the target node is determined based on the maximum value of the fault severity level corresponding to the at least one associated functional node.

3. The method as described in claim 1 or 2, wherein, The target control strategy for determining the target fault includes: Query the target fault severity level from the configuration file; and The target control strategy is determined based on the preset control strategy corresponding to the severity level of the target fault. The configuration file includes the plurality of faults and the fault severity level of each of the plurality of faults, and the configuration file is determined using the following method: For each of the plurality of hardware nodes, at least one associated functional node with a connected path to that hardware node is determined based on the plurality of first edges; The fault severity level of each hardware node is determined based on the maximum value of the fault severity level corresponding to at least one associated functional node of each hardware node, so as to obtain the fault severity level of each of the multiple faults represented by the multiple hardware nodes.

4. The method of claim 3, wherein, The configuration file also includes at least one associated functional node corresponding to each of the plurality of faults, and the method further includes: In response to a change in the fault severity level corresponding to the target functional node among the plurality of functional nodes, the fault severity level of the fault corresponding to the target functional node in the configuration file is updated based on the fault severity level change information.

5. The method according to any one of claims 1-4, wherein, The directed graph further includes at least one AND gate node, and the method further includes: When the directed graph includes a first edge pointing from the target node to the first AND gate node, a first edge pointing from the first hardware node to the first AND gate node, and a first edge pointing from the first AND gate node to the first functional node, in response to detecting that the autonomous vehicle experiences a corresponding first fault at the first hardware node while the target fault occurs, the severity level of the fault corresponding to the first functional node is determined; and In response to determining that the fault severity level corresponding to the first functional node is higher than the target fault severity level, the target control strategy is updated based on the preset control strategy corresponding to the first functional node, so as to control the autonomous vehicle using the updated target control strategy.

6. The method according to any one of claims 1-5, further comprising: After the target fault is detected, in response to the failure to detect a corresponding fault in the second hardware node in the directed graph, a monitoring function early warning message for the second hardware node is generated, wherein the directed graph includes a first edge from the target node to the second hardware node.

7. The method according to any one of claims 1-6, wherein, The plurality of hardware nodes includes at least one root cause node, the root cause node being used to characterize a root cause fault that can trigger other faults, and the method further includes: When the target node is not a root cause node, in response to the failure to detect a corresponding fault of any first root cause node in the directed graph after the target fault is detected, a root cause missing warning message for the target fault is generated, wherein the directed graph includes a first edge pointing from the first root cause node to the target node.

8. The method of claim 7, wherein, The directed graph further includes at least one second edge, each second edge representing the fault propagation relationship to be verified between the nodes at both ends of the second edge, and the method further includes: When the target node is not a root cause node, in response to the fact that no fault corresponding to any first root cause node in the directed graph is detected after the target fault is detected, and a fault corresponding to the second root cause node in the directed graph that has a target second edge with the target node is detected, a verification prompt message for the target second edge is generated.

9. A control device for an autonomous vehicle, comprising: The first determining unit is configured to determine a target control strategy based on the target fault in response to detecting a target fault in the autonomous vehicle. as well as The control unit is configured to control the autonomous vehicle based on the target control strategy. The target control strategy is determined using a second determining unit, which includes: The acquisition subunit is configured to acquire a directed graph, wherein the directed graph includes multiple hardware nodes for characterizing multiple hardware faults that can be monitored in the autonomous vehicle and multiple functional nodes for characterizing multiple functional faults of the autonomous vehicle, and the directed graph includes multiple first edges, each first edge being used to characterize the fault propagation relationship between the nodes at both ends of the first edge. The first determining subunit is configured to determine, based on the plurality of first edges, at least one associated functional node that has a connected path to the target node corresponding to the target fault; The second determining subunit is configured to determine the fault severity level of the target node based on the fault severity level corresponding to the at least one associated functional node; and The third determining subunit is configured to determine the target control strategy based on a preset control strategy corresponding to the fault severity level of the target node.

10. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. An autonomous vehicle, including the electronic equipment as claimed in claim 10.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-8.

13. A computer program product comprising a computer program, wherein, The computer program, when executed by a processor, implements the method according to any one of claims 1-8.

Images