Vehicle control method and apparatus

Abstract

A vehicle control method and apparatus, which are used for implementing redundant backup of related functions of a vehicle, so as to improve the safety and reliability of vehicle driving. The method may comprise: a first control module determines that a second control link is abnormal, both the first control module and a second control module supporting a first function of the vehicle, the first control module belonging to a first control link, and the second control module belonging to the second control link; and takes over the first function, and in the first control link, on the basis of first information, controls driving of the vehicle, the first information comprising at least one of the following: accelerator pedal position information of the vehicle, brake pedal position information of the vehicle, or torque request information of an advanced driving system of the vehicle.

Description

A vehicle control method and device Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle control method and device. Background Technology

[0002] With the development of vehicle intelligence and electrification, vehicle powertrain systems have shifted from traditional engine-driven systems to electric motor-driven systems (referred to as electric drive systems). As shown in Figure 1, in an electric drive system, the vehicle control unit (VCU) or vehicle domain controller (VDC) serves as the control center. Accelerator pedal sensors or advanced driving system (ADS) controllers are connected to the VCU / VDC. The VCU / VDC is connected to the vehicle's motor control unit, used to convert the driver's acceleration intention into torque commands from the electric drive system and send them to the motor control unit, or to calculate the output torque based on torque requests from the ADS controller and send it to the motor control unit, thus completing torque output and realizing the vehicle's torque control function. Simultaneously, the VCU / VDC is also connected to vehicle components or auxiliary systems on which the powertrain system depends, used to implement component control and auxiliary functions.

[0003] The aforementioned control chain is singular. When the VCU / VDC fails or malfunctions, it cannot transmit the driver's driving intentions or intelligent driving intentions to the motor control unit. This interrupts the torque output control of the motor control unit, resulting in a loss of vehicle power. It also causes some vehicle components or auxiliary systems to become inoperable, affecting the system's safety and reliability. Summary of the Invention

[0004] This application provides a vehicle control method and apparatus for implementing redundant backup of relevant vehicle functions, thereby improving the safety and reliability of vehicle driving.

[0005] Firstly, this application provides a vehicle control method, which can be executed by a first control module. The first control module can be an independent device, a chip or component in the vehicle, or a software module. The software module can be deployed on relevant in-vehicle equipment, such as integrated into the vehicle's intelligent driving domain control unit (e.g., mobile data center (MDC)), vehicle control unit (VCU), vehicle domain controller (VDC), chassis domain control unit, motor control unit (MCU), or vehicle interface unit (VIU), or deployed on the control unit of other components of the vehicle. The embodiments of this application do not limit the product form and deployment method of this control.

[0006] In this method, the first control module belongs to the first control link, and both the first and second control modules support the first function of the vehicle. The second control module belongs to the second control link. The method may include: determining that the second control link is abnormal; taking over the first function, and controlling the vehicle to drive according to first information in the first control link. The first information includes at least one of the following: the accelerator pedal opening information, the brake pedal opening information, or the torque request information of the vehicle's intelligent driving system.

[0007] Therefore, redundant control links enable backup control of the vehicle's primary functions. When one control link in the redundant architecture fails, the driver or ADS controller can take over the primary functions through the backup control link, effectively control the vehicle's movement, and ensure that other critical subsystems can still operate smoothly under the control of the backup control link.

[0008] In conjunction with the first aspect, in one possible implementation, the first function may include vehicle motion control functions and vehicle motion-dependent functions.

[0009] In conjunction with the first aspect, in one possible implementation, the first control module is connected to an in-vehicle control network. Controlling the vehicle's movement according to first information in the first control link may include: broadcasting a first control message corresponding to the first function according to the first information in the first control link. The in-vehicle control network is further connected to one or more of the following execution units: a motor control unit (MCU), an electronic stability control (ESC) unit, a main braking unit (IPB), a redundant braking unit (RBU), a steering unit, a power-on / off management unit, a gear control unit, a thermal management control unit, a battery management system (BMS) control unit, and a voltage conversion and distribution unit.

[0010] In conjunction with the first aspect, in one possible implementation, determining that the second control link is abnormal includes: obtaining the power-on status information of the second control module; if the second control module is not powered on within a first time period, determining that the second control link is abnormal.

[0011] In conjunction with the first aspect, in one possible implementation, the first control module and the second control module are connected to the vehicle control network. When the second control module performs the first function, it broadcasts a second control message corresponding to the first function. The step of determining that the second control link is abnormal includes: if the second control message is not received within a second time period, determining that the second control link is abnormal.

[0012] In conjunction with the first aspect, in one possible implementation, the second duration is n times the sending period of the second control message, where n is greater than or equal to 2.

[0013] In conjunction with the first aspect, in one possible implementation, determining that the second control link is abnormal includes: if fault status information of the second control module is obtained and the fault time reaches a third duration, determining that the second control link is abnormal.

[0014] In conjunction with the first aspect, in one possible implementation, the third duration is m times the sending period of the second control message of the second control module, where m is greater than or equal to 2, and the second control message is a control message corresponding to the first function broadcast by the second control module in the vehicle control network.

[0015] In conjunction with the first aspect, in one possible implementation, the method further includes: sending takeover flag information to the second control module, wherein the takeover flag information is associated with the silent state of the second control module, and the second control module does not send a second control message corresponding to the first function after entering the silent state.

[0016] In conjunction with the first aspect, in one possible implementation, the method further includes: clearing the takeover flag information upon power-off; or, clearing the takeover flag information based on control information from the user.

[0017] In conjunction with the first aspect, in one possible implementation, the method further includes: obtaining control status information of the second control module; if the control status information indicates that the second control module is performing the first function, entering a silent state, wherein the first control module does not send a first control message corresponding to the first function after entering the silent state.

[0018] In conjunction with the first aspect, in one possible implementation, the method further includes: notifying the user of the vehicle to take over the first function via the vehicle's human-machine interface (HMI) or voice broadcast; or notifying the first control module to take over the first function via the vehicle's intelligent driving system (ADS).

[0019] In conjunction with the first aspect, in one possible implementation, the first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: analog input (AI) method, digital input (DI) method, single-sided nibble transmission protocol (SENT), and Ethernet.

[0020] In conjunction with the first aspect, in one possible implementation, the first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are combinations of any two of the following controllers of the vehicle: vehicle domain controller (VDC), motor control unit (MCU), area control unit (VIU), intelligent driving system domain control unit (MDC), or chassis domain controller.

[0021] Secondly, this application provides a vehicle control method applied to a second control module. The second control module can be an independent device, a chip or component in the vehicle, or a software module. The software module can be deployed on relevant vehicle equipment, such as integrated into an MDC, VCU, VDC, chassis domain control unit, motor control unit MCU, or area controller VIU, or deployed on the control unit of other components of the vehicle. This application does not limit the product form and deployment method of the control.

[0022] In this method, the second control module belongs to the second control link. Both the second control module and the first control module support the first function of the vehicle. The method includes: when executing the first function, sending a second control message corresponding to the first function in the second control link according to first information; and stopping sending the second control message after the first control module takes over the first function.

[0023] In conjunction with the second aspect, in one possible implementation, the first function includes vehicle motion control function and vehicle motion dependency function.

[0024] In conjunction with the second aspect, in one possible implementation, the second control module is connected to the vehicle control network. When the second control module performs the first function, it broadcasts a second control message corresponding to the first function. The vehicle control network is also connected to one or more of the following execution units: motor control unit (MCU), vehicle electronic stability control (ESC) unit, main braking unit (IPB), redundant braking unit (RBU), steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system (BMS) control unit, and voltage conversion and distribution unit.

[0025] In conjunction with the second aspect, in one possible implementation, the method further includes: determining that there is no abnormality in the second control link upon power-up, powering on and executing the first function; sending control status information to the first control module, the control status information indicating that the second control module is executing the first function.

[0026] In conjunction with the second aspect, in one possible implementation, the second control module is connected to an in-vehicle control network, and sending control status information to the first control module includes broadcasting the control status information on the in-vehicle control network.

[0027] In conjunction with the second aspect, in one possible implementation, the step of stopping the transmission of the second control message after the first control module takes over the first function includes: obtaining takeover flag information, the takeover flag information indicating that the first control module takes over the first function; entering a silent state and stopping the transmission of the second control message.

[0028] In conjunction with the second aspect, in one possible implementation, the method further includes: obtaining control status information of the first control module after fault recovery; if the control status information indicates that the first control module is performing the first function, entering a silent state, wherein the second control module does not send a second control message corresponding to the first function after entering the silent state.

[0029] In conjunction with the second aspect, in one possible implementation, the method may further include: notifying the user of the vehicle to stop executing the first function via the vehicle's human-machine interface (HMI) or voice broadcast; or notifying the second control module to stop executing the first function via the vehicle's intelligent driving system (ADS).

[0030] In conjunction with the second aspect, in one possible implementation, the first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: analog input (AI) method, digital input (DI) method, single-sided nibble transmission protocol (SENT), and Ethernet.

[0031] In conjunction with the second aspect, in one possible implementation, the first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are a combination of any two of the following controllers of the vehicle: vehicle domain controller (VDC), motor control unit (MCU), area control unit (VIU), intelligent driving system domain control unit (MDC), or chassis domain controller.

[0032] Thirdly, embodiments of this application provide a vehicle control device, comprising: a determining unit, configured to determine an anomaly in a second control link, the second control link including a second control module, both the second control module and a first control module supporting a first function of the vehicle, the first control module belonging to a first control link; and a control unit, configured to take over the first function and, in the first control link, control the vehicle to drive according to first information, the first information including at least one of the following: accelerator pedal opening information, brake pedal opening information, or torque request information of the vehicle's intelligent driving system.

[0033] In conjunction with the third aspect, in one possible implementation, the first function may include vehicle motion control functions and vehicle motion-dependent functions.

[0034] In conjunction with the third aspect, in one possible implementation, the first control module is connected to the vehicle control network. The control unit is specifically used to: broadcast a first control message corresponding to the first function according to the first information in the first control link. The vehicle control network is also connected to one or more of the following execution units: motor control unit (MCU), vehicle electronic stability control (ESC) unit, main braking unit (IPB), redundant braking unit (RBU), steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system (BMS) control unit, and voltage conversion and distribution unit.

[0035] In conjunction with the third aspect, in one possible implementation, the determining unit is specifically used to: obtain the power-on status information of the second control module; if the second control module is not powered on within a first time period, determine that the second control link is abnormal.

[0036] In conjunction with the third aspect, in one possible implementation, the first control module and the second control module are connected to the vehicle control network. When the second control module performs the first function, it broadcasts a second control message corresponding to the first function. The determining unit is specifically used to: determine that the second control link is abnormal if the second control message is not received within a second time period.

[0037] In conjunction with the third aspect, in one possible implementation, the second duration is n times the sending period of the second control message, where n is greater than or equal to 2.

[0038] In conjunction with the third aspect, in one possible implementation, the determining unit is specifically used to: if the fault status information of the second control module is obtained and the fault time reaches a third duration, determine that the second control link is abnormal.

[0039] In conjunction with the third aspect, in one possible implementation, the third duration is m times the sending period of the second control message of the second control module, where m is greater than or equal to 2, and the second control message is a control message corresponding to the first function broadcast by the second control module in the vehicle control network.

[0040] In conjunction with the third aspect, in one possible implementation, the device further includes: a transceiver unit, configured to send takeover flag information to the second control module, wherein the takeover flag information is associated with the silent state of the second control module, and the second control module does not send a second control message corresponding to the first function after entering the silent state.

[0041] In conjunction with the third aspect, in one possible implementation, the control unit method is further configured to: clear the takeover flag information upon power-off; or, clear the takeover flag information based on control information from the user.

[0042] In conjunction with the third aspect, in one possible implementation, the device further includes: an acquisition unit for acquiring control status information of the second control module; if the control status information indicates that the second control module is performing the first function, it enters a silent state, wherein the first control module does not send a first control message corresponding to the first function after entering the silent state.

[0043] In conjunction with the third aspect, in one possible implementation, the device further includes a notification unit, configured to notify the user of the vehicle, via the vehicle's human-machine interface (HMI) or voice broadcast, that the first control module has taken over the first function; or, to notify the vehicle's intelligent driving system (ADS) that the first control module has taken over the first function.

[0044] In conjunction with the third aspect, in one possible implementation, the first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: analog input (AI) method, digital input (DI) method, single-sided nibble transmission protocol (SENT), and Ethernet.

[0045] In conjunction with the third aspect, in one possible implementation, the first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are combinations of any two of the following controllers of the vehicle: vehicle domain controller (VDC), motor control unit (MCU), area control unit (VIU), intelligent driving system domain control unit (MDC), or chassis domain controller.

[0046] Fourthly, embodiments of this application provide a vehicle control device, comprising: a control unit, configured to, when performing the first function, send a second control message corresponding to the first function of the vehicle in a second control link according to first information, the second control link including a second control module, both the second control module and the first control module supporting the first function, the first control module belonging to the first control link; and a transceiver unit, configured to stop sending the second control message after the first control module takes over the first function.

[0047] In conjunction with the fourth aspect, in one possible implementation, the first function includes vehicle motion control function and vehicle motion dependency function.

[0048] In conjunction with the fourth aspect, in one possible implementation, the second control module is connected to the vehicle control network. When the second control module performs the first function, it broadcasts a second control message corresponding to the first function. The vehicle control network is also connected to one or more of the following execution units: motor control unit (MCU), vehicle electronic stability control (ESC) unit, main braking unit (IPB), redundant braking unit (RBU), steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system (BMS) control unit, and voltage conversion and distribution unit.

[0049] In conjunction with the fourth aspect, in one possible implementation, the control unit is further configured to determine that there is no abnormality in the second control link upon power-up, power on and execute the first function; the transceiver unit is configured to send control status information to the first control module, the control status information indicating that the second control module is executing the first function.

[0050] In conjunction with the fourth aspect, in one possible implementation, the second control module is connected to an in-vehicle control network, and the transceiver unit is specifically used to broadcast the control status information to the in-vehicle control network.

[0051] In conjunction with the fourth aspect, in one possible implementation, the device further includes: a silencing unit for entering a silencing state and ceasing to send the second control message upon receiving takeover flag information, the takeover flag information indicating that the first control module takes over the first function.

[0052] In conjunction with the fourth aspect, in one possible implementation, the device further includes: a silencing unit for acquiring control status information of the first control module after fault recovery; if the control status information indicates that the first control module is performing the first function, it enters a silencing state, wherein the second control module does not send a second control message corresponding to the first function after entering the silencing state.

[0053] In conjunction with the fourth aspect, in one possible implementation, the device may also notify a unit to notify the user of the vehicle to stop executing the first function via the vehicle's human-machine interface (HMI) or voice broadcast; or to notify the second control module to stop executing the first function via the vehicle's intelligent driving system (ADS).

[0054] In conjunction with the fourth aspect, in one possible implementation, the first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: analog input (AI) method, digital input (DI) method, single-sided nibble transmission protocol (SENT), and Ethernet.

[0055] In conjunction with the fourth aspect, in one possible implementation, the first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are a combination of any two of the following controllers of the vehicle: vehicle domain controller (VDC), motor control unit (MCU), area control unit (VIU), intelligent driving system domain control unit (MDC), or chassis domain controller.

[0056] Fifthly, this application provides a vehicle control method, comprising: receiving a first torque control command from a first control module, and / or receiving a second torque control command from a second control module, wherein the first control module belongs to a first control link, the second control module belongs to a second control link, and the first control module and the second control module support torque control functions of the vehicle, as well as vehicle driving-dependent functions; determining a target torque control command from the first torque control command and the second torque control command; and controlling the vehicle to drive based on the target torque control command.

[0057] In conjunction with the fifth aspect, in one possible implementation, the first torque control command includes a first torque, and the second torque control command includes a second torque. Determining a target torque control command from the first torque control command and the second torque control command includes: if the first torque and the second torque are the same, determining either the first torque control command or the second torque control command as the target torque control command; or, if the first torque and the second torque are not the same, determining the target torque control command from the first torque control command and the second torque control command by selecting the smaller torque; or, if the first torque control command is not received, determining the second torque control command as the target torque control command; or, if the second torque control command is not received, determining the first torque control command as the target torque control command.

[0058] In conjunction with the fifth aspect, in one possible implementation, controlling the vehicle's movement based on the target torque control command includes: sending a third torque control command to a target execution unit based on the target torque in the target torque control command, wherein the target execution unit includes at least one of the following: a motor control unit (MCU), a vehicle electronic stability control system (ESC), a main braking system (IPB), a redundant braking unit (RBU), or a steering unit.

[0059] In conjunction with the fifth aspect, in one possible implementation, the first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle, wherein the first controller and the second controller are combinations of any two of the following execution units of the vehicle: vehicle domain controller (VDC) / vehicle control unit (VCU), motor control unit (MCU), area controller (VIU), intelligent driving computing platform (MDC), or chassis domain controller.

[0060] Sixthly, this application provides a vehicle control device, comprising: a transceiver unit, configured to receive a first torque control command from a first control module, and / or receive a second torque control command from a second control module, wherein the first control module belongs to a first control link, the second control module belongs to a second control link, and the first control module and the second control module support torque control functions of the vehicle, as well as vehicle driving dependency functions; a determining unit, configured to determine a target torque control command from the first torque control command and the second torque control command; and a control unit, configured to control the vehicle driving based on the target torque control command.

[0061] In a seventh aspect, this application provides a communication device including a processor coupled to a memory: the processor is configured to execute a computer program or instructions stored in the memory to cause the device to perform the method as described in the first aspect and any possible implementation thereof, or to perform the method as described in the second aspect and any possible implementation thereof, or to perform the method as described in the fifth aspect and any possible implementation thereof.

[0062] Eighthly, this application provides a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the method as described in the first aspect and any possible implementation thereof, or to perform the method as described in the second aspect and any possible implementation thereof, or to perform the method as described in the fifth aspect and any possible implementation thereof.

[0063] Ninthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method as described in the first aspect and any possible implementation thereof, or to perform the method as described in the second aspect and any possible implementation thereof, or to perform the method as described in the fifth aspect and any possible implementation thereof.

[0064] In a tenth aspect, this application provides a vehicle including a control module for performing the method as described in the first aspect and any possible implementation thereof, or for performing the method as described in the second aspect and any possible implementation thereof. Optionally, the vehicle may further include a control module for performing the method as described in the fifth aspect and any possible implementation thereof.

[0065] The technical effects that can be achieved by any possible implementation of any of the second to tenth aspects mentioned above can be described with reference to the technical effects that can be achieved by any possible implementation of any of the first aspects mentioned above, and the repetitions will not be discussed. Attached Figure Description

[0066] Figure 1 illustrates a schematic diagram of a vehicle control architecture;

[0067] Figure 2 illustrates a schematic diagram of an application scenario of an embodiment of this application;

[0068] Figure 3 shows a schematic diagram of the system architecture applicable to the vehicle control method of this application embodiment;

[0069] Figure 4 shows a schematic diagram of the connection method between the sensor and the controller according to an embodiment of this application;

[0070] Figure 5 shows a schematic flowchart of an example vehicle control method according to an embodiment of this application;

[0071] Figure 6 shows a schematic flowchart of another example of a vehicle control method according to an embodiment of this application;

[0072] Figure 7 shows a schematic diagram of a system architecture of an example embodiment of this application;

[0073] Figure 8 shows a schematic diagram of the system architecture of another example of an embodiment of this application;

[0074] Figure 9 shows a schematic diagram of the system architecture of another example of an embodiment of this application;

[0075] Figure 10 shows a schematic diagram of the system architecture of another example of an embodiment of this application;

[0076] Figure 11 shows a schematic diagram of the system architecture of another example of an embodiment of this application;

[0077] Figure 12 shows a schematic diagram of an anomaly detection mechanism as an example of an embodiment of this application;

[0078] Figure 13 shows a schematic diagram of a system architecture of an example embodiment of this application;

[0079] Figure 14 shows a schematic diagram of a vehicle control principle according to an example of an embodiment of this application;

[0080] Figure 15 shows a schematic diagram of a vehicle control principle according to an example of an embodiment of this application;

[0081] Figure 16 shows a schematic diagram of a vehicle bus connection component according to an embodiment of this application;

[0082] Figure 17 shows a schematic diagram of a vehicle bus connection component according to an embodiment of this application;

[0083] Figure 18 shows a schematic diagram of a vehicle bus connection component according to an embodiment of this application;

[0084] Figure 19 shows a schematic diagram of a vehicle bus connection component according to an embodiment of this application;

[0085] Figure 20 shows a schematic diagram of a vehicle control principle according to an example of an embodiment of this application;

[0086] Figure 21 shows a schematic diagram of the vehicle control principle of another example of an embodiment of this application;

[0087] Figure 22 shows a schematic diagram of a communication device according to an embodiment of this application;

[0088] Figure 23 shows a schematic diagram of a communication device according to an embodiment of this application;

[0089] Figure 24 shows a schematic diagram of the structure of a communication device according to an embodiment of this application. Detailed Implementation

[0090] This application provides a vehicle control method and apparatus to achieve redundant backup of relevant vehicle functions, thereby improving the safety and reliability of vehicle driving. The method and apparatus are based on the same technical concept. Since the principles by which the method and apparatus solve problems are similar, their implementations can be mutually referenced, and repeated details will not be repeated. Furthermore, in the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0091] The vehicle control scheme in this application embodiment can be applied to vehicle-to-everything (V2X), long-term evolution-vehicle (LTE-V), and vehicle-to-vehicle (V2V) communication. For example, it can be applied to vehicles with driving mobility functions, or other devices within a vehicle with driving mobility functions. These other devices include, but are not limited to, on-board terminals, on-board controllers, on-board modules, on-board components, on-board chips, on-board units, on-board radar, or on-board cameras, and other sensors. Vehicles can implement the vehicle control method provided in this application embodiment through these on-board terminals, on-board controllers, on-board modules, on-board components, on-board chips, on-board units, on-board radar, or on-board cameras. The control scheme in this application embodiment can also be used in other intelligent terminals with mobility control functions besides vehicles, or installed in other intelligent terminals with mobility control functions besides vehicles, or installed in components of such intelligent terminals. These intelligent terminals can be intelligent transportation equipment, smart home devices, robots, etc. Examples include, but are not limited to, smart terminals or controllers, chips, radar or cameras, and other sensors and components within smart terminals.

[0092] It should be noted that in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0093] Furthermore, unless otherwise specified, the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects and are not used to limit the priority or importance of multiple objects. For example, "first control link" and "second control link" are only used to distinguish different control links, and do not indicate that the two control links have different priorities or importance.

[0094] Figure 2 illustrates an application scenario of an embodiment of this application. As shown in Figure 2, this application scenario may include a vehicle 100 and a cloud server 200, which can communicate via a network. In one embodiment, the cloud server 200 may also be implemented using a virtual machine.

[0095] Some or all of the functions of vehicle 100 are controlled by computing platform 150 (or computer system). Computing platform 150 may include at least one processor 151, which can execute instructions 153 stored in a non-transitory computer-readable medium such as memory 152. In some embodiments, computing platform 150 may also be multiple computing devices that control individual components or subsystems of vehicle 100 in a distributed manner. Processor 151 may be any conventional processor, such as a central processing unit (CPU). Alternatively, processor 151 may also include graphics processing unit (GPU), field-programmable gate array (FPGA), system-on-chip (SoC), application-specific integrated circuit (ASIC), or combinations thereof.

[0096] Optionally, the vehicle 100 mentioned above can be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawnmower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, etc., and this application embodiment does not impose any special limitations.

[0097] It should be understood that the structure of the vehicle in Figure 2 should not be construed as a limitation on the embodiments of this application.

[0098] The vehicle control method of this application embodiment can be implemented by a control module. This control module can be an independent device, a chip or component in the vehicle 100 shown in Figure 2, or a software module. This software module can be deployed on relevant on-board equipment of the vehicle 100, such as the intelligent driving domain control unit (e.g., mobile data center (MDC)) integrated into the computing platform 150 of the aforementioned vehicle 100, or the vehicle control unit (VCU), or the vehicle domain controller (VDC), or the chassis domain control unit, or the motor control unit (MCU), or the vehicle interface unit (VIU), or deployed on control units of other components of the vehicle. This application embodiment does not limit the product form or deployment method of this control. In the following text, the various control units of the vehicle can also be described as control modules or controllers, and will not be distinguished or described in detail below.

[0099] The vehicle control scheme of this application embodiment is described below with reference to the accompanying drawings and examples.

[0100] Figure 3 shows a schematic diagram of the system architecture to which the vehicle control method of this application is applicable.

[0101] As shown in Figure 3, the system architecture may include at least two control modules, such as a first control module 310 and a second control module 320. Optionally, the system architecture may also include a third control module 330. The generator of the vehicle's driving intention signal 340 can be connected to at least two control modules, enabling these at least two control modules to receive the driving intention signal 340 and, based on the received driving intention signal 340, to achieve redundant backup of relevant vehicle functions, thereby improving the safety and reliability of vehicle driving.

[0102] For example, the at least two control modules can be used to implement redundant backups of a first function of the vehicle, which may include vehicle motion control functions and vehicle motion-dependent functions. Vehicle motion-dependent functions may also be referred to as component control and auxiliary functions.

[0103] Specifically, vehicle motion control function can be the vehicle's torque control function. The vehicle's torque control function refers to the function of controlling and adjusting the torsional torque generated during vehicle operation. By controlling and adjusting the vehicle's torque, the control module can drive the vehicle to move longitudinally, laterally, or vertically.

[0104] The functions that depend on vehicle motion can specifically include the basic functions that control vehicle motion, or the basic functions (or necessary functions) that enable torque output. For example, the basic functions that depend on vehicle motion can include power-on / off management, gear control, and component control and management. Component control and management functions may include, but are not limited to, vehicle thermal management, battery management, and voltage conversion and distribution.

[0105] At least one of the vehicle's accelerator pedal sensor, brake pedal sensor, and advanced driving system (ADS) controller can serve as the generator of the vehicle's driving intention signal 340. At least one of these sensors can be redundantly connected to the at least two control modules, each providing the driving intention signal 340 to one of the at least two control modules. This redundant control architecture enables multi-channel acquisition of the driving intention signal 340. Specifically, for example, the accelerator pedal sensor can provide an accelerator pedal signal as the driving intention signal 340 to the at least two control modules, the brake pedal sensor can provide a brake pedal signal as the driving intention signal 340, and the ADS controller can provide torque request information as the driving intention signal 340 to the at least two control modules.

[0106] Both of the at least two control modules can be connected to an in-vehicle control network (e.g., the vehicle's powertrain control bus system) and support the first function. For example, when any one of the at least two control modules acts as the target control module, it converts the received driving intention signal 340 into control commands for certain actuators / assistance systems 350 of the vehicle to achieve the vehicle's first function. Specifically, for example, the first control module 310 can receive the driving intention signal 340 via link ① and send control commands to the corresponding actuator / assistance system 350 via link ②. Or, for example, the second control module 320 can receive the driving intention signal 340 via link ③ and send control commands to the corresponding actuator / assistance system 350 via link ④. The third control module 330 can receive the driving intention signal 340 via link ⑤ and send control commands to the corresponding actuator / assistance system 350 via link ⑥.

[0107] Specifically, when any one of the at least two control modules acts as the target control module, it can receive one or more driving intention signals 340, analyze and process these signals, identify the driving intention of the driver or ADS, calculate the torque or other parameters required to control the vehicle's movement based on the identified intention, and send control commands to the corresponding actuators / auxiliary systems 350 through the vehicle control network to control the vehicle's movement, thereby achieving the vehicle's torque control function. Simultaneously, while implementing the vehicle's torque control function and controlling the vehicle's movement, the target control module can also communicate with certain actuators / auxiliary systems 350 of the vehicle to ensure the proper functioning of the vehicle's driving-dependent functions, thus ensuring the proper functioning of the torque control function.

[0108] For example, the actuators / auxiliary systems involved in implementing the torque control function of a vehicle may include, but are not limited to, at least one of the following actuators of the vehicle: motor control unit (MCU), electronic stability control (ESC) unit, main braking unit (e.g., intelligent integrated power braking (IPB)), redundant braking unit (RBU), steering unit, etc. The actuators / auxiliary systems involved in implementing vehicle driving-dependent functions may include, for example, at least one of the following actuators of the vehicle: power-on / off management unit, gear position control unit, thermal management drive unit (TDU), battery management system (BMS) control unit, and DC-to-DC converter (DCDC) unit.

[0109] It should be understood that this description only uses the vehicle's torque control function and its dependent functions as an example and does not constitute any limitation. In other embodiments, the first function can also be implemented as other vehicle functions, and the actuators / auxiliary systems involved in the first function can also include other vehicle control units, which will not be elaborated here.

[0110] In this embodiment, the accelerator pedal signal may include accelerator pedal opening information. The driver can respond to their acceleration needs by the force applied to the accelerator pedal. Generally, the accelerator pedal opening is directly proportional to or positively correlated with the torque required for vehicle movement. For example, a larger pedal opening requires more torque, and a smaller pedal opening requires less torque. The brake pedal signal may include brake pedal opening information. The driver can respond to their braking needs by the force applied to the brake pedal. Generally, pressing the pedal indicates a braking demand; a larger pedal opening requires more braking, and a smaller pedal opening requires less braking. The torque request information from the ADS controller may carry control parameters, which can be directly or indirectly related to the torque required for vehicle movement. For example, the torque request information may carry a torque value; a larger torque value indicates a larger torque required for vehicle movement, and a smaller torque value indicates a smaller torque required for vehicle movement.

[0111] To address the safety and reliability issues caused by failures or malfunctions when using the VCU / VDC as the control center in Figure 1, one implementation involves designing the sensor (including the accelerator pedal sensor or brake pedal sensor) or ADS controller that provides the driving intention signal 340 in Figure 3 to employ heterogeneous output or multi-channel digital signal output, simultaneously providing the driving intention signal 340 to at least two control modules. Based on these at least two control modules, a redundant control link (or backup system) is constructed for the vehicle's primary function. Thus, in the event of an anomaly in one control link, one or more redundant control links can be used to achieve the vehicle's primary function.

[0112] Taking the accelerator pedal sensor providing driving intention signal 340 to at least two control modules as an example, the connection methods supported between the accelerator pedal sensor and at least two control modules may include, but are not limited to: hardwired (e.g., analog input AI type or digital input DI type), single-edge nibble transmission (SENT) bus, CAN bus, CANFD bus, CANXL bus, Ethernet, SPI, UART, PCIE, I2C, LVDS, LIN or other buses, etc.

[0113] As shown in Figure 4, in scenario (A), the accelerator pedal sensor can be designed to use AI and (symbol &) DI output methods, and can support four or six outputs, each connected to at least two of the aforementioned control modules in dual-path configuration. In scenario (B), the accelerator pedal sensor can be designed to use SENT and (symbol &) AI / DI output methods, and can support four or six outputs, each connected to at least two of the aforementioned control modules in dual-path configuration. In scenario (C), the accelerator pedal sensor can be designed to use multi-channel digital signal (bus, Ethernet, etc.) output methods, and can support four or six outputs, each connected to at least two of the aforementioned control modules in dual-path configuration.

[0114] Similarly, the connection methods supported between the brake pedal sensor and the aforementioned at least two control modules may include, but are not limited to: hardwired connections (e.g., analog input type AI or digital input type DI), SENT bus, CAN bus, CANFD bus, CANXL bus, Ethernet, SPI, UART, PCIE, I2C, LVDS, LIN, or other buses. The brake pedal sensor and the at least two control modules may also employ heterogeneous output or multi-channel digital signal output to achieve multi-channel signal transmission; details can be found in Figure 4, and will not be elaborated further here.

[0115] Similarly, the connection methods supported between the ADS controller and the above-mentioned at least two control modules may include, but are not limited to: hardwired connections (e.g., analog input AI type or digital input DI type), single-edge nibble transmission (SENT) bus, CAN bus, CANFD bus, CANXL bus, Ethernet, SPI, UART, PCIe, I2C, LVDS, LIN, or other buses. The ADS controller and the above-mentioned at least two control modules may also use heterogeneous output or multi-channel digital signal output to achieve multi-channel signal transmission. For details, please refer to the relevant description in Figure 4, which will not be elaborated further here.

[0116] Therefore, by using the accelerator pedal sensor, brake pedal sensor, or ADS controller with multi-output capability shown in Figure 4, the driving intention signal 340 can be simultaneously output to at least two control modules. This enables the at least two control modules to have multi-channel signal acquisition capabilities for sensor signal perception and sensor input. In this way, the at least two control modules can combine the driving intention signal to achieve redundant backup of the first function. When the main control link in the redundant architecture fails, the driver or ADS controller can take over the first function through the backup control link to effectively control the movement of the vehicle and ensure that other key subsystems can still operate smoothly under the control of the backup control link.

[0117] For example, in Figure 3, the first control link to which the first control module 310 belongs may include the link from the generator of the driving intention signal 340 to link ①, the first control module 310 to link ②, and the actuator / auxiliary system 350. The second control link to which the second control module 320 belongs includes the link from the generator of the driving intention signal 340 to link ③, the second control module 320 to link ④, and the actuator / auxiliary system 350. The third control link to which the third control module 330 belongs includes the link from the generator of the driving intention signal 340 to link ⑤, the third control module 330 to link ⑥, and the actuator / auxiliary system 350.

[0118] In a redundant architecture, when redundant control links are constructed based on the first control module 310 and the second control module 320, the first control link and the second control link are redundant to each other. If the first control link fails, the second control module 320 can take over the vehicle's primary functions and control the vehicle's movement within the second control link. If the second control link fails, the first control module 310 can take over the vehicle's primary functions and control the vehicle's movement within the first control link.

[0119] In a redundant architecture, when redundant control links are constructed based on the first control module 310 and the third control module 330, the first control link and the third control link are redundant to each other. If the first control link fails, the third control module 330 can take over the vehicle's primary functions and control the vehicle's movement within the third control link. If the third control link fails, the first control module 310 can take over the vehicle's primary functions and control the vehicle's movement within the first control link.

[0120] In a redundant architecture, when redundant control links are constructed based on the second control module 320 and the third control module 330, the second and third control links are redundant to each other. If the second control link malfunctions, the third control module 330 can take over the vehicle's primary functions and control the vehicle's movement within the third control link. If the third control link malfunctions, the second control module 320 can take over the vehicle's primary functions and control the vehicle's movement within the second control link.

[0121] In a redundant architecture, when redundant control links are constructed based on the first control module 310, the second control module 320, and the third control module 330, the first control link, the second control link, and the third control link are redundant to each other. Similarly, when any one or two control links malfunction, the vehicle can be controlled to move through the control links that are functioning correctly.

[0122] It should be understood that the solid arrows in Figure 3 indicate that the driving intention signal 340 can be simultaneously output to different control modules, so that different control modules can perform torque calculations, etc., based on the received driving intention signal 340. The dashed arrows indicate optional outputs, that is, different control modules selectively output control commands to the actuator / auxiliary system 350. For example, when constructing a redundant control link based on the first control module 310 and the second control module 320, the first control module 310 and the second control module 320 can choose one of them to output control commands to the actuator / auxiliary system 350. In an optional embodiment, the first control module 310 and the second control module 320 can also output control commands to the actuator / auxiliary system 350 using at least two link output control methods. The actuator / auxiliary system 350 can internally select the target control command from at least two control commands and execute it through arbitration. In an optional implementation, the redundant control architecture may also include independently deployed arbitration nodes, such as chassis domain controllers, which can be connected between different control modules and actuators / auxiliary systems 350. These nodes can be used to arbitrate control commands from different control modules to select the target control command and hand it over to the corresponding actuator / auxiliary system 350 for execution.

[0123] For example, the control command output methods in the embodiments of this application may include the following two:

[0124] Control command output mode 1: At least two control modules in Figure 3 perform torque calculations and output control commands to the corresponding actuator / auxiliary system 350 in an optional manner. This control command output mode 1 can also be called a single-link output control mode or a master-slave output control mode.

[0125] Taking the dual-link redundant control based on the first control module 310 and the second control module 320 as an example, the second control module 320 can serve as the main control module to implement the first function, and the second control link to which the second control module 320 belongs is the main control link. The first control module 310 can serve as the backup control module to implement the first function, and the first control link to which the second control module 320 belongs is the backup control link. Based on the multi-channel signal acquisition function introduced in Figure 4, both the second control module 320 and the first control module 310 can analyze and process one or more received driving intention signals 340, identify the driving intention of the driver or ADS, and calculate the torque required to control the vehicle movement based on the driving intention. Under normal circumstances, the second control module 320 can send the second control message to the corresponding actuator / auxiliary system 350 through link ② to implement the first function. At the same time, the first control module 310 can monitor the working status of the second control link to which the second control module 320 belongs and execute the steps shown in Figure 5:

[0126] S510: The first control module 310 determines that the second control link is abnormal.

[0127] In this embodiment, an anomaly in the second control link may include an anomaly in the second control module. Optionally, based on the implementation of the second control link, an anomaly may also include anomalies in other modules besides the second control module or other communication connections. For example, as shown in Figure 3, an anomaly in the second control link may include an anomaly in link ③, or an anomaly in link ④, or an anomaly in the generator of the driving intention signal 340, or an anomaly in the actuator / assistance system 350. This embodiment does not specifically limit the location of the anomaly in the second control link. The anomaly mode may include, for example, a failure of the second control module, including a power outage or malfunction of the second control module, or a communication anomaly between the second control module and an upstream module (e.g., the generator of the driving intention signal) or a downstream module (e.g., the actuator / assistance system 350). This embodiment does not specifically limit the anomaly mode of the second control link. The method for monitoring anomalies in the second control link will be described below in conjunction with the accompanying drawings and examples, and will not be elaborated here.

[0128] S520: The first control module 310 takes over the first function of the vehicle and controls the vehicle's movement according to the first information in the first control link.

[0129] For example, the first control module 310 can replace the second control module 320 to send a first control message to the actuator / auxiliary system 350 to implement the first function.

[0130] In this embodiment, the first information may include at least one of the following: accelerator pedal opening information, brake pedal opening information, and torque request information from the ADS controller. Optionally, the first information may also include vehicle status information collected through the vehicle control network, and feedback information from various subsystems of the vehicle. Any information that may affect the implementation of vehicle functions can be used as the first information, and this embodiment does not specifically limit this.

[0131] Optionally, the third control module 330 can also serve as a backup control module for implementing the first function. In the event of an anomaly in the second control link, the third control module 330 can replace the second control module 320 in sending a third control message to implement the first function. This application embodiment does not limit the redundancy backup method or number of backups for the first function.

[0132] It should be understood that in Figure 5, the roles of the first control module 310 and the second control module 320 can be interchanged, and the method steps implemented by the second control module 320 and the first control module 310 can be interchanged. For example, the first control module 310 can act as the main control module to implement the first function, and the second control module 320 can act as a backup control module to implement the first function. In S510, the second control module 320 can be replaced by determining that the first control link is abnormal. In S520, the second control module 320 can be replaced by taking over the first function of the vehicle and controlling the vehicle to drive according to the first information in the second control link.

[0133] Control command output mode 2: At least two control modules in Figure 3 perform torque calculation and can use at least two link output control modes to output control commands to the actuator / auxiliary system 350. The actuator / auxiliary system 350 makes arbitration decisions to select the target control command.

[0134] Optionally, the chassis domain controller can be connected to the output of different control modules and the input of the actuator / auxiliary system 350 respectively. The chassis domain controller can make arbitration decisions based on at least two received control commands, select the target control command, and then hand it over to the corresponding actuator / auxiliary system 350 for execution.

[0135] For example, both the first control module 310 and the second control module 320 can serve as control modules for implementing the first function. Both can analyze and process one or more received driving intention signals 340, identify the driving intention of the driver or ADS, calculate the torque required to control the vehicle's movement based on the driving intention, and send control messages for implementing the first function to the chassis domain controller through their respective control links, for example, represented as the first control message and the second control message, respectively. Optionally, the third control module 330 can also serve as a control module for implementing the first function. After calculating the torque required to control the vehicle's movement based on the driving intention, it sends a third control message for implementing the first function to the chassis domain controller through its own control link. The chassis domain controller can make an arbitration decision based on at least two received control messages to select a target control message from the at least two control messages and deliver it to the corresponding actuator / auxiliary system 350 for execution. This application embodiment does not limit the redundancy backup method or number of the first function.

[0136] As shown in Figure 6, taking the dual-link redundancy control based on the first control module 310 and the second control module 320 as an example, the method may include the following steps:

[0137] S610a: The first control module sends a first torque control command to the chassis domain controller in the first control link. The first torque control command may, for example, be carried in a first control message corresponding to the first function.

[0138] S610b: The second control module sends a second torque control command to the chassis domain controller in the second control link. The second torque control command may, for example, be carried in a second control message corresponding to the first function.

[0139] The execution order of S610b and S610a is not important; they can be executed simultaneously or with a time difference.

[0140] Accordingly, the chassis domain controller can receive a first torque control command from the first control module, and / or receive a second torque control command from the second control module.

[0141] S620: The chassis domain controller analyzes the decision to determine the target torque control command from the first torque control command and the second torque control command. For example, the first torque control command is determined to be the target torque control command. Or, for example, the second torque control command is determined to be the target torque control command.

[0142] S630: The chassis domain controller controls vehicle movement based on target torque control commands.

[0143] For example, the chassis domain controller can send a third torque control command to the target actuator based on the target torque in the target torque control command. The target actuator may include at least one of the following: motor control unit (MCU), ESC, IPB, RBU, or steering unit.

[0144] It should be understood that the chassis domain controller in Figure 6 is only used as an example and does not constitute any limitation. In other embodiments, the actuator / auxiliary system itself may also make arbitration decisions and execute them. This application does not specifically limit this.

[0145] Therefore, based on the redundant control architecture of this application embodiment, by constructing two or more control links, whether using the above-mentioned control command output method 1 or control command output method 2, the redundant control link can take over control when a certain control link is abnormal, thereby improving driving safety and reliability.

[0146] For ease of description, the following mainly uses the dual-link functional backup based on the two control modules in Figure 3 as an example to introduce the specific implementation details of the vehicle control method of this application embodiment. The implementation details of the control method based on three or more control links are the same as the implementation details of the dual-link control method, and can be referred to each other, and will not be repeated below.

[0147] Based on the first control module 310 and the second control module 320 in Figure 3, the first function of the vehicle is redundantly backed up. When using a master-slave output control method, for example, the second control module 320 can act as the master control module, and the first control module 310 as the backup control module. When using at least two link output control methods, the first control module 310 and the second control module 320 can respectively output control messages to the chassis domain controller. After arbitration decision-making in the chassis domain controller, the target control message is selected and executed by the corresponding execution unit. In some descriptions, the first control module can be located in the vehicle's first controller, and the second control module can be located in the vehicle's second controller. The control link to which the second controller belongs can also be represented as the second control link, and the control link to which the first controller belongs can also be represented as the first control link; that is, the second controller belongs to the second control link, and the first controller belongs to the first control link. The first control link and the second control link are redundant control links.

[0148] In one example, taking the second control module 320 as being located in the vehicle domain controller (VDC) of the vehicle, the first control module 310 can be deployed on a controller outside the VDC to provide redundant backup for the vehicle's first function.

[0149] For example, the accelerator pedal sensor or brake pedal sensor can be modified into a sensor with multi-output capability as shown in Figure 4. In the redundant control architecture of this application embodiment, the first control module 310 can be deployed in any controller in the vehicle's VIU, MDC, MCU, etc. Sensor signals can be simultaneously connected to the VDC where the first control module 310 is located and the controller where the second control module 320 is located. The VDC where the first control module 310 is located and the controller where the second control module 320 is located can be connected to the vehicle's power control bus system. Through the input sensor signals, the first control module 310 and the second control module 320 can achieve redundant backup of vehicle motion control functions and functions dependent on vehicle motion, including but not limited to torque control functions, vehicle control functions, component control functions, gear management functions, power-on / off management functions, thermal management functions, battery management functions, voltage conversion and distribution functions, etc. The first control module 310 and the second control module 320 can adopt a master-slave output control mode or a two-link output control mode.

[0150] It should be understood that in the embodiments of this application, the vehicle motion control function and the vehicle motion-dependent functions can be deployed and backed up in the same control module. In optional embodiments, the vehicle motion control function and the vehicle motion-dependent functions can also be decoupled and deployed and backed up in different control modules; the embodiments of this application do not specifically limit this.

[0151] In practice, the redundancy backup method for the first function can be flexibly deployed according to the deployment location of various functions of the vehicle and the connection status of various components of the vehicle.

[0152] For example, the power-on / off function can be deployed and backed up in the vehicle's VIU. Depending on the vehicle's VIU computing resources and the connection of the communication bus to sensors (including accelerator pedal sensors and / or brake pedal sensors) and actuators, the deployment and backup of the power-on / off function can be completed in one or more VIUs.

[0153] For example, component control functions can be backed up and deployed in a specific VIU (Variable Interchange Unit) based on the connection between the vehicle's chassis bus and powertrain bus. Alternatively, they can be backed up and deployed in a central controller such as the MDC (Multi-Controller Unit) according to the needs of the vehicle's electronic and electrical architecture. For component management functions (such as the vehicle's DC-DC converter, thermal management system, battery management system, etc.), both inputs and outputs are completed on the bus, and logical calculations and signal processing can be performed according to the actual vehicle status and system requirements.

[0154] For example, the gear position control function can be deployed in a VIU, MDC, or MCU, depending on the access point of the gear position controller. Alternatively, the deployment can be defined according to the access method of the gear position controller; this application embodiment does not specifically limit this.

[0155] It should be understood that the above are examples of backup implementations of the basic functions of longitudinal torque control, and do not constitute any limitation. The backup of the basic functions can fulfill the necessary system dependencies for the backup of the torque control function. Torque can only be output normally when these basic functions are not lost. In other embodiments, the vehicle motion-dependent functions may also include other functions not shown, which will be described in conjunction with examples below, and will not be elaborated here.

[0156] The following section uses a vehicle with a dual-drive (or two-drive) motor drive system as an example to introduce the redundant control architecture based on the first control module 310 and the second control module 320 in Figure 3.

[0157] In vehicles employing a dual-drive motor system, the motor control unit may include a front-drive motor control unit and a rear-drive motor control unit, denoted as F-MCU and R-MCU, respectively. The vehicle's intelligent driving system control unit (e.g., a mobile data center (MDC)) can support dual-control modes, including direct control and cooperative control modes. In direct control mode, the MDC directly controls the motor control unit (or directly controls the MCU), for example, the MDC directly sends control commands to the motor control unit. In cooperative control mode, the MDC assists in controlling the motor control unit through other controllers. For example, VDC cooperative control, where the MDC assists in controlling the motor control unit through the VDC; or VIU cooperative control, where the MDC assists in controlling the motor control unit through the VIU. In cooperative control mode, the MDC can send driving intention signals, such as torque request information, to the VDC / VIU. The VDC / VIU can then calculate the torque required for vehicle movement based on the torque request information and send control commands to the motor control unit.

[0158] As shown in Figure 7, by using redundant access to sensors (including accelerator pedal sensor and / or brake pedal sensor), four selectable torque control links can be implemented to achieve system backup for the vehicle's torque control function and the functions necessary for torque control. Different types of arrows represent the transmission of driving intention signals, the transmission of torque control signals, and the torque control links, respectively. These four selectable torque control links may include:

[0159] Torque control link 1: This includes the torque control link constructed from the sensor → VDC → target actuator.

[0160] The VDC (Vehicle Control Center) supports vehicle torque control and component control and assistance functions. Upon receiving sensor signals from the accelerator pedal or brake pedal sensor, it can identify the driver's intention and calculate the torque required for vehicle movement. Based on the torque calculation result, it sends a torque control signal to the target actuator. The MDC (Autopilot Control Center) enables autonomous driving control and / or intelligent assisted driving control of the vehicle. When the MDC (Autopilot Control Center) uses the VDC cooperative control mode, the VDC can receive a driver intention signal from the MDC, identify the ADS's driving intention, calculate the torque required for vehicle movement, and send a torque control signal to the target actuator based on the torque calculation result. The target actuator may include an R-MCU and / or an F-MCU.

[0161] Torque control link 2: This includes the torque control link constructed from the sensor → VIU0 → target actuator.

[0162] The VIU0 supports vehicle torque control and component control and assistance functions. Upon receiving sensor signals from the accelerator pedal sensor or brake pedal sensor, it can identify the driver's driving intention and calculate the torque required for vehicle movement. Based on the torque calculation result, it sends a torque control signal to the target actuator. The MDC (ADS) enables autonomous driving control and / or intelligent assisted driving control of the vehicle. When the MDC (ADS) uses the VIU cooperative control mode, the VIU0 can, upon receiving a driving intention signal from the MDC, identify the ADS's driving intention, calculate the torque required for vehicle movement, and send a torque control signal to the target actuator based on the torque calculation result. The target actuator may include an R-MCU and / or an F-MCU.

[0163] Torque control link 3: This includes the torque control link constructed from the sensor → MDC → target actuator.

[0164] The MDC (ADS) can monitor sensor signals and implement autonomous driving control and / or intelligent assisted driving control of the vehicle. The MDC (ADS) can send torque control signals to the target actuator in direct control mode or in cooperative control mode via VDC / VIU0. The target actuator may include R-MCU and / or F-MCU.

[0165] Torque control link 4: This includes the torque control link constructed from the sensor to the target actuator.

[0166] The target actuator can include, for example, a chassis domain controller, an R-MCU, or an F-MCU. Taking an R-MCU as the target actuator as an example, the R-MCU can back up the vehicle's torque control function and vehicle motion-dependent functions. After receiving sensor signals from the accelerator pedal sensor or brake pedal sensor, it can identify the driver's driving intention, calculate the torque required for vehicle motion based on the driving intention, and execute the torque through motor control, or send a torque control signal to the F-MCU based on the torque calculation result. Similarly, taking an F-MCU as the target actuator as an example, the F-MCU can back up the vehicle's torque control function and vehicle motion-dependent functions. After receiving sensor signals from the accelerator pedal sensor or brake pedal sensor, it can identify the driver's driving intention, calculate the torque required for vehicle motion based on the driving intention, and execute the corresponding torque through motor control, or send a torque control signal to the R-MCU based on the torque calculation result. An arbitration module can also be deployed in the R-MCU or F-MCU. This arbitration module can arbitrate based on at least two received control messages to select and execute the target control message. Taking the chassis domain controller as an example, an arbitration module can be deployed in the chassis domain controller. This arbitration module can arbitrate based on at least two received control messages to select the target control message and execute it.

[0167] It should be understood that the torque control link shown by the solid arrow in Figure 7 is only a logical control link and does not constitute any limitation on the actual transmission path of driving intention signals and control signals. When implementing backup functions dependent on vehicle motion, the R-MCU and F-MCU can be replaced with other controlled actuators / auxiliary systems. When the vehicle uses other drive modes (including single-drive, three-drive, multi-drive, etc.), the R-MCU and F-MCU can be replaced with other motor control units or other actuators, which will not be elaborated further here.

[0168] In practice, two or more of the four optional torque control links shown in Figure 7 can be selected to redundantly back up the vehicle's torque control function. When one control link malfunctions (e.g., fails), the redundant control link takes over the vehicle's torque control function, thereby ensuring the safety and reliability of vehicle driving.

[0169] Taking a primary / standby output control method as an example, torque control link 1 where VDC is located and torque control link 2 where VIU0 is located can be redundant control links. If torque control link 1 malfunctions, VIU0 can take over the vehicle's torque control function. Alternatively, torque control link 1 where VDC is located and torque control link 3 where MDC is located can be redundant control links. If torque control link 1 malfunctions, MDC can take over the vehicle's torque control function. Or, torque control link 1 where VDC is located and torque control link 4 where MCU is located can be redundant control links. If torque control link 1 malfunctions, MCU can take over the vehicle's torque control function. Or, torque control link 3 where MDC is located and torque control link 4 where MCU is located can be redundant control links. If torque control link 3 malfunctions, MCU can take over the vehicle's torque control function.

[0170] Taking a control method employing at least two links and arbitration by the chassis domain controller as an example, functional backup can be performed based on VDC and VIU0. VDC and VIU0 can simultaneously output control messages to the chassis domain controller, which then arbitrates to select the target control message from at least two control messages. Alternatively, functional backup can be performed based on VDC and MDC. VDC and MDC can simultaneously output control messages to the chassis domain controller, which then arbitrates to select the target control message from at least two control messages. Or, functional backup can be performed based on VDC and MCU. VDC and MCU can simultaneously output control messages to the chassis domain controller, which then arbitrates to select the target control message from at least two control messages. Or, functional backup can be performed based on MDC and MCU. MDC and MCU can simultaneously output control messages to the chassis domain controller, which then arbitrates to select the target control message from at least two control messages. The chassis domain controller can send control commands to the corresponding actuators based on the selected target control message to execute the corresponding torque control function and dependent functions. In an optional implementation, different control modules can also be directly connected to the actuator / auxiliary system to be controlled, and the actuator / auxiliary system can arbitrate to select the target control message from at least two control messages and execute it.

[0171] It should be understood that, in Figure 7, when using a primary / standby output control method, if any of the torque control links 1-3 mentioned above is used to achieve redundancy backup of the vehicle's torque control function, the R-MCU or F-MCU can execute the torque carried in the received control message through motor control. If torque control link 4 is used to achieve redundancy backup of the vehicle's torque control function, the R-MCU or F-MCU can implement the torque control function based on the received driving intention signal, calculate the torque required for vehicle movement, and execute the corresponding torque through motor control, or send a torque control signal to other MCUs based on the torque calculation result. When using at least two link output control methods, the arbitration module in the R-MCU or F-MCU can make a decision based on at least two received control messages to select a target control message from these at least two control messages and execute the target torque carried in the target control message through motor control.

[0172] It should be understood that in the embodiments of this application, when any control module calculates torque output as the target control module, it can collect vehicle status information (including sensor signals) and feedback information from various subsystems based on the on-board bus, and integrate the collected information as the first information to calculate torque output. Simultaneously, any control module can also monitor the torque request output by the ADS. Therefore, effective torque request response calculation can be performed regardless of whether it is in human-driven mode, autonomous driving mode, intelligent assisted driving mode, or human-machine co-driving mode. MCU is a general term for the vehicle's motor control unit. Without a clear distinction, it can represent any motor control unit in a single-drive system, dual-drive system, or multi-drive system; these will not be clarified individually below.

[0173] Based on the four optional torque control links shown in Figure 7, the deployment positions of the first control module 310 and the second control module 320 in Figure 3 can be implemented in the following examples:

[0174] Example 1: Taking functional backup based on VDC and VIU as an example, as shown in Figure 8, the redundant control architecture of this application embodiment may include sensor 810, VDC 820, VIU 830, MCU 840, and MDC (ADS) 850. Sensor 810 may include the vehicle's accelerator pedal sensor or brake pedal sensor. MDC (ADS) 850 supports the vehicle's autonomous driving control and / or assisted driving control, and may adopt a cooperative control mode. VDC 820 may include the second control module 320 in Figure 3, and VIU 830 may include the first control module 310 in Figure 3. Sensor 810 is modified to use AI-type hardwire to make dual-path connections with VDC 820 and VIU 830 respectively, so as to provide driving intention signals from the vehicle driver to VDC 820 and VIU 830. The MDC (ADS) 850 can be modified to provide driving intention signals from the ADS to the VDC 820 using a traditional ADS master control link, and to provide driving intention signals from the ADS to the VIU 830 using a backup torque control link in the redundant control architecture of this application embodiment. The MCU 840 can be, but is not limited to, a motor control unit in a single electric drive system, a dual electric drive system, and a multi-electric drive system.

[0175] The VDC 820 can be used to implement vehicle torque control, power-on / off management, component control, gear control, and vehicle management functions. For example, when implementing torque control, the VDC 820 sends control commands carried by two or more control messages (101 and (&)102) to the MCU 840 via the main control link. Alternatively, when implementing vehicle motion-dependent functions, the VDC 820 sends corresponding control messages to other execution units via the main control link.

[0176] In addition to its own supported body control functions, the VIU 830 can also back up and deploy torque control, power-on / off management, component control, gear control, and vehicle management functions implemented by VDC. For example, when the VIU 830 implements the vehicle's torque control function, it can send control commands carried by two or more control messages (101 and (&)102) to the MCU 840 via the backup control link. Or, for example, when the VIU 830 implements vehicle motion-dependent functions, it sends corresponding control messages to other execution units through the backup control link.

[0177] Optionally, a functional module arbitration and management module can also be deployed in the VIU 830. This module can be used, for example, to monitor the status of the VDC 820 and arbitrate to determine whether it is necessary to take over one or more backup functions from the VDC 820, such as vehicle torque control, power-on / off management, component control, gear control, and vehicle management, to ensure vehicle safety and reliability. For example, if the VDC 820 malfunctions, the VIU 830 can take over the backup vehicle functions. Or, for example, if the control link of the VDC 820 malfunctions, the VIU 830 can take over the backup vehicle functions.

[0178] In implementing the vehicle control method of this application embodiment, VDC 820 and VIU 830 can achieve a dual-link simultaneous output control mode. When using the dual-link simultaneous output control mode, arbitration can be performed at the chassis domain controller to select and execute the target control command. Alternatively, VDC 820 and VIU 830 can also adopt a dual-link calculation, single-output mode, with VIU 830 serving as a backup control module to monitor the output of the main control link to which VDC 820 belongs. When the output of the main control link is abnormal, VIU 830 can take over the first function, such as taking over the operation of the output control message involved in the first function. VIU 830 can use the torque calculation result it has calculated to resend the control message to the vehicle control network so that the corresponding execution unit can receive the control message and perform response processing on the control message.

[0179] Example 2: Taking functional backup based on VDC and MDC as an example, as shown in Figure 9, the redundant control architecture of this application embodiment may include sensor 910, VDC 920, VIU 930, MCU 940, and MDC (ADS) 950. Sensor 910 may include the vehicle's accelerator pedal sensor or brake pedal sensor. MDC (ADS) 950 supports the vehicle's ADS control, including autonomous driving control and / or assisted driving control. MDC (ADS) 950 may adopt direct control mode or cooperative control mode, such as VDC cooperative control. VDC 920 may include the second control module 320 in Figure 3, and MDC (ADS) 950 may include the first control module 310 in Figure 3. Sensor 910 is modified to use AI-type hardwire to make dual-path connections with VDC 920 and MDC (ADS) 950 respectively, so as to provide driving intention signals from the vehicle driver to VDC 920 and MDC (ADS) 950. The MCU 940 can be, but is not limited to, a motor control unit in a single-drive system, a dual-drive system, or a multi-drive system.

[0180] VDC 920 can be used to implement vehicle torque control, power-on / off management, component control, gear control, and vehicle management functions. For example, when VDC 920 implements torque control for vehicle movement, it sends control commands carried by two or more control messages (101 and (&)102) to the MCU via the main control link. Alternatively, when VDC 920 implements functions dependent on vehicle movement, it sends corresponding control messages to other execution units via the main control link. In an optional implementation, MDC(ADS)950 can, for example, adopt a VDC cooperative control mode. For example, MDC(ADS)950 can send a driving intention signal to VDC 920. When there is no abnormality in the main control link, VDC 920 can recognize the driving intention and calculate the torque required for vehicle movement, and then send control commands carried by two or more control messages (101 and (&)102) to the MCU 940 via the main control link.

[0181] In addition to its built-in ADS control functions, the MDC(ADS)950 can also back up the vehicle's torque control function and implement backup functions dependent on vehicle motion. For example, when the MDC(ADS)950 is in direct control mode, to implement the torque control function for vehicle motion, it can directly send control commands carried by two or more control messages (101 and (&)102) to the MCU 940 via the backup control link. Alternatively, for example, when the MDC(ADS)950 implements functions dependent on vehicle motion, it sends corresponding control messages to other execution units through the backup control link.

[0182] In implementing the vehicle control method of this application, VDC 920 and MDC(ADS)950 can achieve a dual-link simultaneous output control mode. When using the dual-link simultaneous output control mode, arbitration can be performed, for example, in the arbitration module of the chassis domain controller to select and execute the target control command. Alternatively, VDC 920 and MDC(ADS)950 can also adopt a dual-link calculation, single-output mode, with MDC(ADS)950 serving as a backup control module to monitor the output of the main control link to which VDC 920 belongs. When the output of the main control link is abnormal, MDC(ADS)950 can take over the first function, such as taking over the operation of the output control message involved in the first function. MDC(ADS)950 can use its own calculated torque calculation result to resend the control message to the vehicle control network so that the corresponding execution unit can receive the control message and perform response processing on the control message.

[0183] In an optional implementation, torque chain backup and control simplification can also be achieved based on MDC and VIU backups to save costs. For example, the torque control function can be backed up and deployed in the MDC, while vehicle motion-dependent functions, such as component control functions, power-on / off management functions, gear management functions, and vehicle management functions, can be backed up and deployed in the VIU. Thus, the VDC can be eliminated from the system, simplifying and streamlining the redundant control system.

[0184] Example 3: Taking functional backup based on VDC / VIU and MCU as an example, as shown in Figure 10, the redundant control architecture of this embodiment may include sensor 1010, VDC / VIU 1020, R-MCU 1030, and F-MCU 1040. Optionally, the architecture may also include MDC (ADS) 1050. Sensor 1010 may include the vehicle's accelerator pedal sensor or brake pedal sensor. MDC (ADS) 1050 supports the vehicle's autonomous driving control and / or assisted driving control. MDC (ADS) 1050 may adopt direct control mode or cooperative control mode, such as VDC cooperative control or VIU cooperative control. VDC / VIU 1020 may include the second control module 320 in Figure 3, and R-MCU 1030 may include the first control module 310 in Figure 3. Sensor 1010 is modified to use AI and DI type hardwires to make dual connections with VDC / VIU 1020 and R-MCU 1030 respectively, to provide driving intention signals from the vehicle driver to VDC / VIU 1020 and R-MCU 1030. Optionally, when MDC(ADS) 1050 is in co-control mode, MDC(ADS) 1050 can provide driving intention signals from the vehicle ADS to VDC / VIU 1020. VDC / VIU 1020 and MDC(ADS) 1050 provide driving intention signals from the vehicle driver. R-MCU 1030 and F-MCU 1040 can be replaced with motor control units in other electric drive systems.

[0185] The VDC / VIU 1020 can be used to implement vehicle torque control functions, as well as component control and auxiliary functions. For example, when implementing vehicle torque control, the VDC / VIU 1020 can send control commands carried by two or more control messages (101 and (&)102) to the R-MCU 1030 and F-MCU 1040 via the main control link. Alternatively, when implementing component control and auxiliary functions, the VDC / VIU 1020 can send control messages to the corresponding execution units via the main control link.

[0186] The R-MCU1030 can be used to back up the vehicle's torque control function. For example, when implementing the vehicle's torque control function, the R-MCU1030 can monitor sensor signals, identify the driver's driving intention based on the sensor signals, calculate the torque required for the vehicle's movement based on the driving intention, and execute the torque through motor control. Alternatively, based on the torque calculation result, it can send control commands carried by two or more control messages (101 and (&)102) to the F-MCU1040 via a backup control link. Or, for example, when implementing component control and auxiliary functions, the R-MCU1030 sends control messages to the corresponding execution units via the backup control link.

[0187] In implementing the vehicle control method of this application, VDC / VIU 1020 and R-MCU1030 can achieve a dual-link simultaneous output control mode. When using the dual-link simultaneous output control mode, arbitration can be performed in the arbitration module of R-MCU1030 (or the chassis domain controller) to select and execute the target control command. Alternatively, VDC / VIU 1020 and R-MCU1030 can also adopt a dual-link calculation, single-output mode, with R-MCU1030 acting as a backup control module to monitor the output of the main control link to which VDC / VIU 1020 belongs. When the output of the main control link is abnormal, R-MCU1030 can take over the first function, such as taking over the operation of the output control message involved in the first function. R-MCU1030 can use its own calculated torque result to resend the control message to the vehicle control network so that the corresponding execution unit can receive the control message and perform response processing.

[0188] When the MCU is used as a backup control module, it can also perform a safety filtering function for torque output. For example, when the MCU detects unexpected torque output control, such as when the accelerator pedal is not depressed or the intelligent driving function is not activated, the MCU can suppress the unexpected torque output to filter out unexpected torque output control caused by software calculation errors, thereby ensuring the safety of vehicle operation.

[0189] Example 4: Taking functional backup based on MDC and MCU as an example, as shown in Figure 11, the redundant control architecture of this application embodiment may include sensor 1110, MDC (ADS) 1120, MCU 1130, and other MCUs 1140. Sensor 1110 may include the vehicle's accelerator pedal sensor or brake pedal sensor. MDC (ADS) 1120 supports the vehicle's autonomous driving control and / or assisted driving control. MDC (ADS) 1120 may adopt a direct control mode. MDC (ADS) 1120 may include the second control module 320 in Figure 3, and MCU 1130 may include the first control module 310 in Figure 3. Sensor 1110 is modified to use AI and DI type hardwires to make dual-path connections with MDC (ADS) 1120 and MCU 1130 respectively, so as to provide driving intention signals from the vehicle driver to MDC (ADS) 1120 and MCU 1130. Other MCU1140s can be replaced with one or more of the following: power-on / off management unit, gear control unit, thermal management unit, battery management system, voltage conversion and distribution unit, etc., depending on the function.

[0190] In addition to its built-in ADS control functions, the MDC(ADS)1120 can also deploy vehicle torque control functions and provide backup for functions dependent on vehicle motion, including but not limited to gear control and component control. When implementing torque control, the MDC(ADS)1120 can use direct control mode, sending control commands carried by two or more control messages (101 and (&)102) directly to the MCU 1130 and other MCUs 1140 via the main control link. When implementing dependent functions, the MDC(ADS)1120 can directly send control messages to the corresponding execution units via the main control link.

[0191] The MCU1130 can back up the vehicle's torque control function and other functions that depend on vehicle movement, including but not limited to gear control and component control. For example, the MCU1130 can monitor sensor signals and identify the driver's driving intention based on the sensor signals. It can then calculate the torque required for the vehicle's movement and execute that torque through motor control. Alternatively, based on the torque calculation result, it can send control commands carried by two or more control messages (101 and (&)102) to other MCUs1140 via a backup control link.

[0192] In implementing the vehicle control method of this application embodiment, the MDC(ADS)1120 and MCU1130 can achieve a dual-link simultaneous output control mode. When using the dual-link simultaneous output control mode, arbitration can be performed in the arbitration module of the MCU1130 (or chassis domain controller) to select and execute the target control command. Alternatively, the MDC(ADS)1120 and MCU1130 can also adopt a dual-link calculation, single-output mode, with the MCU1130 acting as a backup control module to monitor the output of the main control link to which the MDC(ADS)1120 belongs. When the output of the main control link is abnormal, the MCU1130 can take over the first function, such as taking over the operation of the output control message involved in the first function. The MCU1130 can use its own calculated torque result to resend the control message to the vehicle control network so that the corresponding execution unit can receive the control message and perform response processing on the control message.

[0193] When the MCU is used as a backup control module, it can also perform a safety filtering function for torque output. For example, when the MCU detects unexpected torque output control, such as when the accelerator pedal is not depressed or the intelligent driving function is not activated, the MCU can suppress the unexpected torque output to filter out unexpected torque output control caused by software calculation errors, thereby ensuring the safety of vehicle operation.

[0194] In an optional implementation, torque chain backup and control simplification can also be achieved based on MDC and MCU backups to save costs. For example, the torque control function can be backed up and deployed in the MDC, while vehicle motion-dependent functions, such as component control, power-on / off management, gear management, and vehicle management, can be backed up and deployed in the MCU. Thus, VDC can be eliminated from the system, simplifying and streamlining the redundant control system.

[0195] As can be seen from the above examples, the embodiments of this application do not limit the deployment location of the control module or the combination of controllers to implement the redundant control architecture. This design differs from the traditional single control link and can achieve redundant backup control based on two or more control links. In practical applications, any two control links can be flexibly selected for redundant backup control according to application requirements, business requirements, or the vehicle's hardware and software structure. Alternatively, any three or more control links can be selected for redundant backup control to enhance reliability verification.

[0196] The above design can be achieved by modifying the output of the accelerator pedal sensor, brake pedal sensor, or ADS controller of the current vehicle system to build a redundant control architecture. This converts a single control link into two or more redundant control links, so that when a certain control link fails, control can be carried out through the redundant control links to ensure the vehicle's power performance, thereby improving the safety and reliability of vehicle driving.

[0197] Simultaneously, this design supports the establishment of a new control link, enabling backup of the control link for the vehicle's primary functions. This supports highly reliable application scenarios, such as ASIL3+ autonomous driving scenarios. Link 1 represents the traditional control link of the current dual-electric drive vehicle system. As an example, optional redundant control links can be shown below:

[0198] a. Link 1: Accelerator pedal sensor → VDC → R-MCU / F-MCU;

[0199] b. Link 2 (optional): Accelerator pedal sensor → VIU → R-MCU / F-MCU;

[0200] c. Link 3 (optional): Accelerator pedal sensor → MDC (MCU control module) → R-MCU / F-MCU;

[0201] d. Link 4 (optional): Accelerator pedal sensor → R-MCU → F-MCU.

[0202] Meanwhile, in this design, when building a redundant control link based on the MCU, a dual-active control approach can be used to suppress unexpected acceleration / braking requests, enhancing the safety characteristics of the vehicle system. For example, in human-driven mode, when the accelerator pedal is not depressed and the VDC provides an unexpected acceleration request to the MCU (e.g., R-MCU), under a traditional control architecture, the MCU (e.g., R-MCU) would execute it directly. In the scenario of the redundant control link built based on VDC and MCU (e.g., R-MCU) in this application embodiment, the R-MCU can verify the driving intention through sensor signals from the accelerator pedal sensor and then choose to directly reject the unexpected acceleration request from the VDC, suppressing unexpected acceleration and improving the safety of the vehicle control system.

[0203] Furthermore, the vehicle can also feature a sport mode. Through the aforementioned design, the time difference between torque driving intention and response can be shortened in sport mode, thereby achieving rapid torque response and precise control—that is, rapid torque request response characteristics in sport mode. For example, a. When building a redundant control link based on VDC and MCU, directly connecting sensors to the MCU (e.g., R-MCU) enables the MCU to quickly read and respond to driving intentions, saving a cycle of external VDC processing and cross-system interaction, thus improving the sensitivity of torque request response. b. Torque increase and decrease are faster and the cycle is shorter.

[0204] The link anomaly detection method involved in the vehicle control method shown in Figure 5 is described below with reference to the accompanying drawings and embodiments.

[0205] In this embodiment, a method for switching between a primary control link and a backup control link is constructed. For example, by deploying a silencing module, a fault diagnosis module, and a status synchronization module in the primary control link, silencing during fault conditions can be achieved to avoid interference with the normal system. By deploying a status diagnosis module and a mutual exclusion function module in the backup control link, secure takeover can be achieved.

[0206] A redundant control architecture is constructed using the first control module 310 and the second control module 320. When employing a master-slave output control method, taking the second control module as the master control module as an example, the second control link can promptly inform the vehicle control network of its own status through fault diagnosis, status synchronization, etc. The first control module 310 can achieve safe takeover through a status diagnosis module and a mutual exclusion function module. For example, the first control module 310 can monitor whether the second control link to which the second control module 320 belongs is abnormal, including but not limited to: monitoring whether the second control module is abnormal, monitoring whether the communication connection between the second control module and other modules is abnormal, etc. This monitoring can be conducted during power-on, during the execution of the first function by the second control module 320, after anomaly recovery, or after power-off and power-on again. This application embodiment does not specifically limit the anomaly detection method and timing of the second control link. After the first control module 310 takes over the first function, it can notify the vehicle control network. Optionally, after the first control module 310 takes over the first function, it can also notify the vehicle user through an HMI or voice playback.

[0207] In the master-slave output control mode, the first control module and the second control module selectively implement the vehicle's first function, meaning their functions are mutually exclusive. For example, after the vehicle is powered on, the second control module can be assumed to be the master control module to implement the vehicle's first function. The first control module, acting as a backup control module, can obtain the control status information of the second control module upon power-on. If this control status information indicates that the second control module is executing the first function, the first control module enters a silent state. In the silent state, the first control module does not send the first control message corresponding to the first function. It should be understood that the methods implemented by the first and second control modules described above are interchangeable.

[0208] In one optional implementation, if the second control module malfunctions / fails and the first control module takes over the vehicle's first function, the first control module can send a takeover flag to the second control module. This takeover flag is associated with the second control module's silent state. Upon receiving the takeover flag from the first control module, the second control module can enter a silent state. In this silent state, the second control module does not send second control messages corresponding to the first function. If the second control module recovers from the malfunction / failure, it remains in a silent state until the vehicle is powered off to avoid interfering with the backup system. After the vehicle is powered on again, both the first and second control modules can perform self-checks to determine which module will act as the primary control module to implement the vehicle's first function. The other module will then act as the backup control module and enter a silent state to avoid interfering with the main control link's functionality. It should be understood that the methods implemented by the first and second control modules described above are interchangeable.

[0209] Taking the monitoring of whether the second control module is abnormal by the first control module as an example, the timing-based monitoring can include the following scenarios:

[0210] Scenario (1): The first control module can monitor whether the second control module is abnormal when powered on:

[0211] When the vehicle is powered on normally, the second control module will control the vehicle to start up. Normally, the second control module will complete the normal start-up and power-on process within a specified time. At this time, the first control module can simultaneously monitor the power-on status of the second control module; if the second control module fails, it will be unable to power on normally.

[0212] In practical implementation, a power-on timeout diagnostic mechanism can be used, for example. For instance, the second control module typically completes its power-on normally within 200ms or 400ms. The first control module can obtain the power-on status information of the second control module to analyze whether it has powered on normally. If the second control module fails to complete the power-on process normally within the first duration, it is determined that the second control module is abnormal, i.e., the second control link is abnormal. At this time, the first control module can take over the first function. For example, the first control module can take over the power-on process to implement power-on control. It completes the vehicle power-on and takes over the subsequent control functions of the second control module, such as controlling vehicle driving and implementing other auxiliary controls and management related to vehicle movement. The first duration can be a pre-set timeout power-on diagnostic duration for the second control module, which can be set as needed, for example, to 200 milliseconds, 400 milliseconds, or other values; this embodiment does not limit this.

[0213] Scenario (2): The first control module monitors the following when the second control module is powered on normally and performs the first function:

[0214] Once the vehicle is started normally via a key or other activation method, the vehicle power-on process is completed, and the vehicle is ready for use. When the second control module is powered on normally and executes the first function, it can send a second control message corresponding to the first function in the second control link, based on the first information. For example, if the second control module is connected to an in-vehicle control network, it can broadcast the second control message corresponding to the first function over the in-vehicle control network. The corresponding execution unit can also be connected to the in-vehicle control network and, upon detecting the second control message, perform subsequent response processing to control vehicle movement and implement other auxiliary controls and management related to vehicle motion.

[0215] When the second control module executes the first function, the first control module can, for example, acquire the control status information of the second control module. If the control status information indicates that the second control module is executing the first function, the first control module enters a silent state. While in the silent state, the first control module will still perform calculations based on the input signals, but will not send the first control message corresponding to the first function. Simultaneously, the first control module can monitor whether the second control module is malfunctioning. Reasons for malfunctions in the second control module may include, for example, a power outage in the second controller where the second control module resides, a fault in the second control module, or a fault in the second controller.

[0216] Specifically, for example, the second control module can periodically broadcast a second control message corresponding to the first function on the vehicle control network. If the first control module does not receive the second control message within a second duration, it can be determined that the second control module is malfunctioning, i.e., the second control link is malfunctioning. The second duration can be, for example, n times the sending period of the second control message, where n is greater than or equal to 2. The sending period of the second control message is a base period. Typically, the effective output interruption duration or stop duration of the second control module can be set to exceed 3-5 base periods, in which case the second control module is determined to be malfunctioning. In specific implementations, this base period can be set as needed, for example, 10ms, 20ms, or 30ms, etc. The value of n can also be defined as other values, such as 5 or 10, etc.

[0217] Alternatively, for example, if the first control module obtains the fault status information of the second control module and the fault time reaches a third duration, then it determines that the second control module is abnormal, i.e., the second control link is abnormal. The second duration can be, for example, m times the sending period of the second control message, where m is greater than or equal to 2. The fault status information of the second control module can be provided periodically by the hardware status detection module of the second control module, for example.

[0218] At this point, the first control module can take over the first function, sending the corresponding first control message to the relevant execution unit to control vehicle movement and implement other auxiliary controls and management related to vehicle motion. For example, a series of vehicle movement and motion control messages such as gear control messages, vehicle mode control messages, and component management control messages. This ensures that if the second control module fails and stops sending all vehicle motion control-related messages, the first control module can take over, resend the control messages that the second control module stopped sending, and ensure normal vehicle operation.

[0219] Simultaneously, the first control module can record takeover flag information and send it to the second control module to notify the second control module that it has taken over the first function. In other words, this takeover flag information can be associated with the silent state of the second control module. Upon receiving the takeover flag information, the second control module can control itself to enter a silent state. After entering the silent state, the second control module will still perform calculations based on the input signals, but will not send the second control message corresponding to the first function. That is, in the master-slave output control mode, through functional mutual exclusion, it is ensured that only one control message will be output at any given time, thereby improving the overall reliability of the control.

[0220] Optionally, the first control module can also notify the vehicle user to take over the first function via the vehicle's human-machine interface (HMI) or voice broadcast, so that the vehicle user can be informed of changes in the vehicle's status in a timely manner. Alternatively, the first control module can also notify the vehicle's intelligent driving system (ADS) to take over the first function, so that the ADS can adjust the details of its autonomous driving or intelligent assisted driving decisions as needed.

[0221] Scenario (3): After the first control module takes over the first function, it continues to monitor whether the anomaly of the second control module has been resolved.

[0222] During the same power-on phase, once the first control module detects an anomaly in the second control module and takes over to execute the first function, it will retain control and will not re-execute the first function even if the anomaly in the second control module is resolved.

[0223] After detecting an anomaly in the second control module and taking over the execution of the first function, the first control module can also monitor whether the anomaly in the second control module has been resolved. For example, the second control module may recover after a power outage and subsequent power-on, or it may successfully undergo a soft reset after a period of time following a fault.

[0224] After the second control module recovers from an anomaly, it can check for the presence of a takeover flag from the first control module via a silent function. If the takeover flag is present, the second control module enters a silent state and does not send the corresponding second control message for the first function. This takeover flag can be periodically sent from the first control module to the second control module.

[0225] Alternatively, if the first control module detects an abnormal recovery of the second control module, it can send its own control status information to the second control module, indicating that the first control module is performing the first function. Correspondingly, upon receiving the control status information from the first control module, the second control module enters a silent state and does not send the second control message corresponding to the first function. This control status information can also be periodically sent from the first control module to the second control module. In some embodiments, the control status information and the takeover flag information can be the same information, used to indicate whether the first control module is controlling the vehicle.

[0226] When the vehicle is powered off, the first control module can clear the takeover indicator information. This can be done automatically by the first control module, or by user-input control information. For example, in debugging or special modes, maintenance personnel can manually clear the takeover indicator information.

[0227] After the vehicle is powered on again, the first control module can still monitor whether the second control module is abnormal in accordance with the methods of (1)-(3).

[0228] Scenario (4): During the power-on process, check if the second control module is abnormal:

[0229] When the second control module fails and the vehicle is powered down, the vehicle is powered on again after the second control module recovers from the fault state. Alternatively, the second control module may be repaired, such as during a maintenance scenario where a technician repairs or replaces the second control module, after which the vehicle is powered on again.

[0230] During the power-on process, the second control module can perform a self-test to regain control of the first function. The second control module will take over control of the first function once it completes startup within the specified time frame. Since the first control module cleared the takeover flag information when the vehicle was powered off, the first control module is no longer in a takeover state when the second control module starts up and performs a self-test. As long as the second control module passes the self-test normally, it will take over control of the first function. Simultaneously, the first control module enters a state of monitoring the second control link for abnormalities, so that it can take over the first function promptly if an abnormality occurs in the second control link. For example, if the second control module fails again or stops outputting control commands, the first control module will take over the first function. See the above description in conjunction with scenarios (1)-(3).

[0231] For ease of understanding, the following example of a redundant control backup system based on VDC and VIU will be used to introduce the anomaly detection mechanism of this application embodiment.

[0232] As shown in Figure 12, upon power-up, both the VDC and VIU perform a hardware self-test, checking their own hardware readiness. Simultaneously, both the VDC and VIU communicate their hardware status to each other via status broadcast. With the VDC acting as the main control module, if the VDC hardware self-test passes and is in good condition without faults, the system executes the normal startup process. The VDC executes the main control program, performing torque calculation and output, and system management, such as power-on / off control, component control (TDC, CDU, BMS, etc.), and torque control.

[0233] When the VDC fails, the VDC controller becomes ineffective. At this time, the VIU detects the VDC failure. For example, the VDC stops sending control command messages, and the VDC status broadcast is suspended or a fault status is broadcast. When the VDC fault timer expires (e.g., 30ms or 50ms), the VIU enters takeover mode. The VIU will send a takeover flag message. Upon receiving the takeover flag message from the VIU, the VDC executes a silent function. For example, it enters a silent state and stops sending control messages corresponding to the first function, such as all torque control-related control messages and messages for the control and management of various subsystems. The VIU then takes over control by sending torque control-related control messages and sending control commands to various subsystems via these control messages. Examples include power-on / off control, component control (TDC, CDU, BMS, etc.), and torque control.

[0234] When the VDC restarts or recovers from a fault, if the entire backup system does not restart or is still operational, the VDC will directly enter a silent state upon receiving information that the VIU is in takeover mode. This maintains the uniqueness of control over the backup system and ensures that multiple master control does not occur. Specifically, the VDC can determine whether the VIU is in takeover mode by analyzing the presence of takeover flag information through a self-test of the silent function. Alternatively, the VDC can determine whether the VIU is in takeover mode by monitoring control messages broadcast by the VIU on the vehicle control network. For example, when the VIU performs power-on / off control, the power-on / off control messages sent by the VIU indicate that the VIU is in takeover mode, and the VDC will directly enter a silent state. Similarly, when the VIU performs component control, the component control messages sent by the VIU indicate that the VIU is in takeover mode, and the VDC will directly enter a silent state. Or, when the VIU performs torque control, the torque control messages sent by the VIU indicate that the VIU is in takeover mode, and the VDC will directly enter a silent state.

[0235] When the entire vehicle infotainment system is reset and restarted, VDC and VIU are powered on again and perform their respective hardware self-tests. If both VDC and VIU pass their self-tests and are fault-free and can operate normally, VDC takes priority in implementing the vehicle's torque control function and other functions required for vehicle movement. If VDC fails, VIU, as a backup controller, needs to take over control of the commands forwarded and output by VDC on the bus.

[0236] Similarly, when the VIU acts as the main control module, if the VIU hardware self-test passes and is in good condition without faults, the system executes the normal startup process. The VIU executes the main control program, performing torque calculation and output, and system management, such as power-on / off control, component control (TDC, CDU, BMS, etc.), and torque control. Details of the VIU's anomaly detection and functional takeover of the VDC can be found in the above description combined with Figure 12, and will not be repeated here.

[0237] It should be noted that, in this embodiment, the takeover time of the primary and backup links can also be defined. For example, using the sending cycle of the torque output control command as the base cycle, the takeover time of the primary and backup links can be within 3-5 base cycles. For instance, if the cycle of the torque output control command is 20 milliseconds (ms), the first control module can complete the functional takeover within 100ms. The takeover time of the primary and backup links can be the same as the first duration, second duration, or third duration described above.

[0238] Takeover time affects vehicle performance. When using a primary / backup output control method, takeover time should be minimized to ensure smooth function takeover. The takeover time of the primary / backup control link primarily depends on the verification time of the received control command. Typically, the takeover control must occur before the controlled component diagnoses a control timeout. Otherwise, if the controlled component continuously detects that the control module has not issued a control command, it will enter a fault state or an irreversible protection state, resulting in malfunction. For example, if a high-voltage system enters a fault state and the high-voltage power is cut off, the power-on process must be re-executed to restore high-voltage output.

[0239] In practical implementation, the takeover time in this embodiment can be determined based on the communication timeout fault diagnosis time. For applications with strict timeout diagnosis, for example, it can be 3 base periods. If the base period is 10ms, then the fault diagnosis time is 30ms. If the controlled component does not receive the control command within 30ms, the controlled component will report a communication timeout fault and activate the timeout fault response mechanism. Some services that are not sensitive to timeout requirements and control may also define 5 or 10 base periods as the communication timeout diagnosis time. In other embodiments, the takeover time can also be defined as a larger value, such as 15 base periods. In actual control, the output of control messages may also be affected by associated functional modules on the same functional set, and there will be differences. In this embodiment, the switching time of the primary and backup control links can be controlled within 30ms, achieving seamless takeover. When multiple links output in parallel, takeover with 0ms delay is achieved.

[0240] Therefore, by using the above method, other controllers besides VDC are designated as redundant controllers for the vehicle's primary function. In human-driven mode, when VDC fails, the driver can still directly control the vehicle's motor drive system via the accelerator or brake pedal, achieving direct control of the vehicle, based on the redundant control link. In autonomous driving mode or intelligent assisted driving mode, when VDC fails, the ADS controller (e.g., MDC) can still directly control the vehicle's motor drive system through the redundant control link, providing a backup for the vehicle's torque control function. The redundant controllers also ensure the normal operation of the vehicle's auxiliary systems / actuators, thus providing a fundamental guarantee for the vehicle's torque control.

[0241] It should be understood that the above is merely an example of an anomaly / fault monitoring method in a redundant control architecture based on VDC and VIU, and does not constitute any limitation. The method steps implemented by the first control module and the second control module described above are interchangeable. The first control module and the second control module can also be deployed on other controllers, as shown in the previous example. In other embodiments, the same method can also be used to monitor whether other modules on the second control link are abnormal / faulty, or to monitor whether other communication connections are abnormal / faulty, which will not be elaborated here. Furthermore, the vehicle's motor drive system can include, but is not limited to, a single-motor drive system, a dual-motor drive system, and a multi-motor drive system.

[0242] The arbitration method involved in the vehicle control method shown in Figure 6 is described below with reference to the accompanying drawings and embodiments.

[0243] Taking arbitration in the chassis domain controller as an example, as shown in Figure 13, the input terminal of the chassis domain controller can be connected to the output terminals of at least two control modules to receive control messages from different control modules, such as control messages carrying torque control commands, represented as the first control message, the second control message, and the third control message. The output terminal of the chassis domain controller can be connected to at least one execution unit, such as the motor control unit (MCU), the electronic stability control (ESC) unit, the main braking unit (IPB), the redundant braking unit (RBU), the steering unit, etc. The chassis domain controller may include an arbitration module, which can analyze and decide to select the target control message from the received at least one control message and hand it over to the corresponding execution unit for response processing. It should be understood that the vehicle's motor drive system may include, but is not limited to, a single-motor drive system, a dual-motor drive system, and a multi-motor drive system.

[0244] Taking the first control message and the second control message respectively carrying a first torque control command and a second torque control command as an example, the first torque control command may include a first torque, and the second torque control command may include a second torque. When implementing S620, the chassis domain controller arbitrates according to, for example, the following strategy to determine the target control command from the first torque control command and the second torque control command:

[0245] (1) If the first torque and the second torque are the same, either the first torque control command or the second torque control command shall be determined as the target torque control command; or,

[0246] (2) If the first torque and the second torque are not the same, the target torque control command is determined from the first torque control command and the second torque control command by selecting the smaller torque; or,

[0247] (3) If the first torque control command is not received, the second torque control command is determined as the target torque control command; or, if the second torque control command is not received, the first torque control command is determined as the target torque control command; or,

[0248] (4) If the first torque control command and the second torque control command are not received, an alarm will be issued and the default torque control strategy can be used to control the vehicle to ensure that the vehicle can travel to a safe road section.

[0249] Let link A and link B represent the first control link and the second control link, respectively. In the first control link, the first torque included in the first torque control command is represented by the value A. In the second control link, the second torque included in the second torque control command is represented by the value B. The arbitration strategy is shown in Table 1.

[0250] Table 1

[0251] Based on the above arbitration strategy, if the first torque control command is determined to be the target torque control command in S620, then the first torque is the target torque. If the second torque control command is determined to be the target torque control command, then the second torque is the target torque. Accordingly, when implementing S630, the chassis domain controller can send a third torque control command to the target execution unit based on the target torque, thereby controlling the vehicle's movement.

[0252] Simultaneously, during vehicle control, the chassis domain controller can also send corresponding control commands to the vehicle's auxiliary systems / actuators to implement vehicle-dependent functions. For example, the chassis domain controller can send corresponding control commands to one or more of the following actuators: power-on / off management unit, gear position control unit, thermal management control unit, battery management system, and voltage conversion and distribution unit.

[0253] Therefore, through the above-mentioned redundant control (or backup control) method, even if there is an abnormality or failure in either the first control link or the second control link, the driver or ADS controller can still effectively control the vehicle through the corresponding redundant control link. At the same time, after the vehicle's VDC fails, other auxiliary systems / actuators can still operate smoothly under the control of the functional backup control module to ensure the realization of the vehicle's torque control function and the functions that depend on vehicle driving, thereby improving the safety and reliability of vehicle driving.

[0254] It should be understood that the above is merely an illustrative example of the redundancy control method for the first function and does not constitute any limitation. In specific implementations, the control module for implementing the first function of the vehicle can be flexibly deployed and backed up according to the location of the relevant functions, the connection between various components / modules / controllers of the vehicle, or the needs of the vehicle's electrical / electronic architecture (EE), to implement the vehicle control method of this application embodiment. Furthermore, different functions involved in the first function of the vehicle can be deployed and backed up in association on the same controller, or they can be deployed and backed up separately on different controllers, or they can be deployed and backed up at multiple points as needed. This application embodiment does not specifically limit this.

[0255] Furthermore, depending on the computing resources, communication bus, and access status of various sensors / actuators on the vehicle side, functional deployment and backup can be flexibly completed in one or more control modules. This application embodiment does not impose specific limitations on this.

[0256] For example, the backup deployment of the vehicle's power-on / off management function can be implemented in the VIU. Depending on the VIU's computing resources and the access status of communication buses (including chassis bus and power bus), accelerator pedal sensors, actuators, etc., the deployment and backup of the power-on / off management function can be completed in one or more VIUs.

[0257] Alternatively, based on the connection between the chassis bus and the powertrain bus, backup deployment of component control functions can be implemented in the VIU. Or, based on the needs of the vehicle's EE architecture, backup deployment of component control functions can be implemented in a central controller such as the MDC. For component management functions (such as thermal management, battery management, and voltage conversion and distribution functions), their inputs and outputs are all completed on the vehicle's control bus, and logical calculations and signal processing can be performed according to the actual state of the vehicle and system requirements.

[0258] Alternatively, depending on the access point or access method of the gear position controller (or gear position control unit), the backup deployment of the gear position control function can be implemented in the VIU, or it can be implemented in a controller such as MDC or MCU.

[0259] It should be understood that, in the embodiments of this application, the controller used to back up the first function of the vehicle needs to meet the following prerequisites: the controller is connected to both the vehicle's chassis bus and power bus. For example, the controller is connected to the same bus as one or more of the vehicle's next execution units: motor control unit MCU, ESC, IPB, RBU, steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system, and voltage conversion and distribution unit.

[0260] In practical implementation, functional backups for the vehicle's primary functions can be flexibly implemented based on the vehicle's EE architecture or resource availability. For example, the vehicle's torque control function and driving-dependent functions can be backed up together on the same controller, or they can be backed up separately on different controllers. Alternatively, driving-dependent functions can be backed up at multiple points as needed. Alternatively, both the aforementioned dual-link output control system and the primary / standby output control system can be constructed simultaneously in the onboard control network. Depending on the safety level and reliability requirements of different systems, either a dual-link output control method or a primary / standby output control method can be selected for redundant control. This application does not specifically limit this approach.

[0261] Furthermore, to ensure that the driver or ADS controller is promptly informed of the vehicle's internal decision-making and control results, in this vehicle control method, the first control module can also notify the vehicle's users (including the driver) to take over the vehicle's first function via the vehicle's human-machine interface (HMI) or voice broadcast. The HMI can be, for example, a vehicle-mounted display screen, a display screen located in front of the driver's seat, or a mobile terminal such as the driver's smartphone or tablet; this application embodiment does not specifically limit this. Alternatively, the first control module can also notify the vehicle's ADS controller to take over the vehicle's first function, for example, through an in-vehicle control network.

[0262] Furthermore, when the first control module serves as the control module in a redundant control link, it can also perform torque output safety filtering. For example, when the accelerator or brake pedal is not pressed by the driver and the vehicle's intelligent driving function is not activated, if the torque request information from the ADS controller is an unexpected acceleration or deceleration scenario, the first control module can suppress unexpected acceleration or deceleration outputs to filter out unexpected acceleration or deceleration commands caused by software calculation errors, thereby ensuring the safety of acceleration or deceleration requests from the ADS controller. For example, in human-driven mode, if the accelerator pedal is not pressed and the VDC issues an unexpected acceleration request, the motor controller in a traditional architecture would directly select to execute it. However, in the new architecture of this application, the motor controller can verify the driving intention through the accelerator pedal sensor and then directly reject the unexpected acceleration request, improving system safety and suppressing unexpected acceleration.

[0263] Furthermore, the aforementioned control method also features rapid torque response in Sport mode: rapid torque response and precise control in Sport mode shortens the time difference between torque driving intention and response. For example, a) by directly connecting the accelerator pedal sensor to the motor controller, rapid reading and response to driving intentions can be achieved, saving a cycle of external VDC processing and cross-system interaction. This improves the sensitivity of torque request response. Or, for example, b) torque request acceleration and deceleration are faster and the cycle is shorter.

[0264] The vehicle control scheme of this application embodiment is described below using a typical vehicle platform as an example.

[0265] This example primarily provides two typical implementation schemes based on several current typical vehicle platforms: (1) implementing a torque backup scheme based on VDC and VIU; and (2) implementing a backup scheme based on VDC and motor controller (e.g., R-MCU). These two implementations divide the torque output link into two major module domains based on functional associations and dependencies: one is the prerequisite dependencies for torque output, such as power-on / off management, subsystem control, gear management, and vehicle mode; the other is the torque output to actuators such as motors.

[0266] When VDC fails, the backup system needs to take over the torque control function and the control of related dependent functions to ensure that the entire system has the prerequisites for torque output. This enables the final torque calculation function to have the conditions for calculation and output in the backup system, completes the torque output calculation, and sends the calculation result to the actuator.

[0267] In the method of this application embodiment, redundant access to multiple systems is constructed through the accelerator pedal sensor. Based on any three core controllers of the torque chain among MDC, VDC, VIU, motor controller, and chassis domain controller, three torque control links are constructed. In the event of a single point of failure at any node, the remaining links can still complete effective torque output, thereby achieving redundant backup of the torque control function. The backup scenario for the sensors can be flexibly configured by selecting any two or more of the multiple controllers (MDC, VDC, VIU, motor controller, chassis domain controller) according to actual application needs, thus achieving effective backup of the torque control function and realizing the beneficial effects of this application. The access of the accelerator pedal sensor and brake pedal sensor to the motor controller can be flexibly connected to the rear or front electric drive according to actual deployment and implementation requirements. Digital sensors can also be used to achieve heterogeneous output of CAN bus and other signals; this application embodiment does not specifically limit this approach.

[0268] Based on the current multi-output design of sensors, the deployment of torque control links and new technologies have achieved redundant backup of torque reliability, which can be flexibly deployed to support the reliability requirements of torque control links for ASIL3 and higher levels of autonomous driving.

[0269] For example, taking Figure 7 as an example, the fault scenarios involved in different control links and the corresponding control outputs can be shown in Table 2 below:

[0270] Table 2

[0271] In this text, × indicates an anomaly, and √ indicates no anomaly.

[0272] Taking the construction of torque control output links in VDC and VIU and the adoption of dual electric drives in the vehicle as an example, as shown in Figure 14, when the torque control function of the vehicle is implemented redundantly based on VDC and VIU, the torque control function can include core modules such as torque calculation, torque arbitration, torque distribution, and torque filtering, with synchronous backup component control to achieve control over functions dependent on vehicle motion. The electric drive system can include a front drive control unit (F-MCU) and a rear drive motor control unit (R-MCU). Arbitration modules can be deployed in the F-MCU and R-MCU respectively to arbitrate the torque control commands input from both paths, enabling reliable control of torque output. The integrity of any torque control link ensures effective control of the vehicle's power.

[0273] Example 1:

[0274] Taking a vehicle control network based on a CAN bus as an example, the VDC (Vehicle Control Center) calculates and outputs CAN bus messages in the chassis bus, sending the corresponding control commands and status feedback information to various components of the bus. For example, the VDC can forward electric drive status information of the powertrain bus, torque information of the front and rear electric drives, door lock status information, and information such as ambient temperature.

[0275] VDC's cross-bus information forwarding is primarily used by various subsystems for access to power status information. Subsystem coordination requires power information as a valid output, and these inputs are crucial for each subsystem to calculate its own system functions. For example, the braking system has a strong dependence on power input; in longitudinal acceleration / deceleration control and vehicle speed control, the braking system needs to know the motor torque output information.

[0276] As shown in Figure 15, with the accelerator pedal sensor dual-channel access to both the VDC and VIU, the VDC and VIU can simultaneously parse and calculate the torque response request. The torque request can be a physical signal from the accelerator pedal sensor, such as throttle opening (AccPedal) information. Optionally, the torque request can also be a command signal from the ADS controller. Under normal circumstances, the VDC outputs control messages via a bus (e.g., CANFD bus), which include control commands, such as control command 101 and control command 102. The VIU synchronously calculates the torque response request. Upon detecting a control message sent by the VDC, the VIU disables the transmission of backup control messages via a message transmission switch (logic switch), indicated by a dashed arrow. In other words, the VIU enters a silent state and does not send corresponding control messages. At this time, only the VDC sends control messages for torque control and related auxiliary functions, indicated by a solid arrow. When the VDC fails or malfunctions, the VIU diagnoses the VDC's inability to send control messages. The VIU then quickly activates the backup message transmission switch, allowing it to continue operating in place of the VDC. It sends the results of synchronous calculations to the bus via the backup control link. For example, the VIU outputs control messages via the bus (e.g., CANFD bus), including control commands such as control command 101 and control command 102. The MCU or other execution units receive the control commands and execute the response. This achieves rapid switching between the primary and backup links.

[0277] To prevent ping-pong switching issues, a startup silencing module is deployed in the VDC. When a serious fault occurs in the VDC, the VIU takes over. After taking over, the VIU stores the takeover flag information in the system and sends it out via the bus. Upon VDC startup (including startup after fault recovery), the startup silencing module first runs to check the bus and system status. If it finds that the VIU is controlling the torque chain output (i.e., the VIU is implementing the vehicle's torque control function and other vehicle-dependent functions), the VDC remains silent and does not send corresponding control messages until the power-on ends and the vehicle is powered off normally, at which point the VIU clears the takeover flag information. Upon a normal startup on the second power-on, the VDC performs a self-test. If the self-test passes and startup is normal, the VDC takes control of the vehicle. If the VDC fails to start normally within the specified time, the VIU initiates the vehicle takeover function and notifies the driver or intelligent driving system via the instrument cluster: the VDC has failed, and the VIU is now in control.

[0278] When the VDC fails, the VIU, acting as a backup controller, needs to take over control of the commands within messages on the bus that require VDC forwarding and output. For example, the torque control function can be backed up in the VIU. Optionally, the following functions can be backed up in the VIU:

[0279] (1) Backup of basic power-on and power-off functions: The VIU backs up the power-on and power-off management functions of the VDC according to the gateway topology. When the VDC fails, the VIU will manage and control the power-on and power-off functions and take over the normal power-on and power-off functions to ensure that the VIU can control the normal power-on and power-off of the whole vehicle in the case of VDC failure.

[0280] (2) Component Control Function Backup: The VIU needs to be mounted on the power bus system according to the network topology. When the VDC fails, it will stop sending component control messages. For example, component control commands, such as the control commands and messages and heartbeat signals of the DC-DC, the control command messages and heartbeat signals of the TDU thermal management system, and the control messages and heartbeat signals of the BMS. When the VDC fails, if the subsystem or component does not receive the control commands from the VDC within the diagnostic time limit, it will stop working and put the subsystem or component into a fault state. VIU takeover can be completed after the VDC stops sending control messages, but before other subsystems and subcomponents trigger timeout diagnostic faults, to take over the control output message commands and realize the takeover of component control functions.

[0281] (3) Gear Position Control Takeover: The VIU takes over gear position control based on the input from the gear position controller. When the VDC fails, the VIU takes over gear position control and gear position input requests, and outputs gear position control and gear position switching management based on the system status and gear position calculation results. When the VDC fails, the VIU takes over gear position control management to realize the control of the entire vehicle.

[0282] (4) Torque output control and torque management: VIU backup torque calculation module. When VDC fails and stops sending electric drive torque control messages (e.g., front electric drive control message 101, rear electric drive control message 102), VIU takes over control and starts sending torque control messages 101 and 102 to take over control.

[0283] It should be understood that for control commands of dependent and auxiliary functions, the VIU can use a primary / backup approach to back up control messages. That is, when the VDC fails, the VIU will take over sending control messages for components (DCDC, TDU, BMS), such as the messages described below (0x11A, 0x114, 0x115, 0x3B2, 0x02B0, 0x385, etc.). Different implementations or different vehicle models may use different CAN messages and CAN IDs to send this information, but the commands and information for each subsystem are similar and can be referred to accordingly; they will not be elaborated further in this document. Simultaneously, the VIU will also directly take over dependent functions, including power-on / off control and gear control messages. Other message forwarding and event-type and status-type messages, such as state machine and status maintenance information, will be directly backed up through the VIU.

[0284] As shown in Figure 16, when the VDC is working normally, it can send control messages carrying the following control commands through the chassis bus to control various sub-components and subsystems of the vehicle:

[0285] 0x11A\0x114\0x115\0x3B2\0x02B0\0x385.

[0286] 0x11A can be used to indicate the electric drive status information of the power bus. VDC can forward the electric drive status information of the power bus. MDC, ABM, VIU, IPB, RBU, and steering units (such as electric power steering (EPS)) connected to the power bus can receive electric drive status information through the bus.

[0287] 0x115 and 0x114 are used to indicate the torque information of the front and rear electric drives, respectively. VDC can forward the torque information of the front and rear electric drives through the bus. MDC, ABM, IPB, RBU, and steering unit can receive the torque information of the front and rear electric drives through the bus and execute responses.

[0288] 0x3B2 is used to indicate vehicle body status information. The VDC can forward vehicle body status information via the bus, and the MDC, ABM, IPB, RBU, and steering unit can receive vehicle body status information via the bus.

[0289] 0x02B0 is used to indicate the vehicle's door lock status information. VDC can forward door lock status information via the bus, and MDC, IPB, and RBU can receive torque information from the front and rear electric drives via the bus.

[0290] 0x385 is used to indicate ambient temperature information. VDC can forward ambient temperature information via the bus, and IPB and RBU can receive ambient temperature information via the bus.

[0291] The VIU system can back up the vehicle's torque control function and vehicle driving-dependent functions.

[0292] For example, the VIU can back up power-on / off management functions. The VIU can back up power-on / off management functions based on the gateway topology. When the VDC fails, the VIU will manage and control the power-on / off functions, taking over normal power-on / off functions. This ensures that the VIU can control the normal power-on / off of the entire vehicle in the event of a VDC failure. Alternatively, the VIU can back up the vehicle's component control functions. The VIU1 needs to be mounted on the power bus system according to the network topology connection. When the VDC fails, it will stop sending component control messages. This includes component control commands, such as DC-DC control commands and messages and heartbeat signals, thermal management system control commands and messages and heartbeat signals, and battery management system control messages and heartbeat signals. If, after a VDC failure, the subsystem or component does not receive VDC control commands within the diagnostic time limit, it will stop working and enter a fault state. After the VDC stops sending control messages, the VIU can take over the component control functions, thus outputting corresponding control messages before other subsystems and subcomponents trigger timeout diagnostic faults, thereby taking over the component control functions. Alternatively, for example, the VIU can back up the gear position control function. The VIU takes over gear position control based on the input from the gear position controller. When the VDC fails, the VIU can take over gear position control and gear position input requests, outputting gear position control and gear position switching management based on the system status and gear position calculation results. When the VDC fails, the VIU takes over the gear position control management function, achieving overall vehicle control. Alternatively, for example, the VIU can back up torque control. The VIU can back up the torque calculation module. When the VDC fails and stops sending electric drive torque control messages, the VIU takes over control and begins sending torque control messages 101 and 102. Torque control message 101 is the front electric drive control message, and torque control message 102 is the rear electric drive control message.

[0293] After the VDC stops sending one or more control messages as shown in Figure 16, the VIU, based on its diagnostic and detection mechanisms, determines that the VDC is unable to send control messages normally and that the control over the relevant subsystems has timed out. The VIU will then resend status information based on the packet information of the control messages.

[0294] For example, when the VDC stops sending 0x11A messages, the backup system will group them into a functional group based on the messages associated with 0x11A, the associated control modules, control programs, and other related messages that need to be received and sent. When this control message 0x11A is stopped in the VDC, the VIU will take over the control of that function.

[0295] In this embodiment, the takeover function can be implemented in different scenarios. For example, in scenarios where some functions of the VDC fail or a single core fails, some management messages may not be sent, and the VIU can take over the missing messages. When the VDC is completely powered down and cannot send all messages, the VIU can also take over all messages according to the instruction requirements.

[0296] In one implementation, the VIU can be deployed with the same computational logic program as the VDC, and can maintain consistency in takeover using the same control program. The VIU can execute the same control program (logic) based on the same signals received on the bus, calculate the result, and output it as a control signal. When the VDC stops sending the corresponding message, the VIU will resend the corresponding message, and the control instructions or control signals within the message will be filled in according to the computational logic and results.

[0297] For example, as shown in Figure 17, for control commands of dependent and auxiliary functions, the VIU can use a primary / backup approach to back up control messages. That is, when the VDC fails, the VIU will take over sending control messages from components (DCDC, TDU, BMS), such as 0x11A, 0x114, 0x115, 0x3B2, 0x02B0, 0x385, etc. Different embodiments or different vehicle models may use different CAN messages and CANIDs to send this information, but the commands and information for each subsystem are similar and will not be elaborated further here. Simultaneously, the VIU will also directly take over power-on / off management, gear control messages, other message forwarding, and event-type and status-type messages, such as state machine and status maintenance information, which will be directly backed up through the VIU.

[0298] In another implementation, different computational methods or logics can be deployed within the VIU to control the same signal interface. This heterogeneous backup method backs up the control over components and the system. When the VDC stops sending the corresponding message, the VIU will resend the corresponding message, and the control commands or signals within the message will be filled in according to the computational logic and results.

[0299] Furthermore, the VDC can also control the powertrain system, transmitting control information for powertrain components and subsystems via CAN messages (or other types of messages) to the powertrain bus. For example, VDC sends control messages for high-voltage components (0x181), system functional status (0x184), and overall vehicle status (0x311). When the VDC stops sending relevant messages, the VIU takes over the control of the corresponding subsystem and resends the same control message. The logic and program control of the control commands or signals within the message are calculated and controlled by the VIU, and the results are used as outputs to fill the corresponding message. The VDC sends control messages and signals to the current subsystem and subcomponents, controlling and managing the system, subsystems, and components through these messages and their internal signals. Interactions between components and component status management are achieved through bus signal interaction.

[0300] For example, as shown in Figure 18, the VDC controls and manages the system, subsystems, and components through control messages and signals to the current subsystems and sub-components. The interaction between components and the status management of components are achieved through bus signal exchange.

[0301] When the VDC stops sending the corresponding message, the VIU performs replacement control for the corresponding message. Function association groups are established with control messages as the core. For example, when the component control message 0x181 stops sending, the VIU takes over the corresponding control interface. Simultaneously, associated messages and dependency groups are established using the 0x181 message interface. When the VDC stops sending the 0x181 message, the VIU takes over the transmission of the 0x181 message and also backs up the associated dependency messages according to computing and business needs. When the VDC fails and cannot take over the component management tasks in the 0x181 interface, the VIU backs up the interface of the component management control message, and also completes the backup of associated and dependent functions according to the function group and associated message method.

[0302] As shown in Figure 19, after VDC fails, VIU backup activates backup functions such as component control, gear control, and vehicle status. For example, when VDC loses power or hardware failure and completely loses its function, VIU completes the backup and activation of related functions through identified control interfaces, such as 0x181, 0x184, and 0x311.

[0303] It should be understood that the electric drive control interface connected to VDC, for example, using 0x101 to control the front electric drive system as the torque control interface for the front electric drive, and using 0x102 as the control interface for the rear electric drive to achieve torque control of the rear electric drive, does not constitute any limitation on the electric drive control interface. The VIU performs torque integration functions, such as torque calculation, torque arbitration, torque distribution, and torque filtering—four core functions—and outputs the final results as control messages through the interface. The calculations in the VIU are synchronized with VDC; only the output of bus signals is controlled. When the VDC stops sending torque control messages and the timeout occurs, the VIU activates and outputs the backup messages 0x101 and 0x102.

[0304] In a typical primary / standby system, the logic implementation of the torque control link backup system constructed by VDC and VIU can be shown in Figure 12 above. During the hardware startup self-test in VDC, the system checks its own hardware integrity. If the VDC hardware self-test passes and is in good condition without faults, the system proceeds with the normal startup process. VDC executes the main control program, performing torque calculation and output, and managing the system.

[0305] When the VDC fails, the VDC controller becomes ineffective. At this time, the VIU detects the VDC's stop-control command message and its status broadcast is either suspended or a fault status is broadcast. When the fault timer expires (e.g., 30ms or 50ms), the VIU initiates takeover control. The VIU sends a takeover flag. Upon receiving the VIU1 takeover status, the VDC executes a silent function, stopping all torque output-related control messages. The VIU then begins sending control commands via control messages to each subsystem to take over control.

[0306] When the VDC restarts or recovers from a fault, if the entire system does not restart or is still in operation, the VDC will receive a notification from the VIU that it is in takeover mode. The VDC will then directly enter a silent state to maintain the sole control of the system and ensure that there is no multi-master control.

[0307] When the entire system is reset and restarted, VDC and VIU1 are powered on again and perform their own self-tests. If both VDC and VIU1 pass the self-test and are fault-free and can operate normally, VDC will take priority in running torque control output.

[0308] In another implementation, dual-link output control can be achieved using VDC and VIU. In this case, new torque output interfaces, such as interfaces 0x201 and 202, can be used. VIU and VDC can output control messages simultaneously; for example, VDC controls the front and rear electric drives via interface messages 0x101 and 0x102, while VIU controls the front and rear electric drives via messages 0x201 and 0x202. The actuator (e.g., the motor controller) arbitrates the outputs of the same two torque control commands before outputting the torque. Further details are omitted here.

[0309] The above example provides a typical backup control scheme. Since the vehicle domain controller and VDC are typically located at nodes on the chassis bus and powertrain bus, the backup of torque control functions and related dependent functions requires only software deployment and support, resulting in a very low-cost backup solution. Furthermore, in terms of hardware resources, the VIU has abundant port resources and types, requiring no special hardware design to connect and read the accelerator pedal sensor / brake pedal sensor, minimizing the impact on hardware modifications and requirements. This solution only requires reselecting the accelerator pedal sensor / brake pedal sensor, and the wiring harness modification is limited to adding sensor wiring from the accelerator pedal sensor or brake pedal sensor to the VIU. This solution involves minimal modifications to hardware and wiring harnesses, enabling minimal changes and high compatibility for both existing and new projects.

[0310] Therefore, through the above examples, flexible backup between VIU and VDC can be achieved, completing the backup of torque control functions and other functions dependent on vehicle operation. Even if the main control VDC fails, VIU can still take over vehicle control, ensuring normal vehicle operation. For example, when the vehicle is traveling on a highway and VDC fails, it can still maintain speed in the busy fast lane. Or, for example, it can smoothly change lanes to the slow lane in autonomous driving scenarios.

[0311] On the one hand, traditional cars lack this backup function. When the VDC (Vehicle Control Controller) fails, the autonomous driving controller loses control of the vehicle's acceleration and automatically disengages. The vehicle can only coast or, in scenarios with braking, rapidly decelerate until it comes to a stop within its lane. Stopping in the fast lane is inherently dangerous. During the continuous deceleration process, if there are many vehicles in the driving lane, the vehicle may be unable to change lanes from the fast lane to the driving or slow lane, thus posing safety hazards and limiting its usability. This application effectively solves this problem by backing up the vehicle's basic driving functions and torque control functions. It allows the system to quickly take over vehicle control after the main controller (VDC) fails. Whether driven by a human or in autonomous mode, the vehicle can still maintain acceleration and torque output control after the main controller fails, thereby ensuring driving safety.

[0312] On the other hand, current electric drive systems, whether single-drive or multi-drive, typically have only one controller for torque output control. The technical improvement in this application primarily achieves software backup for basic control and torque control functions through redundant sensor access and dual access of the main control to the power bus and chassis bus. This allows for the flexible construction of two or more torque control links on a single vehicle, enabling flexible takeover and control of related functions. This ensures that even if a single link or node fails, the vehicle still possesses complete driving functionality, significantly improving driving safety and controllability under fault conditions. An extended application of this embodiment can achieve dual-output, with the final actuator arbitrarily deciding which output to execute. For example, the VDC sends control command messages 0x101 and 0x102 to control the front and rear electric drives respectively, while the VIU sends 0x201 and 0x202 to control the front and rear electric drives respectively. The VDC and VIU simultaneously calculate the torque request, and the calculation results are sent in control messages through various controllers. When the current electric drive receives 0x101 and 0x201 within the same cycle, it selects to execute either the 0x101 or 0x201 instruction based on the arbitration truth table. This achieves faster and more efficient backup, eliminating torque control deficiencies caused by timeout diagnostics. The subsequent electric drive can also execute the same logic.

[0313] Example 2:

[0314] In this embodiment, torque control functionality can also be backed up through heterogeneous backup. Heterogeneous backup is achieved by redundantly connecting the accelerator pedal sensor to any one of the VDC / VCU / MDC / VIU, and redundantly connecting the accelerator pedal sensor to the motor controller. For the backup of basic functions, distributed takeover can be implemented using domain control such as the VIU, thereby achieving comprehensive resource utilization. Backup of complex functions is also completed to reduce the cascading failure reaction caused by the failure of a single component.

[0315] For example, if VDC fails in the current system, it will not only cause the loss of torque control function, but also the loss of the vehicle's gear shifting function, making gear shifting impossible. The vehicle's component management function will be lost, leading to the loss of many functions such as heat exchange, battery management, and voltage conversion, thus rendering the entire system unusable.

[0316] In practical implementation, the backup of the vehicle's torque control function can be completed through the following steps, realizing the technical implementation methods of different torque control links:

[0317] S1: Sensor Redundancy Access. Select accelerator pedal and brake pedal sensors that support dual or multiple redundant access. The accelerator pedal / brake pedal sensors can be connected to two or more controllers, such as directly connecting to the VDC and the motor controller. It should be understood that different access methods exist for the main controller; the VDC can be replaced by controllers such as MDC or VIU, as detailed in the relevant introduction above, and will not be repeated here.

[0318] S2: Backup of dependent functions.

[0319] For example, the backup of power-on / off management functions: when the VDC fails, the vehicle will lose its power-on / off management functions, resulting in the vehicle being unable to perform normal power-on / off processing, including low-voltage power-on / off and high-voltage power-on / off management of the battery. In this embodiment, by leveraging the access characteristics of the VIU and central controls such as VDC and MDC located on the chassis bus and power bus, the power-on / off management functions can be backed up to the VIU. When the main controller fails, the VIU can take over the entire power-on / off management function, thereby enabling the vehicle to still start normally when the VDC fails, and to go into hibernation mode after stopping, thus achieving effective control of the vehicle.

[0320] S3: Backup of component management function.

[0321] For example, when the VDC fails, control messages to components (subsystems) will cease to be sent. These subsystems include DC-DC, TDU, BMS, etc. When a component (subsystem) loses communication with the main controller (VDC), it will trigger a communication failure and enter protection mode, ceasing operation. The cessation of operation of a component (subsystem) will cause the vehicle to lose its main functions. In this embodiment, the component management function can be backed up through the VIU. Here, the component management function and torque control function can be deployed separately, or in other words, in a distributed deployment. The deployment scheme can be to deploy the component's control function module (application, based on the vehicle status and logic control) in the VIU. The VIU receives bus signals, performs calculations and logic processing, and then sends them to each component through the bus to complete the control. The component management function backup based on the chassis bus is shown in Figure 15. The component management function backup based on the powertrain bus is shown in Figure 17.

[0322] Distributed functional backup can balance the tasks and loads of different controllers, thereby achieving optimal overall solution. Of course, if the backup controller (such as the motor controller) has sufficient resources, functional modules can also be deployed and backed up directly within the motor controller.

[0323] S4: Gear control function backup.

[0324] For example, the gear shift control function can also be backed up to the VIU. Specifically, the gear shift controller sends a gear shift signal to the VIU via the vehicle control network (e.g., CAN bus) based on the user's gear shift request. The VIU, based on the current gear shift control module and vehicle status, calculates whether to respond to the gear shift request and ultimately executes the gear shift control to achieve the vehicle's gear shift. The gear shift control result is also sent to the corresponding bus. When the main controller VDC or the gear shift control function fails, and gear shift control messages are stopped, the VIU will take over the gear shift control function as a backup.

[0325] S5: Gateway function backup.

[0326] For example, information forwarding between the powertrain bus and chassis bus. Due to limitations in the number of components and communication bandwidth, it's impossible to mount all devices on a single CAN bus. Typically, chassis components are mounted on the chassis bus, and powertrain-related components are mounted on the powertrain bus. Both chassis and powertrain components need to know the status and output of each system for coordinated control. For instance, the braking system in the chassis system needs to know the power output, while the powertrain system needs to know the braking system's status to control torque output, such as negative torque and kinetic energy recovery. Therefore, a crucial function of the main controller is to forward signals between the powertrain bus and chassis bus. When the main controller fails, the signal exchange between the chassis bus and powertrain bus is interrupted, leading to system malfunction or limited functionality. In this embodiment, the VIU can simultaneously possess both chassis bus and powertrain bus interfaces, allowing it to take over the gateway function and achieve cross-bus signal forwarding after the VDC fails. For example, when the VIU detects that the VDC has stopped transmitting the corresponding CAN message, the VIU will directly calculate and forward the corresponding message based on the backup arbitration logic.

[0327] S6: Torque control function backup.

[0328] In this embodiment, the backup of the torque control function mainly implements a heterogeneous torque backup function. In the main link, the accelerator pedal sensor is connected to the VDC. After the VDC calculates the torque, it sends the torque control information to the motor controller via the CAN bus. In the backup link, the accelerator pedal sensor is directly connected to the motor controller, and the motor controller synchronously calculates the torque output based on the pedal opening information. This includes the following scenarios:

[0329] a) When the main controller outputs a valid torque command, the motor controller can respond according to the received torque command. When the main controller's VDC fails, the motor controller can directly respond to the torque output request from the accelerator pedal, perform torque calculation, and directly control the output of the electric drive within the electric drive system.

[0330] b) Unexpected acceleration of inhibition.

[0331] After calculating the torque, the VDC master controller outputs a torque control command to the motor controller. The motor controller synchronously calculates the torque output based on the output of the accelerator pedal sensor. If the torque calculated by the master controller deviates significantly, for example, if it is much greater than the torque output calculated by the motor controller, the motor controller can directly reject the torque output request from the VDC. Compared to traditional motor controllers that only have execution functions, the input verification of redundantly connected accelerator sensors can prevent unexpected acceleration or deceleration scenarios, thereby improving system safety. For example, in a human-driven scenario, if the accelerator pedal is not pressed, but the VDC sends a large torque request, the motor controller can determine whether the output is due to an incorrect calculation by the VDC based on sensor information.

[0332] c) Heterogeneous backup: In the main control link, the accelerator pedal sensor → VDC torque calculation → motor controller is controlled via bus. Compared to the backup control link, which directly connects the accelerator pedal sensor to the motor controller, the control path, information transmission path, and signal processing path are shorter. This allows for heterogeneous backup of the two control links, one controlled by calculation and communication, and the other by direct connection of hard-wired sensors and internal calculation. This avoids common-cause failure issues caused by the CAN bus, which is used as an interface for both.

[0333] For example, as shown in Figure 17, when performing functional backup on the chassis bus, the VIU can use a primary / backup approach to back up control messages for dependent and auxiliary functions. That is, when the VDC fails, the VIU will take over sending control messages for components (DCDC, TDU, BMS), such as 0x11A, 0x114, 0x115, 0x3B2, 0x02B0, 0x385, etc. Different embodiments or different vehicle models may use different CAN messages and CANIDs to send this information, but the commands and information for each subsystem are similar and will not be elaborated further here. Simultaneously, the VIU will also directly take over power-on / off management, gear control messages, other message forwarding, and event-type and status-type messages, such as state machine and status maintenance information, which will be directly backed up through the VIU.

[0334] Alternatively, as shown in Figure 19, during power bus function backup, after VDC failure, VIU backup resumes functions such as component control, gear control, and vehicle status. For example, when VDC loses power or hardware failure and completely loses its function, VIU completes the backup and resume of related functions through identified control interfaces, such as 0x181, 0x184, and 0x311.

[0335] The above backup deployment scheme can achieve balanced deployment of vehicle control capabilities. Based on the resource requirements of business and applications, it can achieve flexible deployment of applications, thereby achieving load balancing of the vehicle controller and avoiding the problem of some controllers being overloaded due to one or more controllers having too many functions.

[0336] Meanwhile, this solution enables heterogeneous backup of the torque control link, thereby improving the overall safety of the motor drive system. Compared to the traditional single torque link and the homogeneous backup solution described above, this heterogeneous backup solution can effectively perform heterogeneous backup of the torque control function and its dependent functions, preventing common-cause failures.

[0337] This solution can also achieve short closed-loop torque control. For example, by directly connecting the accelerator pedal sensor to the motor controller, the torque control cycle can be significantly shortened. Taking the motor controller's smaller reference cycle, such as a 2ms task control cycle, as an example of torque control response to the accelerator pedal sensor, it exhibits higher response latency and responsiveness than traditional control schemes in some scenarios. In traditional technology, the main controller's calculation task is at least 10ms, which is transmitted through a CAN message cycle (10ms), leading to timeliness issues. This embodiment directly solves this problem, enabling direct short closed-loop torque request from the sensor, thereby achieving a more sensitive torque control response.

[0338] As shown in Figure 20, one output signal from the accelerator pedal sensor is connected to the VDC (Vehicle Control Unit). The VDC calculates the torque request and outputs the calculation result to the motor controller via the CAN bus. The backup torque control link directly connects the accelerator pedal sensor signal to the motor controller, which can directly read the accelerator pedal opening information to identify the driver's intention. The calculation and response to the torque request are then completed within the motor controller.

[0339] This solution uses an accelerator pedal sensor directly connected to the electric drive system controller, enabling heterogeneous backup of torque control functions and providing a backup for traditional torque chains and direct sensor connections. Simultaneously, by directly connecting the accelerator pedal to the motor controller, faster and more sensitive driver intent responses are achieved. Traditional VDC-based calculations convert the accelerator pedal's driving intent into torque, sending it to the motor controller with a 10ms baseline period. This embodiment, by directly connecting the accelerator pedal to the electric drive system, allows for direct 2ms or 1ms closed-loop control of the electric drive, achieving higher sensitivity than traditional control methods and enabling faster and more precise torque control and rapid response. This solution also effectively increases the safety of torque control by preventing abnormal outputs caused by calculation errors or other errors in intermediate components such as VDC through the direct connection of the accelerator pedal to the drive controller, thereby preventing unexpected acceleration requests and responses.

[0340] As shown in Figure 21, when the accelerator pedal is directly connected to the motor controller (e.g., R-MCU), the motor controller will complete the calculation and output through several modules, including torque calculation, torque arbitration, torque distribution, and torque filtering. A torque control module is also deployed in the motor controller connected to the sensor to achieve drive control of other motor controllers (e.g., F-MCU). A new arbitration module can be deployed in the R-MCU to execute the arbitration logic mentioned above, distinguishing which output result to execute when the same control command arrives. Simultaneously, this arbitration module also performs logical processing, using the output of the backup link to execute or not execute its result when one signal is lost.

[0341] The R-MCU can perform closed-loop control. When the VDC main torque link fails, the R-MCU maintains power output. It can also control the F-MCU through control commands to achieve complete power control backup, thereby realizing the control of the vehicle's power output.

[0342] The above embodiments represent a novel torque control technology architecture, providing a vehicle control method based on multiple torque control links. This includes building new torque links within a domain controller, or building new torque control links within an intelligent driving system such as MDC. Alternatively, it may include a method for creating redundant torque control links by combining two newly created torque control links in pairs.

[0343] On the one hand, in practical applications, two or more torque links can be selected to control the torque output of the vehicle according to the application requirements, so as to ensure the vehicle's power performance.

[0344] On the other hand, a multi-torque calculation link is employed. By deploying torque control programs to different processors, the same torque control method can be implemented using different approaches, either through the same or heterogeneous torque control programs. Furthermore, these programs can be deployed on different controllers, enabling heterogeneous backup of the torque control function, thereby achieving redundancy and enhanced reliability of the torque calculation link. The calculation results can be cross-verified, and arbitration can be performed to ensure safe verification and output of different torque algorithms.

[0345] On the other hand, distributing the critical functions that depend on torque output, such as component control functions, can decouple torque from these critical functions. By adopting a distributed deployment approach for component control and torque control functions, distributed or backup deployment can be carried out according to controller resources and deployment requirements, flexibly adapting to different electronic and electrical architectures and resource constraints.

[0346] On the other hand, the redundant access scheme for the accelerator pedal sensor enables a two-way / three-way output technology. Through the multiple outputs of the accelerator pedal sensor, the sensor signal is transmitted to different controllers to achieve torque request response. The accelerator pedal sensor can use sensors with multiple AI / DI channels, or it can use sensors with digital signal output, such as numerical sensors supporting SENT interfaces or other interfaces, flexibly adapting to different electronic and electrical architectures and communication resource limitations.

[0347] This application also provides a communication device that can be used to implement the method implemented by the vehicle control device described above.

[0348] As shown in Figure 22, the device 2200 may include: a determining unit 2201, used to determine an anomaly in the second control link, the second control link including a second control module, both the second control module and the first control module supporting the first function of the vehicle, the first control module belonging to the first control link; and a control unit 2202, used to take over the first function and, in the first control link, control the vehicle to drive according to first information, the first information including at least one of the following: accelerator pedal opening information, brake pedal opening information, or torque request information of the vehicle's intelligent driving system. Related details can be found in the above method embodiments and will not be repeated here.

[0349] As shown in Figure 23, the device 2300 may include: a control unit 2301, used to send a second control message corresponding to the first function of the vehicle in a second control link according to first information when executing the first function. The second control link includes a second control module, both the second control module and the first control module support the first function, and the first control module belongs to the first control link; and a transceiver unit 2302, used to stop sending the second control message after the first control module takes over the first function. Related details can be found in the above method embodiments and will not be repeated here.

[0350] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The functional units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0351] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to it, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0352] In one possible implementation, embodiments of this application provide a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the method embodiments described above.

[0353] In one possible implementation, this application provides a computer program product that, when run on a computer, causes the computer to execute the above-described method embodiments.

[0354] In a simplified embodiment, those skilled in the art will realize that the communication devices in the above embodiments can all take the form shown in FIG24.

[0355] The device 2400 shown in Figure 24 includes at least one processor 2410 and a communication interface 2430. In an alternative design, a memory 2420 may also be included.

[0356] The specific connection medium between the processor 2410 and the memory 2420 described above is not limited in the embodiments of this application.

[0357] In the device shown in Figure 24, when the processor 2410 communicates with other devices, it can transmit data through the communication interface 2430.

[0358] When the communication device adopts the form shown in FIG24, the processor 2410 in FIG24 can call the computer execution instructions stored in the memory 2420, so that the device 2400 can execute the method executed by the communication device in any of the above method embodiments.

[0359] This application also relates to a chip system including a processor for calling a computer program or computer instructions stored in a memory to cause the processor to execute the methods of any of the above embodiments.

[0360] In one possible implementation, the processor can be coupled to the memory via an interface.

[0361] In one possible implementation, the chip system may also directly include a memory in which computer programs or computer instructions are stored.

[0362] For example, the memory can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0363] This application also relates to a processor for calling a computer program or computer instructions stored in a memory to cause the processor to execute the methods described in any of the above embodiments.

[0364] For example, in the embodiments of this application, the processor is an integrated circuit chip with signal processing capabilities. For instance, the processor can be a field-programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, a system-on-chip (SoC), a central processing unit (CPU), a network processor (NP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0365] It should be understood that embodiments of this application may be provided as methods, systems, or computer program products. Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0366] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0367] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0368] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A vehicle control method characterized by, The method is applied to a first control module, which belongs to a first control link. Both the first and second control modules support a first function of the vehicle. The second control module belongs to a second control link. The method includes: The second control link is determined to be faulty; Take over the first function and, in the first control link, control the vehicle to drive according to the first information, the first information including at least one of the following: the accelerator pedal opening information, the brake pedal opening information, or the torque request information of the vehicle's intelligent driving system.

2. The method of claim 1, wherein, The first function includes vehicle motion control function and vehicle motion dependency function.

3. The method according to claim 1 or 2, characterized in that, The first control module is connected to the vehicle control network. In the first control link, controlling the vehicle's movement based on first information includes: In the first control link, a first control message corresponding to the first function is broadcast according to the first information. The vehicle control network is also connected to one or more of the following execution units: Motor control unit (MCU), vehicle electronic stability control (ESC) unit, main braking unit (IPB), redundant braking unit (RBU), steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system (BMS) control unit, and voltage conversion and distribution unit.

4. The method according to any one of claims 1-3, characterized in that, The determination of the second control link anomaly includes: Obtain the power-on status information of the second control module; If the second control module is not powered on within the first time period, it is determined that the second control link is abnormal.

5. The method according to any one of claims 1-3, characterized in that, The first control module and the second control module are connected to the vehicle control network. When the second control module executes the first function, it broadcasts a second control message corresponding to the first function. Determining that the second control link is abnormal includes: If the second control message is not received within the second time period, the second control link is determined to be abnormal.

6. The method according to claim 5, characterized in that, The second duration is n times the sending period of the second control message, where n is greater than or equal to 2.

7. The method according to any one of claims 1-3, characterized in that, The determination of the second control link anomaly includes: If the fault status information of the second control module is obtained and the fault time reaches the third duration, it is determined that the second control link is abnormal.

8. The method according to claim 7, characterized in that, The third duration is m times the sending period of the second control message of the second control module, where m is greater than or equal to 2. The second control message is the control message corresponding to the first function broadcast by the second control module in the vehicle control network.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: Send takeover flag information to the second control module, wherein the takeover flag information is associated with the silent state of the second control module, and the second control module does not send the second control message corresponding to the first function after entering the silent state.

10. The method according to claim 9, characterized in that, The method further includes: Clear the takeover flag information upon power-off; or... The takeover flag information is cleared based on control information from the user.

11. The method according to any one of claims 1-10, characterized in that, The method further includes: Obtain the control status information of the second control module; If the control status information indicates that the second control module is executing the first function and enters a silent state, the first control module does not send the first control message corresponding to the first function after entering the silent state.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: The first control module is notified to take over the first function by means of the vehicle's human-machine interface (HMI) or voice broadcast; or... The first control module is notified to take over the first function by informing the vehicle's intelligent driving system (ADS).

13. The method according to any one of claims 1-12, characterized in that, The first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: Analog input (AI), digital input (DI), single-sided nibble transmission protocol (SENT), and Ethernet.

14. The method according to any one of claims 1-13, characterized in that, The first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are combinations of any two of the following controllers of the vehicle: Vehicle Domain Controller (VDC), Motor Control Unit (MCU), Area Control Unit (VIU), Intelligent Driving System Domain Control Unit (MDC), or Chassis Domain Controller.

15. A vehicle control method, characterized in that, The method is applied to a second control module, which belongs to a second control link. Both the second control module and the first control module support the first function of the vehicle. The method includes: When the first function is executed, a second control message corresponding to the first function is sent in the second control link according to the first information; After the first control module takes over the first function, it stops sending the second control message.

16. The method according to claim 15, characterized in that, The first function includes vehicle motion control function and vehicle motion dependency function.

17. The method according to claim 15 or 16, characterized in that, The second control module is connected to the vehicle control network. When the second control module executes the first function, it broadcasts a second control message corresponding to the first function. The vehicle control network is also connected to one or more of the following execution units: Motor control unit (MCU), vehicle electronic stability control (ESC) unit, main braking unit (IPB), redundant braking unit (RBU), steering unit, power-on / off management unit, gear control unit, thermal management control unit, battery management system (BMS) control unit, and voltage conversion and distribution unit.

18. The method according to any one of claims 15-17, characterized in that, The method further includes: Upon power-up, ensure that the second control link is functioning correctly, then power on and execute the first function. The control status information is sent to the first control module, and the control status information indicates that the second control module is performing the first function.

19. The method according to claim 18, characterized in that, The second control module is connected to the vehicle control network, and sending control status information to the first control module includes: The control status information is broadcast on the vehicle control network.

20. The method according to any one of claims 15-18, characterized in that, The step of stopping the sending of the second control message after the first control module takes over the first function includes: The takeover flag information is obtained, which indicates that the first control module takes over the first function; Enter a silent state and stop sending the second control message.

21. The method according to any one of claims 15-18, characterized in that, The method further includes: After the fault is recovered, the control status information of the first control module is obtained; If the control status information indicates that the first control module is executing the first function and enters a silent state, the second control module does not send a second control message corresponding to the first function after entering the silent state.

22. The method according to any one of claims 15-21, characterized in that, The method further includes: The second control module is notified to stop executing the first function by means of the vehicle's human-machine interface (HMI) or voice broadcast; or... The vehicle's intelligent driving system (ADS) notifies the second control module to stop performing the first function.

23. The method according to any one of claims 15-22, characterized in that, The first control module and the second control module respectively use at least one of the following communication methods to establish dual-path connections with the vehicle's accelerator pedal sensor, brake pedal sensor, or intelligent driving system domain controller: Analog input (AI), digital input (DI), single-sided nibble transmission protocol (SENT), and Ethernet.

24. The method according to any one of claims 15-23, characterized in that, The first control module is located in the first controller of the vehicle, and the second control module is located in the second controller of the vehicle. The first controller and the second controller are combinations of any two of the following controllers of the vehicle: Vehicle Domain Controller (VDC), Motor Control Unit (MCU), Area Control Unit (VIU), Intelligent Driving System Domain Control Unit (MDC), or Chassis Domain Controller.

25. A vehicle control device, characterized in that, include: A determining unit is used to determine that the second control link is abnormal. The second control link includes a second control module. Both the second control module and the first control module support the first function of the vehicle. The first control module belongs to the first control link. The control unit is used to take over the first function and, in the first control link, control the vehicle to drive according to first information, the first information including at least one of the following: the accelerator pedal opening information, the brake pedal opening information, or the torque request information of the vehicle's intelligent driving system.

26. A vehicle control device, characterized in that, include: The control unit is used to send a second control message corresponding to the first function of the vehicle in the second control link according to the first information when performing the first function. The second control link includes a second control module. Both the second control module and the first control module support the first function. The first control module belongs to the first control link. The transceiver unit is used to stop sending the second control message after the first control module takes over the first function.

27. A communication device, characterized in that, Includes a processor, which is coupled to memory: The processor is configured to execute a computer program or instructions stored in the memory to cause the apparatus to perform the method as described in any one of claims 1-14, or to perform the method as described in any one of claims 15-24.

28. A computer-readable storage medium, characterized in that, The computer-readable medium stores program code that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1-14, or the method as described in any one of claims 15-24.

29. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-14, or the method as described in any one of claims 15-24.

30. A vehicle, characterized in that, It includes a control module for performing the method as described in any one of claims 1-14, and / or a control module for performing the method as described in any one of claims 15-24.

Images