A method and device for configuring computing resources

Abstract

The embodiment of the present application discloses a method and device for configuring computing power resources, which can be applied to the field of autonomous driving, and can be applied to smart cars, autonomous driving cars, connected cars, etc., including: any domain controller (DCU) of the vehicle receives computing power configuration data corresponding to the DCU sent by a cloud server or a host computer, and the computing power configuration data includes the preset configuration quantity of each type of processor (including processor cores) in the DCU. The DCU resets the target processor in the DCU according to the computing power configuration data, and processes the perception information based on the reset target processor when the perception information collected by the vehicle falls within the processing scope of the DCU. The computing power configuration data supports updates via near-end upgrades (UDS) or remote upgrades (OTA). The computing power configuration data can be updated on demand to adjust the computing power resources in the DCU, saving computing power resources while ensuring the smooth operation of the business, and avoiding the situation where the corresponding computing power configuration data of the DCU can only be solidified in the eFuse and cannot be modified when it leaves the factory.

Description

Technical Field

[0001] The present application relates to the field of autonomous driving, and in particular to a method and device for configuring computing resources. Background Art

[0002] Since its invention, the automobile has undergone over a century of development and has become an indispensable part of people's lives. With rising living standards, people's demands for travel comfort and convenience have become increasingly stringent, leading to the evolution of automobiles towards intelligence. With the advent of autonomous driving, the need to implement multi-sensor access, fusion, perception, positioning, and regulation requires substantial hardware computing power. The existing distributed computing architecture, where each function corresponds to a single electronic control unit (ECU), is no longer adequate. For example, data from GPS, cameras, lidar, millimeter-wave radar, and wheel speed sensors (also known as perception information) must be processed within a single computing center to ensure optimal output for autonomous driving. Consequently, centralized domain control units (DCUs) and multi-domain controllers (MDCs) have become a growing trend.

[0003] The processors for autonomous driving usually include a multi-core central processing unit (CPU), a graphics processing unit (GPU), a video processing unit (VPU), a neural network processing unit (NPU), a tensor processing unit (TPU), a digital signal processing (DSP) unit, an image signal processing (ISP) unit, an AI core, a vector core, etc. A DCU may include one or more of the above processors (a processor core is also considered a processor). Figure 1The DCU shown includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. When the structure of a DCU is fixed, the types of processors and the number of processors of each type included in the DCU are also fixed. Since the computing power resources of each type of processor are determined by the processor structure itself, the computing power resources of the corresponding processor can be roughly estimated based on the processor type and structure. Therefore, before the DCU leaves the factory, the total number of processors of each type included in the DCU is burned into the eFuse in the DCU as computing power configuration data, as shown in the figure below. Figure 1 The x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores are the computing power configuration data.

[0004] The above-mentioned computing power resource configuration method configures all processors (including processor cores) in the DCU. This is because it is impossible to accurately estimate the computing power required for subsequent different autonomous driving functions before the DCU leaves the factory, and it can only be burned and configured according to the maximum computing power resources. However, in the actual application of the DCU, such a large computing power resource may not be needed, resulting in a waste of resources; secondly, the computing power configuration data is burned into the eFuse, and the eFuse is a one-time programmable memory and cannot be changed later. Summary of the Invention

[0005] An embodiment of the present application provides a method and device for configuring computing power resources. The computing power configuration data in this method can be sent by a host computer providing unified diagnostic services (UDS) during a local upgrade or by a cloud server providing over the air (OTA) during a remote upgrade, and is used to adjust the DCU computing power resources by adjusting the computing power configuration data on demand.

[0006] Based on this, the embodiments of the present application provide the following technical solutions:

[0007] In a first aspect, an embodiment of the present application first provides a method for configuring computing resources, which can be applied to the field of autonomous driving, and can be applied to smart cars, autonomous driving cars, connected cars, etc. The method includes: first, a DCU receives first computing power configuration data corresponding to the DCU sent by a host computer or a cloud server. The DCU is any DCU on the vehicle, and the DCU includes at least one processor. The first computing power configuration data includes a preset configuration number of each type of processor in the DCU. The preset configuration number can be set based on the historical computing power resource consumption of the DCU and the specific circumstances of the DCU's running business. It should be noted that since the various types of processors included in the DCU can be multi-core processors, for example, each type of processor may also include multiple CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc., in some embodiments, the number of cores within each type of processor can also be configured. That is, in some embodiments of the present application, the processor can refer to not only ordinary CPUs, GPUs, etc., but also processor cores, i.e., the various cores mentioned above. For ease of understanding, in the embodiments of the present application, ordinary processors and processor cores are collectively referred to as processors. In addition, the operating main frequency of each type of processor can also be configured in the computing power configuration data, without specific limitation. That is, the computing power configuration data can be characterized by configuring the number of processors of each type in the DCU, the processor operating main frequency, and the number of cores in the processor. After the DCU receives the first computing power configuration data corresponding to the DCU sent by the host computer or cloud server, it can reset the corresponding processor in the DCU (which can be called the target processor) according to the first computing power configuration data, thereby obtaining the reset target processor.

[0008] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is a DCU, the first computing power configuration data supports the upper computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, avoiding the situation where the corresponding computing power configuration data of the DCU can only be solidified in the eFuse and cannot be modified when it leaves the factory, and enhancing the adaptability to the ever-changing subsequent driving business scenarios.

[0009] In a possible design of the first aspect, after the DCU de-resets the target processor within the DCU based on the first computing power configuration data, when the autonomous driving vehicle collects perception information through sensors and the perception information falls within the processing scope of the DCU, the DCU processes the collected perception information based on the target processor obtained after the de-reset.

[0010] In the above-mentioned embodiments of the present application, the DCU can process corresponding perception information based on the target processor after reset, and the perception information reflects the driving business scenario. Therefore, the embodiments of the present application can enhance the adaptability of the ever-changing driving business scenario.

[0011] In a possible design of the first aspect, regardless of whether the first computing power configuration data is sent by the host computer or the cloud server, the first computing power configuration data can be included in a target file (which may be called a first file), and then the first file is sent to the DCU by the host computer or the cloud server.

[0012] In the above-mentioned embodiment of the present application, it is specifically explained that the first computing power configuration data can be included in the first file, so that a one-to-one correspondence between each independent DCU and the first computing power configuration data is achieved, which is convenient for control and management and has feasibility.

[0013] In one possible design of the first aspect, the first file is an encrypted file. It should be noted that the encryption method for the first file can be symmetric encryption, i.e., the same key is used for encryption and decryption; or asymmetric encryption, i.e., asymmetric encryption requires two keys, namely a public key and a private key. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, it can only be decrypted with the corresponding public key. In the embodiments of the present application, the encryption method is not limited.

[0014] In the above-mentioned embodiment of the present application, the first file may be an encrypted file to prevent the first computing power configuration data from being modified at will, thereby improving the security of the data.

[0015] In a possible design of the first aspect, the first file can be a license file of the DCU (each DCU has a license file), or a file defined by the user in advance, or some files in the diagnostic service or OTA related software update package. The type and format of the first file are not specifically limited here.

[0016] In the above-mentioned implementation of the present application, the user can choose what type of file to include the first computing power configuration data in according to needs, which has flexibility and selectivity.

[0017] In a possible design of the first aspect, the DCU can also perform a validity check on the first computing power configuration data, and if the first computing power configuration data passes the validity check, the target processor in the DCU is reset according to the first computing power configuration data. For example, the validity check can specifically be: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether there is a jump or tampering with the first computing power configuration data; whether the first computing power configuration data has integrity; when the first computing power configuration data is included in the encrypted first file, checking whether the encryption process of the first file is abnormal and whether the encrypted first file can be decrypted; checking whether the data value range of the first computing power configuration data is within the normal range, etc. For example, the DCU has a total of 4 CPUs, and the number of CPUs in the first computing power configuration data is 5, then the data value range is not within the normal range. Only when the first computing power configuration data passes the validity check, the DCU resets the corresponding target processor in the DCU according to the first computing power configuration data.

[0018] In the above-mentioned embodiment of the present application, before the DCU resets the corresponding target processor in the DCU according to the first computing power configuration data, it is also necessary to perform a validity check on the first computing power configuration data, so as to prevent erroneous and illegal data from entering the service, or to detect data errors in a timely manner.

[0019] In a possible design of the first aspect, when the DCU receives the first computing power configuration data, the first computing power configuration data is backed up at a first moment to obtain first backup data, and the first computing power configuration data and the first backup data are respectively stored in different storage modules in the DCU, such as, respectively stored in different storage media in the DCU or different blocks in the same storage medium.

[0020] In the above-mentioned implementation manner of the present application, the DCU may also perform redundant backup of the received first computing power configuration data to improve the storage reliability of the data.

[0021] In a possible design of the first aspect, after the DCU stores the first computing power configuration data and the first backup data in different storage modules within the DCU respectively, the DCU can also periodically determine whether the second computing power configuration data and the second backup data are consistent. The second computing power configuration data is the computing power configuration data at the current moment, and the second backup data is the backup data at the current moment. When the second computing power configuration data and the second backup data are inconsistent, the DCU verifies and aligns the second computing power configuration data and the second backup data. For example, assuming that the setting period is 2 hours, assuming that the DCU receives the first computing power configuration data and stores the first computing power configuration data and the first backup data in the storage module 1 and storage module 2 in the DCU respectively at the first time 8:00, when the time is 10:00, the DCU will determine whether the first computing power configuration data in the storage module 1 at the current time 10:00 (the first computing power configuration data at the current time can be called the second computing power configuration data) and the first backup data in the storage module 2 at the current time 10:00 (the first backup data at the current time can be called the second backup data) are consistent. If the second computing power configuration data is inconsistent with the second backup data, the DCU verifies and aligns the second computing power configuration data and the second backup data so that the second computing power configuration data and the second backup data are consistent with the first computing power configuration data.

[0022] In the above-mentioned embodiment of the present application, the DCU can also periodically check and verify the first computing power configuration data and the first backup data in different storage modules within the DCU. The purpose of the check and verification is to ensure the accuracy of the first computing power configuration data, and at the same time, when data errors occur, they can be discovered and corrected in time.

[0023] In the second aspect, the embodiment of the present application first provides a method for configuring computing power resources, which can be applied to the field of autonomous driving, and can be applied to smart cars, autonomous driving cars, connected cars, etc. The method includes: first, the MDC receives third computing power configuration data corresponding to the MDC sent by the host computer or cloud server through the main DCU in the MDC, and the MDC is any MDC on the vehicle (generally, one MDC is deployed for one vehicle, and when the vehicle is only deployed with one MDC, the MDC is this MDC). The MDC includes multiple DCUs, wherein the main DCU is any one of the multiple DCUs, and each DCU includes at least one processor (such as a CPU). The third computing power configuration data includes the preset configuration number of each type of processor in each DCU in the MDC. After the MDC receives the third computing power configuration data from the host computer or cloud server through the main DCU, it can further send the third computing power configuration data to other DCUs in the first DMC except the main DCU. After each DCU in the MDC obtains the third computing power configuration data, each DCU will reset the target processor in its own DCU according to the third computing power configuration data obtained, and obtain the reset target processor.

[0024] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is MDC, the third computing power configuration data supports the host computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, and solving the problem that the existing solution can only configure the computing power resources of this DCU but cannot support the combined application scenarios of MDC composed of multiple DCUs.

[0025] In a possible design of the first aspect, after each DCU in the MDC resets the target processor in the MDC based on the third computing power configuration data received by each of them, when the autonomous driving vehicle collects perception information through sensors and the perception information falls within the processing scope of the MDC, the MDC processes the collected perception information based on the target processor obtained after the above-mentioned reset.

[0026] In the above-mentioned embodiments of the present application, the corresponding perception information can also be processed based on the target processor after reset. The perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of the ever-changing driving business scenario.

[0027] In a possible design of the second aspect, regardless of whether the third computing power configuration data is sent by the host computer or the cloud server, the third computing power configuration data can be included in a target file (which may be called a second file), and then the host computer or the cloud server sends the second file to the DCU.

[0028] In the above-mentioned embodiment of the present application, it is specifically explained that the third computing power configuration data can be included in the second file, so that a one-to-one correspondence between each independent MDC and the third computing power configuration data is achieved, which is convenient for control and management and has feasibility.

[0029] In one possible design of the second aspect, the second file is an encrypted file. It should be noted that the encryption method for the second file can be symmetric encryption, i.e., the same key is used for encryption and decryption; or asymmetric encryption, i.e., asymmetric encryption requires two keys, namely a public key and a private key. If the public key is used to encrypt the data, it can only be decrypted using the corresponding private key. If the private key is used to encrypt the data, it can only be decrypted using the corresponding public key. In the embodiments of the present application, the encryption method is not limited.

[0030] In the above-mentioned embodiment of the present application, the second file may be an encrypted file to prevent the third computing power configuration data from being modified at will, thereby improving the security of the data.

[0031] In a possible design of the second aspect, the second file can be the license file of the MDC (each MDC has a license file), or it can be a file defined by the user in advance, or it can be some files in the diagnostic service or OTA related software update package. The type and format of the second file are not specifically limited here.

[0032] In the above-mentioned implementation of the present application, the user can choose what type of file to include the third computing power configuration data in according to needs, which has flexibility and selectivity.

[0033] In a possible design of the second aspect, the MDC can also perform a validity check on the third computing power configuration data through multiple DCUs in the MDC, and when each third computing power configuration data passes the validity check, each DCU can reset the target processor in its own DCU according to the third computing power configuration data. For example, the validity check can specifically include: verifying whether the third computing power configuration data is the computing power configuration data corresponding to the MDC; verifying whether there is a jump or tampering with the third computing power configuration data; whether the third computing power configuration data has integrity; when the third computing power configuration data is included in the encrypted second file, verifying whether the encryption process of the second file is abnormal and whether the encrypted second file can be decrypted; verifying whether the data value range of the third computing power configuration data is within the normal range, etc. Only when the third computing power configuration data passes the validity check, each DCU in the MDC resets the corresponding target processor in its own DCU according to its own third computing power configuration data.

[0034] In the above-mentioned embodiment of the present application, before each DCU in the MDC resets the corresponding target processor in its own DCU according to its own third computing power configuration data, it is also necessary to perform a validity check on the third computing power configuration data, so as to prevent erroneous and illegal data from entering the service, or to detect data errors in a timely manner.

[0035] In a possible design of the second aspect, the MDC can also periodically determine through the main DCU whether the fourth computing power configuration data in each DCU within multiple DCUs at the current moment are consistent. If there is inconsistency among the fourth computing power configuration data, the main DCU can verify and align the fourth computing power configuration data. For example, assume that the MDC includes three DCUs, namely DCU1, DCU2, and DCU3, and the setting cycle is 1 hour. Assume that the MDC receives the third computing power configuration data through DCU1 (i.e., the main DCU) and sends the third computing power configuration data to DCU2 and DCU3, and DCU1, DCU2, and DCU3 respectively store their respective third computing power configuration data in their respective storage modules at the first time 7:30. When the time is 8:30, DCU1 will obtain the third computing power configuration data on DCU2 and DCU3, and determine whether the third computing power configuration data in DCU1 at the current time 8:30 and the third computing power configuration data in DCU2 and DCU3 at the current time 8:30 (the third computing power configuration data in each DCU at the current time can be called the fourth computing power configuration data) are consistent. If the fourth computing power configuration data in each DCU is inconsistent, the MDC verifies and aligns the fourth computing power configuration data in each DCU through the main DCU, so that the fourth computing power configuration data in each DCU remains consistent.

[0036] In the above-mentioned embodiment of the present application, the MDC can also periodically check and verify the third computing power configuration data stored in each of the different DCU storage modules within the MDC. The purpose of the check and verification is to ensure the accuracy of the third computing power configuration data, and at the same time, when data errors occur, they can be discovered and corrected in a timely manner.

[0037] A third aspect of the present application provides a DCU, which can be used in smart cars, self-driving cars, connected cars, and the like. The DCU has the functionality to implement the method described in the first aspect or any possible implementation of the first aspect. This functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functionality.

[0038] A fourth aspect of the present application provides an MDC, which can be applied to smart cars, self-driving cars, connected cars, and the like. The MDC has the function of implementing the method of the second aspect or any possible implementation of the second aspect. This function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions.

[0039] A fifth aspect of an embodiment of the present application provides a DCU, which may include a memory, a processor, and a bus system, wherein the memory is used to store programs, and the processor is used to call the programs stored in the memory to execute the method of the first aspect of the embodiment of the present application or any possible implementation method of the first aspect.

[0040] In a sixth aspect of an embodiment of the present application, an MDC is provided, which may include a memory, a DCU, and a bus system, wherein the DCU includes a processor, the memory is used to store programs, and the processor is used to call the programs stored in the memory to execute the method of the second aspect of the embodiment of the present application or any possible implementation of the second aspect.

[0041] In a seventh aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, the computer can execute the method of the above-mentioned first aspect or any possible implementation of the first aspect, or the computer can execute the method of the above-mentioned second aspect or any possible implementation of the second aspect.

[0042] An eighth aspect of an embodiment of the present application provides a computer program which, when run on a computer, enables the computer to execute the method of the above-mentioned first aspect or any possible implementation of the first aspect, or enables the computer to execute the above-mentioned second aspect or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A schematic diagram of the types of processors included in a DCU and the number of processors of each type;

[0044] Figure 2 A schematic diagram of the architecture of a distributed automotive ECU provided in an embodiment of the present application;

[0045] Figure 3 A schematic diagram of the architecture of an automotive DCU provided in an embodiment of the present application;

[0046] Figure 4 A schematic diagram of the architecture of an automotive MDC provided in an embodiment of the present application;

[0047] Figure 5 A flowchart showing the configuration of computing resources currently used in vehicles;

[0048] Figure 6 A schematic diagram of the structure of an autonomous driving vehicle provided in an embodiment of the present application;

[0049] Figure 7 A flowchart of a method for configuring computing resources provided in an embodiment of the present application;

[0050] Figure 8 A schematic diagram of a host computer according to an embodiment of the present application sending corresponding first computing power configuration data to a DCU in an autonomous driving vehicle via a CAN bus;

[0051] Figure 9 A schematic diagram of a cloud server according to an embodiment of the present application sending corresponding first computing power configuration data to a DCU in an autonomous driving vehicle via wireless communication;

[0052] Figure 10 Another flowchart of the method for configuring computing resources provided in an embodiment of the present application;

[0053] Figure 11 A schematic diagram of an MDC provided in an embodiment of the present application;

[0054] Figure 12 A schematic diagram of a host computer according to an embodiment of the present application sending corresponding third computing power configuration data to an MDC in an autonomous driving vehicle via a CAN bus;

[0055] Figure 13 A schematic diagram of a cloud server according to an embodiment of the present application sending corresponding third computing power configuration data to an MDC in an autonomous driving vehicle via wireless communication;

[0056] Figure 14 A flowchart of the specific configuration process of computing resources provided in the embodiment of the present application;

[0057] Figure 15 A schematic diagram of the structure of a DCU provided in an embodiment of the present application;

[0058] Figure 16 A schematic diagram of the structure of the MDC provided in an embodiment of the present application;

[0059] Figure 17 A schematic diagram of the structure of the device (DCU or MDC) provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] An embodiment of the present application provides a method and device for configuring computing power resources. The computing power configuration data in this method can be sent by a host computer providing unified diagnostic services (UDS) during a local upgrade or by a cloud server providing over the air (OTA) during a remote upgrade, and is used to adjust the DCU computing power resources by adjusting the computing power configuration data on demand.

[0061] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0062] The embodiments of this application involve a lot of knowledge related to computing power. In order to better understand the solutions of the embodiments of this application, the following first introduces the relevant terms and concepts that may be involved in the embodiments of this application. It should be understood that the interpretation of related concepts may be limited by the specific circumstances of the embodiments of this application, but it does not mean that this application is limited to this specific situation. The specific circumstances of different embodiments may also vary, and are not specifically limited here.

[0063] (1) Electronic control unit (ECU)

[0064] ECU is also known as driving computer, on-board computer, etc. In terms of usage, it is a microcomputer controller for automobiles, also called automobile-specific single-chip microcomputer. Like ordinary computers, it is composed of a microprocessor (microcontroller unit, MCU), read-only memory (ROM), random access memory (RAM), input / output interface (I / O), analog-to-digital converter (A / D), and large-scale integrated circuits such as shaping and driving. At the beginning, ECU was relatively simple in structure and was mainly used to control the operation of the generator. Later, with the development of vehicle electrification, ECU gradually occupied the entire vehicle, from anti-lock braking system, four-wheel drive system, electronically controlled automatic transmission, active suspension system, airbag system, etc., gradually extending to various safety, network, entertainment, sensor control, powertrain, vehicle motion system, etc. of the current vehicle body. There may be dozens or hundreds of ECUs on the whole vehicle, for example, ECU used on the engine, ECU used on the anti-lock braking system, etc. Figure 2 As shown, Figure 2 This is a schematic diagram of the architecture of a distributed automotive ECU provided in an embodiment of the present application. The functions of each ECU are relatively independent. With the development of digital cars, especially autonomous driving technology, the ECUs on cars are gradually becoming more complex and tend to be concentrated in a super ECU.

[0065] (2) Domain Control Unit (DCU)

[0066] DCU divides the vehicle into several domains, such as powertrain, vehicle safety, body electronics, smart cockpit, and smart driving, based on the functions of automotive electronic components. It uses processors with stronger processing power, such as multi-core CPUs and GPUs, to relatively centrally control each domain, replacing the current distributed automotive electronic architecture. Figure 3 As shown, Figure 3 This is a schematic diagram of the architecture of an automotive DCU provided in an embodiment of the present application. Generally speaking, one DCU is used to control one domain.

[0067] The reason for the emergence of DCU is to integrate functional classification control, reduce line speed, modularize the automobile control system, and use high-speed in-vehicle Ethernet to exchange data between different DCUs. What is being discussed here are single independently working DCUs.

[0068] (3) Multi-domain controller (MDC)

[0069] As the degree of automotive automation continues to improve, data exchange between some control domains is becoming increasingly frequent, requiring higher real-time performance. For example, the autonomous driving module needs to detect the vehicle's speed in real time and adjust and control it according to the autonomous driving strategy in real time. This requires the calculation to be completed within a high-performance domain controller. Therefore, a controller containing multiple domains, namely MDC, has emerged. Figure 4 As shown, Figure 4 This is a schematic diagram of the architecture of an automotive MDC provided in an embodiment of the present application. For example, the zFAS jointly developed by Audi and Delphi uses a single ECU to access sensory information collected by various sensors, analyze and process it, and ultimately issue control commands. Generally speaking, an MDC is composed of multiple DCUs, one of which serves as the master DCU, responsible for sending commands to other DCUs within the MDC for data exchange.

[0070] (4) Computing power

[0071] Computing power is usually used to estimate the execution capability of a processor (such as a CPU) and is usually measured in units of the number of computing operations that can be performed per second, such as "tera operations per second (TOPS)", "floating-point operations per second (FLOPS)", "million instructions per second (MIPS)", etc. For example, 1 TOPS means that the processor can perform one trillion (10^12) operations per second.

[0072] (5) Computing power configuration data

[0073] In the embodiment of the present application, if it is a single independently working DCU, the computing power configuration data described in the present application refers to the preset configuration quantity of each type of processor in the DCU. Figure 1For example, assuming that the DCU includes a total of x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. Since the computing power resources of each type of processor are determined by the processor's own structure, the computing power resources of the corresponding processor can be roughly estimated based on the processor type and structure. Assume that the preset configuration number of each type of processor in the DCU is x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, where 0≤x0≤x+1, 0≤y0≤y+1, 0≤m0≤x+1, and 0≤n0≤y+1. Then, during the operation of the DCU, only x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores participate, and the remaining processors are in a dormant state. Therefore, based on these x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, the computing power resources of the DCU during operation can be roughly estimated. When the preset configuration number of a processor is 0, it means that the processor does not participate in the operation of the DCU.

[0074] It should be noted that in the embodiment of the present application, how to preset the number of processor configurations of each type in the DCU can be estimated based on the computing power resources consumed by the historical operation of the DCU, thereby ensuring the normal operation of the DCU and saving computing power resources.

[0075] It should also be noted that since the various types of processors included in the DCU can be multi-core processors, for example, each type of processor may also include multiple CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc., in some implementations, the number of Cores within each type of processor can also be configured. In addition, the operating main frequency of each type of processor can also be configured in the computing power configuration data, without specific limitation. That is, by configuring the number of processors of each type in the DCU, the main frequency of the processor and the number of Cores in the processor, participating in specific autonomous driving services, the controllable configuration capability of computing power resources in the DCU is realized.

[0076] Similarly, in the embodiments of the present application, if a single, independently operating MDC is used, the computing power configuration data described herein refers to the preset number of processors of each type in each DCU within the MDC. The method for presetting the number of processors of each type in each DCU within the MDC is similar to the method for presetting the number of processors of each type in the DCU described above and is not further described here.

[0077] (6) Host computer

[0078] The host computer refers to a computer device that can directly issue control commands. In the embodiment of the present application, any computer device that can communicate with the ECU, DCU or MDC based on the unified diagnostic service protocol (UDS) can be called a host computer (also called a diagnostic instrument, diagnostic machine, diagnostic tool, etc.). For example, personal computers (PCs), mobile phones, tablet computers and other smart handheld terminal devices, as well as smart wearable devices such as smart bracelets and smart watches, and even single-chip microcomputers, as long as the device can run the corresponding diagnostic software and can communicate with the ECU, DCU or MDC based on the UDS protocol can be used as the host computer in the embodiment of the present application, and the specific details are not limited here.

[0079] (7) Unified Diagnosis Service (UDS)

[0080] In the automotive electrical electronics field, diagnostics are a fundamental function of ECUs / DCUs / MDCs. They support software or firmware updates for ECUs / DCUs / MDCs.

[0081] The development, adaptation, implementation, and maintenance of different diagnostic communication protocols incur unnecessary costs for vehicle manufacturers, system suppliers, and ECU / DCU / MDC vendors. To address this issue, the various technical protocols and data communication principles have been compiled into an international ISO standard, commonly known as UDS (also known as ISO 14229-1). UDS is a universal automotive diagnostic protocol that is data link-independent. Table 1 lists the protocols used at each layer of the Open System Interconnection (OSI) model. UDS targets the application layer of the OSI model and can be implemented on various automotive buses (such as CAN, LIN, Flexray, Ethernet, and K-line). Currently, most automakers use the UDS on CAN diagnostic protocol. This means using a device (generally referred to as a host computer) to analyze the information and data within the vehicle's ECU / DCU / MDC. This device communicates with the ECU / DCU / MDC using UDS (though this is not the only method).

[0082] Table 1: Protocols used at each layer of the OSI model

[0083] OSI layers Protocol Type Application Layer ISO 14229-1 (UDS) Presentation Layer --- Session layer ISO 15765-3 Transport layer ISO 15765-2 Network layer ISO 15765-2 Data Link Layer ISO 11898-1 Physical layer ISO 11898

[0084] UDS is essentially a series of diagnostic services. The diagnostic services defined by UDS can be called standard diagnostic services. There are 26 standard diagnostic services in 6 categories. Each standard diagnostic service has its own independent service identifier (SID). SID is essentially a directional communication and an interactive protocol. That is, the host computer sends a specified diagnostic request to the ECU / DCU / MDC. This request needs to include the SID. If it is a positive response, the ECU / DCU / MDC returns [SID+0x40] to the host computer. For example, if the SID of the diagnostic request sent is 0x10, the positive response is 0x50. If it is a negative response, the ECU returns 0x7F+SID+NRC to the host computer, which is a statement. The full name of NRC is Negative Response Code. That is, if the ECU rejects a request, it will return an NRC to the host computer. Different diagnostic services may contain different NRCs, and different NRCs have different meanings.

[0085] Therefore, the diagnostic communication process based on UDS is: the host computer sends a diagnostic request to the ECU / DCU / MDC, and the ECU / DCU / MDC gives a diagnostic response. The diagnostic response includes positive response and negative response. UDS defines a unified protocol format for the request and response of different diagnostic services.

[0086] (8) Over the air (OTA)

[0087] OTA (Over-the-Air) refers to the process of downloading new software update packages from a remote server (also known as a cloud server) over the Internet to upgrade the system. This means that in addition to being supported by diagnostic functions (local updates), software or firmware updates for ECUs, DCUs, and MDCs can also be performed remotely via OTA (remote updates).

[0088] In the smart car sector, traditional vehicles have experienced systemic defects during user driving verification. The only solution to these problems is for the car manufacturer to initiate a recall program, requiring users to return to the factory for a unified system upgrade. OTA technology, however, can remotely fix defects via data packets, avoiding the risks of months-long factory recalls. Furthermore, thanks to advanced hardware design, smart car operating systems can continuously unlock new features for owners through repeated OTA upgrades, optimizing the product experience, enabling rapid iteration, and providing higher-quality system services.

[0089] (9) Processor

[0090] In the embodiment of the present application, the processor may refer to a processor in the traditional sense such as a CPU, GPU, NPU, or may refer to one or more CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc. included in a traditional processor. The arithmetic unit, instruction fetch and decoding hardware, instruction pipeline, and some cache memory are integrated into the "Core" described in the present application. The Core may also be referred to as a core. In the embodiment of the present application, since the various types of processors included in the DCU may be multi-core processors, for example, each type of processor may also include multiple CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc., that is, in the example of the present application, in addition to ordinary CPUs, GPUs, and other processors, the processor may also refer to processor cores, i.e., the various Cores mentioned above. For ease of understanding, in the embodiment of the present application, ordinary processors and processor cores are collectively referred to as processors.

[0091] In addition, before introducing the embodiments of the present application, a brief introduction is first given to the configuration method of computing resources currently used in vehicles, so that it is easier to understand the embodiments of the present application later.

[0092] Specific as Figure 5 As shown, it is assumed that the processor types and quantities included in the DCU are m+1 CPUs, n+1 AI Cores, k+1 Vector Cores, and one eFuse, where the m+1 CPUs are CPU0, CPU1, ..., CPU m , these n+1 AICores are AI Core0, AI Core1, ..., AI Core n , these k+1 Vector Cores are Vector Core0, Vector Core1, ..., Vector Core k Before the DCU leaves the factory, the total number of processors of each type in the DCU (i.e., m+1 CPUs, n+1 AI Cores, and k+1 Vector Cores) is burned into the eFuse as computing power configuration data. When the DCU is powered on, one of the CPUs (for example, CPU0) is selected as the main CPU. After the main CPU initializes the relevant peripherals, it reads the computing power configuration data from the eFuse and then resets the other CPUs, AI Cores, and Vector Cores based on the read computing power configuration data, allowing each other processor to complete its own initialization. In this way, when the DCU is running, all processors in the DCU are called up to process relevant business data.

[0093] Due to the complexity of autonomous driving application scenarios, the DCU cannot fully determine the computing power resources required for subsequent autonomous driving functions and the specific configuration quantity of each processor before leaving the factory. The current computing power configuration solution, which burns the computing power configuration data into the eFuse, can only be burned and configured according to the maximum computing power resources. However, in the actual application of the DCU, such a large computing power resource may not be needed, resulting in a waste of resources. In addition, the computing power configuration data is burned into the eFuse, which is a one-time programmable memory and cannot be changed later.

[0094] Based on this, in order to solve the above-mentioned problems, the embodiment of the present application first provides a configuration method for computing power resources. The computing power configuration data in this method can be sent by the host computer providing UDS during local upgrade or by the cloud server providing OTA during remote upgrade, and is used to adjust the DCU computing power resources by adjusting the computing power configuration data on demand.

[0095] The embodiments of the present application are described in detail below with reference to the accompanying drawings. Those skilled in the art will appreciate that, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0096] The computing resource configuration method provided in the embodiments of the present application can be applied to scenarios where motion planning (e.g., speed planning, driving behavior decision-making, global path planning, etc.) is performed on intelligent entities (e.g., smart cars, self-driving cars, connected cars, etc.) for various intelligent driving (e.g., unmanned driving, assisted driving, etc.). Taking the intelligent entity as an autonomous driving vehicle as an example, the specific functions of each structure within the autonomous driving vehicle are introduced. For details, please refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of an autonomous vehicle provided in an embodiment of the present application. Autonomous vehicle 100 is configured for a fully or partially autonomous driving mode. For example, autonomous vehicle 100 can control itself while in autonomous driving mode and can determine, through human operation, the current state of the vehicle and its surrounding environment, the possible behavior of at least one other vehicle in the surrounding environment, and the confidence level corresponding to the likelihood that the other vehicle will perform the possible behavior, and control autonomous vehicle 100 based on the determined information. While autonomous vehicle 100 is in autonomous driving mode, it can also be set to operate without human interaction.

[0097] The autonomous vehicle 100 may include various subsystems, such as a travel system 102, a sensor system 104 (e.g., cameras, SICK, lidar, etc. are modules in the sensor system 104), a control system 106, one or more peripheral devices 108, a power supply 110, a computer system 112, and a user interface 116. Optionally, the autonomous vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. In addition, each subsystem and component of the autonomous vehicle 100 may be interconnected via wired or wireless connections.

[0098] Propulsion system 102 may include components that provide powered motion for autonomous vehicle 100 .

[0099] In one embodiment, travel system 102 may include engine 118 , energy source 119 , transmission 120 , and wheels / tires 121 .

[0100] The engine 118 may be an internal combustion engine, an electric motor, an air compression engine, or a combination of other types of engines, such as a hybrid engine consisting of a gasoline engine and an electric motor, or a hybrid engine consisting of an internal combustion engine and an air compression engine. The engine 118 converts the energy source 119 into mechanical energy. Examples of the energy source 119 include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electricity. The energy source 119 may also provide energy for other systems of the autonomous vehicle 100. The transmission 120 may transmit the mechanical power from the engine 118 to the wheels 121. The transmission 120 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission 120 may also include other devices, such as a clutch. The drive shaft may include one or more shafts that can be coupled to one or more wheels 121.

[0101] The sensor system 104 may include several sensors that sense information about the environment surrounding the autonomous vehicle 100. For example, the sensor system 104 may include a positioning system 122 (the positioning system may be a global positioning GPS system, or a Beidou system or other positioning system), an inertial measurement unit (IMU) 124, a radar 126, a laser rangefinder 128, and a camera 130. The sensor system 104 may also include sensors of the internal systems of the monitored autonomous vehicle 100 (for example, an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). The sensing data from one or more of these sensors can be used to detect objects and their corresponding characteristics (position, shape, direction, speed, etc.). This detection and recognition is a key function for the safe operation of the autonomous autonomous vehicle 100. In the embodiment of the present application, the laser perception module is a very important perception module in the sensor system 104.

[0102] Among them, the positioning system 122 can be used to estimate the geographic location of the autonomous vehicle 100. The IMU 124 is used to sense changes in the position and orientation of the autonomous vehicle 100 based on inertial acceleration. In one embodiment, the IMU 124 can be a combination of an accelerometer and a gyroscope. The radar 126 can use radio signals to sense objects in the surrounding environment of the autonomous vehicle 100. Specifically, it can be manifested as a millimeter wave radar or a lidar. In some embodiments, in addition to sensing objects, the radar 126 can also be used to sense the speed and / or direction of movement of objects. The laser rangefinder 128 can use lasers to sense objects in the environment in which the autonomous vehicle 100 is located. In some embodiments, the laser rangefinder 128 may include one or more laser sources, a laser scanner, and one or more detectors, among other system components. The camera 130 can be used to capture multiple images of the surrounding environment of the autonomous vehicle 100. The camera 130 can be a still camera or a video camera.

[0103] Control system 106 controls the operation of autonomous vehicle 100 and its components. Control system 106 may include various components, including a steering system 132 , a throttle 134 , a brake unit 136 , a computer vision system 140 , a lane control system 142 , and an obstacle avoidance system 144 .

[0104] Among them, the steering system 132 is operable to adjust the forward direction of the autonomous driving vehicle 100.

[0105] For example, in one embodiment, the system may be a steering wheel. The throttle 134 is used to control the speed of the engine 118 and, in turn, the speed of the autonomous vehicle 100. The brake unit 136 is used to control the deceleration of the autonomous vehicle 100. The brake unit 136 may use friction to slow the wheels 121. In other embodiments, the brake unit 136 may convert the kinetic energy of the wheels 121 into electrical current. The brake unit 136 may also take other forms to slow the rotational speed of the wheels 121 and thus control the speed of the autonomous vehicle 100. The computer vision system 140 may be operable to process and analyze images captured by the camera 130 to identify objects and / or features in the environment surrounding the autonomous vehicle 100. These objects and / or features may include traffic signs, road boundaries, and obstacles. The computer vision system 140 may use object recognition algorithms, structure from motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system 140 may be used to map the environment, track objects, estimate the speed of objects, and so on. The route control system 142 is used to determine the route and speed of the autonomous vehicle 100. In some embodiments, the route control system 142 may include a lateral planning module 1421 and a longitudinal planning module 1422, respectively configured to combine data from the obstacle avoidance system 144, GPS 122, and one or more predetermined maps to determine a driving route and driving speed for the autonomous vehicle 100. The obstacle avoidance system 144 is configured to identify, assess, and avoid or otherwise navigate obstacles in the environment of the autonomous vehicle 100. The aforementioned obstacles may specifically be actual obstacles and virtual moving objects that may collide with the autonomous vehicle 100. In one embodiment, the control system 106 may include additional or alternative components in addition to those shown and described. Alternatively, some of the components shown above may be reduced.

[0106] The autonomous vehicle 100 interacts with external sensors, other vehicles, other computer systems, or users via peripheral devices 108. Peripheral devices 108 may include a wireless communication system 146, an onboard computer 148, a microphone 150, and / or a speaker 152. In some embodiments, the peripheral devices 108 provide a means for the user of the autonomous vehicle 100 to interact with the user interface 116. For example, the onboard computer 148 may provide information to the user of the autonomous vehicle 100. The user interface 116 may also operate the onboard computer 148 to receive user input. The onboard computer 148 may be operated via a touchscreen. In other cases, the peripheral devices 108 may provide a means for the autonomous vehicle 100 to communicate with other devices located within the vehicle. For example, the microphone 150 may receive audio (e.g., voice commands or other audio input) from the user of the autonomous vehicle 100. Similarly, the speaker 152 may output audio to the user of the autonomous vehicle 100. The wireless communication system 146 may wirelessly communicate with one or more devices directly or via a communication network. For example, the wireless communication system 146 may utilize 3G cellular communication, such as CDMA, EVDO, GSM / GPRS, or 4G cellular communication, such as LTE. Or 5G cellular communication. The wireless communication system 146 may utilize wireless local area network (WLAN) communication. In some embodiments, the wireless communication system 146 may utilize infrared links, Bluetooth, or ZigBee to communicate directly with devices. Other wireless protocols, such as various vehicle communication systems, for example, the wireless communication system 146 may include one or more dedicated short range communications (DSRC) devices, which may include public and / or private data communications between vehicles and / or roadside stations.

[0107] Power source 110 can provide power to various components of autonomous vehicle 100. In one embodiment, power source 110 can be a rechargeable lithium-ion or lead-acid battery. One or more battery packs of such batteries can be configured as a power source to provide power to various components of autonomous vehicle 100. In some embodiments, power source 110 and energy source 119 can be implemented together, such as in some all-electric vehicles.

[0108] Some or all of the functions of the autonomous vehicle 100 are controlled by a computer system 112. The computer system 112 may include at least one DCU 116, which includes at least one processor 113, and the processor 113 executes instructions 115 stored in a non-transitory computer-readable medium such as a memory 114. The computer system 112 may also be a plurality of computing devices that control individual components or subsystems of the autonomous vehicle 100 in a distributed manner. The processor 113 may be any conventional processor, such as a commercially available CPU, GPU, VPU, NPU, DSP, ISP, etc. What type of processor the DCU 116 includes and the number of processors depends on the domain controlled by the DCU 116. Alternatively, the processor 113 may be a dedicated device such as an application specific integrated circuit (ASIC) or other hardware-based processor. Although Figure 6 The processor, memory, and other components of computer system 112 are functionally illustrated as being in the same block, but one of ordinary skill in the art will appreciate that the processor or memory may actually include multiple processors or memories that are not stored in the same physical housing. For example, memory 114 may be a hard drive or other storage medium located in a different housing than computer system 112. Thus, references to processor 113 or memory 114 will be understood to include references to a collection of processors or memories that may or may not operate in parallel. Rather than using a single processor to perform the steps described herein, some components, such as the steering assembly and the deceleration assembly, may each have their own processor that performs only calculations related to the functionality of the component.

[0109] It should be noted that, in some embodiments of the present application, the computer system 112 may further include at least one MDC ( Figure 6 (not shown), generally speaking, an MDC is composed of multiple DCUs, among which one DCU serves as a master DCU, which is used to send instructions to other DCUs in the MDC for data interaction.

[0110] In various aspects described herein, the processor 113 may be located remotely from the autonomous vehicle 100 and in wireless communication with the autonomous vehicle 100. In other aspects, some of the processes described herein are performed on the processor 113 disposed within the autonomous vehicle 100 while others are performed by the remote processor 113, including taking the necessary steps to execute a single maneuver.

[0111] In some embodiments, memory 114 may contain instructions 115 (e.g., program logic) that are executable by processor 113 to perform various functions of autonomous vehicle 100, including those described above. Memory 114 may also contain additional instructions, including instructions for sending data to, receiving data from, interacting with, and / or controlling one or more of travel system 102, sensor system 104, control system 106, and peripherals 108. In addition to instructions 115, memory 114 may also store data such as road maps, route information, the vehicle's location, direction, speed, and other such vehicle data, as well as other information. This information may be used by autonomous vehicle 100 and computer system 112 during operation of autonomous vehicle 100 in autonomous, semi-autonomous, and / or manual modes. A user interface 116 is provided for providing information to or receiving information from a user of autonomous vehicle 100. Optionally, user interface 116 may include one or more input / output devices within the set of peripherals 108, such as wireless communication system 146, onboard computer 148, microphone 150, and speaker 152.

[0112] The computer system 112 may control functions of the autonomous vehicle 100 based on input received from various subsystems (e.g., the travel system 102, the sensor system 104, and the control system 106) and from the user interface 116. For example, the computer system 112 may utilize input from the control system 106 to control the steering system 132 to avoid obstacles detected by the sensor system 104 and the obstacle avoidance system 144. In some embodiments, the computer system 112 may be operable to provide control over many aspects of the autonomous vehicle 100 and its subsystems.

[0113] Alternatively, one or more of the aforementioned components may be installed or associated separately from the autonomous vehicle 100. For example, the memory 114 may be partially or completely separate from the autonomous vehicle 100. The aforementioned components may be communicatively coupled together in a wired and / or wireless manner.

[0114] Optionally, the above components are just an example. In actual applications, the components in the above modules may be added or deleted according to actual needs. Figure 6 This should not be construed as limiting the embodiments of the present application. An autonomous vehicle traveling on a road, such as autonomous vehicle 100 above, can identify objects in its surrounding environment to determine adjustments to its current speed. The objects can be other vehicles, traffic control devices, or other types of objects. In some examples, each identified object can be considered independently, and based on the object's respective characteristics, such as its current speed, acceleration, distance from the vehicle, etc., the speed of the autonomous vehicle to be adjusted can be determined.

[0115] Optionally, the autonomous vehicle 100 or a computing device associated with the autonomous vehicle 100 may be Figure 6 The computer system 112, computer vision system 140, and memory 114 can predict the behavior of the identified objects based on the characteristics of the identified objects and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.). Optionally, each identified object depends on the behavior of each other, so all identified objects can also be considered together to predict the behavior of a single identified object. The autonomous vehicle 100 can adjust its speed based on the predicted behavior of the identified objects. In other words, the autonomous vehicle 100 can determine what stable state the vehicle will need to adjust to (e.g., accelerate, decelerate, or stop) based on the predicted behavior of the objects. In this process, other factors can also be considered to determine the speed of the autonomous vehicle 100, such as the lateral position of the autonomous vehicle 100 in the road it is traveling on, the curvature of the road, the proximity of static and dynamic objects, etc. In addition to providing instructions to adjust the speed of the autonomous vehicle, the computing device may also provide instructions to modify the steering angle of the autonomous vehicle 100 so that the autonomous vehicle 100 follows a given trajectory and / or maintains a safe lateral and longitudinal distance from objects near the autonomous vehicle 100 (e.g., cars in adjacent lanes on the road).

[0116] The above-mentioned autonomous driving vehicle 100 can be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, and cart, etc., and the embodiments of the present application do not make any special limitations.

[0117] The embodiment of the present application provides a method for configuring computing resources, which can be applied to various intelligent driving (such as unmanned driving, assisted driving, etc.) intelligent agents (such as, Figure 6 In scenarios where motion planning (e.g., speed planning, driving behavior decision-making, global path planning, etc.) is performed by an intelligent agent (e.g., the overall architecture of the corresponding autonomous vehicle), for ease of understanding, the embodiments of this application are illustrated using the autonomous vehicle as an example. In addition, when the autonomous vehicle includes a DCU or MDC, the computing power resource configuration methods provided in the embodiments of this application are slightly different, which are explained below.

[0118] 1. The controller in an autonomous vehicle is the DCU

[0119] See also Figure 7 , Figure 7 A flowchart of a method for configuring computing resources provided in an embodiment of the present application specifically includes the following steps:

[0120] 701. A DCU receives first computing power configuration data corresponding to the DCU sent by a cloud server or a host computer, where the DCU is any DCU on a vehicle, the DCU includes at least one processor, and the first computing power configuration data includes a preset configuration quantity of at least one type of processor in the DCU.

[0121] First, the DCU receives the first computing power configuration data corresponding to the DCU, which is any DCU on the vehicle. The DCU includes at least one processor, and the first computing power configuration data includes a preset configuration number of at least one type (e.g., various types) of processors in the DCU. The preset configuration number can be set according to the historical computing power resource consumption of the DCU and the specific circumstances of the DCU's operating business, and the first computing power configuration data supports the host computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so as to facilitate subsequent on-demand updates of the first computing power configuration data to achieve adjustments to the DCU computing power resources, thereby saving computing power resources while ensuring the smooth operation of the business.

[0122] It should be noted that in the embodiment of the present application, the computing power configuration data refers to the preset configuration quantity of each type of processor in the DCU. Figure 1 For example, assuming that the DCU includes a total of x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. Since the computing power resources of each type of processor are determined by the processor's own structure, the computing power resources of the corresponding processor can be roughly estimated based on the processor type and structure. Assume that the preset configuration number of each type of processor in the DCU is x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, where 0≤x0≤x+1, 0≤y0≤y+1, 0≤m0≤m+1, and 0≤n0≤n+1. Then, during the operation of the DCU, only x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores participate, and the remaining processors are in a dormant state. Therefore, based on these x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, the computing power resources of the DCU during operation can be roughly estimated. When the preset configuration number of a processor is 0, it means that the processor does not participate in the operation of the DCU.

[0123] It should also be noted that in some embodiments of the present application, the x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores involved in the calculation are not limited to which of the x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. For example, assuming that there are 3 ISPs, 4 GPUs, 2 CPUs, and 6 AI cores in the DCU, and the preset configuration numbers of each type of processor in the DCU are 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores, that is, the computing power configuration data is 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores, then the 2 ISPs can be any 2 of the total 3 ISPs, similarly, the 2 GPUs can be any 2 of the total 4 GPUs, the 1 CPU can be any 1 of the total 2 CPUs, and the 3 AI cores can be any 3 of the total 6 AI cores.

[0124] It should also be noted that in some embodiments of the present application, the number of cores within the same type of processor may be slightly different. In this case, the x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores involved in the calculation can be limited to which of the x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores.

[0125] It should also be noted that since the various types of processors included in the DCU can be multi-core processors, for example, each type of processor may also include multiple CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc., in some implementations, the number of cores within each type of processor can also be configured. In addition, the operating main frequency of each type of processor can also be configured in the computing power configuration data, without specific limitations. In other words, the computing power configuration data can be characterized by configuring the number of processors of each type in the DCU, the main frequency of the processors, and the number of cores in each processor.

[0126] It should be noted that, in some embodiments of the present application, the DCU may receive the first computing power configuration data corresponding to the DCU in the following ways:

[0127] A. The first computing power configuration data is sent by the host computer.

[0128] Since the software or firmware update of ECU / DCU / MDC can be supported by the diagnostic function, the first computing power configuration data can be included in the diagnostic service of UDS. When the host computer provides the diagnostic service to the DCU, the host computer sends the first computing power configuration data to the DCU, such as Figure 8 As shown, Figure 8 The upper computer ( Figure 8 (Using a PC as an example for illustration) the first computing power configuration data is sent to the DCU in the autonomous vehicle via the controller area network (CAN) bus. Specifically, the host computer sends a diagnostic request, and the DCU on the autonomous vehicle gives a response. During this communication process, the host computer and the DCU respectively play the roles of client and server in computer network communication.

[0129] B. The first computing power configuration data is sent by the cloud server.

[0130] In addition to being supported by the diagnostic function (i.e., local upgrade), the software or firmware update of the ECU / DCU / MDC can also be upgraded through OTA via a network remote channel (i.e., remote upgrade). Therefore, the first computing power configuration data can also be stored on a cloud server that provides OTA services. When the cloud server provides OTA services to the vehicle installed with the DCU, the cloud server sends the first computing power configuration data to the DCU, such as Figure 9 As shown, Figure 9 It shows that the cloud server sends the corresponding first computing power configuration data to the DCU in the autonomous driving vehicle through wireless communication.

[0131] It should be noted that in some embodiments of the present application, regardless of whether the first computing power configuration data is sent by the host computer or the cloud server, the first computing power configuration data can be included in a target file (which can be called a first file), and then the host computer or the cloud server sends the first file to the DCU, and includes the first computing power configuration data in the first file, thereby realizing a one-to-one correspondence between each independent DCU and the first computing power configuration data, facilitating control and management, and having feasibility.

[0132] It should also be noted that the first file can be the license file of the DCU (each DCU has a license file), or it can be a file defined in advance by the user, or it can be some files in the relevant software update package of the diagnostic service or OTA. Specifically, the type and format of the first file are not limited here. The user can choose what type of file to include the first computing power configuration data in according to their needs, which has flexibility and selectivity. In addition, the first file supports the host computer to be updated through the near-end upgrade method (i.e. UDS) or the remote upgrade method (i.e. OTA), which facilitates the subsequent on-demand update of the first computing power configuration data to achieve the adjustment of the DCU computing power resources, saving computing power resources while ensuring the smooth operation of the business.

[0133] It should also be noted that, in some embodiments of the present application, the first file may be an encrypted file to prevent the first computing power configuration data from being modified at will, thereby improving data security.

[0134] It should be noted that the encryption method for the first file can be symmetric encryption, that is, the same key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two keys, namely a public key and a private key. If the public key is used to encrypt the data, it can only be decrypted with the corresponding private key. If the private key is used to encrypt the data, it can only be decrypted with the corresponding public key. In the embodiments of the present application, the encryption method is not limited.

[0135] It should also be noted that in some embodiments of the present application, after the DCU receives the first computing power configuration data sent by the host computer or cloud server, it can be persistently stored in the storage module within the DCU. For example, the storage module can be an electrically erasable programmable read only memory (EEPROM), Flash memory, etc. The persistent storage described in the embodiments of the present application refers to saving data (such as the first computing power configuration data described in the embodiments of the present application) to a storage module that can be permanently saved (such as a disk). The main application of persistence is to store objects in memory in a database, or in a disk file, XML data file, etc. In the embodiments of the present application, only when the DCU receives new first computing power configuration data again will the original first computing power configuration data persistently stored in the storage module within the DCU be updated to the new first computing power configuration data.

[0136] It should also be noted that, in some embodiments of the present application, in order to improve the storage reliability of data, the DCU can also perform redundant backup of the received first computing power configuration data. Specifically, when the DCU receives the first computing power configuration data, it backs up the first computing power configuration data at the first moment to obtain first backup data, and stores the first computing power configuration data and the first backup data in different storage modules in the DCU, such as, respectively, in different storage media within the DCU or different blocks in the same storage medium.

[0137] It should also be noted that in some embodiments of the present application, the first computing power configuration data and the first backup data in different storage modules within the DCU can also be periodically checked and verified. The purpose of the check and verification is to ensure the accuracy of the first computing power configuration data and to promptly detect and correct any errors in the data. For example, assuming that the set period is 2 hours, assuming that the DCU receives the first computing power configuration data and stores the first computing power configuration data and the first backup data in the storage module 1 and storage module 2 within the DCU at the first time 8:00, respectively. When the time is 10:00, the DCU will determine whether the first computing power configuration data in the storage module 1 at the current time 10:00 (the first computing power configuration data at the current time can be referred to as the second computing power configuration data) and the first backup data in the storage module 2 at the current time 10:00 (the first backup data at the current time can be referred to as the second backup data). If the second computing power configuration data is inconsistent with the second backup data, the DCU will verify and align the second computing power configuration data and the second backup data to ensure that the second computing power configuration data and the second backup data are consistent with the first computing power configuration data.

[0138] Specifically, in some embodiments of the present application, the DCU has automatic recovery and self-healing capabilities, and the DCU can detect which data has errors. Suppose the DCU determines that the second computing power configuration data is consistent with the first computing power configuration data, and the second backup data is inconsistent with the first backup data, indicating that the second computing power configuration data is inconsistent with the second backup data and the second computing power configuration data is correct data. The DCU can re-back up the second computing power configuration data to obtain the corrected second backup data, thereby completing the verification and alignment of the second computing power configuration data and the second backup data; similarly, assuming that the DCU determines that the second computing power configuration data is inconsistent with the first computing power configuration data, the second backup data is inconsistent with the first backup data. If the second backup data is consistent with the first backup data, it means that the second computing power configuration data is inconsistent with the second backup data and the second backup data is correct data. The DCU can back up the second backup data and use the backed-up data as the corrected second computing power configuration data, thereby completing the verification and alignment of the second computing power configuration data and the second backup data. Assuming that the DCU determines that the second computing power configuration data is inconsistent with the first computing power configuration data and the second backup data is also inconsistent with the first backup data, it means that both data are wrong. At this time, the local upgrade or remote upgrade process can be started to receive a new copy of the first computing power configuration data from the host computer or cloud server and back it up.

[0139] It should be noted that in the embodiment of the present application, the DCU is any DCU in the autonomous vehicle. In some implementation plans of the present application, each independently working DCU in the autonomous vehicle can execute the process of step 701 as a DCU, thereby obtaining the computing power configuration data corresponding to each DCU in the autonomous vehicle. The specific process is similar to step 701 and will not be repeated here.

[0140] 702. The DCU de-resets a target processor in the DCU according to the first computing power configuration data to obtain a de-reset target processor.

[0141] After the DCU receives the first computing power configuration data corresponding to the DCU sent by the host computer or cloud server, it can reset the corresponding processor in the DCU (which can be called the target processor) according to the first computing power configuration data, thereby obtaining the reset target processor.

[0142] For ease of understanding, the following is still Figure 1 For example, assume that the DCU includes a total of x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. The preset configuration numbers of each type of processor in the DCU are x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, respectively. 0≤x0≤x+1, 0≤y0≤y+1, 0≤m0≤m+1, and 0≤n0≤n+1. That is, the first computing power configuration data of the DCU is x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores, and the first computing power configuration data is stored in the storage module within the DCU. After the DCU is powered on, the first computing power configuration data is read from the storage module, and based on the first computing power configuration data, x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores are decompressed from the DCU. Then, during the operation of the DCU, there are only x0 ISPs, y0 GPUs, m0 CPUs, and n0 AI cores. core participates, these x0 ISPs, y0 GPUs, m0 CPUs and n0 AI cores are called the target processors described in this application, and the remaining processors are in a dormant state. Therefore, based on these x0 ISPs, y0 GPUs, m0 CPUs and n0 AI cores, the computing power resources of the DCU during operation can be roughly estimated. When the preset configuration quantity of a processor is 0, it means that the processor does not participate in the operation of the DCU.

[0143] It should be noted that in some embodiments of the present application, before the DCU resets the corresponding target processor in the DCU according to the first computing power configuration data, it is also necessary to perform a legitimacy check on the first computing power configuration data, which can prevent erroneous and illegal data from entering the service, or can promptly detect data errors. For example, the legitimacy check can specifically include: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether there is a jump or tampering with the first computing power configuration data; whether the first computing power configuration data has integrity; when the first computing power configuration data is included in the encrypted first file, checking whether the encryption process of the first file is abnormal and whether the encrypted first file can be decrypted; checking whether the data value range of the first computing power configuration data is within the normal range, etc. For example, if the DCU has a total of 4 CPUs, and the number of CPUs in the first computing power configuration data is 5, then the data value range is not within the normal range. Only when the first computing power configuration data passes the legitimacy check, the DCU resets the corresponding target processor in the DCU according to the first computing power configuration data.

[0144] It should also be noted that in some embodiments of the present application, if the first computing power configuration data is included in the first file, then the DCU performs a validity check on the first computing power configuration data by performing a validity check on the first file. In other embodiments of the present application, if the first file is an encrypted file, then the DCU needs to first decrypt the encrypted first file to obtain the decrypted first file, and then perform a validity check on the decrypted first file.

[0145] 703. When the vehicle collects perception information through sensors and the perception information falls within the processing scope of the DCU, the DCU processes the perception information based on the target processor after de-reset.

[0146] In some embodiments of the present application, after obtaining the target processor after de-resetting, step 703 can be continued to be executed. That is, after the DCU de-resets the target processor in the DCU based on the first computing power configuration data, when the autonomous driving vehicle collects perception information through sensors and the perception information belongs to the processing scope of the DCU, the DCU processes the collected perception information based on the target processor obtained after the de-resetting.

[0147] For ease of understanding, the following is still Figure 1Take an example for illustration: assuming that the DCU includes a total of x+1 ISPs, y+1 GPUs, m+1 CPUs and n+1 AI cores, and the first computing power configuration data of the DCU is x0 ISPs, y0 GPUs, m0 CPUs and n0 AI cores, then the target processor obtained by de-resetting is x0 ISPs, y0 GPUs, m0 CPUs and n0 AI cores. Finally, the DCU processes the perception information collected by the sensor based on these target processors (i.e., x0 ISPs, y0 GPUs, m0 CPUs and n0 AI cores) (if the perception information falls within the processing scope of the DCU).

[0148] It should be noted that in the embodiment of the present application, the steps performed by the DCU are all implemented through the main CPU in the DCU. For example, the DCU receives the first computing power configuration data sent by the host computer or cloud server through the main CPU in the DCU.

[0149] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is a DCU, the first computing power configuration data supports the upper computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, avoiding the situation where the corresponding computing power configuration data of the DCU can only be solidified in the eFuse and cannot be modified when it leaves the factory, and enhancing the adaptability to the ever-changing subsequent driving business scenarios.

[0150] 2. The controller in the autonomous vehicle is MDC

[0151] See also Figure 10 , Figure 10 Another flowchart of a method for configuring computing resources provided in an embodiment of the present application specifically includes the following steps:

[0152] 1001. The MDC receives third computing power configuration data corresponding to the MDC sent by the cloud server or the host computer through the master DCU. The MDC includes multiple DCUs, the master DCU is one of the multiple DCUs, each of the multiple DCUs includes at least one processor, and the third computing power configuration data includes a preset configuration number of at least one type of processor in each DCU.

[0153] First, the MDC receives the third computing power configuration data corresponding to the MDC through the main DCU in the MDC. The MDC is any MDC on the vehicle (generally, one MDC is deployed on one vehicle. When the vehicle only deploys one MDC, the MDC is this one MDC). The MDC includes multiple DCUs, where the main DCU is any one of these multiple DCUs. Each DCU includes at least one processor (such as a CPU). The third computing power configuration data includes the preset configuration number of at least one type (such as various types) of processors in each DCU in the MDC.

[0154] For ease of understanding, the following Figure 11 For example, assume that the MDC includes three DCUs, namely DCU1, DCU2, and DCU3. DCU1 includes m1+1 CPUs, x1+1 ISPs, y1+1 GPUs, and n1+1 AI Cores; DCU2 includes m2+1 CPUs, y2+1 GPUs, and n2+1 Vector Cores; and DCU3 includes m3+1 CPUs, x3+1 ISPs, y3+1 GPUs, and n3+1 Vector Cores. Assume that the preset configuration quantities of each type of processor in DCU1 within the MDC are m. 01 CPUs, x 01 ISP, y 01 GPUs and n 01 AI core, the preset configuration number of each type of processor in DCU2 in the MDC is m 02 CPU, y 02 GPUs and n 02 Vector cores, the preset configuration number of each type of processor in DCU3 in the MDC is m 03 CPUs, x 03 ISP, y 03 GPUs and n 03 Vector cores, where 0≤m 01 ≤m1+1,0≤x 01 ≤x1+1,0≤y 01 ≤y1+1,0≤n 01 ≤n1+1,0≤m 02 ≤m2+1,0≤y 02 ≤y2+1,0≤n 02 ≤n2+1,0≤m 03 ≤m3+1,0≤x 03 ≤x3+1,0≤y 03 ≤y3+1,0≤n 03≤n3+1. Then during the operation of the MDC, only m in DCU1 01 CPUs, x 01 ISP, y 01 GPUs, n 01 AI cores, and m in DCU2 02 CPU, y 02 GPUs and n 02 Vector cores, and m in DCU3 03 CPUs, x 03 ISP, y 03 GPUs and n 03 Vector cores participate, and the remaining processors in each DCU are in sleep state, so that according to the m in DCU1 01 CPUs, x 01 ISP, y 01 GPUs, n 01 AI cores, and m in DCU2 02 CPU, y 02 GPUs and n 02 Vector cores, and m in DCU3 03 CPUs, x 03 ISP, y 03 GPUs and n 03 The computing resources of the MDC during operation can be roughly estimated by using a Vector core. When the preset configuration quantity of a processor in a DCU is 0, it means that the processor does not participate in the operation of the MDC.

[0155] It should also be noted that in some embodiments of the present application, the m 01 CPUs, x 01 ISP, y 01 GPUs, n 01 AI cores, and m in DCU2 02 CPU, y 02 GPUs and n 02 Vector cores, and m in DCU3 03 CPUs, x 03 ISP, y 03 GPUs and n 03The number of vector cores is not limited to which ones among DCU1, DCU2, and DCU3. For example, assuming that there are 3 ISPs, 4 GPUs, 2 CPUs, and 6 AI cores in the DCU1 in the MDC, the preset configuration number of each type of processor in the DCU1 is 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores, that is, the part corresponding to DCU1 in the third computing power configuration data is 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores. Then, these 2 ISPs can be any 2 of the total 3 ISPs. Similarly, these 2 GPUs can also be any 2 of the total 4 GPUs, this 1 CPU can also be any 1 of the total 2 CPUs, and these 3 AI cores can also be any 3 of the total 6 AI cores. Similarly, the situation of the parts corresponding to DCU2 and DCU3 in the third computing power configuration data is similar to that of DCU1, and the details are not repeated here.

[0156] It should also be noted that in some embodiments of the present application, the number of cores in the processors of the same type may be slightly different. In this case, taking DCU1 as an example, the number of cores participating in the operation is 01 ISP, y 01 GPUs, m 01 CPUs and n 01 The AI ​​core can be limited to x1+1 ISPs, y1+1 GPUs, m1+1 CPUs, and n1+1 AI cores.

[0157] It should be noted that, in some embodiments of the present application, the MDC may receive the third computing power configuration data corresponding to the MDC in the following ways:

[0158] A. The third computing power configuration data is sent by the host computer.

[0159] Since the software or firmware update of ECU / DCU / MDC can be supported by the diagnostic function, the third computing power configuration data can be included in the diagnostic service of UDS. When the host computer provides diagnostic service to the MDC, the host computer sends the third computing power configuration data to the main DCU in the MDC, such as Figure 12 As shown, Figure 12 The upper computer ( Figure 12 (Using a PC as an example for illustration, the third computing power configuration data is sent to the MDC in the autonomous driving vehicle via the CAN bus. Specifically, the host computer sends a diagnostic request, and the MDC on the autonomous driving vehicle responds through the main DCU. During this communication process, the host computer and MDC respectively play the roles of client and server in computer network communication.

[0160] B. The third computing power configuration data is sent by the cloud server.

[0161] In addition to being supported by the diagnostic function (i.e., local upgrade), the software or firmware update of the ECU / DCU / MDC can also be upgraded through OTA via a network remote channel (i.e., remote upgrade). Therefore, the third computing power configuration data can also be stored on a cloud server that provides OTA services. When the cloud server provides OTA services to a vehicle equipped with the MDC, the cloud server sends the third computing power configuration data to the MDC. Figure 13 As shown, Figure 13 It shows that the cloud server sends the corresponding third computing power configuration data to the main DCU in the MDC in the autonomous driving vehicle through wireless communication.

[0162] It should be noted that in some embodiments of the present application, regardless of whether the third computing power configuration data is sent by the host computer or the cloud server, the third computing power configuration data can be included in a target file (which can be called a second file), and then the host computer or the cloud server sends the second file to the main DCU in the MDC, and includes the third computing power configuration data in the second file, thereby realizing a one-to-one correspondence between each independent MDC and the third computing power configuration data, facilitating control and management, and being feasible.

[0163] It should also be noted that the second file can be the MDC's license file (each MDC has a license file), or it can be a file defined in advance by the user, or some files in the diagnostic service or OTA related software update package. Specifically, the type and format of the first file are not limited here. The user can choose what type of file to include the first computing power configuration data in according to their needs, which has flexibility and selectivity. In addition, the second file supports the host computer to be updated through the local upgrade method (i.e., UDS) or the remote upgrade method (i.e., OTA), which facilitates the subsequent on-demand update of the third computing power configuration data to achieve the adjustment of the MDC computing power resources, saving computing power resources while ensuring the smooth operation of the business.

[0164] It should also be noted that, in some embodiments of the present application, the second file may be an encrypted file to prevent the third computing power configuration data from being arbitrarily modified, thereby improving data security.

[0165] It should be noted that similarly, the encryption method for the second file can be symmetric encryption, that is, the same key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two keys, namely a public key and a private key. If the public key is used to encrypt the data, it can only be decrypted with the corresponding private key. If the private key is used to encrypt the data, it can only be decrypted with the corresponding public key. In the embodiments of the present application, the encryption method is not limited.

[0166] It should also be noted that in some embodiments of the present application, after the MDC receives the third computing power configuration data sent by the host computer or cloud server through the main DCU, it can be persistently stored in a storage module within the MDC. For example, the storage module can be an EEPROM, Flash memory, etc. The persistent storage described in the embodiments of the present application refers to saving data (such as the first computing power configuration data described in the embodiments of the present application) to a storage module that can be permanently saved (such as a disk). The main application of persistence is to store objects in memory in a database, or in a disk file, XML data file, etc. In the embodiments of the present application, only when the MDC receives new third computing power configuration data again will the original third computing power configuration data persistently stored in the storage module within the MDC be updated to the new third computing power configuration data.

[0167] 1002. The MDC sends the third computing power configuration data to other DCUs in the multiple DCUs except the main DCU through the main DCU.

[0168] After the MDC receives the third computing power configuration data from the host computer or cloud server through the main DCU, it can further send the third computing power configuration data to other DCUs in the first DMC except the main DCU, still in the same way. Figure 11 For example, assuming that DCU1 is the master DCU, after DCU1 receives the third computing power configuration data, it sends the third computing power configuration data to DCU2 and DCU3. After receiving the third computing power configuration data, DCU2 and DCU3 each store it in their respective storage modules. By storing the third computing power configuration data in each DCU in the MDC, redundant backup is achieved, thereby improving data storage reliability.

[0169] It should be noted that in some embodiments of the present application, in order to save storage space while achieving redundant backup of data, the MDC can also send the third computing power configuration data to another DCU in the MDC except the main CDU through the main DCU, still in the form of Figure 11For example, assuming DCU1 is the master DCU, after receiving the third computing power configuration data, DCU1 can send it to DCU2 (or DCU3). DCU2 (or DCU3) stores the third computing power configuration data in its own storage module. When the MDC is powered on and operating normally, DCU3, which has not yet obtained the third computing power configuration data, can read the third computing power configuration data from DCU1 at any time. In short, in an MDC, it is sufficient to ensure that the third computing power configuration data is stored in the storage modules of at least two DCUs in the MDC.

[0170] It should also be noted that in some embodiments of the present application, the third computing power configuration data stored in each of the different DCU storage modules in the MDC can also be periodically checked and verified. The purpose of the check and verification is to ensure the accuracy of the third computing power configuration data and to promptly detect and correct any errors in the data. Figure 11 Take this as an example: assuming that the setting period is 1 hour, assuming that the MDC receives the third computing power configuration data through DCU1 (i.e., the main DCU) and sends the third computing power configuration data to DCU2 and DCU3, and DCU1, DCU2, and DCU3 respectively store their respective third computing power configuration data in their respective storage modules at the first time 7:30. When the time is 8:30, DCU1 will obtain the third computing power configuration data on DCU2 and DCU3, and determine whether the third computing power configuration data in DCU1 at the current time 8:30 and the third computing power configuration data in DCU2 and DCU3 at the current time 8:30 (the third computing power configuration data in each DCU at the current time can be called the fourth computing power configuration data) are consistent. If the fourth computing power configuration data in each DCU is inconsistent, the MDC verifies and aligns the fourth computing power configuration data in each DCU through the main DCU to ensure that the fourth computing power configuration data in each DCU remains consistent.

[0171] Similarly, the method of verifying and aligning each fourth computing power configuration data is similar to the method of verifying and aligning the second computing power configuration data and the second backup data by the above-mentioned DCU. Please refer to the above description and the details will not be repeated here.

[0172] It should be noted that in the embodiment of the present application, the MDC is any MDC in the autonomous driving vehicle. In some embodiments of the present application, each independently working MDC in the autonomous driving vehicle can execute the process of steps 1001-1002 as an MDC, thereby obtaining the computing power configuration data corresponding to each MDC in the autonomous driving vehicle. The specific process is similar to steps 1001-1002 and will not be repeated here.

[0173] 1003. The MDC de-resets the target processor in each of the multiple DCUs according to the third computing power configuration data to obtain the de-reset target processor.

[0174] After each DCU in the MDC obtains the third computing power configuration data, each DCU will reset the target processor in its own DCU according to the third computing power configuration data obtained, and obtain the reset target processor. How the MDC resets the target processor in its own DCU according to the third computing power configuration data is similar to the above step 702, and the details will not be repeated here.

[0175] It should be noted that in some embodiments of the present application, before each DCU in the MDC resets the corresponding target processor in its respective DCU according to its respective third computing power configuration data, it is also necessary to perform a validity check on the third computing power configuration data, which can prevent erroneous and illegal data from entering the service, or can promptly detect data errors. For example, the validity check can specifically include: verifying whether the third computing power configuration data is the computing power configuration data corresponding to the MDC; verifying whether there is a jump or tampering with the third computing power configuration data; whether the third computing power configuration data has integrity; when the third computing power configuration data is included in the encrypted second file, verifying whether the encryption process of the second file is abnormal and whether the encrypted second file can be decrypted; verifying whether the data value range of the third computing power configuration data is within the normal range, etc. Only when the third computing power configuration data passes the validity check, each DCU in the MDC resets the corresponding target processor in its respective DCU according to its respective third computing power configuration data.

[0176] It should also be noted that in some embodiments of the present application, if the third computing power configuration data is included in the second file, then each DCU performs a validity check on the third computing power configuration data by performing a validity check on the second file. In other embodiments of the present application, if the second file is encrypted, then each DCU needs to first decrypt the encrypted second file to obtain the decrypted second file, and then perform a validity check on the decrypted second file.

[0177] 1004. When the vehicle collects perception information through sensors and the perception information falls within the processing scope of the MDC, the MDC processes the perception information based on the target processor after de-reset.

[0178] In some embodiments of the present application, after obtaining the target processor in the MDC after de-resetting, step 1004 can be continued to be executed, that is, after each DCU in the MDC de-resets the target processor in the MDC based on the third computing power configuration data received by each of them, when the autonomous driving vehicle collects perception information through sensors and the perception information belongs to the processing scope of the MDC, the MDC processes the collected perception information based on the target processor obtained after the above-mentioned de-resetting.

[0179] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is MDC, the third computing power configuration data supports the host computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, and solving the problem that the existing solution can only configure the computing power resources of this DCU but cannot support the combined application scenarios of MDC composed of multiple DCUs.

[0180] To further understand the above solution, the following uses the controller in an autonomous vehicle as an example of a DCU to explain the specific configuration process of DCU computing resources in three stages. Figure 14 , Figure 14 A flow chart of the specific configuration process of computing power resources provided in the embodiment of the present application, which specifically includes the computing power configuration data storage stage, the computing power configuration data loading stage and the computing power configuration data synchronization stage, wherein DCU w DCU0~DCU in the autonomous driving vehicle v Any DCU in DCU w Including CPU0~CPU m (CPU0 is the main CPU), Vector Core0 to Vector Core k 、AI Core0~AI Core k ISP0~ISP x 、GPU0~GPU y , storage module and hardware security module (HSM), which may specifically include the following steps: wherein, steps 1401-1403 are the computing power configuration data storage stage, steps 1404-1047 are the computing power configuration data loading stage, and step 1408 is the computing power configuration data synchronization stage.

[0181] 1401. Local or remote upgrade.

[0182] The local upgrade process (or remote upgrade process) is triggered between the host computer (or cloud server) and the autonomous driving vehicle, and the DCU is connected to the host computer (or cloud server) during the upgrade process. w The corresponding computing power configuration data is included in the DCU w The encrypted license file is sent to CPU0 to implement the DCU w The one-to-one correspondence with the corresponding computing power configuration data and the encrypted license file can prevent the computing power configuration data from being modified at will, thereby improving data security.

[0183] 1402. CPU0 sends a secure access authentication to the HSM.

[0184] CPU0 sends a security access authentication to the HSM. After the authentication is passed, step 1403 is executed.

[0185] 1403. CPU0 persistently stores the encrypted license file in the storage module.

[0186] The encrypted license file is sent to the DCU via local or remote upgrade. w The storage module is used, and the license file is backed up to obtain a backup file, and the license file and the backup file are persistently stored in different areas within the storage module (or in different storage modules).

[0187] 1404. CPU0 reads the encrypted license file from the storage module.

[0188] DCU w After power-on, before the autonomous driving service model is loaded, the DCU w CPU0 reads the encrypted license file from the storage module.

[0189] 1405. CPU0 decrypts the license file.

[0190] After CPU0 reads the license file from the storage module, it decrypts the license and verifies whether the decrypted license file is the license of the DCU. w License file.

[0191] 1406. CPU0 verifies the validity of the computing power configuration data.

[0192] The license file after verification and decryption on CPU0 is the DCU w In the case of a license file, CPU0 obtains the computing power configuration data in the decrypted license file and performs a validity check on the computing power configuration data.

[0193] 1407. CPU0 resets the corresponding target processor according to the computing power configuration data.

[0194] Specifically, CPU0 resets the corresponding other CPUs, resets the corresponding VectorCore, resets the corresponding AI Core, resets the corresponding ISP, and resets the corresponding GPU in sequence according to the computing power configuration data. w The target processor in the system can process the collected perception information, that is, load the driving business model based on the reset target processor.

[0195] 1408. CPU0 periodically checks and verifies the license file and the backup file.

[0196] CPU0 periodically checks and verifies the computing power configuration data in the license file and the computing power configuration data in the backup file, and automatically aligns the data if the computing power configuration data in the license file and the computing power configuration data in the backup file are inconsistent.

[0197] exist Figure 7 and Figure 14 On the basis of the corresponding embodiment, in order to better implement the above solution of the embodiment of the present application, the following also provides related equipment for implementing the above solution. Figure 15 , Figure 15 A structural schematic diagram of a DCU provided in an embodiment of the present application, the DCU1500 can be applied to a vehicle (such as a smart car, a self-driving car, a connected car, etc.), and the DCU1500 can specifically include: a receiving module 1501 and a reset module 1502, wherein the receiving module 1501 is used to receive first computing power configuration data corresponding to the DCU, the DCU is any DCU on the vehicle, the DCU includes at least one processor, and the first computing power configuration data includes a preset configuration number of at least one type of processor in the DCU, and the preset configuration number can be set according to the historical computing power resource consumption of the DCU and the specific circumstances of the running business of the DCU; the reset module 1502 is used to reset the corresponding processor (which can be called a target processor) in the DCU according to the first computing power configuration data, thereby obtaining the reset target processor.

[0198] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is a DCU, the first computing power configuration data supports the upper computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, avoiding the situation where the corresponding computing power configuration data of the DCU can only be solidified in the eFuse and cannot be modified when it leaves the factory, and enhancing the adaptability to the ever-changing subsequent driving business scenarios.

[0199] In one possible design, the DCU 1500 may further include a processing module 1503. The processing module 1503 is configured to process the collected perception information based on the target processor obtained after the above-mentioned de-resetting when the autonomous driving vehicle collects perception information through sensors and the perception information falls within the processing scope of the DCU.

[0200] In the above-mentioned embodiments of the present application, the DCU can process corresponding perception information based on the target processor after reset, and the perception information reflects the driving business scenario. Therefore, the embodiments of the present application can enhance the adaptability of the ever-changing driving business scenario.

[0201] In one possible design, the receiving module 1501 is specifically used to: receive a first file corresponding to the DCU sent by the cloud server or the host computer, and the first computing power configuration data is included in the first file.

[0202] In the above-mentioned embodiment of the present application, it is specifically explained that the first computing power configuration data can be included in a target file (i.e., the first file), and then the first file is sent to the DCU by the host computer or the cloud server, and the first computing power configuration data is included in the first file, thereby realizing a one-to-one correspondence between each independent DCU and the first computing power configuration data, facilitating control and management, and having feasibility.

[0203] In a possible design, the first file is an encrypted file.

[0204] In the above-mentioned embodiment of the present application, the first file may be an encrypted file to prevent the first computing power configuration data from being modified at will, thereby improving the security of the data.

[0205] In one possible design, the first file can be the license file of the DCU (each DCU has a license file), or it can be a file defined by the user in advance, or it can be some files in the diagnostic service or OTA related software update package. The type and format of the first file are not specifically limited here.

[0206] In the above-mentioned implementation of the present application, the user can choose what type of file to include the first computing power configuration data in according to needs, which has flexibility and selectivity.

[0207] In one possible design, the de-reset module 1502 is specifically used to: perform a validity check on the first computing power configuration data, and if the first computing power configuration data passes the validity check, de-reset the target processor in the DCU according to the first computing power configuration data. For example, the validity check can specifically be: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether there is a jump or tampering with the first computing power configuration data; whether the first computing power configuration data has integrity; when the first computing power configuration data is included in the encrypted first file, checking whether the encryption process of the first file is abnormal and whether the encrypted first file can be decrypted; checking whether the data value range of the first computing power configuration data is within the normal range, etc. For example, if the DCU has a total of 4 CPUs, and the number of CPUs in the first computing power configuration data is 5, then the data value range is not within the normal range. Only if the first computing power configuration data passes the validity check, the DCU de-resets the corresponding target processor in the DCU according to the first computing power configuration data.

[0208] In the above-mentioned embodiment of the present application, before the reset module 1502 resets the corresponding target processor in the DCU according to the first computing power configuration data, it is also necessary to perform a validity check on the first computing power configuration data, so as to prevent erroneous and illegal data from entering the service, or to detect data errors in a timely manner.

[0209] In one possible design, the receiving module 1501 is also used to: back up the first computing power configuration data at a first moment to obtain first backup data, where the first computing power configuration data is the computing power configuration data at the first moment, and the first backup data is the backup data at the first moment; and store the first computing power configuration data and the first backup data in different storage modules within the DCU respectively.

[0210] In the above-mentioned implementation manner of the present application, the receiving module 1501 may also perform redundant backup of the received first computing power configuration data to improve the storage reliability of the data.

[0211] In one possible design, the receiving module 1501 is also used to: periodically determine whether the second computing power configuration data is consistent with the second backup data, the second computing power configuration data is the computing power configuration data at the current moment, and the second backup data is the backup data at the current moment; when the second computing power configuration data is inconsistent with the second backup data, verify and align the second computing power configuration data and the second backup data.

[0212] In the above-mentioned embodiment of the present application, the receiving module 1501 can also periodically check and verify the first computing power configuration data and the first backup data in different storage modules in the DCU. The purpose of the check and verification is to ensure the accuracy of the first computing power configuration data, and at the same time, when data errors occur, they can be discovered and corrected in time.

[0213] It should be noted that Figure 15 The information interaction, execution process, etc. between the modules / units in the DCU1500 described in the corresponding embodiment are the same as those in the present application. Figure 7 and Figure 14 The corresponding method embodiments are based on the same concept. For specific contents, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0214] Similarly, in Figure 10 On the basis of the corresponding embodiment, in order to better implement the above solution of the embodiment of the present application, the following also provides related equipment for implementing the above solution. Figure 16 , Figure 16 A structural diagram of an MDC provided in an embodiment of the present application, the MDC1600 can be applied to a vehicle (such as a smart car, a self-driving car, a connected car, etc.), and the MDC1600 can specifically include: a receiving module 1601, a sending module 1602, and a de-reset module 1603, wherein the receiving module 1601 is used to receive the third computing power configuration data corresponding to the MDC through the main DCU in the MDC, and the MDC is any MDC on the vehicle (generally, one MDC is deployed on one vehicle, and when only one MDC is deployed on the vehicle, the MDC is this MDC), MDC The MDC includes multiple DCUs, wherein the main DCU is any one of the multiple DCUs, and each DCU includes at least one processor (such as a CPU). The third computing power configuration data includes a preset configuration quantity of at least one type of processor in each DCU in the MDC; a sending module 1602 is used to send the third computing power configuration data to other DCUs in the multiple DCUs except the main DCU through the main DCU; and a de-resetting module 1603 is used to de-reset the target processor in each of the multiple DCUs according to the third computing power configuration data to obtain the de-reset target processor.

[0215] In the above-mentioned embodiment of the present application, when the controller of the autonomous driving vehicle is MDC, the third computing power configuration data supports the host computer to be updated through a proximal upgrade method (i.e., UDS) or a remote upgrade method (i.e., OTA), so that the third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, thereby supporting the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, saving computing power resources while ensuring the smooth progress of the business, and solving the problem that the existing solution can only configure the computing power resources of this DCU but cannot support the combined application scenarios of MDC composed of multiple DCUs.

[0216] In one possible design, the MDC 1600 may further include a processing module 1604, which is configured to process the perception information based on the target processor after de-resetting when the vehicle collects perception information through sensors and the perception information falls within the processing scope of the MDC.

[0217] In the above-mentioned embodiments of the present application, the corresponding perception information can also be processed based on the target processor after reset. The perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of the ever-changing driving business scenario.

[0218] In one possible design, the receiving module 1601 is specifically used to: receive a second file corresponding to the MDC sent by the cloud server or the host computer, and the third computing power configuration data is included in the second file.

[0219] In the above-mentioned embodiment of the present application, it is specifically explained that the third computing power configuration data can be included in a target file (i.e., the second file), and then the host computer or the cloud server sends the second file to the MDC, and includes the third computing power configuration data in the second file, thereby realizing a one-to-one correspondence between each independent MDC and the third computing power configuration data, facilitating control and management, and having feasibility.

[0220] In a possible design, the second file is an encrypted file.

[0221] In the above-mentioned embodiment of the present application, the second file may be an encrypted file to prevent the third computing power configuration data from being modified at will, thereby improving the security of the data.

[0222] In one possible design, the second file can be the license file of the MDC (each MDC has a license file), or it can be a file defined by the user in advance, or it can be some files in the diagnostic service or OTA related software update package. The type and format of the second file are not specifically limited here.

[0223] In the above-mentioned implementation of the present application, the user can choose what type of file to include the third computing power configuration data in according to needs, which has flexibility and selectivity.

[0224] In one possible design, the de-resetting module 1603 is specifically used to: perform a validity check on the third computing power configuration data by each of the multiple DCUs; and when the third computing power configuration data passes the validity check, de-reset the target processor in each of the multiple DCUs according to the third computing power configuration data.

[0225] In the above-mentioned embodiment of the present application, before each DCU in the MDC resets the corresponding target processor in its own DCU according to its own third computing power configuration data, it is also necessary to perform a validity check on the third computing power configuration data, so as to prevent erroneous and illegal data from entering the service, or to detect data errors in a timely manner.

[0226] In one possible design, the receiving module 1601 is also used to: periodically determine, through the main DCU, whether the fourth computing power configuration data in each DCU within the multiple DCUs at the current moment are consistent; and when there is inconsistency among the fourth computing power configuration data, verify and align the fourth computing power configuration data through the main DCU.

[0227] In the above-mentioned embodiment of the present application, the receiving module 1601 can also periodically check and verify the third computing power configuration data stored in different DCU storage modules within the MDC. The purpose of the check and verification is to ensure the accuracy of the third computing power configuration data, and at the same time, when errors occur in the data, they can be discovered and corrected in time.

[0228] It should be noted that Figure 16 The information interaction, execution process, etc. between the modules / units in the MDC1600 described in the corresponding embodiment are the same as those in the present application. Figure 10 The corresponding method embodiments are based on the same concept. For specific contents, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0229] The embodiment of the present application also provides a device, which can be a DCU or an MDC. Figure 17 , Figure 17 This is a structural diagram of the device (DCU or MDC) provided in the embodiment of the present application. For the sake of convenience, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The device 1700 can be deployed with Figure 15 The module of the DCU described in the corresponding embodiment is used to implement Figure 7 or Figure 14 Corresponding to the function of DCU in the embodiment, the device 1700 may also be deployed with Figure 16 The module of the MDC described in the corresponding embodiment is used to implement Figure 10 The functions of the MDC in the corresponding embodiment are not specifically limited here.

[0230] Specifically, device 1700 is implemented by one or more servers. Device 1700 may vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1722 (e.g., one or more) and memory 1732, and one or more storage media 1730 (e.g., one or more mass storage devices) storing application programs 1742 or data 1744. Memory 1732 and storage media 1730 may be either short-term storage or persistent storage. The program stored in storage medium 1730 may include one or more modules (not shown), each of which may include a series of instruction operations on device 1700. Furthermore, CPU 1722 may be configured to communicate with storage medium 1730 to execute the series of instruction operations in storage medium 1730 on device 1700.

[0231] The device 1700 may also include one or more power supplies 1726, one or more wired or wireless network interfaces 1750, one or more input and output interfaces 1758, and / or one or more operating systems 1741, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0232] In the embodiment of the present application, if the device 1700 is a DCU, then the above Figure 7 and Figure 14 The steps performed by the DCU in the corresponding embodiment can be based on the Figure 17 If the device 1700 is an MDC, then the above Figure 10 The steps performed by the MDC in the corresponding embodiment can also be based on the Figure 17 The structural implementation shown is not described in detail here.

[0233] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0234] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general-purpose hardware, and of course can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for the present application, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., and includes a number of instructions for causing a computer device (which can be a personal computer, training equipment, or network equipment, etc.) to execute the methods described in each embodiment of the present application.

[0235] In the above embodiments, all or part of the embodiments may be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the embodiments may be implemented in the form of a computer program product.

[0236] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, training equipment or data center to another website, computer, training equipment or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device, data center, etc. that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a high-density digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state drive (SSD)).

Claims

1. A method for configuring computing resources, applied to a vehicle, characterized in that: include: The domain controller DCU receives first computing power configuration data corresponding to the DCU sent by a cloud server or a host computer, where the DCU is any DCU on the vehicle, the DCU includes at least one processor, the first computing power configuration data includes a preset configuration quantity of at least one type of processor in the DCU, and the first computing power configuration data is updated through a local upgrade or a remote upgrade; The DCU de-resets a target processor in the DCU according to the first computing power configuration data to obtain a de-resetted target processor, and processors in the DCU other than the target processor are in a dormant state.

2. The method according to claim 1, characterized in that The method further comprises: When the vehicle collects perception information through sensors and the perception information falls within the processing scope of the DCU, the DCU processes the perception information based on the target processor after de-reset.

3. The method according to any one of claims 1 to 2, characterized in that The domain controller DCU receives the first computing power configuration data corresponding to the DCU and sent by the cloud server or the host computer, including: The DCU receives a first file corresponding to the DCU sent by a cloud server or a host computer, where the first file includes the first computing power configuration data.

4. The method according to claim 3, characterized in that The first file is an encrypted file.

5. The method according to any one of claims 3 to 4, characterized in that The first file includes: License file or custom file.

6. The method according to any one of claims 1 to 5, characterized in that The DCU de-resetting the target processor in the DCU according to the first computing power configuration data includes: The DCU performs a validity check on the first computing power configuration data; In a case where the first computing power configuration data passes the legality check, the DCU resets the target processor in the DCU according to the first computing power configuration data.

7. The method according to any one of claims 1 to 6, characterized in that Before the DCU de-resets the target processor in the DCU according to the first computing power configuration data, the method further includes: The DCU backs up the first computing power configuration data at a first moment to obtain first backup data, where the first computing power configuration data is computing power configuration data at the first moment, and the first backup data is backup data at the first moment; The DCU stores the first computing power configuration data and the first backup data in different storage modules within the DCU respectively.

8. The method according to claim 7, characterized in that After the DCU stores the first computing power configuration data and the first backup data in different storage modules within the DCU, the method further includes: The DCU periodically determines whether the second computing power configuration data is consistent with the second backup data, where the second computing power configuration data is the computing power configuration data at the current moment, and the second backup data is the backup data at the current moment; When the second computing power configuration data is inconsistent with the second backup data, the second computing power configuration data and the second backup data are verified and aligned.

9. A method for configuring computing resources, applied to a vehicle, characterized in that: include: The multi-domain controller MDC receives third computing power configuration data corresponding to the MDC sent by the cloud server or the host computer through the master domain controller DCU, where the MDC is any MDC on the vehicle, the MDC includes multiple DCUs, the master DCU is one of the multiple DCUs, each of the multiple DCUs includes at least one processor, the third computing power configuration data includes a preset configuration quantity of at least one type of processor in each DCU, and the third computing power configuration data is updated through a local upgrade or a remote upgrade; The MDC sends the third computing power configuration data to other DCUs of the multiple DCUs except the main DCU through the main DCU; The MDC de-resets the target processor in each of the multiple DCUs according to the third computing power configuration data to obtain the de-resettled target processor, and the processors in each of the DCUs except the target processor in the respective DCU are in a dormant state.

10. The method according to claim 9, characterized in that The method further comprises: When the vehicle collects perception information through sensors and the perception information falls within the processing scope of the MDC, the MDC processes the perception information based on the target processor after the reset.

11. The method according to any one of claims 9 to 10, characterized in that The multi-domain controller MDC receives, through the master domain controller DCU, third computing power configuration data corresponding to the MDC and sent by the cloud server or the host computer, including: The MDC receives a second file corresponding to the MDC sent by the cloud server or the host computer through the master DCU, where the second file includes the third computing power configuration data.

12. The method according to claim 11, characterized in that The second file is an encrypted file.

13. The method according to any one of claims 11 to 12, characterized in that The second file includes: License file or custom file.

14. The method according to any one of claims 9 to 13, characterized in that The MDC, through the multiple DCUs, respectively, de-resetting the target processor in each DCU according to the third computing power configuration data includes: The MDC performs a validity check on the third computing power configuration data through each of the multiple DCUs; In a case where the third computing power configuration data passes the legality check, the MDC uses the multiple DCUs to reset the target processors in their respective DCUs according to the third computing power configuration data.

15. The method according to any one of claims 9 to 14, characterized in that The method further comprises: The MDC periodically determines, through the master DCU, whether the fourth computing power configuration data of each DCU in the multiple DCUs at the current moment is consistent; When there is inconsistency among the fourth computing power configuration data, the MDC verifies and aligns the fourth computing power configuration data through the master DCU.

16. A domain controller DCU, applied to a vehicle, characterized in that: The DCU includes: a receiving module, configured to receive first computing power configuration data corresponding to the DCU, sent by a cloud server or a host computer, wherein the DCU is any DCU on the vehicle, the DCU including at least one processor, the first computing power configuration data including a preset configuration quantity of at least one type of processor in the DCU, and the first computing power configuration data being updated via a local upgrade or a remote upgrade; The de-resetting module is used to de-reset the target processor in the DCU according to the first computing power configuration data to obtain the de-reset target processor, and the processors in the DCU except the target processor are in a dormant state.

17. The DCU according to claim 16, wherein: The DCU also includes: A processing module is used to process the perception information based on the target processor after the reset when the vehicle collects perception information through the sensor and the perception information belongs to the processing scope of the DCU.

18. The DCU according to any one of claims 16-17, characterized in that: The receiving module is specifically configured to: Receive a first file corresponding to the DCU sent by a cloud server or a host computer, where the first file includes the first computing power configuration data.

19. The DCU according to claim 18, wherein: The first file is an encrypted file.

20. The DCU according to any one of claims 18-19, characterized in that: The first file includes: License file or custom file.

21. The DCU according to any one of claims 16 to 20, characterized in that: The de-reset module is specifically used to: Performing a validity check on the first computing power configuration data; In a case where the first computing power configuration data passes the legality check, the target processor in the DCU is reset according to the first computing power configuration data.

22. The DCU according to any one of claims 16 to 21, characterized in that: The receiving module is further configured to: Backing up the first computing power configuration data at a first moment to obtain first backup data, where the first computing power configuration data is computing power configuration data at the first moment, and the first backup data is backup data at the first moment; The first computing power configuration data and the first backup data are respectively stored in different storage modules within the DCU.

23. The DCU according to claim 22, wherein: The receiving module is further configured to: periodically determining whether the second computing power configuration data and the second backup data are consistent, where the second computing power configuration data is the computing power configuration data at a current moment, and the second backup data is the backup data at the current moment; When the second computing power configuration data is inconsistent with the second backup data, the second computing power configuration data and the second backup data are verified and aligned.

24. A multi-domain controller (MDC), applied to a vehicle, characterized in that: The MDC includes: a receiving module, configured to receive, via a primary domain controller (DCU), third computing power configuration data corresponding to the MDC, sent by a cloud server or a host computer, where the MDC is any MDC on the vehicle, the MDC includes multiple DCUs, a primary DCU is one of the multiple DCUs, each of the multiple DCUs includes at least one processor, the third computing power configuration data includes a preset configuration quantity of at least one type of processor in each DCU, and the third computing power configuration data is updated via a local upgrade or a remote upgrade; a sending module, configured to send the third computing power configuration data to other DCUs in the plurality of DCUs except the main DCU through the main DCU; The de-resetting module is used to de-reset the target processor in each of the multiple DCUs according to the third computing power configuration data to obtain the de-reset target processor, and the processors in each of the DCUs except the target processor in the respective DCU are in a dormant state.

25. The MDC according to claim 24, wherein: The MDC also includes: A processing module is used to process the perception information based on the target processor after the reset when the vehicle collects the perception information through the sensor and the perception information belongs to the processing scope of the MDC.

26. The MDC according to any one of claims 24-25, characterized in that The receiving module is specifically configured to: The master DCU receives a second file corresponding to the MDC sent by the cloud server or the host computer, where the second file includes the third computing power configuration data.

27. The MDC according to claim 26, wherein: The second file is an encrypted file.

28. The MDC according to any one of claims 26-27, characterized in that The second file includes: License file or custom file.

29. The MDC according to any one of claims 24 to 28, characterized in that The de-reset module is specifically used to: Performing a validity check on the third computing power configuration data by each of the multiple DCUs; In a case where the third computing power configuration data passes the legality check, the multiple DCUs each reset the target processor in their respective DCUs according to the third computing power configuration data.

30. The MDC according to any one of claims 24 to 29, wherein: The receiving module is further configured to: Periodically determining, by the master DCU, whether the fourth computing power configuration data of each DCU in the multiple DCUs at the current moment is consistent; When there is inconsistency among the fourth computing power configuration data, the master DCU verifies and aligns the fourth computing power configuration data.

31. A domain controller DCU, comprising a processor and a memory, wherein the processor is coupled to the memory, wherein: The memory is used to store programs; The processor is configured to execute the program in the memory so that the DCU executes the method according to any one of claims 1 to 8.

32. A multi-domain controller (MDC), comprising a domain controller (DCU) and a memory, wherein the DCU comprises a processor coupled to the memory, wherein: The memory is used to store programs; The DCU is configured to execute the program in the memory through the processor, so that the MDC executes the method according to any one of claims 9 to 15.

33. A computer-readable storage medium comprising a program, characterized in that When the method is executed on a computer, the method enables the computer to execute the method according to any one of claims 1 to 8, or enables the computer to execute the method according to any one of claims 9 to 15.

34. A computer program product comprising instructions, characterized in that When the method is executed on a computer, the method enables the computer to execute the method according to any one of claims 1 to 8, or enables the computer to execute the method according to any one of claims 9 to 15.

Images