Dual control system and method for operating autonomous vehicle

Abstract

A system and method for deployment on an autonomous vehicle is provided. In some example embodiments, the system includes a first computing unit configured to receive first information of the vehicle and the vehicle environment, generate a first control command based on the first information, and generate a second control command based on the second information. The first control command is transmitted to a controller of the vehicle so as to realize autonomous operation of the vehicle; the second computing unit is configured to receive second information of the vehicle and the vehicle environment, generate a second control command based on the second information, and control the vehicle only when a fault or failure of the first computing unit is detected. And transmitting the second control command to a controller of the vehicle to realize autonomous operation of the vehicle.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to and the benefit of U.S. Provisional Application No. 63 / 422,904, filed on November 4, 2022. The entirety of the above application is incorporated herein by reference. Technical Field

[0003] The present invention relates generally to autonomous vehicles and more particularly to dual control systems and methods for controlling at least partially autonomous operation of a motor vehicle. Background Art

[0004] Autonomous vehicle (AV) technology can provide a motor vehicle that can safely navigate to a destination with limited or no driver assistance. Safe navigation of an autonomous vehicle from one point to another may include the ability to generate timely control commands based on the AV's environmental data and operating parameters and cause the AV to operate accordingly. Summary of the invention

[0005] Systems and methods are described herein that enable deployment of an autonomous vehicle to navigate from a first point to a second point. In some embodiments, the vehicle can navigate from a first point to a second point with limited or no human driver intervention and comply with instructions for safe and legal operation. For example, at least partially autonomous navigation of a vehicle involves a dual control system and method. Example embodiments disclose dual control through two computing units. In some embodiments, the two computing units receive substantially identical information and independently generate control commands based on the information, and control commands generated by only one of the two computing units are used to control vehicle operation; if a malfunction or failure of a computing unit is detected, the other computing unit takes over control almost immediately.

[0006] In one exemplary aspect, a system for deploying an autonomous vehicle is provided. In some embodiments, the system includes a first computing unit and a second computing unit. In some embodiments, the first computing unit receives first information of a motor vehicle and its environment, generates a first control command based on the first information, and transmits the first control command to the motor vehicle to enable autonomous operation of the motor vehicle. In some embodiments, the second computing unit receives second information of the motor vehicle and its environment, generates a second control command based on the second information, and transmits the second control command to the motor vehicle to enable autonomous operation of the motor vehicle only when a fault or failure of the first computing unit is detected.

[0007] In another exemplary aspect, a method of deploying an autonomous vehicle is provided. In a further exemplary aspect, a non-transitory computer-readable program storage medium having code stored thereon is provided. The code stored on the storage medium, when executed by a processor, causes the processor to implement the method of deploying an autonomous vehicle.

[0008] In yet another exemplary aspect, a system is provided for deployment on an autonomous vehicle according to a redundancy rule. In some embodiments, the system includes a first computing unit and a second computing unit as described elsewhere herein; and a vehicle controller configured to receive a first control command from the first computing unit and a second control command from the second control unit, and selectively use the first control command or the second control command to autonomously operate the vehicle according to the redundancy rule. In a further exemplary aspect, a method for deployment on an autonomous vehicle according to a redundancy rule and a non-transitory computer-readable program storage medium storing code are provided.

[0009] In some embodiments, the systems, methods, and non-transitory computer-readable program storage media storing code disclosed herein are configured to at least partially autonomously deploy operations of an autonomous vehicle.

[0010] The above and other aspects and implementations thereof are described in more detail in the drawings, the description and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For a more complete understanding of this disclosure, reference is now made to the following brief description, which is taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0012] Figure 1 An example motor vehicle is shown according to some embodiments herein.

[0013] Figure 2 An example system including a blade server according to some embodiments herein is shown.

[0014] Figure 3 The architecture of an example system according to some embodiments herein is shown.

[0015] Figure 4 A block diagram of an example computing unit is shown according to some embodiments herein.

[0016] Figure 5 A block diagram of an example CPU module is shown according to some embodiments herein.

[0017] Figure 6 A block diagram of an example GPU module is shown according to some embodiments herein.

[0018] Figure 7 A block diagram of an example VCU module is shown according to some embodiments herein.

[0019] Figure 8 A block diagram illustrating an example sensor unit stack according to some embodiments herein.

[0020] Figure 9-10B A block diagram illustrating portions of an example system according to some embodiments herein.

[0021] Fig.11 A block diagram of an example system is shown according to some embodiments herein.

[0022] Fig.12 A process flow chart for deploying an autonomous vehicle according to some embodiments of the present invention is shown. DETAILED DESCRIPTION

[0023] Vehicles on highways and roads are required by law to comply with regulations and ordinances during safe operation. For autonomous vehicles (AVs), and in particular autonomous tractor trailers, the ability to identify a system failure and safely stop the vehicle enables legal and safe operation of the vehicle. Systems and methods for legal and safe operation of an autonomous vehicle on a roadway are described in detail below, including performing maneuvers that bring the autonomous vehicle into compliance with the law while signaling its status to surrounding vehicles.

[0024] It should be understood that features described in different parts of the present disclosure may be combined. The same reference numerals may represent the same components or operations.

[0025] Figure 1 A motor vehicle (or simply vehicle) 100 is shown according to some embodiments of the present invention. The vehicle 100 may include a tractor of a semi-trailer truck, a passenger car, etc. The vehicle 100 may be a motor vehicle with full or limited autonomous operation capabilities. The vehicle 100 includes a system 105 for deploying the autonomous vehicle 100. Figure 2 As shown, system 105 may include a modular blade server including a plurality of blade modules operably interconnected via, for example, a backplane. The modular blade server design facilitates management of interfaces and connectors of system 105 with other systems and facilitates repair and maintenance of components of system 105 when any hardware-related problems occur and / or are detected. In addition, different components in system 105 may be allocated on one blade module or the same circuit board according to their printed circuit board (PCB) design and physical size requirements. For example, a central processing unit (CPU) module and a vehicle control unit (VCU) may be placed on one blade module (see, e.g., Figure 4 ), and the program database (PDB) can be integrated into the CPU board.

[0026] In some embodiments, the system 105 can be expanded by at least one of the following: adding additional blade modules, replacing or removing one of the plurality of blade modules, or modifying the configuration of one of the plurality of blade modules. For example, if a sensor is damaged, or an upgraded version of a sensor or a different type of sensor is available, the system 105 can be easily adjusted to achieve the upgrade, increase or replacement of the sensor by replacing or adding a new blade module with a suitable new data connector, appropriate storage capacity, computing capacity, etc. or a combination thereof.

[0027] The components of system 105 may be Figure 3-11 The point-to-point connection shown by the arrow in the figure is operably connected. In the context of autonomous driving, point-to-point connections can bring one or more advantages to the exchange of information (such as sensor data, control commands, etc. or a combination thereof). The example advantages provided here are for illustrative purposes only and are not restrictive. Point-to-point connections can be directly set up and configured. A single connection is usually dedicated to a specific purpose and involves fewer variables, making it easier to manage and troubleshoot. Point-to-point connections can reduce or minimize the risk of crosstalk, which may occur when signals interfere with each other in a multi-component environment. Therefore, point-to-point connections can improve signal integrity and reduce data errors. Point-to-point connections have low latency in data transmission because there are no intermediate components or network routes to compete. Point-to-point connections can be easily expanded by adding or removing connections as needed. This flexibility may be of great value because the number (or count) of components involved in the autonomous operation of the vehicle or the components themselves may change over time. Point-to-point connections can provide the deterministic communication required for precise control by ensuring that signals and / or data arrive reliably and on time. Point-to-point connections allow customization of communication protocols and data formats between components. In some embodiments, in specialized applications where standard protocols may not be sufficient, this level of customization can be achieved without interfering with other components that are operably connected via other connections (e.g., point-to-point connections) independent of the customized connection. Point-to-point connections can isolate components from each other, reducing the risk of one component affecting the operation of another. This can be very useful in vehicle autonomous operation, where fault tolerance is low and / or high reliability is required for safety reasons.

[0028] The system 105 may be an onboard system installed on the vehicle 100. The system 105 may communicate with a cloud server (e.g. Fig. 10A The system 105 may communicate with a cloud server 1070 as shown to obtain information such as the status, location, operating state, environment, etc. of the vehicle 100, and / or receive information from the cloud server for controlling the operation of the vehicle 100. The system 105 may include a supervisory subsystem, such as Fig. 10A Advanced Vehicle Control / Guidance (AVCG) 1080 is shown. In some embodiments, the supervisory subsystem may be remote from the vehicle 100.

[0029] In some embodiments, the supervisory subsystem may determine performance parameters of the vehicle 100 (e.g., an autonomous vehicle, an autonomous truck, a passenger car), including, but not limited to: data logging frequency, compression rate, location, data type; communication priority; service frequency of the autonomous vehicle (e.g., the number of miles driven between services); when to perform a minimum risk condition (MRC) maneuver while monitoring the vehicle's maneuver progress; when to hand over control of the autonomous vehicle to a human driver (e.g., at a destination station); ensuring that the vehicle passes pre-trip inspection; ensuring that the vehicle complies with regulatory requirements at checkpoints and weigh stations; ensuring that the vehicle complies with human instructions at roadblocks, crosswalks, intersections, construction, or accident sites; or any combination thereof. In some embodiments, the supervisory subsystem may be configured to detect a fault or failure (e.g., a fault or failure that exceeds a tolerable threshold) of a portion of the system 105 (e.g., a computing unit). For example, the supervisory subsystem may be implemented as Fig.11 The diagnostic monitoring software module 1114 and the VCU 1130 are shown. Fig.11 Related description.

[0030] For example, when system 105 detects that one or all of its computing units (e.g. Fig. 10A 920 in Fig. 10B 930 of them Fig.11 When a fault or failure (e.g., a fault or failure exceeding a tolerable threshold) occurs in CU-1 1110 and CU-2 in the system 105, the system 105 may activate an emergency maneuver. Exemplary emergency maneuvers include: stopping the vehicle, generating a notification (sent to a cloud server, law enforcement, or emergency response agency), and transferring vehicle control to a third party (e.g., a cloud server with appropriate authority and / or capabilities). In some embodiments, when such a third party receives a request to take over control of the vehicle 100, or determines that the vehicle 100 has a fault or failure, the third party may take over operational control of the vehicle 100. For example, the third party may send a control command or control signal to cause the vehicle to stop in an emergency, or drive the vehicle 100 to the nearest police station, hospital, etc.

[0031] As another example, in response to detecting a failure or malfunction of a computing unit, system 105 (e.g., Fig.11 For example, the first computing unit (e.g., Fig. 10A 920 of them, Fig.11 CU-11110 in the example is a main computing unit configured to generate a first control command and transmit it to a vehicle controller to implement autonomous operation (or partially autonomous operation) of the vehicle; a second computing unit (e.g., Fig. 10B 930 of them, Fig.11 CU-21120 in the system 105) as a secondary or redundant computing unit, configured to generate a second control command that is not transmitted to the vehicle controller. Fig.11 The VCU 1130 in the embodiment may be configured to monitor whether the first computing unit is operating normally, and in response to detecting a fault or failure of the first computing unit (e.g., a fault or failure exceeding a tolerable threshold), the system 105 (e.g., Fig.11 The VCU 1130 in the embodiment may take remedial measures by terminating the transmission of a first control command to a vehicle controller that controls vehicle operation and causing a second computing unit to transmit a second control command to the vehicle controller to achieve autonomous (or partially autonomous) operation of the vehicle.

[0032] In some embodiments, the system 105 may include a vehicle controller configured to receive control commands independently generated by different computing units (e.g., a first control command from a first computing unit and a second control command from a second control unit), and selectively use the first control command or the second control command according to a redundancy rule. In some embodiments, the redundancy rule stipulates that the first control command is used by default, and switches to the second control command when a failure of the first computing unit is detected.

[0033] Figure 3An example of a system 105 according to some embodiments of the present invention is shown. The system 105 may include three sensor units (SU): SU1 350-1, SU2 350-2, and SU3 350-3. The system 105 may include two computing units (CU): a first computing unit CU1 360-1 and a second computing unit CU2 360-2. The system 105 may include an electronic control unit (ECU) 370. The bidirectional arrow between two components indicates that the information exchange between the two components is bidirectional, and one of the two components can receive information from the other of the two components and can provide information to the other of the two components. The three sensor units (SU1 350-1 to SU3 350-3) can each be operably connected to the first computing unit CU1 360-1 through an interface 310 (represented by a solid line with bidirectional arrows), so that the sensor unit can transmit information (e.g., sensor data) to the first computing unit CU1 and receive information (e.g., control signals) from the first computing unit CU1. The sensor unit may be connected to a plurality of sensors including, for example, a camera, a microphone, a light detection and ranging (LiDAR) sensor, a radar sensor, an ultrasonic sensor, a positioning or navigation sensor, etc. The sensor unit may receive sensor data acquired by one or more of the plurality of sensors to which it is operably connected, and / or transmit a control signal to one or more of the plurality of sensors. Example control signals may include signals for controlling or configuring the operation of the sensor to which the sensor unit is operably connected (e.g., resolution, sensor data acquisition refresh rate, sensor orientation (e.g., sensor unit angle or its change), etc. or a combination thereof). Each of the three sensor units (SU1 350-1 to SU3 350-3) may also be operably connected to the second computing unit CU2 360-2 via an interface 320 (represented by a dotted line with a double-headed arrow), so that the sensor unit may transmit information (e.g., sensor data) to the second computing unit CU2 360-2 and receive information (e.g., control signals) from the second computing unit CU2 360-2. The interface 310 is independent of the interface 320, so that data transmission through the interface 310 is independent of data transmission of the interface 320. The interface 310 and the interface 320 may be different interfaces of the same type. For example, one or both of the interface 310 and the interface 320 may be a controller area network (CAN) interface. In some embodiments, the interface 310 may be a controller area network (CAN) interface. The first computing unit CU1 360-1 may be operably connected to the ECU via the interface 330. The second computing unit CU2 360-2 may be operably connected to the ECU 370 via an interface 340 independent of the interface 330.

[0034] As an example only, one or more sensor units may be implemented on a blade module; the first computing unit CU1 360-1 and the second computing unit CU2 360-2 may each be implemented on a blade module. In some embodiments, each computing unit may be operably connected to two sensor units (see, e.g. Figure 8-11 ).

[0035] In some embodiments, one of the computing units may be used or designated as a primary computing unit and the other as a secondary or redundant computing unit. In some embodiments, the primary computing unit and the redundant computing unit may have a substantially symmetrical or identical configuration; that is, the primary computing unit and the redundant computing unit may include the same components that are operably connected to each other in the same manner. By way of example only, the primary computing unit and the redundant computing unit may include the same number (count) of central processing unit (CPU) modules, the same number (count) of graphics processing unit (GPU) modules, the same number (count) of vehicle control units (VCU), and these components are operably connected to each other in the same manner. It should be understood that Figure 3 The two computing units shown in FIG. 1 are for illustration purposes only and are not limiting. System 105 may include more than two computing units.

[0036] Figure 4 A block diagram of an exemplary computing unit 400 according to some embodiments herein is shown. The computing unit 400 may include a CPU module 410, two GPU modules 420-1 and 420-2, and a VCU 430. The CPU module 410 is operably connected to GPU1 420-1, GPU2 420-2, and VCU 430, and exchanges information bidirectionally with each of them.

[0037] The CPU module 410 may include at least one of a CPU, a CPU motherboard, a storage unit, a board management controller (BMC), a motherboard chipset, and a network interface controller (NIC), or a combination thereof. At least some of the components of the CPU module 410 may be deployed on the CPU motherboard. In some embodiments, the storage capacity of the CPU module may be fixedly allocated to different components of the CPU module, such as being evenly or unevenly allocated between different CPUs of the CPU module 410. In some embodiments, the storage capacity of the CPU module 410 may be dynamically allocated to different components of the CPU module 410, such as being allocated between different CPUs of the CPU module 410, based on the demand for storage capacity of one or more CPUs of the CPU module 410.

[0038] Either GPU1 420-1 or GPU 420-2 may include at least one of a GPU, a microcontroller, a GPU carrier board, a switch, a data interface, a power connector, or a combination thereof.

[0039] The VCU 430 may provide an interface between the system 105 and the ECU of the vehicle 100. The VCU 430 may convert control commands from the system 105 into control signals and transmit them to the vehicle 100 (e.g., vehicle actuators) via the ECU. Examples of control signals include at least one of an engine torque request, a brake request, or a steering wheel angle request. In some embodiments, safety-related functions and maintenance requirement card (MRC) functions may also be run in the VCU 430. For example, before converting a control command into a control signal, the VCU 430 may check the control command and related information to determine whether the control command is valid and / or whether the computing unit is operating normally.

[0040] In operation, Figure 3 The sensor data of the sensor units shown in SU1 350-1 to SU3 350-3 may be transmitted to one or both of GPU1 420-1 and GPU2 420-2 for processing, and the resulting information may be provided to the CPU module 410 for further processing to generate control commands. The control commands may be transmitted to the VCU 430 and then transmitted to one or more ECUs (e.g., Figure 3 The VCU 430 may perform several checks on the control command and related information to determine whether the control command is valid and / or whether the computing unit is operating normally. The VCU 430 may convert the valid control command into a control signal and transmit the control signal to the vehicle actuator of the vehicle 100 through the ECU to control the operation of the vehicle 100. The ECU may be an original equipment manufacturer (OEM) ECU.

[0041] The computing unit 400 may be implemented in a blade module or a blade server (eg, Figure 2 The computing unit 400 may be a first computing unit, a second computing unit, and / or one of the plurality of computing units described elsewhere herein.

[0042] Figure 5A block diagram of an exemplary CPU module 500 according to some embodiments of the present invention is shown. The CPU module 500 provides an example of a CPU module 410 of a computing unit 400. As shown in the figure, the exemplary CPU module 500 has two CPUs (CPU1 and CPU2) (e.g., Intel's fourth-generation Xeon CPU (Sapphire Rapids)), a double data rate 5 (DDR5) memory (e.g., a total storage capacity of 512GB, 256GB per CPU), and a non-volatile memory express (NVMe) solid-state drive (SSD) (e.g., 4TB storage capacity) on its CPU motherboard. In addition, a BMC, a 10G network card, and a motherboard chipset (e.g., an Intel motherboard chipset) are deployed on the CPU motherboard. The CPU module 500 also provides different types of interfaces / connectors. For example, the CPU module 500 may include a 9V-32V power connector (e.g., 510), eight peripheral component interconnect express (PCIe) Gen5 slots (e.g., 520) (each in a 16-lane configuration), two 1G Ethernet ports (e.g., 530), four 10G Ethernet ports, and a 16-lane PCIe Gen5 card electromechanical (CEM) connector. One or more of these connectors / interfaces may be implemented on the backplane of the CPU motherboard. It should be understood that the specific parameters provided herein, such as the generation, model, protocol, configuration, manufacturer, etc. of the connector or interface, and the number / count of connector / interface types, storage devices, processors, etc., are for illustrative purposes only and are not intended to be limiting.

[0043] Figure 6 A block diagram of an exemplary GPU module 600 according to some embodiments of the present invention is shown. The GPU module 600 provides an example of a GPU module of a computing unit 400, such as GPU1 420-1, GPU2 420-2. As shown, the exemplary GPU module 600 includes two GPUs 610 (identified as 610-A and 610-B, respectively) (e.g., NVIDIA pg199), which are connected to a 52-lane PCIe Gen4 switch via, for example, 8-lane PCIe. Each of the two GPUs 610 of the GPU module 600 is configured to receive a control signal from a microcontroller 620. The microcontroller 620 is used to control power supply and reset, and monitor the voltage and temperature of the GPU 610. The microcontroller 620 has an automotive safety integrity level (ASIL)-D capability. The GPU module 600 (also referred to as a GPU carrier board) has multiple backplane connectors, including, for example, a 1G Ethernet connector 640, a 9V-32V power connector 650, and four independent PCIe connectors (e.g., a 4-lane 630-A, a 16-lane 630-B, and two 8-lane 630-C and 630-D).

[0044] Figure 7 A block diagram of an exemplary VCU module 700 according to some embodiments of the present invention is shown. The VCU module 700 provides an example of a VCU 430. As described elsewhere herein, the VCU 430 may be integrated into or operably connected to the computing unit 400. As shown, the exemplary VCU module 700 may be hosted on a microcontroller 705 (e.g., a microcontroller with ASIL-D capabilities, such as the Infineon 32-bit TC399 microcontroller), which also meets automotive-grade safety requirements. A voltage monitoring system 720 is deployed to monitor the CPU power supply voltage state through the CPU power rail. An Ethernet switch 710 (e.g., an 802.1AS Ethernet switch) is involved to achieve time alignment of data from different sources through Ethernet. A variety of interfaces are provided on the backplane connector. Exemplary interfaces include one or more (e.g., twelve) CAN flexible data rate (FD) interfaces 730, one or more (e.g., four) low side drive (LSD) connectors 740, one or more (e.g., eight) high side drive (HSD) connectors 750, one or more (e.g., twelve) analog input ports 760, one or more (e.g., sixteen) pulse width modulation (PWM) output ports 770, one or more (e.g., six) Ethernet connectors 780 (illustrated as 780-A and 780-B, respectively) (e.g., 1G Ethernet connectors), power connectors 790 (e.g., 9V-32V power connectors), ports 795 (e.g., OEM+ input / output (IO) ports) (which are configured to allow operable connection to one or more ECUs of a vehicle (e.g., a truck), etc., or a combination thereof. By way of example only, the backplane Ethernet connector 780-A may be configured to facilitate connection between the VCU module 700 and the computing unit.

[0045] Figure 8 A block diagram of an exemplary sensor unit stack 800 according to some embodiments of the present invention is shown. The sensor unit stack 800 may include one or more sensor units, such as sensor unit SU1 350-1, sensor unit SU2 350-2, and sensor unit SU3 350-3. Multiple sensor units may be integrated in a blade module as a sensor unit stack 800. The sensor unit stack 800 is configured to address systemic risks caused by one or more factors, including, for example, network switch failure, data transmission loss and delay between sensors and system 105, etc. or a combination thereof. It can provide stable data transmission between sensors and servers, sensor control and management services, and multi-sensor synchronous data transmission.

[0046] As shown, the example sensor unit stack 800 includes two identical sensor units, for example, two dual OrinX boards (identified as Orin X Blade-1 and Orin X Blade-2, respectively). Each dual OrinX board has two NVIDIA OrinX (identified as Orin-1 and Orin-2, respectively) system-on-chip (SoC), an Ethernet switch supporting 1G and 10G speeds (identified as "Eth Switch"), two power management integrated circuits (PMICs), sixteen Gigabit Multimedia Serial Link 2 (GMSL2) deserializers, a 32-lane PCIe Gen4 switch, and optionally two ASIL-D capable safety microcontrollers (e.g., Infineon TC39x). As shown, the two sensor units are each operably connected to a plurality of sensors including, for example, cameras, one or more microphones. By way of example only, the main camera group transmits the acquired image data to the sensor group (e.g., via the GMSL2 protocol). Figure 8 Orin X Blade-1 shown, Fig. 9 SU#1 shown), the data from these GMSL2 serializer camera modules then needs to be deserialized and input to the SoC (e.g. Figure 8 Orin-1 and Fig. 9 Multi-processor SoC shown).

[0047] The example sensor unit stack 800 provides a rich interface setting to transmit sensor data to the computing unit. On the front panel, multiple (e.g., thirty-two) Gigabit Multimedia Serial Link 2 (GMSL2) interfaces (e.g., sixteen per dual OrinX board, eight per OrinX) are used to connect cameras and microphones, multiple (e.g., four) CAN FD are used for inertial measurement units (IMUs), multiple (e.g., twenty-four) 1000BASE-T1 ports, and multiple (e.g., twenty) 100BASE-T1 ports are used to transmit Lidar and / or radar sensor data. In addition, an automotive audio bus (A2B) interface is used to collect microphone audio. Multiple sets of PCIe connectors (e.g., four 16-lane PCIe Gen4 connectors) and multiple power connectors (e.g., two 9V-32V power connectors) are provided on the back panel. In some embodiments, each sensor unit in the sensor unit stack 800 can obtain an independent power supply through the power connector. The components in the sensor unit stack 800 can be connected through the following methods: Figure 8 The point-to-point connections (each connected to two components) shown by the arrows in the figure are operatively connected. The components in the dashed box can be optional components of the example sensor unit stack 800.

[0048] Figures 9 to 10B900 is an example of system 105. Fig. 9 Portion 910 is shown including a stack of sensor cells operably connected to the sensor. Fig. 10A The portion 920 shown includes a first computing unit (eg, a main computing unit). Fig. 10B Portion 930 is shown to include a second computing unit (eg, a secondary or redundant computing unit). Fig. 10A The portion 940 shown comprises the vehicle top stack. The various components of the system 105 may be provided as follows: Fig. 9 The point-to-point connections shown by the arrows (each connected to two components) are operably connected. One or more connections can be implemented via Ethernet connections (e.g., 100M, 1G), GMSL2, or a combination thereof. One or more connections can be wired using cables. The cables can be suitable for automotive environments. For example, the cables have temperature protection, climate protection, or motion protection characteristics. One or more connections can be implemented via interfaces / connectors (e.g., PCIe Gen4 / Gen5 connectors) or switches. Figures 9 to 10B In the figure, the dotted line represents the Ethernet connection between the component and the main system (SU#1); the short dash line represents the Ethernet connection between the component and the redundant system (SU#2); the double dotted line represents the Ethernet interconnection between the main system (SU#1) and the redundant system (SU#2); the long dash line represents the connection between the main system (SU#1) and the PCIe connector; the long dash-short double dash line represents the connection between the redundant system (SU#2) and the PCIe connector. Figures 9 to 10B The same letters A to L in the figure represent corresponding connections. One or both of SU#1 and SU#2 may have an Ethernet interface, a PCIe interface, etc.

[0049] Fig. 9 Portion 910 is shown including a sensor unit stack 912 operatively connected to the sensor. The sensor may be external and not part of the system 900, but communicates with the system 900 through one or more sensor units (e.g., sensor units SU#1, SU#2 shown). The sensor may include at least one of a camera, an audio sensor, a microphone, a light detection and ranging (LiDAR) sensor, a radar sensor, an ultrasonic sensor, a positioning or navigation sensor (e.g., a global navigation satellite system (GNSS) sensor).

[0050] Sensor unit SU#1 and sensor unit SU#2 may form a sensor unit stack 912 (eg, with Figure 8 The two sensor units SU#1 and SU#2 may communicate with each other or be connected to a master clock to achieve time synchronization. For example, a cloud-oriented database engine solution (such as Aurora) may be used to achieve synchronization.

[0051] In some embodiments, sensor unit SU#1 and sensor unit SU#2 may receive sensor data from different sensors. For example, sensor unit SU#1 may receive sensor data from a navigation sensor (e.g., GNSS), a lidar sensor, a radar sensor, a camera, a microphone, etc. In some embodiments, sensor unit SU#2 may receive sensor data from a different camera, a different microphone, etc. than sensor unit SU#1. As an example only, the first camera group is configured to transmit the acquired image data to SU#1, and the second camera group is configured to transmit the acquired image data to SU#2. In some embodiments, sensor unit SU#2 may receive sensor data from the same sensor as sensor unit SU#1. Sensor unit SU#1 and sensor unit SU#2 may be operably connected to different power supplies. For example, sensor unit SU#1 may be operably connected to a first power supply (e.g., a main power supply), and sensor unit SU#2 may be operably connected to a second power supply (e.g., a redundant power supply). As shown, sensor units SU#1 and SU#2 may include two multi-processor (MP) system-on-chips (SoCs).

[0052] Fig. 10A and Fig. 10B Calculation units 920 and 930 are shown respectively. The calculation units 920 and 930 may be, for example Figure 3 and Figure 4 The main computing unit and the secondary computing unit shown. The computing unit 920 / 930 may include a storage unit 1010, a CPU module 1020, two GPU modules including a GPU module 1 1030 and a GPU module 2 1040, and a VCU 1050. The computing unit 920 is operably connected to a power supply 1060 (e.g., a main power supply). The computing unit 930 is operably connected to a power supply 1095 (e.g., a redundant power supply). More descriptions of the components of the computing unit 920 / 930 can be found in other parts of this document. See, for example Figure 4-7 The related descriptions will not be repeated here.

[0053] Fig. 10AA roof stack 940 is shown. The roof stack 940 includes an advanced vehicle control / guidance (AVCG) 1080. The AVCG 1080 is operably connected to a cloud service 1070. The cloud service 1070 may have storage capacity, processing capabilities, etc. For example, through the AVCG 1080, information of the vehicle 100 may be transmitted to the cloud 1070 for storage, processing, etc., and information from the cloud service 1070 may be transmitted to the vehicle 100. Exemplary information of the vehicle 100 includes operating status, parameters, environmental data of the environment of the vehicle 100, etc. Exemplary information from the cloud service 1070 to the vehicle 100 includes notifications (e.g., weather information, traffic information), overriding control commands or signals (e.g., in an emergency situation where all computing units of the system 105 fail), etc. The AVCG 1080 is operably connected to a power supply 1090 (e.g., a primary power supply as shown, a redundant power supply). It should be understood that although the assembly 940 is referred to as a "roof stack", this does not mean that the assembly must be installed on or in the roof of the vehicle 100. Instead, it can be installed at a suitable location on the vehicle 100 other than the roof or its interior.

[0054] Fig.11 A block diagram of an example system 1100 according to some embodiments of the present invention is shown. System 1100 provides an example of system 105. System 1100 may include a first computing unit CU-1 (also referred to as CU1) 1110, a second computing unit CU-2 (also referred to as CU2) 1120, and a VCU 1130. System 1100 may also include sensor units SU1 and SU2. Various components of the first computing unit CU-1 1110 may be divided into a dynamic driving task (DDT) software (SW) module 1112 and a diagnostic monitoring SW module 1114 based on functionality. The DDT SW module 1112 may include a perception module 1112-1, a positioning system (LPS) module 1112-2, a prediction and planning module 1112-3, and a control module 1112-4.

[0055] In some embodiments, the DDT SW module 1112 may receive sensor data (or sensor input) from sensor units SU1 and SU2, and determine the desired trajectory and vehicle control commands based on the sensor input. The sensor input from sensor units SU1 and / or SU2 may be transmitted to the perception module 1112-1 and / or the LPS module 1112-2 of the DDT SW module 1112. At least part of the DDT SW module 1112 may also receive, for example, environmental data about the environment of the vehicle 100, positioning data from the LPS module 1112-2, and use it in the determination process. The DDT SW module 1112 may output a planned trajectory generated by, for example, the prediction and planning module 1112-3, and a control command generated by, for example, the control module 1112-4 of the DDT SW module 1112.

[0056] In some embodiments, the diagnostic monitoring SW module 1114 may be configured to monitor the execution of the DDT, obtain the timing and errors reported by the DDTSW module 1112. The output of the diagnostic monitoring SW module 1114 may include, for example, no errors detected, minimum risk condition (MRC) 1 capable, MRC 3 capable, MRC 2 only, etc. The output may be related to or suggest remedial or emergency measures to be taken. For example, the output of MRC 2 may indicate that a minimum risk maneuver (MRM) needs to be performed to bring the vehicle to a safe state.

[0057] For example, the diagnostic monitoring SW module 1114 may include computing unit hardware (HW) health monitoring (HM). By way of example only, the HM may provide the following features: monitoring different rails on the board; power sequencing at startup; logging critical errors, including power failures, soft reset times (or counts), watchdog failures; and controlling hardware communications and activities to maintain vehicle safety. In some embodiments, the diagnostic monitoring SW module 1114 may monitor algorithm states to assess, for example, the autonomous capabilities of the system 105. In some embodiments, the diagnostic monitoring SW module 1114 may monitor, for example, message delays, watchdogs, etc. In some embodiments, the diagnostic monitoring SW module 1114 may constitute at least a portion of the supervisory subsystem described elsewhere herein. See, for example, Figure 3 For more information in this regard, please refer to (for example) International Application Publication No. WO2023009987, entitled "Systems and methods for operating an autonomous vehicle", filed on July 25, 2022, the contents of which are incorporated herein by reference.

[0058] The configuration of the second computing unit CU-2 1120 may be substantially the same as that of the first computing unit CU-1 1110. The description of the first computing unit CU-1 1110 is applicable to the second computing unit CU-2 1120 and will not be repeated here.

[0059] Fig.11 The VCU 1130 shown illustrates the software architecture of a redundant L4 ECU architecture. As shown, the VCU 1130 is configured to determine which vehicle control trajectory is safe and reliable through a series of steps. These steps may include MRC monitors and actuators, as well as diagnostic checks on the overall health and status of CU1 and CU2. One or more of the steps may be referred to as rationality checks, and facilitate arbitration of which CU (e.g., CU1 and CU2) should be adopted for the final output trajectory. By way of example only, the VCU 1130 may detect faults or failures and / or monitor the operation of the first computing unit CU-1 1110 and the second computing unit CU2 1120 by comparing information from the first computing unit CU-1 1110 and the second computing unit CU2 1120. For example, the VCU 1130 (e.g., at the CU1&CU2 trajectory difference check module 1130-1) may compare the trajectories independently predicted by the first computing unit CU-1 1110 and the second computing unit CU2 1120. For a trajectory close to a point of interest (e.g., a destination), a small tolerance range (e.g., a small deviation) is allowed between the trajectory determined by the first computing unit CU-1 111 and the trajectory determined by the second computing unit CU2 1120. For a trajectory far from a point of interest (e.g., a destination), a large tolerance range (e.g., a larger deviation than a trajectory close to the point of interest) may be allowed between the trajectory determined by the first computing unit CU-1 1110 and the trajectory determined by the second computing unit CU2 1120. In some embodiments, the VCU 1130 may compare the timestamps of the corresponding information independently predicted by the first computing unit CU-1 1110 and the second computing unit CU2 1120. If the deviation of the timestamps of the corresponding information independently predicted by the first computing unit CU-1 1110 and the second computing unit CU2 1120 exceeds a threshold, the VCU 1130 may determine, for example, whether the first computing unit CU-1 1110 or the second computing unit CU2 1120 is faulty or failed, whether the first control instruction or the second control instruction is valid, etc. In some embodiments, the various results of the trace comparison may be considered in combination to determine an end-to-end checksum, based on which the VCU 1130 makes decisions.

[0060] The VCU 1130 (e.g., at the control rationality check module 1130-2) may perform a rationality check on the control commands independently generated by the first computing unit CU-1 1110 and the second computing unit CU2 1120. For example, the VCU 1130 may check information related to the timestamp, range, etc. of the control commands independently generated by the first computing unit CU-1 1110 and the second computing unit CU2 1120, generate a checksum, and make a rationality determination based on the checksum.

[0061] The VCU 1130 (e.g., at the diagnostic rationality check module 1130-3) may perform a computing unit diagnostic rationality check. The output of the diagnostic monitoring SW module 1114 may be double checked. For example, the VCU 1130 may check information related to the output of the diagnostic monitoring SW module 1114 regarding timestamps, program flow, etc., generate a checksum, and make a rationality determination based on the checksum.

[0062] In some embodiments, VCU 1130 may constitute at least a portion of the supervisory subsystem described elsewhere herein. Figure 3 and related descriptions.

[0063] Fig.12 A flow chart of a process for deploying an autonomous driving vehicle according to some embodiments of the present invention is shown. The process can be executed on the system 105.

[0064] At 1210, a sensor unit of the system 105 may receive information. The information may include sensor data acquired by one or more sensors as described elsewhere herein. In some embodiments, the information may also include operating parameters of the vehicle 100. The sensor unit may send the received information to the first computing unit and the second computing unit substantially simultaneously. In some embodiments, one or more operating parameters of the vehicle 100 may be transmitted directly to the first computing unit and the second computing unit.

[0065] At 1220, the first computing unit receives first information of the vehicle 100. At 1250, the second computing unit receives second information of the vehicle 100. The first information may be substantially equivalent to the second information. The first computing unit receiving the first information and the second computing unit receiving the second information may occur substantially simultaneously.

[0066] In 1230, the first computing unit generates a first control command based on the first information. In 1260, the second computing unit generates a second control command based on the second information. The generation of the first control command is independent of the generation of the second control command.

[0067] At 1240, it is evaluated whether the first computing unit has a fault or failure, or whether the first control command is valid (e.g., as shown in the attached Fig.11If it is determined that the first computing unit is not faulty or has not failed, and / or the first control command is valid, then at 1270 the first control command is transmitted to the vehicle (e.g., a vehicle actuator) to enable at least partially autonomous operation of the vehicle.

[0068] If it is determined that the first computing unit is faulty or failed, and / or the first control command is invalid, the first control command is not transmitted to the vehicle; instead, a second control command is transmitted to the vehicle (e.g., a vehicle actuator) to achieve at least partially autonomous operation of the vehicle in 1280. For example, as described elsewhere, the valid control command can be converted into a control signal, which can be transmitted to the vehicle actuator via, for example, an ECU, and the vehicle actuator can cause the vehicle 100 to operate accordingly.

[0069] In some embodiments, both the first control command and the second control command are transmitted to a processing unit or device (e.g., a vehicle controller). The vehicle controller can selectively use the first control command or the second control command according to a redundancy rule. In some embodiments, the redundancy rule specifies that the first control command is used as a default option and switches to the second control command when a failure of the first computing unit is detected.

[0070] Some exemplary technical solutions implemented by some preferred embodiments are listed below.

[0071] 1. A system for deploying an autonomous vehicle, comprising:

[0072] The first computing unit is configured as follows:

[0073] receiving first information about the vehicle and the vehicle environment,

[0074] generating a first control command based on the first information, and

[0075] transmitting the first control command to a controller of the vehicle to enable autonomous operation of the vehicle; and

[0076] The second computing unit is configured as follows:

[0077] receiving second information about the vehicle and the vehicle environment,

[0078] generating a second control command based on the second information, and

[0079] Only when a fault or failure of the first computing unit is detected, the second control command is transmitted to a controller of the vehicle to enable autonomous operation of the vehicle.

[0080] 2. A system as described in any of the preceding schemes, wherein the first information is substantially identical to the second information.

[0081] 3. A system as described in any of the preceding schemes, wherein the first information and the second information include the same sensor data acquired by at least one sensor.

[0082] 4. A system as described in any of the preceding schemes, wherein the at least one sensor includes at least one of a camera, an audio sensor, a light detection and ranging (LiDAR) sensor, a radar sensor, or a navigation sensor.

[0083] 5. The system according to any of the preceding solutions, further comprising:

[0084] a first sensor unit configured to receive a first portion of the sensor data from a first group of the at least one sensor; and

[0085] A second sensor unit is configured to receive a second portion of the sensor data from a second group of the at least one sensor.

[0086] 6. The system as described in any of the preceding solutions, wherein the first sensor unit and the second sensor unit are implemented on a blade module.

[0087] 7. A system as described in any of the preceding embodiments, wherein the blade module containing the first sensor unit and the second sensor unit includes a front panel and a back panel, the front panel includes at least one interface, and the interface is configured to facilitate communication between the first sensor unit and the second sensor unit and the at least one sensor; the back panel includes at least one connector, and the connector is configured to facilitate communication between the first sensor unit and the second sensor unit and at least one of the first computing unit and the second computing unit.

[0088] 8. The system according to any one of the preceding embodiments, wherein the first sensor unit and the second sensor unit are connected to independent power supplies, respectively.

[0089] 9. A system as described in any of the preceding schemes, wherein the first sensor unit and the second sensor unit are operably coupled to the first computing unit via a first sensor data interface, and the first sensor unit and the second sensor unit are operably coupled to the second computing unit via a second sensor data interface independent of the first sensor data interface.

[0090] 10. A system as described in any of the preceding embodiments, wherein at least one of the first information and the second information includes an operating parameter of the vehicle.

[0091] 11. A system as described in any of the preceding embodiments, wherein the first computing unit is operably coupled to a first power supply, and the second computing unit is operably coupled to a second power supply independent of the first power supply.

[0092] 12. A system as described in any of the preceding schemes, wherein the first computing unit or the second computing unit includes at least one of a central processing unit (CPU) module, a graphics processing unit (GPU) module and a vehicle control unit (VCU).

[0093] 13. A system as described in any of the preceding solutions, wherein the CPU module includes at least one of a CPU unit, a CPU mainboard, a storage unit, a power connector, a PCIe connector, and an Ethernet connector.

[0094] 14. The system according to any of the preceding solutions, wherein the GPU module comprises at least one of a GPU unit, a GPU carrier board, a power connector, a switch, a microcontroller, and an Ethernet connector.

[0095] 15. The system according to any of the preceding solutions, wherein a configuration of the first computing unit is substantially the same as a configuration of the second computing unit.

[0096] 16. The system according to any of the preceding solutions, further comprising a master timer configured to synchronize the first computing unit and the second computing unit.

[0097] 17. A system according to any preceding solution, wherein the first computing unit comprises a first vehicle control unit (VCU) operatively coupled to an electronic control unit (ECU) via a first VCU-ECU connection, and

[0098] The second computing unit includes a second VCU operatively coupled to the ECU via a second VCU-ECU connection, the second VCU-ECU connection being independent of the first VCU-ECU connection.

[0099] 18. The system of any preceding solution, wherein at least one of the first computing unit and the second computing unit is implemented on a blade module.

[0100] 19. The system according to any of the preceding solutions, wherein the system is configured as a blade server, the blade server comprising one or more blade modules, at least one of the first computing unit and the second computing unit being implemented on the blade module.

[0101] 20. A system according to any of the preceding solutions, wherein the system is configured as a blade server, the blade server comprising a plurality of blade modules, at least one of the first computing unit and the second computing unit being implemented on the blade module, and the plurality of blade modules being operably connected to each other via a backplane.

[0102] 21. The system according to any of the preceding solutions, wherein the system is expandable by at least one of: adding additional blade modules, replacing or removing one of the plurality of blade modules, or modifying the configuration of one of the plurality of blade modules.

[0103] 22. The system according to any of the preceding solutions, wherein at least one of the first computing unit and the second computing unit is implemented to include at least one of the following: a dynamic driving task (DDT) software (SW) module or a diagnostic monitoring SW module.

[0104] 23. A method for deploying an autonomous driving vehicle, comprising: receiving first information about the vehicle and the vehicle environment on a first computing unit, generating a first control command based on the first information, and transmitting the first control command to a controller of the vehicle to achieve autonomous operation of the vehicle; and receiving second information about the vehicle and the vehicle environment on a second computing unit, generating a second control command based on the second information, and in response to detecting a fault or failure of the first computing unit, transmitting the second control command to the vehicle to achieve autonomous operation of the vehicle.

[0105] 24. The method according to any preceding solution, wherein the first information is substantially identical to the second information.

[0106] 25. The method according to any preceding solution, wherein the first computing unit receives the first information and the second computing unit receives the second information substantially simultaneously.

[0107] 26. The method according to any of the aforementioned solutions further includes: (periodically or irregularly) comparing the first control command and the second control command on the VCU on the first computing unit or the second computing unit; and determining whether the difference between the first control command and the second control command exceeds a threshold.

[0108] 27. The method according to any of the above solutions further comprises: converting the first control command or the second control command into a control signal; and transmitting the control signal to an actuator of the vehicle through an ECU.

[0109] 28. The method according to any of the preceding solutions, wherein the control signal comprises at least one of an engine torque request, a brake request, and a steering wheel angle request.

[0110] 29. The method according to any of the preceding solutions further comprises: detecting that the first computing unit has failed or failed; and terminating the transmission of the first control command to the vehicle.

[0111] 30. A non-volatile computer-readable program storage medium storing code, which, when executed by a processor, enables the processor to implement a method for deploying an autonomous driving vehicle, the method comprising: receiving first information about the vehicle and the vehicle environment on a first computing unit, generating a first control command based on the first information, and transmitting the first control command to a controller of the vehicle to achieve autonomous operation of the vehicle; and receiving second information about the vehicle and the vehicle environment on a second computing unit, generating a second control command based on the second information, and in response to detecting a fault or failure of the first computing unit, transmitting the second control command to the controller of the vehicle to achieve autonomous operation of the vehicle.

[0112] 31. A system for deployment on an autonomous vehicle, comprising: a first computing unit as described in any of the above solutions herein, a second computing unit as described in any of the above claims; and a vehicle controller configured to receive a first control command from the first computing unit and a second control command from the second control unit, and selectively use the first control command or the second control command according to a redundancy rule.

[0113] 32. The system of any solution herein, wherein the redundancy rules specify a first control command as a default option and switching to a second control command in response to detecting a fault or failure in the first computing unit.

[0114] 33. The system according to any solution described herein further comprises a supervisory subsystem, wherein the supervisory subsystem is configured to: detect a malfunction or failure of both the first computing unit and the second computing unit; and activate an emergency maneuver.

[0115] 34. A system according to any solution herein, wherein the emergency maneuver includes stopping the vehicle, generating a notification, and transferring vehicle control to a third party. Various embodiments of this system solution are described throughout the text and Figures 1 to 12 All are described in.

[0116] It should be understood that a system for path planning and navigation control deployed on an autonomous vehicle (e.g., an autonomous truck) is disclosed herein, which provides a unique redundant solution to address failures in the operation of the main system. In one example aspect, the system achieves fail-safety by allowing multiple identical implementations to run independently of each other (e.g., independent hardware) while coordinating each other's processing (so that all systems issue the same path planning commands based on sensor inputs from vehicle sensors). At a specific moment, at least one system is configured to monitor for failures (e.g., deviations between different implementations or other operating scenarios) and instruct the vehicle to perform emergency maneuvers that can avoid road hazards. In another example aspect, since the main system and one or more backup systems may always provide path planning and control instructions to the vehicle controller, the switching between the main system and the redundant system is actually instantaneous. It should be further understood that the design of the system includes the use of a star topology for delay-sensitive data communications, and the use of a bus, switch, or multicast topology for configuration flexibility requirements. For example, sensor inputs are transmitted using multicast, and sensor data processing performed by multiple GPUs is communicated through dedicated point-to-point connections.

[0117] Although several embodiments are provided herein, it should be understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of this document. The present examples should be considered illustrative rather than restrictive, and are not intended to be limited to the details given herein. For example, various elements or components may be combined or integrated into other systems, and certain features may be omitted or not implemented.

[0118] In addition, the techniques, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of this document. Other items shown or described as coupled, directly coupled, or communicatively connected may be indirectly coupled or communicated electrically, mechanically, or otherwise through some interface, device, or intermediate component. Other variations, substitutions, and modified examples that can be identified by those skilled in the art may be implemented without departing from the spirit and scope disclosed herein.

[0119] The implementation of the subject matter and functional operations described in this patent document can be implemented by various systems, semiconductor devices, ultrasonic devices, digital electronic circuits, or computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents) or a combination thereof. The implementation of various aspects of the subject matter described in this specification can be implemented as one or more computer program products, for example, one or more computer program instruction modules encoded on a non-transient computer-readable medium, for being executed or controlling its operation by a data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a material combination that affects a machine-readable propagation signal, or a combination of one or more thereof. The term "data processing unit" or "data processing device" covers all devices, devices and machines for processing data, such as a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device can also include code to create an execution environment for a related computer program, such as code constituting a processor firmware, a protocol stack, a database management system, an operating system or one or more combinations thereof.

[0120] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language (including compiled or interpreted languages) and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a file portion that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to a related program, or in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program may be deployed to execute on a single computer, or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0121] The processes and logical operations described in this specification can be performed by one or more programmable processors executing one or more computer programs to implement functions by operating on input data and generating outputs. The processes and logical operations can also be performed by dedicated logic circuits, and the device can also be implemented as a dedicated logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0122] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include or be operably connected to receive data from or transfer data to one or more large-capacity storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, such as semiconductor storage devices (such as EPROM, EEPROM, and flash memory devices). The processor and memory can be supplemented or incorporated therein by dedicated logic circuits.

[0123] Although this patent document contains many specific details, these details should not be interpreted as limitations on the scope of any invention or what may be claimed, but rather should be viewed as descriptions of features of specific invention embodiments or portions. Certain features described in this patent document in the context of different embodiments or sections may also be implemented in combination in a single embodiment or a single section. Conversely, the various features described in the context of a single embodiment or section may also be implemented in multiple embodiments or multiple sections individually or in any suitable sub-combination. A feature or operation described in one embodiment or section may be combined with another feature or another operation in another embodiment or another section in any reasonable manner. In addition, although certain features may be described in the above description as acting in a particular combination or even initially claimed as such, in some cases, one or more features may be removed from the claimed combination, and the claimed combination may point to a sub-combination or a variation of a sub-combination.

[0124] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations must be performed in the particular order or order shown, or that all illustrated operations be performed to achieve the desired results. In addition, the separation of various system components in the embodiments described in this patent document should not be understood as requiring that all embodiments be so separated.

[0125] Only a few implementations and examples are described herein, and other implementations, enhancements, and variations may be made based on what is described and illustrated in this patent document.

Claims

1. A system deployed on an autonomous vehicle, include: The first computing unit is configured as follows: receiving first information about the vehicle and the environment of the vehicle, generating a first control command based on the first information, and transmitting the first control command to a controller of the vehicle to enable autonomous operation of the vehicle; as well as The second computing unit is configured as follows: receiving second information about the vehicle and the environment of the vehicle, generating a second control command based on the second information, and Only when a fault or failure of the first computing unit is detected, the second control command is transmitted to a controller of the vehicle to enable autonomous operation of the vehicle.

2. The system of claim 1, wherein the first information is substantially identical to the second information. 3 . The system of claim 1 , wherein the first information and the second information include the same sensor data acquired by at least one sensor.

4. The system of claim 3, wherein the at least one sensor comprises at least one of a camera, an audio sensor, a light detection and ranging (LiDAR) sensor, a radar sensor, and a navigation sensor.

5. The system according to claim 3, further comprising: include: a first sensor unit configured to receive a first portion of the sensor data from a first group of the at least one sensor; as well as A second sensor unit is configured to receive a second portion of the sensor data from a second group of the at least one sensor. 6 . The system of claim 5 , wherein the first sensor unit and the second sensor unit are implemented on a blade module.

7. The system of claim 6, wherein the blade module containing the first sensor unit and the second sensor unit comprises a front panel and a back panel, the front panel comprising at least one interface configured to facilitate communication between the first sensor unit and the second sensor unit and the at least one sensor; the back panel comprising at least one connector configured to facilitate communication between the first sensor unit and the second sensor unit and at least one of the first computing unit and the second computing unit.

8. The system according to claim 5, wherein the first sensor unit and the second sensor unit are respectively connected to independent power supplies.

9. The system according to claim 5, wherein The first sensor unit and the second sensor unit are operatively coupled to the first computing unit via a first sensor data interface, and The first sensor unit and the second sensor unit are operatively coupled to the second computing unit via a second sensor data interface independent of the first sensor data interface.

10. The system of claim 1, wherein at least one of the first information and the second information comprises an operating parameter of the vehicle.

11. The system of claim 1, wherein The first computing unit is operably coupled to a first power source, and The second computing unit is operably coupled to a second power supply independent of the first power supply.

12. The system of claim 1, wherein the first computing unit or the second computing unit comprises at least one of a central processing unit (CPU) module, a graphics processing unit (GPU) module, and a vehicle control unit (VCU).

13. The system of claim 12, wherein the CPU module comprises at least one of a CPU unit, a CPU main board, a memory unit, a power connector, a peripheral component interconnect express (PCIe) connector, and an Ethernet connector.

14. The system of claim 12, wherein the GPU module comprises at least one of a GPU unit, a GPU carrier board, a power connector, a switch, a microcontroller, and an Ethernet connector.

15. The system according to claim 1, wherein a configuration of the first computing unit is substantially the same as a configuration of the second computing unit.

16. The system of claim 1, further comprising a master timer configured to synchronize the first computing unit and the second computing unit.

17. The system of claim 1, wherein The first computing unit comprises a first vehicle control unit (VCU) operatively coupled to an electronic control unit (ECU) via a first VCU-ECU connection, and The second computing unit includes a second VCU operatively coupled to the ECU via a second VCU-ECU connection independent of the first VCU-ECU connection.

18. The system of claim 1, wherein at least one of the first computing unit and the second computing unit is implemented on a blade module.

19. The system of claim 1, wherein the system is configured as a blade server comprising one or more blade modules, at least one of the first computing unit and the second computing unit being implemented in the blade module.

20. The system of claim 1, wherein The system is configured as a blade server comprising a plurality of blade modules, at least one of the first computing unit and the second computing unit is implemented in the blade module, and The plurality of blade modules are operably connected to each other via a backplane.

21. The system of claim 20, wherein the system is expandable in at least one of the following ways: Add additional blade modules, replacing or removing one of the plurality of blade modules, and The configuration of one of the plurality of blade modules is modified.

22. The system of claim 1, wherein at least one of the first computing unit and the second computing unit is implemented with at least one of a dynamic driving task (DDT) software (SW) module and a diagnostic monitoring SW module.

23. A method for deploying an autonomous vehicle, include: On the first computing unit, receiving first information about the vehicle and the environment of the vehicle, generating a first control command based on the first information, and transmitting the first control command to a controller of the vehicle to enable autonomous operation of the vehicle; as well as On the second computing unit, receiving second information about the vehicle and the environment of the vehicle, generating a second control command based on the second information, and In response to detecting a fault or failure of the first computing unit, the second control command is transmitted to the vehicle to enable autonomous operation of the vehicle.

24. The method of claim 23, wherein the first information is substantially identical to the second information.

25. The method of claim 23, wherein receiving the first information at the first computing unit is substantially synchronized with receiving the second information at the second computing unit.

26. The method of claim 23, further comprising: include: Periodically comparing the first control command with the second control command on a VCU of the first computing unit or the second computing unit; as well as It is determined whether a difference between the first control command and the second control command exceeds a threshold.

27. The method of claim 23, further comprising: include: converting the first control command or the second control command into a control signal; as well as The control signal is transmitted to an actuator of the vehicle through the ECU.

28. The method of claim 27, wherein the control signal comprises at least one of an engine torque request, a brake request, or a steering wheel angle request.

29. The method of claim 23, further comprising: include: detecting that the first computing unit has failed or failed; as well as Transmitting the first control command to the vehicle is terminated.

30. A non-transitory computer-readable program storage medium having a code stored thereon, which, when executed by a processor, causes the processor to implement a method of deploying an autonomous vehicle, the method include: On the first computing unit, receiving first information about the vehicle and the environment of the vehicle, generating a first control command based on the first information, and transmitting the first control command to a controller of a vehicle to enable autonomous operation of the vehicle; And on the second computing unit, receiving second information about the vehicle and the environment of the vehicle, generating a second control command based on the second information, and In response to detecting a fault or failure of the first computing unit, the second control command is transmitted to a controller of the vehicle to enable autonomous operation of the vehicle.

31. A system deployed on an autonomous vehicle, include: A first computing unit as claimed in any preceding claim; A second computing unit as claimed in any preceding claim; as well as The vehicle controller is configured to receive a first control command from the first computing unit and a second control command from the second control unit, and selectively use the first control command or the second control command according to a redundancy rule.

32. The system of claim 31, wherein the redundancy rules specify the first control command as a default option and switching to the second control command in response to detecting a fault or failure of the first computing unit.

33. The system of claim 31 , further comprising a supervisory subsystem, wherein the supervisory subsystem is configured to detect that both the first computing unit and the second computing unit have failed or failed; and Activate emergency maneuver.

34. The system of claim 33, wherein the emergency maneuver includes stopping the vehicle, generating a notification, transferring control of the vehicle to a third party.

Images