Autonomous driving system, autonomous driving redundancy control method, device and vehicle

Abstract

The application provides an automatic driving system, an automatic driving redundancy control method, a device and a vehicle. The method is applied to an automatic driving system, the system comprising a plurality of automatic driving controllers, wherein each controller is used for outputting control instructions of a plurality of driving functions respectively; the method comprises: in the case that there is at least one fault controller in the plurality of controllers, determining a fault driving function and a normal driving function corresponding to each controller respectively; in the case that the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, acquiring independent normal control instructions of the normal driving function corresponding to each controller output by each controller respectively, and determining a function weight of each controller for each normal driving function respectively; and performing fusion processing on the independent normal control instructions according to the function weight of each controller to obtain corresponding recombined control instructions, and sending the instructions to an actuator to control the vehicle to travel.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving, and in particular to an autonomous driving system, an autonomous driving redundancy control method, a device, and a vehicle. Background Technology

[0002] With the rapid development of intelligent driving technology, more and more vehicles are supporting intelligent driving. For more advanced autonomous driving technologies, the industry typically classifies them into multiple levels of autonomous driving based on their degree of automation.

[0003] To ensure that vehicles with autonomous driving capabilities meet functional safety requirements, the industry generally adopts a redundant control scheme, which involves equipping two sets of autonomous driving controllers (i.e., A / B Teams) to form a primary / backup architecture. In this architecture, the A and B teams in traditional solutions execute the perception-decision-control process independently and in parallel, outputting control commands. The validity of the commands is ensured through consistency checks (e.g., whether command deviation is within a preset threshold). In the event of a serious failure in the primary controller (i.e., A Team) (e.g., failure of both steering and braking functions), a vehicle degradation strategy (e.g., emergency parking) is directly triggered, or manual intervention is initiated.

[0004] While traditional solutions offer simple fault response logic and rapid degradation response, they have significant drawbacks: their strategies for handling multiple concurrent faults are overly conservative (i.e., vehicle degradation or manual takeover), which can easily lead to the interruption of autonomous driving functions and increase safety risks such as rear-end collisions, side drifts, and scrapes in complex road conditions; moreover, in the event of a serious failure of the main controller, directly adopting the above-mentioned conservative response strategy reduces the utilization rate of the backup controller and the reliability of the system, which urgently needs improvement. Summary of the Invention

[0005] In view of this, the present invention provides an autonomous driving system, an autonomous driving redundancy control method, an apparatus, and a vehicle to address the shortcomings of related technologies.

[0006] Specifically, the present invention is achieved through the following technical solution: According to a first aspect of the present invention, an autonomous driving redundancy control method is provided, applied to an autonomous driving system of a vehicle, the autonomous driving system comprising a plurality of autonomous driving controllers, wherein each controller is configured to output control commands for various driving functions, and the vehicle is equipped with actuators; the method comprises: In the case where at least one of the multiple controllers is faulty, the fault driving function affected by the fault and the normal driving function unaffected by the fault are determined for each controller respectively. When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function. Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

[0007] According to a second aspect of the present invention, an autonomous driving system for a vehicle is provided, the autonomous driving system comprising a management module and a plurality of autonomous driving controllers, wherein each controller is configured to output control commands for various driving functions, and the vehicle is equipped with actuators; wherein the management module is configured to: In the case where at least one of the multiple controllers is faulty, the fault driving function affected by the fault and the normal driving function unaffected by the fault are determined for each controller respectively. When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function. Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

[0008] According to a third aspect of the present invention, an autonomous driving redundancy control device is provided, applied to an autonomous driving system of a vehicle, the autonomous driving system including a plurality of autonomous driving controllers, wherein each controller is configured to output control commands for various driving functions, and the vehicle is equipped with actuators; the device includes: The fault determination unit is used to determine the fault driving function affected by the fault and the normal driving function not affected by the fault for each controller when at least one faulty controller is present among the plurality of controllers. The instruction acquisition unit is used to acquire the independent normal control instructions for the normal driving function output by each controller when the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, and to determine the functional weight of each controller for each normal driving function. The instruction recombining unit is used to fuse the independent normal control instructions of each normal driving function according to the functional weight of each controller for each normal driving function to obtain the corresponding recombined control instructions, and send the recombined control instructions to the actuator to control the vehicle driving.

[0009] According to a fourth aspect of the invention, a vehicle is provided, the vehicle having a highly automated driving function and equipped with controls for manual driving, the vehicle being used to implement the method as described in the first aspect.

[0010] According to a fifth aspect of the present invention, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0011] According to a sixth aspect of the present invention, a computer program product is provided, comprising a computer program and / or instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0012] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: In this scheme, when there is at least one fault controller, the fault driving function and normal driving function corresponding to each controller are first determined. Then, when the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, the independent normal control instructions output by each controller are obtained and the corresponding function weights are determined. Finally, the independent normal control instructions of each normal driving function are fused according to the function weights of each controller for each normal driving function to obtain the corresponding recombined control instructions, and then the instructions are sent to the actuator to realize autonomous driving.

[0013] Understandably, in the event of a faulty controller, this solution does not perform a master-slave switchover at the overall controller level or directly degrade the autonomous driving system. Instead, it generates recombined control commands for vehicle control through a cross-team functional reconfiguration mechanism between different controllers (i.e., merging the independent normal control commands output by each controller based on their respective control weights). Thus, based on this cross-team functional reconfiguration mechanism, the multiple autonomous driving controllers (such as A / B Teams) in the autonomous driving system described in this solution no longer have a strict master-slave distinction (i.e., each Team no longer has a fixed "master / slave" identity in the traditional sense), but becomes a collection of multi-controllers with functional collaboration (note, not backup). These controllers have evolved into multiple functionally equivalent, interchangeable, and composable "resource pools." The cross-team functional reconfiguration mechanism is implemented at the fine-grained level of specific driving functions: the system no longer uses the output of a single controller as the basis for vehicle control, but rather determines the recombined control commands based on the independent control commands output by multiple controllers and their respective functional weights.

[0014] As can be seen, in the event of some controller failures, this solution can utilize the fault-free functions of each controller (including partially faulty controllers and / or fully normal controllers) to generate sufficient control commands for vehicle control, thereby making full use of the normal functions of each controller to complete vehicle control, effectively avoiding the "stop when the controller fails" scenario, and significantly reducing the number of interruptions in the autonomous driving function under controller failure scenarios. This not only helps to reduce safety risks, but also improves the overall utilization rate of each controller and the reliability of the system, especially improving the system's continuous operation capability and safety under multi-point concurrent failures, with significant improvement effects. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the present invention, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0016] Figure 1 This is a schematic diagram of the architecture of an autonomous driving system shown in an embodiment of the present invention; Figure 2 This is a flowchart illustrating an autonomous driving redundancy control method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of another autonomous driving system architecture shown in an embodiment of the present invention; Figure 4 This is a flowchart illustrating another method for controlling redundancy in autonomous driving, as shown in an embodiment of the present invention; Figure 5 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention; Figure 6 This is a block diagram of an autonomous driving redundancy control device shown in an embodiment of the present invention. Detailed Implementation

[0017] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the present invention.

[0018] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms “a,” “the,” and “the” used in this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0019] It should be understood that although the terms first, second, third, etc., may be used in this invention to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of this invention, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0020] With the rapid development of intelligent driving technology, more and more vehicles are supporting intelligent driving. For more advanced autonomous driving technologies, the industry typically classifies them into multiple levels of autonomous driving based on their degree of automation.

[0021] To ensure that vehicles with autonomous driving capabilities meet functional safety requirements, the industry generally adopts a redundant control scheme, which involves equipping two sets of autonomous driving controllers (i.e., A / B Teams) to form a primary / backup architecture. In this architecture, the A and B teams in traditional solutions execute the perception-decision-control process independently and in parallel, outputting control commands. The validity of the commands is ensured through consistency checks (e.g., whether command deviation is within a preset threshold). In the event of a serious failure in the primary controller (i.e., A Team) (e.g., failure of both steering and braking functions), a vehicle degradation strategy (e.g., emergency parking) is directly triggered, or manual intervention is initiated.

[0022] While traditional solutions offer simple fault response logic and rapid degradation response, they have significant drawbacks: their strategies for handling multiple concurrent faults are overly conservative (i.e., vehicle degradation or manual takeover), which can easily lead to the interruption of autonomous driving functions and increase safety risks such as rear-end collisions, side drifts, and scrapes in complex road conditions; moreover, in the event of a serious failure of the main controller, directly adopting the above-mentioned conservative response strategy reduces the utilization rate of the backup controller and the reliability of the system, which urgently needs improvement.

[0023] To address this issue, this invention proposes a novel redundant control scheme for autonomous driving. This scheme aims to maximize the utilization of driving functions in both faulty and / or functioning controllers when certain controllers fail, thereby reducing safety risks in controller failure scenarios and improving overall controller utilization and system reliability. The specific implementation process of this scheme is described in detail below with reference to the accompanying drawings and embodiments.

[0024] The vehicles described in this invention, in terms of their functional form, can be pickup trucks, sedans, SUVs (Sport Utility Vehicles), motorhomes, trucks, etc.; in terms of their power form, they can be fuel vehicles or new energy vehicles (such as hybrid vehicles, pure electric vehicles, hydrogen fuel cell vehicles, methanol fuel cell vehicles, etc.). This invention does not limit the specific form of the vehicles described.

[0025] The vehicle described in this invention is equipped with autonomous driving functions, such as the aforementioned conditional autonomous driving function (i.e., Level 3 autonomous driving) and / or highly automated driving function (i.e., Level 4 autonomous driving). Where the vehicle simultaneously possesses both conditional and highly automated driving functions, the highly automated driving function is backward compatible with the conditional autonomous driving function.

[0026] It is important to emphasize that any autonomous driving function implemented by the autonomous driving system described in this invention shall comply with the relevant laws, regulations, and standards of the corresponding country and region (such as the place of sale and / or place of use of the vehicle), and provide relevant personnel (such as drivers, vehicle owners, and back-end administrators) with corresponding operation interfaces for them to choose to authorize or refuse use. Furthermore, the user information (including but not limited to user device information, user biometric information, and other personal information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this invention are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant country and region, and corresponding operation interfaces must be provided for users to choose to authorize or refuse use.

[0027] In addition, the vehicle is equipped with various devices (or functional modules) to achieve the aforementioned autonomous driving function through the cooperation of these devices. For example, it can be equipped with controllers corresponding to the aforementioned autonomous driving function, i.e., multiple controllers (such as Team A and Team B) as described below. As another example, it can also be equipped with an environmental perception module for collecting data on the external environment. For instance, the environmental perception module may include image acquisition devices (such as front-view cameras, side-view cameras, rear-view cameras, etc.), ranging radar (such as LiDAR, millimeter-wave radar, ultrasonic radar, etc.), etc. Of course, the vehicle can also be equipped with at least one other sensor in a suitable location, including but not limited to external rain and fog sensors (such as rain sensors, particulate matter sensors, haze sensors, etc.), and internal cameras, microphones, biosensors, odor sensors, etc., to achieve corresponding in-vehicle functions. This embodiment of the invention does not limit this. For example, the vehicle may also be equipped with a management module corresponding to the aforementioned controller, as well as actuators that execute vehicle control actions according to the control commands output by the autonomous driving system. The actuators are used to convert the control commands output by the autonomous driving system into mechanical displacement, force, torque or fluid pressure to achieve active control of the vehicle's dynamic behavior. For example, the actuators may include longitudinal control actuators (such as electronic throttle ETC, motor controller MCU, electronic parking brake EPB, etc.) for controlling vehicle speed and acceleration / deceleration, lateral control actuators (such as electric power steering system EPS, rear wheel steering actuator RWS, etc.) for controlling direction, and other auxiliary / safety related actuators (such as electronic shift mechanism, adaptive headlight actuator, air suspension adjustment valve, door / window motor, etc.).

[0028] Figure 1 This is a schematic diagram of the architecture of an autonomous driving system for a vehicle, provided as an exemplary embodiment. Figure 1 As shown, the system's autonomous driving controller includes multiple autonomous driving controllers (hereinafter referred to as controllers), such as controllers 1 to 3 shown. It should be noted that these controllers do not have a master / slave distinction; in other words, they do not form a master-slave or master-slave architecture. In fact, from the perspective of providing driving functions and outputting corresponding control commands, these controllers are equivalent to each other. Specifically, for a particular driving function, there is no preset priority for each controller; the priority of these controllers at any given time is determined solely by their respective control weights (a higher control weight can be considered a higher priority).

[0029] Each controller contains multiple functional modules corresponding to various driving functions. Figure 1(Not shown), these functional modules work together to generate and output various control commands. Each driving function supported by the controller can be implemented independently by a single functional module, or it can be implemented collaboratively by multiple functional modules. Therefore, from the perspective of the functions implemented by the controller, each controller can be considered to contain sub-controllers corresponding to various driving functions. For example, Figure 1 The controller 1 shown includes sub-controllers such as steering controller 1, brake controller 1, power controller 1, and other controllers 1. Controller 1 also includes sub-controllers such as steering controller 2, brake controller 2, power controller 2, and other controllers 2. Controller 3 includes sub-controllers such as steering controller 3, brake controller 3, power controller 3, and other controllers 3, etc., which will not be elaborated further. It can be understood that the steering function corresponds to the steering controller, the braking function corresponds to the brake controller, the power function corresponds to the power controller, and so on. Each of the above sub-controllers is used to generate control commands for the corresponding function. For example, steering controllers 1-3 are used to generate steering commands, brake controllers 1-3 are used to generate braking commands, and power controllers 1-3 are used to generate power commands, etc., which will not be elaborated further.

[0030] The controllers described in this specification are essentially multiple parallel-running autonomous driving computing units, acting like two "teams," each operating according to its own autonomous driving logic. In the peer-to-peer redundant architecture described in this invention, each controller can drive its corresponding actuator (such as a steering motor or brake pump), or the control module can agree to calculate and reorganize control commands to drive the actuators (the latter will be used as an example below). In other words, each controller can not only calculate control commands but also send them to the underlying actuators (such as the steer-by-wire / braking system) to truly control the vehicle's movement.

[0031] Furthermore, the multiple controllers described in this specification can adopt a homogeneous redundancy architecture, meaning that their software logic (including perception, planning, and control algorithms) can be completely identical, running on the same or highly consistent hardware platform, and inputting the same environmental data. In this case, they should theoretically output identical control commands. However, due to unpredictable factors in reality (such as timing jitter, memory interference, and hardware transient failures), the control commands output by the two controllers may not be completely synchronized and consistent. The value of the backup controller lies not in "the result calculated by the main controller being different," but in "when the main controller makes a calculation error or malfunctions due to software or hardware anomalies, the backup controller can provide a correct and usable backup." Of course, the multiple controllers can also adopt a heterogeneous redundancy architecture, meaning that their software logic is not completely identical or even significantly different. For example, they can use different algorithms (such as convolutional neural networks (CNN) and traditional vision) and be deployed on different hardware platforms such as chips. This architecture can effectively avoid common-mode failures between the main and backup controllers, but may require additional arbitration mechanisms to ensure output accuracy. Specific implementation details are not elaborated here.

[0032] In addition, the autonomous driving system also includes a management module; wherein the management module is used for: In the case where at least one of the multiple controllers is faulty, the fault driving function affected by the fault and the normal driving function unaffected by the fault are determined for each controller respectively. When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function. Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

[0033] The specific process by which the system implements the aforementioned autonomous driving redundancy control scheme can be detailed in the following embodiments.

[0034] Figure 2 This is a flowchart illustrating an autonomous driving redundancy control method according to an embodiment of the present invention. The method is applied to an autonomous driving system of a vehicle, which includes multiple (i.e., at least two) autonomous driving controllers, each of which is used to output control commands for various driving functions. The vehicle is equipped with actuators.

[0035] In one embodiment, the various driving functions may include core driving functions that directly affect vehicle operation—functions that are crucial to vehicle operation, such as the aforementioned steering, braking, and power functions. Of course, other non-core driving functions may also be included, such as in-cabin voice functions, display functions, lighting functions, and seat functions, which will not be elaborated further.

[0036] like Figure 2 As shown, the method includes the following steps 202-206.

[0037] Step 202: If at least one of the multiple controllers is faulty, determine the fault driving function affected by the fault and the normal driving function unaffected by the fault for each controller.

[0038] As mentioned earlier, each controller can contain multiple functional modules. Any driving function supported by the controller can be implemented independently by one functional module, or it can be implemented collaboratively by multiple functional modules. For example, steering, braking, and propulsion are the three most critical driving functions for system safety. The logic / component units required to implement these driving functions are the aforementioned functional modules. For instance, implementing steering requires a steering path planning module, a steering actuator control module, and a steering status feedback module; implementing braking requires a braking intent parsing module and an electronic brake distribution module; and implementing propulsion requires a power torque coordination module. The normal operation of each of these functional modules consumes certain underlying software / hardware resources, such as CPU load, communication links, and sensor inputs.

[0039] Based on this, it is possible to determine whether any controller has malfunctioned based on the operational status data of each functional module. For example, operational status data (such as CAN bus latency, GPU / memory utilization, IMU communication latency / packet loss rate, etc.) of each functional module within any controller can be acquired in real time, and it can be determined whether these data meet preset fault conditions. For instance, if the load L≥90%, communication latency T≥50ms, and / or instruction execution error E≥5% of any functional module, it can be determined that the module is faulty. The functional module determined to be faulty is referred to below as the faulty functional module. If at least one faulty functional module exists among the multiple functional modules contained in any controller, the controller can be determined to be faulty—in this case, the controller can be called a faulty controller, while a controller without any faults (i.e., all contained functional modules are fault-free / normal) is called a normal controller.

[0040] This solution does not rely on the overall heartbeat of the controller, but rather determines whether a module is faulty based on the fine-grained operating status of its functional modules (such as load, latency, and error). In other words, it determines whether a controller is faulty by performing module-level health checks on each controller. This approach helps avoid the risk of "false health" results (i.e., a normal heartbeat but incorrect output), thereby improving the sensitivity and accuracy of controller fault detection and providing reliable input for subsequent functional-level reconfiguration.

[0041] Furthermore, when determining the fault driving function (i.e., the driving function affected by the aforementioned fault) and normal driving function (i.e., the driving function not affected by the aforementioned fault) corresponding to each controller, for any controller, the driving function corresponding to the fault function module can be determined as the fault driving function corresponding to that controller according to a preset module function mapping relationship, and the driving function that is not corresponding to any of the aforementioned fault function modules can be determined as the normal driving function corresponding to that controller. For example, the steering path planning module, steering actuator control module, and steering state feedback module all correspond to the steering function; the braking intent analysis module and the electronic brake distribution module all correspond to the braking function; the power torque coordination module corresponds to the power function, etc. Based on this, if both the steering path planning module and the braking intent analysis module malfunction (i.e., they are fault function modules), the steering function and braking function can be determined as fault driving functions, while the power function is a (fault-free) normal driving function, which will not be elaborated further.

[0042] Understandably, this solution, by establishing a mapping relationship between "modules and functions," can clearly define the propagation path of faults, facilitating automatic and accurate attribution from lower-level module faults to their impact on upper-level driving functions. Furthermore, this solution requires no manual intervention; once the mapping relationship is configured, the system can dynamically identify which functional modules are faulty (unreliable), thereby achieving automated fault isolation. This approach makes cross-team reorganization decisions explainable and traceable, meeting the SOTIF (Safety of the Intended Functionality) requirements for diagnostic coverage and accuracy.

[0043] Understandably, for a faulty controller, at least one faulty driving function can be identified, and it is also possible to identify at least one normal driving function corresponding to the faulty controller—if at least one normal driving function is identified, it indicates that the controller is not completely faulty (e.g., Figure 1 The controller 1 shown only has a steering function malfunction, while the braking and power functions are normal; if no normal driving function is identified, it indicates that the controller has completely failed (i.e., all its corresponding driving functions are faulty driving functions, such as...). Figure 1The steering, braking, and power functions of controller 1 shown are all faulty (other functions are not considered, the same applies below). For controllers that are not faulty, all their corresponding driving functions are normal driving functions, which need not be elaborated.

[0044] Correspondingly, from the perspective of driving function, among the controllers corresponding to each function in the driving function, there may be zero (i.e., none) or one or more faulty controllers: if there are no faulty controllers, it means that the function of each controller corresponding to the driving function is normal; if there are one or more faulty controllers, it means that the function of these controllers is faulty. In other words, for any faulty controller, the driving function of that controller is a faulty driving function.

[0045] For example, in the corresponding Figure 1 Table 1 below shows the fault conditions for each driving function corresponding to controllers 1 to 3: Table 1

[0046] In this table: From the perspective of the controllers, controllers 1 and 2 each correspond to at least one faulty function, therefore both are faulty controllers; controller 3 is a normal controller. From the perspective of driving functions, the steering function is the faulty driving function of controllers 1 and 2, and the normal driving function of controller 3; the braking function is the faulty driving function of controller 1, and the normal driving function of controllers 2 and 3; the power function is the normal driving function of controllers 1, 2, and 3.

[0047] In one embodiment, if the number of controllers corresponding to at least one faulty driving function is equal to the total number of controllers (i.e., the driving function is a faulty driving function for each controller), it indicates that for this driving function, none of the controllers can output normal and reliable control commands, which will greatly challenge the driving safety of the autonomous driving system. Assuming that the steering function of controller 3 in Table 1 is also faulty, then the "steering function" is a faulty driving function for each controller, meaning controller 3 is also a faulty controller corresponding to the steering function; in this case, the number of controllers corresponding to the steering function is equal to the total number of controllers (i.e., 3). To prevent accidents and ensure driving safety, in such severe fault situations, the vehicle can be controlled according to a preset degradation strategy (e.g., reducing the autonomous driving level, gradually reducing speed, activating hazard warning lights, and / or planning and entering a safe parking area), and / or prompting the driver to manually drive the vehicle (e.g., sending a takeover prompt to the driver). This can serve as a safety fallback for the autonomous driving function safety system in the above extreme scenarios, preventing the system from "silently failing."

[0048] In one embodiment, if there is no faulty controller among the plurality of controllers (i.e., all controllers are fault-free), it indicates that all controllers are operating normally and no fault has occurred. To improve the accuracy of vehicle control commands, the independent control commands output by each controller for each corresponding driving function can be determined, and the functional weight of each controller for each driving function can be determined. Then, based on the functional weights of each controller for each driving function, the independent control commands for each driving function are fused to obtain a corresponding recombined control command, which is then sent to the actuator to control the vehicle's movement.

[0049] exist Figure 1 In the scenario shown, assuming all controllers are functioning correctly, we can obtain the independent steering command C-ste1, independent braking command C-brak1, and independent power command C-prop1 output by controller 1; the independent steering command C-ste2, independent braking command C-brak2, and independent power command C-prop2 output by controller 2; and the independent steering command C-ste3, independent braking command C-brak3, and independent power command C-prop3 output by controller 3. Additionally, we can obtain the function weights K-ste1~3 for steering, K-brak1~3 for braking, and K-prop1~3 for steering from controllers 1~3. Then, the recombined steering command C(safe)-ste=K-ste1*C-ste1+K-ste2*C-ste2+K-ste3*C-ste3, the recombined braking command C(safe)-brak=K-brak1*C-brak1+K-brak2*C-brak2+K-brak3*C-brak3, and the recombined power command C(safe)-prop=K-prop1*C-prop1+K-prop2*C-prop2+K-prop3*C-prop3 can be calculated based on the weighted summation algorithm.

[0050] This solution completes the overall control framework for normal and fault scenarios outlined in this manual. Regardless of whether the controller is faulty, a similar weighted fusion mechanism is used to generate recombined control commands. This simplifies the software architecture, eliminating the need to maintain two sets of code for "normal mode" and "recombined mode," thus reducing development and verification costs. Furthermore, it enhances the system's robustness and maintainability, while improving control accuracy under normal operating conditions through multi-source fusion (such as complementary A / B steering fine-tuning).

[0051] Step 204: When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function.

[0052] In one embodiment, when acquiring the independent normal control commands for the corresponding normal driving functions output by each controller, for each controller, the independent normal control commands output by that controller can be acquired in a corresponding manner according to the severity of the controller's fault. For example, if the faulty driving function indicates that the controller's fault severity is greater than a threshold, only the independent normal control commands for the corresponding normal driving function of that controller can be acquired, and these independent normal control commands are used to generate the recombined control commands. Conversely, if the faulty driving function indicates that the controller's fault severity is not greater than a threshold, both the independent normal control commands for the corresponding normal driving function and the independent faulty driving function output by that controller can be acquired, and these independent normal control commands and independent faulty driving commands are used to generate the recombined control commands. The severity of the controller's fault can be determined by the number or percentage of faulty driving functions corresponding to that controller. Taking the percentage as an example, the ratio of the number of faulty driving functions corresponding to that controller to the total number of driving functions can be calculated: a ratio less than a preset percentage indicates a severity less than the threshold (not very serious), and a ratio greater than a preset percentage indicates a severity greater than the threshold (relatively serious / very serious). Taking Table 1 above as an example, let's assume the threshold is 50%: For controller 1, the proportion of its fault driving function is 2 / 3, which is greater than 50%, so the severity of its fault is determined to be greater than the threshold. At this time, the normal power command output by controller 1 can be obtained; while for controller 2, the proportion of its fault driving function is 1 / 3, which is less than 50%, so the severity of its fault is determined to be less than the threshold. At this time, the fault steering command, normal braking command, and normal power command output by controller 2 can be obtained.

[0053] Understandably, this solution categorizes controller faults according to their severity: minor faults (≤ threshold) indicate a relatively minor controller malfunction (the instruction is likely just inaccurate, not completely erroneous), and the faulty output can continue to be used, allowing it to participate in all functional outputs (e.g., using its instructions for verification or degradation reference). Severe faults (> threshold) indicate a very serious controller malfunction (the instruction may contain significant errors and should not be used), therefore only its normal functions should be used, avoiding the faulty functions, to completely isolate high-risk factors in the output. This mechanism achieves a fine balance between security and resource utilization, avoiding excessive degradation.

[0054] In one embodiment, when determining the functional weights of each controller for each normal driving function, the corresponding functional weight for each normal driving function can be determined according to the number of independent normal control commands obtained for that function. For example, if only one independent normal control command for the normal driving function is obtained, the functional weight of the controller that generated the independent normal control command for that normal driving function can be determined as 1. If multiple independent normal control commands for the normal driving function are obtained, the functional weights of each controller that generated each independent normal control command for that normal driving function can be extracted from the control weight matrix matched to the current driving scenario; wherein the sum of the extracted functional weights of each controller for that normal driving function is 1, and the current driving scenario is determined based on the vehicle's current motion data and current road condition data.

[0055] As can be seen in this scheme, the weight is 1 for a single command: when only one controller issues a normal control command (e.g., only controller 1 issues a "turn" command), it means that other controllers are not activated or have not detected any risk. In this case, the controller is fully trusted to avoid response delays caused by human-induced weight reduction. When multiple commands conflict, intelligent weighting is applied according to the scenario: when multiple controllers output commands simultaneously (e.g., controller 1 suggests a left turn, controller 2 suggests slowing down due to slippery road conditions), the system does not simply take the average or vote, but extracts the optimal weight combination from the preset control weight matrix based on the current driving scenario (e.g., "highway + rainy weather"), making the fusion result more in line with safety priorities, thereby improving driving safety under "controller failure + specific scenario". This approach avoids a "one-size-fits-all" fusion strategy and can select appropriate functional weights according to the actual driving scenario (weights are not statically preset, but scenario-driven), thereby ensuring that the most reliable control source is adopted first in complex scenarios (e.g., emergency obstacle avoidance + low-adhesion road surface). Furthermore, the control weight matrix is ​​bound to current motion data (vehicle speed, acceleration, yaw rate) and road condition data (road friction coefficient, visibility, curvature). For example, in a "low-speed urban + dry road" scenario, controller 1 (such as the intelligent driving domain controller) has a higher weight; while in a "high-speed + flooded road" scenario, controller 2 (such as the chassis / brake controller) has a higher weight, and so on, with the system automatically switching control dominance. A weight sum of 1 ensures that the fused control commands remain within a reasonable physical range, avoiding excessive output (such as excessive steering angle) due to weight aggregation. This solution can achieve performance complementarity through the weight matrix when multiple controllers are working normally, enhancing system robustness and fault tolerance; moreover, it requires no manual intervention, meeting the evolutionary requirements of advanced autonomous driving from "human-machine co-driving" to "system-led".

[0056] In one embodiment, when fusing the independent normal control commands of each normal driving function according to the functional weights of each controller for each normal driving function to obtain the corresponding recombined control commands, for each normal driving function, the processing can be carried out in a corresponding manner according to the number of independent normal control commands obtained for that normal driving function. For example, if only one independent normal control command for that normal driving function is obtained, that independent normal control command can be determined as the recombined control command corresponding to that normal driving function; while if multiple independent normal control commands for that normal driving function are obtained, the multiple independent normal control commands can be weighted and summed according to the functional weights of each controller for that normal driving function to obtain the recombined control command corresponding to that normal driving function. Taking Table 1 above as an example, for the steering function, only the normal control command output by controller 3 can be obtained (controllers 1 and 2 both output fault control commands), so the normal control command can be directly determined as the recombined steering command corresponding to the steering function. As for the braking function, it can obtain the normal control commands output by controllers 2 and 3 respectively (controller 1 outputs the fault control command). Therefore, the two normal control commands can be weighted and summed to obtain the reconfigured braking command corresponding to the braking function. Similarly, for the power function, it can obtain the normal control commands output by controllers 1, 2 and 3 respectively. Therefore, the three normal control commands can be weighted and summed to obtain the reconfigured power command corresponding to the power function. This will not be elaborated further.

[0057] As can be seen, this solution directly adopts a single-instruction approach for scenarios where only one controller outputs a normal instruction (e.g., only the steering controller issues "turn left 15°"). This indicates that there are no other valid inputs or other controllers are inactive. In this case, fusion is unnecessary, and the instruction is directly used as the recombined control instruction, avoiding the introduction of unnecessary delays or noise. For multi-instruction scenarios, a weighted summation is used: when multiple controllers output different instructions for the same driving function (e.g., controller 1 suggests 60km / h, and the ACC module suggests 55km / h), the system performs a weighted average according to the functional weights corresponding to the aforementioned scenarios, generating a smooth and reliable fusion result. This method avoids control jitter caused by "hard switching" (e.g., a sudden jump from 60km / h to 55km / h). The fusion result is continuous and differentiable, which is beneficial for the smooth response of downstream actuators. Moreover, the fusion process can truly reflect the reliability of each controller in the current scenario. For example, on low-adhesion surfaces, even if the intelligent driving domain control suggests acceleration, the fusion result will be more conservative due to the high weight of the chassis controller; while on structured highways, the intelligent driving domain control has a high weight, and the system is more inclined to execute the planned trajectory. This makes the final reconfiguration control command not only "reasonable" but also possesses "contextual intelligence," truly achieving SOTIF. It is evident that this solution, through a lightweight strategy of "single command pass-through + multi-command weighted fusion," transforms the dynamic weights driven by scene perception into smooth, reliable, and real-time control outputs. While ensuring system robustness, it helps improve the safety and passenger experience of autonomous vehicles under complex conditions.

[0058] In one embodiment, the system can also acquire the vehicle's current motion data and current road condition data in real time to determine the corresponding current driving scenario. If the current driving scenario changes, the corresponding control weight matrix can be updated. Traditional solutions typically use statically preset control weight matrices for the primary and backup controllers (e.g., factory-fixed) or switch only according to limited modes (e.g., "city / highway"), failing to provide a precise response to continuously changing driving environments. This solution, however, uses onboard sensors to collect vehicle motion data (e.g., speed, acceleration, yaw rate, steering angle) and road condition data (e.g., road surface friction coefficient, slope, curvature, weather, visibility) in real time. This allows for dynamic identification of the current driving scenario (e.g., "highway curve + slippery road surface," "urban congestion + dense pedestrian traffic"), etc. Once the scenario changes, the control weight matrix can be updated immediately. This transforms the system from a reactive, lagging system into an intelligent control system with foresight and scenario awareness, meeting the closed-loop requirements of autonomous driving systems for "environmental understanding → behavior adjustment." Moreover, by updating the weight matrix in real time, this solution can increase the weight of the chassis / brake controller on low-adhesion surfaces to suppress aggressive steering; reduce the weight of the pure vision module in strong light / backlight scenarios to enhance radar fusion; and increase the weight of the human driver or backup controller in construction zones / unstructured roads, thereby proactively avoiding risks caused by the performance limits of sensors / algorithms and directly supporting the SOTIF verification objectives.

[0059] Step 206: Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain the corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

[0060] As can be seen from the previous embodiments, when there is at least one fault controller, the fault driving function and normal driving function corresponding to each controller are first determined. Then, when the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, the independent normal control instructions output by each controller are obtained and the corresponding function weights are determined. Finally, the independent normal control instructions of each normal driving function are fused according to the function weights of each controller for each normal driving function to obtain the corresponding recombined control instructions, and then the instructions are sent to the actuator to realize autonomous driving.

[0061] Understandably, in the event of a faulty controller, this solution does not perform a master-slave switchover at the overall controller level or directly degrade the autonomous driving system. Instead, it generates recombined control commands for vehicle control through a cross-team functional reconfiguration mechanism between different controllers (i.e., merging the independent normal control commands output by each controller based on their respective control weights). Thus, based on this cross-team functional reconfiguration mechanism, the multiple autonomous driving controllers (such as A / B Teams) in the autonomous driving system described in this solution no longer have a strict master-slave distinction (i.e., each Team no longer has a fixed "master / slave" identity in the traditional sense), but becomes a collection of multi-controllers with functional collaboration (note, not backup). These controllers have evolved into multiple functionally equivalent, interchangeable, and composable "resource pools." The cross-team functional reconfiguration mechanism is implemented at the fine-grained level of specific driving functions: the system no longer uses the output of a single controller as the basis for vehicle control, but rather determines the recombined control commands based on the independent control commands output by multiple controllers and their respective functional weights.

[0062] As can be seen, in the event of some controller failures, this solution can utilize the fault-free functions of each controller (including partially faulty controllers and / or fully normal controllers) to generate sufficient control commands for vehicle control, thereby making full use of the normal functions of each controller to complete vehicle control, effectively avoiding the "stop when the controller fails" scenario, and significantly reducing the number of interruptions in the autonomous driving function under controller failure scenarios. This not only helps to reduce safety risks, but also improves the overall utilization rate of each controller and the reliability of the system, especially improving the system's continuous operation capability and safety under multi-point concurrent failures, with significant improvement effects.

[0063] In one embodiment, the vehicle's current motion data and current road condition data can be acquired in real time to determine the corresponding current driving scenario. Then, scenario rules matching the current driving scenario are determined, and the reconfigured control command is verified to conform to the scenario rules. Subsequently, the reconfigured control command that passes verification can be sent to the actuator. Reconfigured control commands that fail verification are not sent to the actuator to avoid safety risks caused by commands exceeding the rules. Of course, in the event of a failed verification, the command can be forcibly adjusted (or corrected) according to the rules, or the corresponding controller can be triggered to adjust the command automatically (e.g., by calling the "Scene-Ethical Benchmark Command Library" for correction), until a preset number of attempts still fail, at which point the execution of the command is abandoned.

[0064] This solution constructs a dual safety barrier based on "fusion + verification," significantly improving functional safety levels. The first layer of protection involves generating reasonable and smooth control commands through weighted fusion of multiple controllers, as described in the previous embodiment. The second layer of protection is scene rule verification, as described in this embodiment, ensuring that the fusion result does not violate the physical or safety boundaries of the current scenario. For example, in an "icy road + curve" scenario, scene rules prohibit "high lateral acceleration." Therefore, even if the fused command is "to accelerate laterally at 0.6g to corner," the verification module will intercept and correct / reject the command to prevent vehicle loss of control, thereby effectively preventing dangerous outputs caused by weight allocation deviations, sensor misdetections, or multi-source conflict fusion distortion. Furthermore, this solution can use a scenario rule base (such as "maximum braking deceleration in rainy weather ≤ 0.4g" and "speed in school zones ≤ 30km / h") to make reasonable judgments on the fusion results and proactively avoid safety risks. For example, if a construction cone is detected but the fusion command does not decelerate, the command will be blocked due to the "speed limit in construction zone" rule; if the planning module makes an aggressive lane change but the yaw rate still exceeds the safe limit after fusion, the output can be downgraded after verification. In this way, empirical safety knowledge (such as traffic regulations, vehicle dynamics limits, and scenario common sense) can be encoded into executable rules, making up for the unknown defects of pure data-driven models.

[0065] The scenario rules may include at least one of the following: environmental data consistency rules, trajectory safety rules, and traffic ethics rules. The environmental data consistency rules are used to verify whether the environmental data output by the vehicle perception system is consistent, reasonable, and conflict-free, preventing dangerous decisions due to sensor misdetection, missed detection, or fusion errors. For example, the rule is: "If the lidar detects no obstacle 50 meters ahead, but the camera identifies a 'stop line + red light,' and the millimeter-wave radar does not detect a stationary vehicle, then a consistency check is triggered." Under this rule, if GPS positioning confirms an intersection, the red light is trusted; if not at an intersection, it is determined to be a camera misidentification, and the "stop" command is suppressed. As another example, in rainy conditions, if the vision system reports "clear lane lines," but neither the millimeter-wave radar nor the ultrasonic sensors detect the lane boundary, then the vision is considered to be interfered with, and the signal is downgraded. This rule can compensate for the physical perception limitations of the system with logical rationality, thereby improving the system's perception robustness and avoiding overly conservative or overly aggressive driving behaviors. The trajectory safety rules are used to verify whether the vehicle trajectory corresponding to the recombined control command meets dynamic constraints, road boundaries, and collision avoidance requirements, ensuring that execution will not lead to loss of control or accidents. For example, on slippery surfaces (friction coefficient μ < 0.3), steering commands with lateral acceleration greater than 0.2g are prohibited; at a current speed of 80 km / h, the radius of curvature of the lane-changing trajectory must not be less than 150 meters; the minimum lateral distance between the planned trajectory and static obstacles (such as guardrails or construction cones) must be ≥ 0.5 meters. Essentially, this rule encodes the vehicle dynamics model and road geometry into executable safety boundaries, ensuring physical feasibility and real-time collision avoidance. Traffic ethics rules, on the other hand, verify whether control behaviors comply with local traffic regulations, driving etiquette, and social ethical expectations, ensuring that autonomous driving behavior is "legal, reasonable, and acceptable to humans." For example, in school zones (7:00–18:00), the speed must not exceed 30 km / h, even if the road is empty; when pedestrians are crossing a crosswalk, vehicles must stop completely to yield (even if the pedestrian has not fully entered the lane); at intersections without traffic lights, vehicles on main roads have priority, and vehicles on side roads must "stop" rather than "proceed slowly," etc. The essence of these rules is to transform social norms into machine-executable behavioral guidelines, thereby increasing the social acceptability of autonomous driving behavior and reducing the legal and safety risks to the system and vehicles. Through these rules, a three-layer verification system of "credible perception + feasible trajectory + compliant behavior" can be constructed, covering the entire safety chain from underlying data to top-level behavior, significantly improving the safety, legality, and social adaptability of high-level autonomous driving systems.

[0066] In one embodiment, the actuator may include actuators corresponding to various driving functions. The vehicle may support TSN (Time-Sensitive Networking), and various actuators are pre-registered to the TSN. Based on this, when sending a recombined control command obtained by concatenating various recombined control commands to the actuator, for any recombined control command corresponding to any driving function, the access address of each actuator corresponding to that driving function in the TSN can be determined first. Then, a TSN message containing the recombined control command can be constructed based on the access address, and the TSN message can be sent to each actuator corresponding to that driving function through the TSN.

[0067] In this solution, the vehicle employs TSN-enabled in-vehicle network hardware. For example, the vehicle's electrical / electronic (E / E) architecture deploys TSN switches and TSN endpoints (such as domain controllers and actuator ECUs). Actuators (such as steering motor controllers, brake control units, and electric drive controllers) integrate TSN-compatible communication interfaces. Compared to traditional low-bandwidth, non-deterministic buses like CAN / LIN / FlexRay, this solution upgrades the vehicle to a high-bandwidth, deterministic, and scalable Ethernet TSN backbone. This solution achieves deterministic, low-latency, and highly reliable control command delivery through TSN, supporting precise coordination among multiple actuators. Furthermore, combined with pre-registration and address addressing mechanisms, it enhances the system's real-time performance, security, and scalability.

[0068] Corresponding to the above Figure 1 , Figure 3 This is a schematic diagram of another autonomous driving control system architecture shown in an embodiment of the present invention. Figure 3 As shown, the system can be divided into a scene perception layer, a core arbitration layer, a redundant control layer, and a TSN ring network at the software level. The data interaction process between each layer is as follows: [Scene Perception Layer - Multi-Source Sensor Fusion and Scene Understanding] Inputs include raw data from sensors such as cameras, LiDAR, millimeter-wave radar, and maps / positioning.

[0069] The processing takes place in the "Multi-source Sensor Fusion and Scene Understanding" module. The main processing steps include perception fusion (such as target detection and tracking), environmental modeling (lane lines, obstacles, traffic signals, etc.), and scene semantic understanding (such as urban congestion, highways, and low-adhesion road surfaces in rainy weather). After processing, structured scene information (including environmental status, dynamic objects, road attributes, etc.) is generated and output, and then sent to the core arbitration layer.

[0070] [Core Arbitration Layer – MSDA Dynamic Arbitrator] The inputs include scene information from the upper layer, module health information (i.e., running status data, such as controller load, latency, packet loss rate, etc.) from the lower layer, and verification standards and trigger signals from the "instruction verification and correction unit".

[0071] The processing is dynamically determined by MSDA (Multi-dimensional Scenario-aware Dynamic Arbiter) based on the current scenario and system state: the control weight of each controller (such as Team A / Team B) on different driving functions (such as steering, braking, power); and the allocation of control responsibilities of each controller (such as Team A leading steering and Team B assisting braking at a certain moment).

[0072] The output includes control weight and responsibility allocation instructions sent to the redundant control layer, as well as verification criteria and trigger signals sent to the instruction verification and correction unit.

[0073] [Redundant Control Layer – Multiple Controllers (e.g., Team A / Team B)] Inputs include control weight and responsibility assignment instructions from the MSDA and service call requests (such as "request steering control") from the "central security gateway." The controllers maintain consistency through state synchronization (e.g., sharing vehicle status, timestamps, etc.).

[0074] The process is as follows: each controller runs its control algorithm (such as path planning, trajectory tracking, etc.) independently, and then generates its own independent normal control command (such as "steering angle = 5°") according to the weights assigned by MSDA; at the same time, state synchronization ensures logical consistency and avoids conflicts.

[0075] The output includes independent control commands sent to the "Central Security Gateway", module health information (such as load and latency) fed back to the "Core Arbitration Layer" (for MSDA dynamic adjustment), and service call requests sent to the "Central Security Gateway" to obtain services.

[0076] In addition, the input to the instruction verification and correction unit is the verification standard and trigger signal from MSDA (such as the instruction to be verified: "Currently a school zone, speed limit 30km / h"). The processing includes verifying the recombined instruction based on the scenario rule base (including environmental data consistency rules, trajectory safety rules, traffic ethics rules, etc.). If it does not comply with the rules, the instruction is corrected or rejected; instructions that pass verification are sent to the "central security gateway", while rejection signals that fail are used to trigger degradation strategies (such as deceleration) or manual takeover.

[0077] [TSN Ring Network - Transmitting Service Data] The input is a TSN message from the central security gateway. The TSN provides deterministic, low-latency, and highly reliable communication; messages are routed to the corresponding execution service based on the pre-registered access address.

[0078] The outputs include steering function (corresponding to the execution of steering action), braking function (corresponding to the execution of braking action), and power function (corresponding to the execution of acceleration / deceleration action).

[0079] In addition, the input to the system health monitoring unit is the real-time monitoring of the module health information of each module (such as CPU load, network latency, packet loss rate, etc.). The processing involves reporting the module health information to the core arbitration layer so that MSDA can use it to dynamically adjust the control weights (such as reducing the weight of a controller if its load is too high).

[0080] In this system, the four layers of perception, decision-making, control, and execution are decoupled, resulting in a clear structure. MSDA dynamic arbitration enables intelligent allocation of control rights, and multiple controllers with equal redundancy enhance reliability. Furthermore, the TSN network ensures communication determinism, instruction verification strengthens SOTIF and functional safety, and a health feedback closed loop supports adaptive regulation.

[0081] This architecture enables a highly secure, highly available, and highly real-time autonomous driving closed-loop control system, suitable for various autonomous driving systems, especially Level 3 and above autonomous driving systems.

[0082] Figure 4 This is a flowchart illustrating another method for redundant control of autonomous driving according to an embodiment of the present invention. This method uses two controllers (i.e., A / B Team) as an example and is also applied to the aforementioned autonomous driving system. Figure 4 As shown, the specific process is as follows: [Initialization and Frame-by-Frame Execution Phase] This stage is the initialization and continuous operation phase after system startup. Its purpose is to complete hardware and software self-checks, module loading, and state synchronization, preparing the system for normal driving. It mainly includes the following four steps: 1. Start A / B Team and load the primary / standby control policy. The controllers of Team A and Team B are powered on simultaneously and load their respective control algorithms (such as path planning and trajectory tracking); they can be configured as a peer-to-peer redundant architecture or a master / slave architecture, supporting fault switching.

[0083] 2. Initiate health monitoring and continuously analyze the health status of the A / B Team. Real-time data collection of operating status information for each controller, such as load, latency, packet loss rate, and CPU usage, is used to determine whether a "fault" or "performance degradation" has occurred.

[0084] 3. Activate environmental perception and continuously analyze driving environment information. It integrates sensor data from cameras, radar, maps, etc., to output information about the type of the current driving scenario (such as "city congestion", "highway curves", "slippery weather in rain").

[0085] 4. A / B Teams synchronize initial instructions and status. The two controllers exchange initial states (such as vehicle position, speed, target point, etc.) via shared memory or network to ensure that the states are consistent before control begins and to avoid conflicts.

[0086] After initialization, the two controllers cooperate to achieve the autonomous driving function, that is, they calculate the recombined control command according to the independent control command output by each controller and send it to the actuator to control the vehicle to drive automatically.

[0087] [MSDA Arbitration Phase – The Continuous Vehicle Control Process After Autonomous Driving is Activated] MSDA is the core decision-making unit of the entire system, performing dynamic arbitration based on real-time input. It comprises three parallel processing submodules: 1. Continuous monitoring submodule for driving scenario types It is used to continuously analyze whether the current scene changes (such as from "highway" to "tunnel"), and triggers the update of the control weight matrix when the scene changes.

[0088] 2. A / B Team Health Continuous Assessment Submodule It is used to determine whether there is a fault in the A / B Team (such as communication interruption or calculation timeout), and to trigger cross-team reorganization when a fault is detected.

[0089] 3. Scenario-based instruction generation and verification submodule It is used to generate "expected instructions" (such as "should decelerate to 30km / h") based on the current scenario, and compares whether the actual control instructions comply with environmental data consistency rules, trajectory safety rules and / or traffic ethics rules, etc., to decide whether to adopt or downgrade them.

[0090] [Decision Branches and Action Execution] Each of the aforementioned submodules outputs a judgment result, triggering the corresponding action: Decision 1: Has the driving scenario changed? (This is used to implement scenario-adaptive control, ensuring optimal control strategy under different environments) If so, update the control weight matrix (e.g., if it is cloudy turning to rainy, increase the controller weight corresponding to the braking function). If not, the current control weight matrix will be used (keeping the original control strategy unchanged).

[0091] Judgment 2: Is Team A / B faulty? (Used to achieve fault tolerance and redundancy switching, ensuring continuous system operation) If so, then cross-team restructuring will be carried out (if Team A fails, then Team B will take over full control). If not, then conventional collaboration will be used (A / B Teams jointly output instructions according to their weights).

[0092] Decision 3: Has the scenario-based instruction passed the validation? (This is used to implement SOTIF and functional safety fallback, preventing dangerous behavior due to misjudgment) If so, then adopt the current instruction (allowing it to be sent to the executor); If not, a downgrade strategy will be triggered (such as switching to manual control, safe parking, etc.).

[0093] [Output and Execution Phase] This stage is the A / B Team collaborative control instruction based on the arbitration results, which integrates the decision results of the above three branches into the final collaborative control instruction.

[0094] This mainly includes determining the control weights of each controller, deciding whether to enable cross-team reconfiguration, and determining whether degradation processing is required. The final reconfiguration control command is sent to the execution layer (the corresponding actuators for functions such as steering, braking, and power) via the TSN. This TSN provides deterministic, low-latency, and highly reliable communication, ensuring timely and accurate execution of commands.

[0095] In each frame loop, the system synchronously senses the environment and health status. The MSDA arbitrator dynamically determines control weights, fault handling, and instruction compliance, ultimately generating safe and reliable cooperative control instructions and issuing them for execution via the TSN network. This process embodies highly safe, robust, and adaptable autonomous driving control logic.

[0096] Figure 5 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention. Please refer to it. Figure 5 At the hardware level, the device includes a processor 502, a network interface 506, memory 508, non-volatile memory 510, and an internal bus 504, and may also include other hardware required for business operations. One or more embodiments of the present invention can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into memory 508 and then runs it. Of course, in addition to software implementation, one or more embodiments of the present invention do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0097] Figure 6 This invention illustrates a block diagram of an autonomous driving redundancy control device. Please refer to... Figure 6 This device can be applied to, for example Figure 5 The device shown is used to implement the technical solution described in this invention. This device is applied to an autonomous driving system for a vehicle, the autonomous driving system including multiple autonomous driving controllers, each controller being used to output control commands for various driving functions, the vehicle being equipped with actuators, and the device comprising: The fault determination unit 601 is used to determine the fault driving function affected by the fault and the normal driving function not affected by the fault for each controller when at least one faulty controller is present among the plurality of controllers. The instruction acquisition unit 602 is used to acquire the independent normal control instructions for the normal driving function output by each controller when the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, and to determine the functional weight of each controller for each normal driving function. The instruction recombination unit 603 is used to fuse the independent normal control instructions of each normal driving function according to the functional weight of each controller for each normal driving function to obtain the corresponding recombined control instructions, and send the recombined control instructions to the actuator to control the vehicle driving.

[0098] Optionally, each controller includes multiple functional modules, and the fault determination unit 601 is specifically used for: The system acquires the operating status data of each functional module contained in any controller in real time, and determines that any controller has failed if there is a faulty functional module among the multiple functional modules whose operating status data meets the corresponding fault conditions.

[0099] Optionally, the fault determination unit 601 is specifically used for: For any controller, the driving function corresponding to the faulty function module is determined as the faulty driving function corresponding to the controller according to the preset module function mapping relationship, and the driving function that does not correspond to any of the faulty function modules is determined as the normal driving function corresponding to the controller.

[0100] Optionally, the instruction acquisition unit 602 is specifically used for: for each normal driving function, If only one independent normal control command for the normal driving function is obtained, the functional weight of the controller that generated the independent normal control command for the normal driving function is determined to be 1. If multiple independent normal control commands for the normal driving function are obtained, the functional weights of each controller that generated each independent normal control command for the normal driving function are extracted from the control weight matrix matched with the current driving scenario; wherein, the sum of the extracted functional weights of each controller for the normal driving function is 1, and the current driving scenario is determined based on the vehicle's current motion data and current road condition data.

[0101] Optionally, the instruction reconfiguration unit 603 is specifically used for: for each normal driving function, If only one independent normal control command for the normal driving function is obtained, then the independent normal control command is determined as the recombined control command corresponding to the normal driving function. If multiple independent normal control commands for the normal driving function are obtained, the multiple independent normal control commands are weighted and summed according to the function weight of each controller for the normal driving function to obtain the recombined control command corresponding to the normal driving function.

[0102] Optionally, a matrix update unit 604 is also included, for: The system acquires the vehicle's current motion data and current road condition data in real time and determines the corresponding current driving scenario; if the current driving scenario changes, it updates the corresponding control weight matrix.

[0103] Optionally, the instruction acquisition unit 602 is specifically used for: for each controller, When the fault driving function indicates that the severity of the controller's fault is greater than a threshold, only the independent normal control command corresponding to the normal driving function output by the controller is obtained, and the independent normal control command is used to generate the recombined control command. When the fault driving function indicates that the severity of the controller's fault is not greater than a threshold, the independent normal control command for the normal driving function and the independent fault driving function output by the controller are obtained respectively. The independent normal control command and the independent fault control command are used to generate the recombined control command.

[0104] Optionally, the device further includes a rule verification unit 605, used to acquire the vehicle's current motion data and current road condition data in real time and determine the corresponding current driving scenario; determine the scenario rules matching the current driving scenario, and verify whether the recombined control command conforms to the scenario rules; The instruction reassembly unit 603 is specifically used to send the reassembly control instruction that has passed verification to the actuator.

[0105] Optionally, the scenario rules include at least one of the following: environmental data consistency rules, trajectory safety rules, and traffic ethics rules.

[0106] Optionally, the actuators include actuators corresponding to various driving functions, the vehicle supports a Time-Sensitive Network (TSN), and various actuators are pre-registered to the TSN. The instruction reassembly unit 603 is specifically used for: For any reconfiguration control command corresponding to any driving function, determine the access address of each actuator corresponding to the driving function in the TSN; Based on the access address, a TSN message containing any of the reconfiguration control instructions is constructed, and the TSN message is sent to each actuator corresponding to any of the driving functions via the TSN.

[0107] Optionally, a degradation unit 606 is also included, which is used to: control the vehicle to drive and / or prompt the driver to manually drive the vehicle according to a preset degradation strategy when there is at least one faulty driving function whose number of fault controllers is equal to the total number of controllers.

[0108] Optionally, a normal peer control unit 607 is also included, for: In the absence of a faulty controller among the multiple controllers, the independent control commands for each driving function output by each controller are determined, and the functional weight of each controller for each driving function is determined. The independent control commands for each driving function are fused according to the functional weight of each controller for each driving function to obtain the corresponding recombined control command, and the recombined control command is sent to the actuator to control the vehicle's movement.

[0109] Accordingly, the present invention also provides a vehicle equipped with an environmental perception device and a driver assistance system, which is used to implement the autonomous driving system and the autonomous driving redundancy control method described in any of the above embodiments.

[0110] Accordingly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the autonomous driving system and autonomous driving redundancy control method as described in any of the above embodiments.

[0111] Accordingly, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the autonomous driving system and the autonomous driving redundancy control method as described in any of the above embodiments.

[0112] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0113] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

Claims

1. An autonomous driving redundancy control method, characterized in that, An autonomous driving system for a vehicle, the autonomous driving system comprising multiple autonomous driving controllers, each controller being used to output control commands for various driving functions, the vehicle being equipped with actuators; the method comprising: In the case where at least one of the multiple controllers is faulty, the fault driving function affected by the fault and the normal driving function unaffected by the fault are determined for each controller respectively. When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function. Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

2. The method according to claim 1, characterized in that, Each controller contains multiple functional modules. Determining a fault in any controller includes: The system acquires the operating status data of each functional module contained in any controller in real time, and determines that any controller has failed if there is a faulty functional module among the multiple functional modules whose operating status data meets the corresponding fault conditions.

3. The method according to claim 2, characterized in that, The determination of the fault-affected driving function and the normal driving function unaffected by the fault for each controller includes: For any controller, the driving function corresponding to the faulty function module is determined as the faulty driving function corresponding to the controller according to the preset module function mapping relationship, and the driving function that does not correspond to any of the faulty function modules is determined as the normal driving function corresponding to the controller.

4. The method according to claim 1, characterized in that, The step of determining the functional weight of each controller for each normal driving function includes: for each normal driving function, If only one independent normal control command for the normal driving function is obtained, the functional weight of the controller that generated the independent normal control command for the normal driving function is determined to be 1. If multiple independent normal control commands for the normal driving function are obtained, the functional weights of each controller for the normal driving function that generate each independent normal control command are extracted from the control weight matrix matched with the current driving scenario; wherein, the sum of the extracted functional weights of each controller for the normal driving function is 1, and the current driving scenario is determined based on the vehicle's current motion data and current road condition data.

5. The method according to claim 4, characterized in that, The process of fusing the independent normal control commands for each normal driving function according to the functional weights of each controller for each normal driving function to obtain corresponding recombined control commands includes: for each normal driving function, If only one independent normal control command for the normal driving function is obtained, then the independent normal control command is determined as the recombined control command corresponding to the normal driving function; If multiple independent normal control commands for the normal driving function are obtained, the multiple independent normal control commands are weighted and summed according to the function weight of each controller for the normal driving function to obtain the recombined control command corresponding to the normal driving function.

6. The method according to claim 4, characterized in that, Also includes: The vehicle's current motion data and current road condition data are acquired in real time, and the corresponding current driving scenario is determined. If the current driving scenario changes, the corresponding control weight matrix is ​​updated.

7. The method according to claim 1, characterized in that, The acquisition of the independent normal control commands output by each controller for its corresponding normal driving function includes: for each controller, When the fault driving function indicates that the severity of the controller's fault is greater than a threshold, only the independent normal control command corresponding to the normal driving function output by the controller is obtained, and the independent normal control command is used to generate the recombined control command. When the fault driving function indicates that the severity of the controller's fault is not greater than a threshold, the independent normal control command for the normal driving function and the independent fault driving function output by the controller are obtained respectively. The independent normal control command and the independent fault control command are used to generate the recombined control command.

8. The method according to claim 1, characterized in that, The method further includes: acquiring the vehicle's current motion data and current road condition data in real time and determining the corresponding current driving scenario; determining the scenario rules matching the current driving scenario and verifying whether the recombined control command conforms to the scenario rules; Sending the reconfiguration control command to the actuator includes: sending the reconfiguration control command that has passed verification to the actuator.

9. The method according to claim 8, characterized in that, The scenario rules include at least one of the following: environmental data consistency rules, trajectory safety rules, and traffic ethics rules.

10. The method according to claim 1, characterized in that, The actuators include actuators corresponding to various driving functions. The vehicle supports a Time-Sensitive Network (TSN), and the various actuators are pre-registered to the TSN. Sending the reconfiguration control command to the actuators includes: For any reconfiguration control command corresponding to any driving function, determine the access address of each actuator corresponding to the driving function in the TSN; Based on the access address, a TSN message containing any of the reconfiguration control instructions is constructed, and the TSN message is sent to each actuator corresponding to any of the driving functions via the TSN.

11. The method according to any one of claims 1-10, characterized in that, Also includes: If the number of fault controllers corresponding to at least one fault driving function is equal to the total number of controllers, the vehicle driving is controlled according to a preset degradation strategy and / or the driver is prompted to manually drive the vehicle.

12. The method according to any one of claims 1-10, characterized in that, Also includes: In the absence of a faulty controller among the multiple controllers, the independent control commands for each driving function output by each controller are determined, and the functional weight of each controller for each driving function is determined. The independent control commands for each driving function are fused according to the functional weight of each controller for each driving function to obtain the corresponding recombined control command, and the recombined control command is sent to the actuator to control the vehicle's movement.

13. An autonomous driving system for a vehicle, characterized in that, The autonomous driving system includes a management module and multiple autonomous driving controllers, wherein each controller is used to output control commands for various driving functions, and the vehicle is equipped with actuators; wherein the management module is used for: In the case where at least one of the multiple controllers is faulty, the fault driving function affected by the fault and the normal driving function unaffected by the fault are determined for each controller respectively. When the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, obtain the independent normal control command output by each controller for its corresponding normal driving function, and determine the functional weight of each controller for each normal driving function. Based on the functional weight of each normal driving function for each controller, the independent normal control commands for each normal driving function are fused to obtain corresponding recombined control commands, and the recombined control commands are sent to the actuator to control the vehicle's movement.

14. An automated driving redundancy control device, characterized in that, An autonomous driving system for vehicles, the autonomous driving system comprising multiple autonomous driving controllers, each controller being used to output control commands for various driving functions, the vehicle being equipped with actuators; the device comprising: The fault determination unit is used to determine the fault driving function affected by the fault and the normal driving function unaffected by the fault for each controller when at least one faulty controller is present among the plurality of controllers. The instruction acquisition unit is used to acquire the independent normal control instructions for the normal driving function output by each controller when the number of fault controllers corresponding to each fault driving function is less than the total number of controllers, and to determine the functional weight of each controller for each normal driving function. The instruction recombining unit is used to fuse the independent normal control instructions of each normal driving function according to the functional weight of each controller for each normal driving function to obtain the corresponding recombined control instructions, and send the recombined control instructions to the actuator to control the vehicle driving.

15. A vehicle equipped with actuators, the vehicle's autonomous driving system including actuators and an autonomous driving controller for implementing conditional autonomous driving and / or highly autonomous driving, the autonomous driving system being used to implement the method as described in any one of claims 1-12.

16. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-12.

17. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by a processor, they implement the steps of the method as described in any one of claims 1-12.

Images