CN114691346B

CN114691346B - A method and device for configuring computing resources

Info

Publication number: CN114691346B
Application number: CN202011567735.4A
Authority: CN
Inventors: 周慧强
Original assignee: Huawei Technologies Co Ltd; Shenzhen Yinwang Intelligent Technology Co Ltd
Current assignee: Shenzhen Yinwang Intelligent Technology Co Ltd
Priority date: 2020-12-25
Filing date: 2020-12-25
Publication date: 2025-10-03
Anticipated expiration: 2040-12-25
Also published as: CN114691346A; WO2022134965A1

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

Method and equipment for configuring computing power resources

Technical Field

The application relates to the field of automatic driving, in particular to a method and equipment for configuring computing power resources.

Background

Automobiles have been developed for over one hundred years since the invention, become an indispensable part of life of people, and along with the improvement of living standard, the requirements of people on travelling comfort, convenience and the like are higher and higher, and the automobiles are evolved along with the intelligent direction. With the advent of automatic driving, since multiple sensors are required to be connected, fused, perceived, positioned, regulated, and other functions, a large amount of computing power is required to be provided by hardware, and the original distributed computing architecture of one function corresponding to one electronic control unit (electronic control unit, ECU) cannot adapt to the requirements, for example, data (also called perception information) such as a GPS, a camera, a laser radar, a millimeter wave radar, a wheel speed sensor, and the like, are all processed in one computing center to ensure that the output result is optimal for the automatic driving of the whole vehicle, so that domain controllers (domain control unit, DCU), multi-domain controllers (multi domain controller, MDC), and the like of a centralized structure gradually become development trends.

Autopilot processors, typically multi-core central processing units (central processing unit, CPU), graphics processors (graphics processing unit, GPU), video processors (video processing unit, VPU), neural network processors (neural network processing unit, NPU), tensor processing units (tensor processing unit, TPU), digital signal processing (DIGITAL SIGNAL processing, DSP) units, image signal processing (IMAGE SIGNAL processing, ISP) units, AI core, vector core, etc., a DCU may include one or more of the above (processor cores are also considered to be one type of processor). The DCU shown in fig. 1 includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores, and when the structure of one DCU is fixed, it means that the types of processors and the number of various types of processors included in the DCU are also fixed. Therefore, before the DCU leaves the factory, the total number of each type of processor included in the DCU is programmed as the computing power configuration data into the efuses in the DCU, such as x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores in fig. 1.

The method for configuring the computing power resources is to configure all processors (including processor cores) in the DCU, because computing power required by different subsequent automatic driving functions cannot be estimated accurately before the DCU leaves the factory, programming configuration can be performed only according to the maximum computing power resources, the large computing power resources are not needed in the actual application process of the DCU, resource waste is caused, and secondly, computing power configuration data are programmed in eFuses, wherein the eFuses are used as one-time programmable memories, and cannot be changed subsequently.

Disclosure of Invention

The embodiment of the application provides a method and equipment for configuring computing power resources, wherein computing power configuration data in the method can be sent by an upper computer providing unified diagnosis service (unified diagnostic services, UDS) when in near-end upgrading or by a cloud server providing Over The Air (OTA) when in far-end upgrading, and the method is used for realizing the adjustment of DCU computing power resources by adjusting the computing power configuration data according to requirements.

Based on the above, the embodiment of the application provides the following technical scheme:

In a first aspect, an embodiment of the present application firstly provides a method for configuring computing resources, which may be applied to the field of autopilot, netconnect automobile, etc., where the method includes that, firstly, a DCU receives first computing force configuration data corresponding to the DCU sent by a host computer or a cloud server, where the DCU is any DCU on a vehicle, where the DCU includes at least one processor, where the first computing force configuration data includes a preset configuration number of each type of processor in the DCU, where the preset configuration number may be set according to a consumption situation of historical computing resources of the DCU and a specific situation of an operation service of the DCU, and it is noted that, because each type of processor included in the DCU may be a multicore processor, for example, a Core including a plurality of CPUs, GPU cores, ISP cores, vector cores, etc. may be included in each type of processor, and in some embodiments, the DCU may also configure a Core number inside each type of processor, that is, where the Core may be implemented as a Core, and in some embodiments may refer to a general processor, the CPU may be a processor, as well as a general processor, and the CPU may be understood in the general processor, as a processor. In addition, the operating main frequency of each type of processor may be configured in the computing power configuration data, which is not limited in particular, that is, the computing power configuration data may be represented by configuring the number of each type of processor in the DCU, the operating main frequency of the processor, 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 upper computer or the cloud server, the DCU can reset the corresponding processor (which may be referred to as a target processor) in the DCU according to the first computing power configuration data, so as to obtain the target processor after the reset.

In the above embodiment of the present application, when the controller of the automatic driving vehicle is a DCU, the first calculation force configuration data supports the upper computer to update in a near-end upgrade mode (i.e., UDS) or a far-end upgrade mode (i.e., OTA), so that the first calculation force configuration data can be updated subsequently as required to implement adjustment of calculation force resources in the DCU, thereby supporting dynamic configuration appeal of the processor in driving service scenarios of different specifications subsequently, saving calculation force resources on the premise of ensuring smooth operation, avoiding the situation that the corresponding calculation force configuration data of the DCU can only be cured in efuses and enhancing the adaptability of continuous change of the driving service scenarios.

In one possible design of the first aspect, after the DCU decodes the target processor in the DCU based on the first power configuration data, in the case that the autonomous vehicle collects the sensing information through the sensor and the sensing information belongs to the processing category of the DCU, the DCU processes the collected sensing information based on the target processor obtained after the decoding and the resetting.

In the above embodiment of the present application, the DCU may process the corresponding perception information based on the target processor after the reset, where the perception information reflects the driving traffic scene, so the embodiment of the present application may enhance the adaptability of the driving traffic scene that changes continuously.

In one possible design of the first aspect, regardless of whether the first computing power configuration data is sent by the host computer or by the cloud server, the first computing power configuration data may be contained in one target file (which may be referred to as a first file) that is then sent by the host computer or by the cloud server to the DCU.

In the above embodiment of the present application, it is specifically described that the first calculation force configuration data may be included in the first file, so that a one-to-one correspondence between each independent DCU and the first calculation force configuration data is realized, which is convenient for control and management, and has realizability.

In one possible design of the first aspect, the first file is an encrypted file. It should be noted that, the encryption mode of the first file may be symmetric encryption, that is, the same key is used for encryption and decryption, or asymmetric encryption, that is, asymmetric encryption requires two keys, which are a public key and a private key, respectively, and if the public key is used for encrypting the data, the data can be decrypted only by the corresponding private key, and if the private key is used for encrypting the data, the data can be decrypted only by the corresponding public key. In the embodiment of the present application, the encryption manner is not limited.

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

In one possible design of the first aspect, the first file may be a License file of the DCU (each DCU has a License file), may be a file defined by a user in advance, or may be some files in a diagnostic service or related software update package of the OTA, and specifically, the type and format of the first file are not limited herein.

In the above embodiment of the present application, the user may select what type of file the first computing force configuration data is included on, as desired, with flexibility and selectivity.

In one possible design of the first aspect, the DCU may further perform a validity check on the first computing force configuration data, and in case the first computing force configuration data passes the validity check, de-reset the target processor in the DCU according to the first computing force configuration data. For example, the validity check may specifically be to check whether the first computing power configuration data is computing power configuration data corresponding to the DCU, check whether the first computing power configuration data has jump or falsification, check whether the first computing power configuration data has integrity, check whether the first file encryption process is abnormal when the first computing power configuration data is contained in the encrypted first file, check whether the encrypted first file can be decrypted, and check whether a data value range of the first computing power configuration data is within a normal range, or the like, if the DCU has 4 CPUs in total, and if the number of CPUs in the first computing power configuration data is 5, 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.

In the above embodiment of the present application, before the DCU resets the corresponding target processor in the DCU according to the first power configuration data, the DCU needs to perform validity check on the first power configuration data, so that an error and illegal data can be prevented from entering into a service, or can be found in time when the data is in error.

In one possible design of the first aspect, when the DCU receives the first computing force configuration data, the first computing force configuration data is backed up at a first moment to obtain first backup data, and the first computing force configuration data and the first backup data are respectively stored in different storage modules in the DCU, for example, in different storage media within the DCU or in different blocks in the same storage medium.

In the above embodiment of the present application, the DCU may further perform redundancy backup on the received first computing power configuration data, so as to improve the storage reliability of the data.

In one possible design of the first aspect, after the DCU stores the first calculation force configuration data and the first backup data in different storage modules in the DCU, the DCU may further periodically determine whether the second calculation force configuration data is consistent with the second backup data, where the second calculation force configuration data is calculation force configuration data at a current time, the second backup data is backup data at the current time, and in a case where the second calculation force configuration data is inconsistent with the second backup data, the DCU performs verification alignment on the second calculation force configuration data and the second backup data. For example, assuming that the setup period is 2 hours, assuming that the DCU receives the first calculation force configuration data and stores the first calculation force configuration data and the first backup data in the storage module 1 and the storage module 2 in the DCU at the first time 8:00, when the time is 10:00, the DCU may determine whether the first calculation force configuration data in the storage module 1 at the current time 10:00 (the first calculation force configuration data at the current time may be referred to as the second calculation force 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 may be referred to as the second backup data) are consistent, and if the second calculation force configuration data and the second backup data are inconsistent, the DCU performs verification alignment on the second calculation force configuration data and the second backup data so that the second calculation force configuration data and the second backup data are consistent with the first calculation force configuration data.

In the above embodiment of the present application, the DCU may also perform a check for the first calculation force configuration data and the first backup data in different storage modules in the DCU periodically, where the purpose of the check is to ensure the accuracy of the first calculation force configuration data, and at the same time, the first calculation force configuration data may be found and corrected in time when an error occurs in the data.

In a second aspect, the embodiment of the application firstly provides a configuration method of a computing power resource, which can be applied to the field of automatic driving and can be applied to intelligent automobiles, automatic driving automobiles, internet-connected automobiles and the like, and the method comprises the steps that firstly, the MDC receives third computing power configuration data corresponding to an upper computer or a cloud server sent by a main DCU in the MDC, the MDC deploys one MDC for any one MDC on a vehicle (generally, when the vehicle deploys only one MDC, the MDC is the one MDC), the main DCU comprises a plurality of DCUs, the main DCU is any one of the plurality of DCUs, each DCU comprises at least one processor (such as a CPU), and the third computing power configuration data comprises preset configuration quantity 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 the cloud server through the primary DCU, the third computing power configuration data may be further sent to other DCUs except the primary DCU in the first DMC. After each DCU in the MDC acquires the third calculation force configuration data, each DCU will reset the target processor in each DCU according to the acquired third calculation force configuration data, and the reset target processor is obtained.

In the above embodiment of the present application, when the controller of the automatic driving vehicle is an MDC, the third calculation power configuration data supports the upper computer to update in a near-end upgrade mode (i.e. UDS) or a far-end upgrade mode (i.e. OTA), so that the third calculation power configuration data can be updated subsequently as required to implement adjustment of calculation power resources in the MDC, thereby supporting dynamic configuration requirements of the processor in driving service scenarios of different specifications, saving calculation power resources on the premise of ensuring smooth operation, and solving the problem that the existing scheme can only configure calculation power resources of the DCU and cannot support a combined application scenario of the MDC composed of a plurality of DCUs.

In one possible design of the first aspect, after each DCU in the MDC decodes the target processor in the MDC based on the third computing power configuration data received by each DCU, if the autopilot vehicle collects the sensing information through the sensor and the sensing information belongs to the processing category of the MDC, the MDC processes the collected sensing information based on the target processor obtained after the decoding.

In the above embodiment of the present application, the target processor after the reset may process the corresponding perception information, where the perception information reflects the driving traffic scene, so that the embodiment of the present application may enhance the adaptability of the driving traffic scene that changes continuously.

In one possible design of the second aspect, regardless of whether the third computing power configuration data is sent by the host computer or by the cloud server, the third computing power configuration data may be contained in one target file (which may be referred to as a second file) that is then sent by the host computer or by the cloud server to the DCU.

In the above embodiment of the present application, it is specifically described that the third calculation force configuration data may be included in the second file, so that a one-to-one correspondence between each independent MDC and the third calculation force configuration data is realized, which is convenient for control and management, and has realizability.

In one possible design of the second aspect, the second file is an encrypted file. It should be noted that the encryption mode of the second file may be symmetric encryption, that is, the same key is used for encryption and decryption, or asymmetric encryption, that is, two keys are needed for asymmetric encryption, and the two keys are a public key and a private key respectively, if the public key is used for encrypting the data, the data can be decrypted only by the corresponding private key, and if the private key is used for encrypting the data, the data can be decrypted only by the corresponding public key. In the embodiment of the present application, the encryption manner is not limited.

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

In one possible design of the second aspect, the second file may be a License file of the MDC (each MDC has a License file), a file defined by the user in advance, or some files in the diagnostic service or related software update package of the OTA, where the type and format of the second file are not limited.

In the above embodiment of the present application, the user may select what type of file the third computing force configuration data is included on, as desired, with flexibility and selectivity.

In one possible design of the second aspect, the MDC may further perform validity check on the third power configuration data by each of the plurality of DCUs in the MDC, and in case that each of the third power configuration data passes the validity check, de-reset the target processor in each of the DCUs by each of the plurality of DCUs according to the third power configuration data. For example, the validity check may specifically be to check whether the third computing power configuration data is the computing power configuration data corresponding to the MDC, check whether the third computing power configuration data has jump or tampering, whether the third computing power configuration data has integrity, check whether the second file encryption process is abnormal, whether the encrypted second file is decryptable, and the like when the third computing power configuration data is included in the encrypted second file, and check whether the data value range of the third computing power configuration data is within a normal range, and the like. Only if the third computing power configuration data passes the validity check, each DCU in the MDC resets the corresponding target processor in the corresponding DCU according to the respective third computing power configuration data.

In the above embodiment of the present application, before each DCU in the MDC decodes and resets the corresponding target processor in the respective DCU according to the respective third computing power configuration data, the third computing power configuration data needs to be separately checked for validity, so that errors and illegal data can be prevented from entering into service, or can be found in time when the data is in error.

In one possible design of the second aspect, the MDC may further periodically determine, through the master DCU, whether the fourth computing power configuration data of each DCU in the plurality of DCUs at the current time is consistent, and if there is inconsistency in the fourth computing power configuration data, check and align the fourth computing power configuration data through the master DCU. For example, assuming that the MDC includes 3 DCUs, each of which is DCU ₁、DCU₂、DCU₃, and the setting period is 1 hour, assuming that the MDC receives the third calculation power configuration data through DCU ₁ (i.e., the master DCU) and sends the third calculation power configuration data to DCU ₂ and DCU ₃, and the DCU ₁、DCU₂、DCU₃ stores the respective third calculation power configuration data in the respective storage modules at the first time 7:30, when the time is 8:30, the DCU ₁ acquires the third calculation power configuration data on DCU ₂ and DCU ₃, and determines whether the third calculation power configuration data in the current time 8:30DCU ₁ and the third calculation power configuration data in the current time 8:30DCU ₂、DCU₃ (the third calculation power configuration data in each DCU at the current time may be referred to as fourth calculation power configuration data) are consistent, and if the fourth calculation power configuration data in each DCU is inconsistent, the MDC checks the fourth calculation power configuration data in each DCU through the master DCU to keep the fourth calculation power configuration data consistent.

In the above embodiment of the present application, the MDC may also perform a check for periodically checking the third calculation power configuration data stored in each of the different DCU storage modules in the MDC, where the purpose of the check is to ensure the accuracy of the third calculation power configuration data, and meanwhile, the third calculation power configuration data can be found and corrected in time when an error occurs in the data.

A third aspect of the embodiments of the present application provides a DCU, where the DCU may be applied to an intelligent car, an automatic driving car, a networked car, etc., and the DCU has a function of implementing the method of the first aspect or any one of the possible implementations of the first aspect. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

A fourth aspect of the embodiments of the present application provides an MDC, where the MDC may be applied to an intelligent car, an automatic driving car, a network-connected car, etc., and has a function of implementing a method of any one of the possible implementations of the second aspect or the second aspect. The functions can be realized by hardware, and can also be realized by executing corresponding software by hardware. The hardware or software includes one or more modules corresponding to the functions described above.

A fifth aspect of the embodiments of the present application provides a DCU, which may include a memory, a processor, and a bus system, where the memory is configured to store a program, and the processor is configured to call the program stored in the memory to perform the method of the first aspect or any one of the possible implementation manners of the first aspect of the embodiments of the present application.

A sixth aspect of the present embodiment provides an MDC, which may include a memory, a DCU and a bus system, where the DCU includes a processor, the memory is configured to store a program, and the processor is configured to call the program stored in the memory to perform the method of the second aspect or any one of the possible implementation manners of the second aspect of the present embodiment.

A seventh aspect of the application provides a computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of the first aspect or any of the possible implementations of the first aspect or cause the computer to perform the method of the second aspect or any of the possible implementations of the second aspect.

An eighth aspect of the embodiments of the present application provides a computer program which, when run on a computer, causes the computer to perform the method of the first aspect or any of the possible implementations of the first aspect, or causes the computer to perform the method of the second aspect or any of the possible implementations of the second aspect.

Drawings

FIG. 1 is a schematic diagram of a DCU including processor types and the number of processors of each type;

Fig. 2 is a schematic diagram of an architecture of a distributed automobile ECU according to an embodiment of the present application;

Fig. 3 is a schematic diagram of an architecture of an automotive DCU according to an embodiment of the present application;

fig. 4 is a schematic diagram of an architecture of an automotive MDC according to an embodiment of the application;

FIG. 5 is a flow chart of a current configuration of computing resources for a vehicle;

FIG. 6 is a schematic view of an autonomous vehicle according to an embodiment of the present application;

FIG. 7 is a flowchart of a method for configuring computing resources according to an embodiment of the present application;

fig. 8 is a schematic diagram of an upper computer sending corresponding first calculation force configuration data to a DCU in an autopilot vehicle through a CAN bus according to an embodiment of the present application;

Fig. 9 is a schematic diagram of a cloud server according to an embodiment of the present application sending corresponding first calculation force configuration data to a DCU in an autopilot vehicle through a wireless communication manner;

FIG. 10 is another flow chart of a method for configuring computing resources according to an embodiment of the present application;

Fig. 11 is a schematic diagram of an MDC provided in an embodiment of the application;

Fig. 12 is a schematic diagram of an upper computer sending corresponding third calculation force configuration data to an MDC in an autopilot vehicle through a CAN bus according to the embodiment of the application;

fig. 13 is a schematic diagram of a cloud server according to an embodiment of the present application sending corresponding third calculation power configuration data to an MDC in an autopilot vehicle through a wireless communication method;

FIG. 14 is a flowchart illustrating a specific configuration process of computing resources according to an embodiment of the present application;

Fig. 15 is a schematic structural diagram of a DCU according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of MDC provided in an embodiment of the application;

Fig. 17 is a schematic diagram of a configuration of a device (DCU or MDC) according to an embodiment of the application.

Detailed Description

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and are merely illustrative of the manner in which embodiments of the application have been described in connection with the description of the objects having the same attributes. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Embodiments of the present application relate to a number of relevant knowledge regarding computing power, and in order to better understand the schemes of embodiments of the present application, related terms and concepts that may be related to the embodiments of the present application are first described below. It should be understood that the related conceptual explanation may be limited by the specific embodiment of the present application, but it is not intended to limit the present application to this specific embodiment, and differences between different embodiments may exist, which is not limited herein.

(1) Electronic control unit (electronic control unit, ECU)

The ECU is also called a driving computer, a vehicle-mounted computer and the like, is also called a microcomputer controller special for an automobile in terms of application, is also called a singlechip special for the automobile, and is composed of a microprocessor (microcontroller Unit, MCU), a read-only memory (ROM), a random access memory (random access memory, RAM), an input/output interface (I/O), an analog-to-digital converter (A/D), and large-scale integrated circuits such as shaping, driving and the like, like a common computer. The structure of the ECU is relatively simple at first, and is mainly used for controlling the operation of a generator, the ECU gradually occupies the whole vehicle along with the electronic development of the vehicle, and gradually extends from an anti-lock brake system, a four-wheel drive system, an electric control automatic transmission, an active suspension system, an air bag system and the like to various safety, network, entertainment, sensing control, a power assembly, a vehicle motion system and the like of the existing vehicle body, and hundreds of ECUs, such as an ECU applied to an engine and an ECU applied to the anti-lock brake system, may exist on the whole vehicle, as shown in fig. 2, fig. 2 is a schematic diagram of the distributed automobile ECU provided by the embodiment of the application, and the functions of each ECU are relatively independent, and along with the development of digital automobiles, particularly automatic driving technologies, the ECU on the automobile gradually becomes complex and tends to be concentrated on a super ECU.

(2) Domain controller (domain control unit DCU)

The DCU divides the whole vehicle into several domains such as a power assembly, vehicle safety, vehicle body electronics, an intelligent cabin, intelligent driving and the like according to the functions of the vehicle electronics components, and utilizes a multi-core CPU, GPU and other processors with stronger processing capability to control each domain relatively intensively so as to replace the current distributed vehicle electronics architecture, as shown in fig. 3, fig. 3 is a schematic diagram of the architecture of the vehicle DCU provided by the embodiment of the present application, and generally, one DCU is used for controlling one domain.

The DCU is used for integrating function classification control, reducing line speed, modularizing an automobile control system and exchanging data among different DCUs by using a high-speed vehicle-mounted Ethernet, wherein the DCUs are all independently operated.

(3) Multi-domain controller (multi domain controller MDC)

With the continuous improvement of the automation degree of automobiles, data exchange among some control domains is more frequent, and higher real-time performance is required. For example, the autopilot module needs to detect the speed of the automobile in real time and adjust and control the speed according to the autopilot strategy in real time, and needs to complete the calculation in a high-performance domain controller, so that a controller including multiple domains, namely MDC, appears, as shown in fig. 4, and fig. 4 is a schematic diagram of the architecture of the MDC of the automobile according to the embodiment of the present application. For example, zFAS, which is commonly developed by audi and delfu, is that an ECU can access sensing information collected by different sensors, analyze and process the sensing information, and finally issue a control command. In general, an MDC is formed from multiple DCUs, one of which acts as a master DCU for data interaction by sending instructions to other DCUs within the MDC.

(4) Calculating force

The computing power is typically used to estimate the performance capability of a processor (e.g., CPU), typically measured in terms of number of executable operations per second, such as "trillion operations per second (tera operations per second, TOPS)", "floating-point operations per second (FLOPS)", "millions of instructions per second (million instructions per second, MIPS)", etc., for example, 1TOPS represents a processor that can perform trillion operations per second (10≡12).

(5) Calculation force configuration data

In the embodiment of the present application, if a single DCU works independently, the computing power configuration data described in the present application refers to the preset configuration number of each type of processor in the DCU. Taking fig. 1 as an example, assuming that the DCU includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI core in total, since the computing power resources of each type of processor are determined by the processor structure, the computing power resources of the corresponding processor can be estimated approximately according to the processor type and structure, and assuming that the preset configuration numbers of each type of processor in the DCU are x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core, respectively, where 0≤x ₀≤x+1,0≤y₀≤y+1,0≤m₀≤x+1,0≤n₀≤y+1, during the operation of the DCU, only x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core participate, and the remaining processors are in a dormant state, so that the computing power resources of the DCU during the operation can be estimated approximately according to the x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core, when the preset configuration numbers of a certain processor are 0, the DCU does not participate in the operation of the DCU.

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 may be estimated according to the computational power resources consumed by the historical operation of the DCU, so that the normal operation of the DCU may be ensured, and the computational power resources may be saved.

It is further noted that since each type of processor included in the DCU may be a multi-Core processor, for example, each type of processor may also include multiple CPU cores, GPU cores, ISP cores, vector cores, etc. within each type of processor, in some embodiments, the number of cores within each type of processor may also be configured. In addition, the operating main frequency of each type of processor may also be configured in the computing power configuration data, which is not particularly limited. Namely, the number of each type of processor in the DCU, the running main frequency of the processor and the number of each Core in the processor are configured to participate in specific automatic driving business, so that the controllable configuration capability of the computing power resource in the DCU is realized.

Similarly, in the embodiment of the present application, if the MDC is a single MDC that works independently, the computing power configuration data described in the present application refers to the preset configuration number of each type of processor in each DCU in the MDC. The manner of presetting the number of processor configurations of each type in each DCU in the MDC is similar to the manner of presetting the number of processor configurations of each type in the DCU, and will not be described herein.

(6) Upper computer

The upper computer refers to a computer device capable of directly sending out a control command, and in the embodiment of the present application, the computer device capable of communicating with the ECU, DCU or MDC based on the unified diagnostic service protocol (unified diagnosis service, UDS) may be referred to as an upper computer (may also be referred to as a diagnostic apparatus, a diagnostic machine, a diagnostic tool, etc.), for example, an intelligent handheld terminal device such as a personal computer (personal computer, PC), a mobile phone, a tablet computer, and an intelligent wearable device such as a smart bracelet, a smart watch, or even a single-chip microcomputer, so long as the device is capable of running corresponding diagnostic software, and the device capable of communicating with the ECU, DCU or MDC based on the UDS protocol may be used as the upper computer in the embodiment of the present application, which is not limited herein.

(7) Unified diagnostic services (unified diagnosis service, UDS)

In the automotive electronics and electrical (ELECTRICAL ELECTRONICS) field, the diagnostic function is one of the basic functions of ECU/DCU/MDC. The software or firmware refreshing of the ECU/DCU/MDC may be implemented by the diagnostic function support.

Development, adjustment, implementation and maintenance of different diagnostic communication protocols can bring unnecessary costs to the vehicle manufacturer, the system provider and the ECU/DCU/MDC provider. To solve this problem, different technical protocols and data communication principles are compiled into an international ISO standard, commonly referred to as UDS (also referred to as ISO 14229-1), which is a generic diagnostic protocol for automobiles, irrespective of data links, as shown in table 1, table 1 is a protocol applied by layers of the open system interconnection (open system interconnection, OSI) model, in which UDS is oriented to an application layer in the OSI model, and can be implemented on different automobile buses (e.g., CAN, LIN, flexray, ethernet, K-lines, etc.). At present, most automobile manufacturers adopt the diagnosis protocol of UDS on CAN, namely, a set of instruments (generally called an upper computer) is used for analyzing information/data in the ECU/DCU/MDC of the current automobile, and the language used by the set of instruments to talk with the ECU/DCU/MDC is UDS (not the only method).

TABLE 1 protocol applied by layers of OSI model

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

UDS is essentially a series of diagnostic services, which may be referred to as standard diagnostic services, defined by UDS, and includes a total of 26 of 6 classes, each standard diagnostic service having its own independent service identifier (SERVICE IDENTIFIER, SID), which is essentially a directed communication, is an interactive protocol in which the host sends a specified diagnostic request (request) to the ECU/DCU/MDC, which request needs to contain the SID, if it is a positive response, the ECU/DCU/MDC returns to the host a sid+0x40, e.g., the SID of the sent diagnostic request is 0x10, if it is a negative response, the ECU returns to the host a 0x7f+sid+nrc, the full name of NRC is Negative Response Code, i.e., if the ECU refuses a request, it returns to the host an NRC, and if it contains a different diagnostic service, it may contain a different NRC, different NRC.

Therefore, the diagnosis communication process based on the UDS is that the upper computer sends a diagnosis request (request) to the ECU/DCU/MDC, the ECU/DCU/MDC gives a diagnosis response (response), the diagnosis response comprises a positive response and a negative response, and the UDS defines a unified protocol format for the request and the response of different diagnosis services.

(8) Over The Air (OTA)

OTA refers to upgrading its own system by downloading a new software update package from a remote server (also referred to as a cloud server) over a network. That is, the software or firmware refreshes of the ECU/DCU/MDC may be updated by OTA of the network remote channel (i.e., remote upgrade) in addition to being supported by the diagnostic function (i.e., remote upgrade).

In the field of intelligent vehicles, the traditional vehicle has defects in the aspect of system in the running verification of users, but only one solution to the problems is that a vehicle manufacturer starts a recall program, the user returns to the factory to perform unified upgrading of the system after receiving the recall program, and the OTA technology can remotely complete defect repair in the form of a data packet, so that risks brought by continuous factory entering recall for several months are avoided. In addition, due to advanced hardware allocation in product design, the intelligent vehicle operating system can continuously start new functions gradually for vehicle owners through one-time OTA upgrading, optimize product experience, perform quick iteration and provide more excellent system service.

(9) Processor and method for controlling the same

In the embodiment of the present application, the processor may refer to a conventional processor such as CPU, GPU, NPU, or may refer to one or more of a CPU Core, a GPU Core, an ISP Core, a Vector Core, etc. included in the conventional processor, where an arithmetic unit, instruction fetching and decoding hardware, an instruction pipeline, and some cache memory are integrated into a "Core" according to the present application, where the Core may also be referred to as a Core. In the embodiment of the present application, since each type of processor included in the DCU may be a multi-Core processor, for example, each type of processor may also include a plurality of CPU cores, GPU cores, ISP cores, vector cores, and the like, that is, in the embodiment of the present application, the processor may refer to a processor Core in addition to a general CPU, GPU, and the like, that is, for convenience of understanding, the general processor and the processor Core are collectively referred to as a processor in the embodiment of the present application.

In addition, before the embodiment of the application is described, a configuration mode of the computing power resource currently applied to the vehicle is briefly described, so that the embodiment of the application is convenient to understand later.

As shown in fig. 5 in particular, assume that the processor types and numbers included in the DCU are m+1 CPUs, n+1 AI cores, k+1 Vector cores, and one eFuse, wherein the m+1 CPUs are respectively CPU ₀、CPU₁、…、CPU_m, the n+1 AI cores are respectively AI cores ₀、AI Core₁、…、AI Core_n, and the k+1 Vector cores are respectively Vector cores ₀、Vector Core₁、…、Vector Core_k. Before the DCU leaves the factory, the total number of the processors of each type in the DCU (i.e. m+1 CPUs, n+1 AI cores, k+1 Vector cores) is programmed into the eFuse as the calculation power configuration data, when the DCU is started to be powered on, one of the CPUs (for example, CPU ₀) is selected as the main CPU, after the main CPU initializes the relevant peripheral equipment, the calculation power configuration data is read from the eFuse, and then the other CPUs, AI cores and Vector cores are reset according to the read calculation power configuration data, so that the other processors respectively complete the initialization of the other processors, and thus, when the DCU is operated, all the processors in the DCU are called to process the relevant service data.

Because the application scene of the automatic driving function is very complex, the DCU cannot completely determine the calculation force resources required by the subsequent automatic driving function and the specific configuration quantity of each processor before leaving the factory, the calculation force configuration scheme of writing calculation force configuration data into eFuses only can carry out programming configuration according to the maximum calculation force resources, the large calculation force resources are not needed in the actual application process of the DCU, the resource waste is caused, in addition, the calculation force configuration data is programmed in the eFuses, the eFuses are used as one-time programmable memories, and the eFuses cannot be changed subsequently.

Based on this, in order to solve the above-mentioned problems, the embodiment of the present application first provides a method for configuring a computing power resource, where computing power configuration data in the method may be sent when a host computer providing a UDS performs a near-end upgrade or sent when a cloud server providing an OTA performs a far-end upgrade, so as to implement adjustment of the DCU computing power resource by adjusting the computing power configuration data as needed.

Embodiments of the present application will be described in detail below with reference to the accompanying drawings. As one of ordinary skill in the art can appreciate, with the development of technology and the appearance of new scenes, the technical solution provided by the embodiment of the present application is also applicable to similar technical problems.

The method for configuring the computing power resource provided by the embodiment of the application can be applied to the scene of performing motion planning (such as speed planning, driving behavior decision, global path planning, etc.) on various intelligent driving (such as unmanned driving, assisted driving, etc.) agents (such as intelligent automobiles, automatic driving automobiles, networked automobiles, etc.), taking the intelligent agents as the automatic driving automobiles as an example, describing specific functions of each structure in the automatic driving automobiles, specifically referring to fig. 6, fig. 6 is a schematic structural diagram of the automatic driving automobiles provided by the embodiment of the application, the automatic driving automobiles 100 are configured into a fully or partially automatic driving mode, for example, the automatic driving automobiles 100 can control themselves while in the automatic driving mode, and can determine the current state of the automobiles and the surrounding environment thereof through manual operation, determine the possible behavior of at least one other automobile in the surrounding environment, and determine the confidence level corresponding to the possibility of the other automobile to perform the possible behavior, and control the automatic driving automobiles 100 based on the determined information. While the autonomous vehicle 100 is in the autonomous mode, the autonomous vehicle 100 may also be configured to operate without human interaction.

The autonomous vehicle 100 may include various subsystems such as a travel system 102, a sensor system 104 (e.g., a camera, a SICK, a lidar, etc., all belonging to modules in the sensor system 104), a control system 106, one or more peripheral devices 108, and a power supply 110, a computer system 112, and a user interface 116. Alternatively, autonomous vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. In addition, each of the subsystems and components of autonomous vehicle 100 may be interconnected by wires or wirelessly.

The travel system 102 may include components that provide powered movement of the autonomous vehicle 100.

In one embodiment, the travel system 102 may include an engine 118, an energy source 119, a transmission 120, and wheels/tires 121.

The engine 118 may be an internal combustion engine, an electric motor, an air compression engine, or other types of engine combinations, such as a hybrid engine of a gasoline engine and an electric motor, or a hybrid engine of an internal combustion engine and an air compression engine. Engine 118 converts energy source 119 into mechanical energy. Examples of energy sources 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 to other systems of the autonomous vehicle 100. The transmission 120 may transmit 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. Wherein the drive shaft may comprise one or more axles that may be coupled to one or more wheels 121.

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 (which may be a global positioning GPS system, or a Beidou system or other positioning system), an inertial measurement unit (inertial measurement unit, IMU) 124, radar 126, laser rangefinder 128, and camera 130. The sensor system 104 may also include sensors (e.g., in-vehicle air quality monitors, fuel gauges, oil temperature gauges, etc.) that are monitored for internal systems of the autonomous vehicle 100. The sensed data from one or more of these sensors may be used to detect the object and its corresponding characteristics (location, shape, direction, speed, etc.). Such detection and identification is a key function of the safe operation of autonomous vehicle 100. In the embodiment of the present application, the laser sensing module is a sensing module that is very important in the sensor system 104.

Wherein the positioning system 122 may be used to estimate the geographic location of the autonomous vehicle 100. The IMU 124 is configured to sense changes in the position and orientation of the autonomous vehicle 100 based on inertial acceleration. In one embodiment, the IMU 124 may be a combination of an accelerometer and a gyroscope. The radar 126 may utilize radio signals to perceive objects within the surrounding environment of the autonomous vehicle 100, which may embody millimeter wave radar or lidar in particular. In some embodiments, radar 126 may be used to sense the speed and/or heading of an object in addition to sensing the object. The laser rangefinder 128 may utilize a laser to sense objects in the environment in which the autonomous vehicle 100 is located. In some embodiments, 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 may be used to capture a plurality of images of the surroundings of the autonomous vehicle 100. The camera 130 may be a still camera or a video camera.

The control system 106 is configured to control the operation of the autonomous vehicle 100 and its components. The 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 line control system 142, and an obstacle avoidance system 144.

Wherein the steering system 132 is operable to adjust the heading of the autonomous vehicle 100.

For example, in one embodiment may be a steering wheel system. The throttle 134 is used to control the operating speed of the engine 118 and thus the speed of the autonomous vehicle 100. The brake unit 136 is used to control the speed of the autonomous vehicle 100. The brake unit 136 may use friction to slow the wheel 121. In other embodiments, the braking unit 136 may convert the kinetic energy of the wheels 121 into electric current. The brake unit 136 may take other forms to slow the rotational speed of the wheels 121 to 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. The objects and/or features may include traffic signals, road boundaries, and obstacles. The computer vision system 140 may use object recognition algorithms, in-motion restoration structure (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 an environment, track objects, estimate the speed of objects, and so forth. The route control system 142 is used to determine the travel route and the travel 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, the lateral planning module 1421 and the longitudinal planning module 1422 being configured to determine a travel route and a travel speed for the autonomous vehicle 100 in conjunction with data from the obstacle avoidance system 144, the GPS 122, and one or more predetermined maps, respectively. The obstacle avoidance system 144 is operable to identify, evaluate, and avoid or otherwise override obstacles in the environment of the autonomous vehicle 100 that may embody, in particular, actual obstacles and virtual mobiles that may collide with the autonomous vehicle 100. In one example, control system 106 may additionally or alternatively include components other than those shown and described. Or some of the components shown above may be eliminated.

The autonomous vehicle 100 interacts with external sensors, other vehicles, other computing systems, or users through peripheral devices 108. Peripheral devices 108 may include a wireless communication system 146, a vehicle computer 148, a microphone 150, and/or a speaker 152. In some embodiments, the peripheral device 108 provides a means for a user of the autonomous vehicle 100 to interact with the user interface 116. For example, the vehicle computer 148 may provide information to a user of the autonomous vehicle 100. The user interface 116 is also operable with the vehicle computer 148 to receive user input. The vehicle computer 148 may be operated by a touch screen. In other cases, the peripheral device 108 may provide a means for the autonomous vehicle 100 to communicate with other devices located within the vehicle. For example, microphone 150 may receive audio (e.g., voice commands or other audio inputs) from a user of autonomous vehicle 100. Similarly, speaker 152 may output audio to a user of autonomous vehicle 100. The wireless communication system 146 may communicate wirelessly with one or more devices directly or via a communication network. For example, the wireless communication system 146 may use 3G cellular communications, such as CDMA, EVD0, GSM/GPRS, or 4G cellular communications, such as LTE. Or 5G cellular communication. The wireless communication system 146 may utilize wireless local area network (wireless local area network, WLAN) communication. In some embodiments, the wireless communication system 146 may utilize an infrared link, bluetooth, or ZigBee to communicate directly with the device. Other wireless protocols, such as various vehicle communication systems, for example, the wireless communication system 146 may include one or more dedicated short-range communication (DEDICATED SHORT RANGE COMMUNICATIONS, DSRC) devices, which may include public and/or private data communications between vehicles and/or roadside stations.

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

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 DCU116, the DCU116 including at least one processor 113 therein, the processor 113 executing instructions 115 stored in a non-transitory computer readable medium, such as 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. Processor 113 may be any conventional processor, such as commercially available CPU, GPU, VPU, NPU, DSP, ISP, etc., and what type of processor DCU116 includes and the number of processors depends on the domain under which DCU116 is controlling. Alternatively, the processor 113 may be a special purpose device such as an Application SPECIFIC INTEGRATED Circuit (ASIC) or other hardware-based processor. Although FIG. 6 functionally illustrates a processor, memory, and other components of computer system 112 in the same block, one of ordinary skill in the art will appreciate that the processor or memory may in fact comprise multiple processors or memories that are not stored within the same physical housing. For example, memory 114 may be a hard disk 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 component and the retarding component, may each have their own processor that performs only calculations related to the component-specific functions.

It should be noted that, in some embodiments of the present application, the computer system 112 may further include at least one MDC (not shown in fig. 6), where in general, one MDC is formed by multiple DCUs, and one of the multiple DCUs is used as a master DCU to send instructions to other DCUs in the MDC for data interaction.

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 a processor 113 disposed within the autonomous vehicle 100 and others are performed by a remote processor 113, including taking the necessary steps to perform a single maneuver.

In some embodiments, the memory 114 may contain instructions 115 (e.g., program logic) that the instructions 115 may be executed by the processor 113 to perform various functions of the autonomous vehicle 100, including those described above. The memory 114 may also contain additional instructions, including instructions to send data to, receive data from, interact with, and/or control one or more of the travel system 102, the sensor system 104, the control system 106, and the peripherals 108. In addition to instructions 115, memory 114 may store data such as road maps, route information, vehicle location, direction, speed, and other such vehicle data, as well as other information. Such 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 for providing information to or receiving information from a user of the autonomous vehicle 100. Optionally, the user interface 116 may include one or more input/output devices within the set of peripheral devices 108, such as a wireless communication system 146, a vehicle computer 148, a microphone 150, and a speaker 152.

The computer system 112 may control the functions of the autonomous vehicle 100 based on inputs 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 inputs 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, computer system 112 is operable to provide control over many aspects of autonomous vehicle 100 and its subsystems.

Alternatively, one or more of these components may be mounted separately from or associated with autonomous vehicle 100. For example, the memory 114 may exist partially or completely separate from the autonomous vehicle 100. The above components may be communicatively coupled together in a wired and/or wireless manner.

Alternatively, the above components are only an example, and in practical applications, components in the above modules may be added or deleted according to actual needs, and fig. 6 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, may identify objects within its surrounding environment to determine adjustments to the current speed. The object may be another vehicle, a traffic control device, or another type of object. In some examples, each identified object may be considered independently and based on its respective characteristics, such as its current speed, acceleration, spacing from the vehicle, etc., may be used to determine the speed at which the autonomous vehicle is to adjust.

Alternatively, the autonomous vehicle 100 or a computing device associated with the autonomous vehicle 100, such as the computer system 112, computer vision system 140, memory 114 of fig. 6, may predict the behavior of the identified object based on the characteristics of the identified object and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.). Alternatively, each identified object depends on each other's behavior, so all of the identified objects can also be considered together to predict the behavior of a single identified object. The autonomous vehicle 100 is able to adjust its speed based on the predicted behavior of the identified object. In other words, the autonomous vehicle 100 is able to determine what steady state the vehicle will need to adjust to (e.g., accelerate, decelerate, or stop) based on the predicted behavior of the object. In this process, the speed of autonomous vehicle 100 may also be determined in consideration of other factors, such as the lateral position of autonomous vehicle 100 in the road on which it is traveling, the curvature of the road, the proximity of static and dynamic objects, and so forth. 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 such that the autonomous vehicle 100 follows a given trajectory and/or maintains safe lateral and longitudinal distances from objects in the vicinity of the autonomous vehicle 100 (e.g., cars in adjacent lanes on a roadway).

The autopilot vehicle 100 may be a car, truck, motorcycle, bus, boat, airplane, helicopter, mower, recreational vehicle, casino vehicle, construction equipment, electric car, golf car, train, trolley, etc., and embodiments of the present application are not particularly limited.

The embodiment of the application provides a configuration method of computing power resources, which can be applied to scenes of motion planning (such as speed planning, driving behavior decision, global path planning and the like) of intelligent agents (such as general architecture of an automatic driving vehicle corresponding to fig. 6) for various intelligent driving (such as unmanned driving, auxiliary driving and the like), and in the embodiment of the application, the intelligent agents are taken as the automatic driving vehicle for illustration for the sake of convenience of understanding. In addition, when the DCU or the MDC is included in the autopilot vehicle, the configuration method of the computing power resource provided in the embodiment of the present application is slightly different, and the following description will be given respectively.

1. The controller in the automatic driving vehicle is DCU

Referring to fig. 7, fig. 7 is a flowchart of a method for configuring computing power resources according to an embodiment of the present application, which specifically includes the following steps:

701. the DCU receives first computing power configuration data which are sent by a cloud server or an upper computer and correspond to the DCU, the DCU is any one of the DCUs on the vehicle, the DCU comprises at least one processor, and the first computing power configuration data comprise preset configuration quantity of at least one type of processor in the DCU.

Firstly, a DCU receives first calculation force configuration data corresponding to the DCU, wherein the DCU is any DCU on a vehicle, the DCU comprises at least one processor, the first calculation force configuration data comprises preset configuration quantity of at least one type (for example, each type) of processor in the DCU, the preset configuration quantity can be set according to the consumption condition of historical calculation force resources of the DCU and the specific condition of operation business of the DCU, and the first calculation force configuration data supports an upper computer to update in a near-end upgrading mode (namely UDS) or a far-end upgrading mode (namely OTA), so that the first calculation force configuration data can be updated as required to realize adjustment of the calculation force resources of the DCU, and the calculation force resources are saved on the premise of ensuring smooth operation.

It should be noted that, in the embodiment of the present application, the computing power configuration data refers to a preset configuration number of each type of processor in the DCU. Taking fig. 1 as an example, assuming that the DCU includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI core in total, since the computing power resources of each type of processor are determined by the processor structure, the computing power resources of the corresponding processor can be estimated approximately according to the processor type and structure, and assuming that the preset configuration numbers of each type of processor in the DCU are x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core, respectively, where 0≤x ₀≤x+1,0≤y₀≤y+1,0≤m₀≤m+1,0≤n₀≤n+1, during the operation of the DCU, only x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core participate, and the remaining processors are in a dormant state, so that the computing power resources of the DCU during the operation can be estimated approximately according to the x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI core, when the preset configuration numbers of a certain processor are 0, the DCU does not participate in the operation of the DCU.

It is also noted that in some embodiments of the present application, the x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI cores involved in the operations 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 a total of 3 ISPs, 4 GPUs, 2 CPUs, and 6 AI cores in the DCU, the preset configuration numbers of the respective types of processors in the DCU are respectively 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 may be any 2 of the total 3 ISPs, similarly, the 2 GPUs may be any 2 of the total 4 GPUs, the 1 CPU may be any 1 of the total 2 CPUs, and the 3 AI cores may be any 3 of the total 6 AI cores.

It is also noted that in some embodiments of the present application, the number of cores within a processor that may belong to the same type may vary somewhat, and in this case, x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI cores that participate in the operation may define which of x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores are.

It is further noted that since each type of processor included in the DCU may be a multi-Core processor, for example, each type of processor may also include multiple CPU cores, GPU cores, ISP cores, vector cores, etc. within each type of processor, in some embodiments, the number of cores within each type of processor may also be configured. In addition, the operating main frequency of each type of processor may be configured in the computing power configuration data, which is not limited in particular, that is, the computing power configuration data may be represented by configuring the number of each type of processor in the DCU, the operating main frequency of the processor, and the number of cores in the processor.

It should be noted that, in some embodiments of the present application, the DCU receives the first computing force configuration data corresponding to the DCU may be obtained by the following several ways:

A. The first computing power configuration data is sent by the upper computer.

The software or firmware refreshing of the ECU/DCU/MDC may be implemented by the diagnostic function support. Therefore, the first calculation power configuration data may be included in a diagnostic service of the UDS, and when the host computer provides the diagnostic service to the DCU, the host computer sends the first calculation power configuration data to the DCU, as shown in fig. 8, fig. 8 illustrates that the host computer (fig. 8 illustrates a PC as an example) sends the first calculation power configuration data to the DCU in the autopilot vehicle through a controller area network (controller area network, CAN) bus, specifically, the host computer sends a diagnostic request (request), and the DCU on the autopilot vehicle gives a response (response), and during this communication, the host computer and the DCU respectively take roles of clients and servers in computer network communication.

B. The first computing force configuration data is sent by the cloud server.

The software or firmware refreshing of the ECU/DCU/MDC may be implemented by the diagnostic function support (i.e. the near-end upgrade), but may also be updated by the OTA of the network remote channel (i.e. the far-end upgrade), so that the first calculation power configuration data may also be stored on a cloud server providing OTA services, and when the cloud server provides OTA services to a vehicle in which the DCU is installed, the cloud server sends the first calculation power configuration data to the DCU, as shown in fig. 9, fig. 9 illustrates that the cloud server sends the corresponding first calculation power configuration data to the DCU in the autonomous vehicle by means of wireless communication.

It should be noted that, in some embodiments of the present application, whether the first computing force configuration data is sent by the upper computer or sent by the cloud server, the first computing force configuration data may be included in one target file (may be referred to as a first file), and then the upper computer or the cloud server sends the first file to the DCU, and the first computing force configuration data is included in the first file, so that a one-to-one correspondence between each independent DCU and the first computing force configuration data is achieved, which is convenient for control and management, and has feasibility.

It should be further noted that, the first file may be a License file of the DCU (each DCU has one License file), may be a file defined by the user in advance, or may be some files in the diagnostic service or related software update package of the OTA, and specifically, the type and format of the first file are not limited, so that the user may select what type of file the first computing configuration data is included in according to needs, which has flexibility and selectivity. In addition, the first file supports the upper computer to update in a near-end upgrading mode (namely UDS) or a far-end upgrading mode (namely OTA), so that the first calculation power configuration data can be updated conveniently according to the requirement, the adjustment of the DCU calculation power resource can be realized, and the calculation power resource can be saved on the premise that the smooth operation of the service is ensured.

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

It should be noted that the encryption mode of the first file may be symmetric encryption, that is, the same key is used for encryption and decryption, or asymmetric encryption, that is, asymmetric encryption requires two keys, that is, a public key and a private key, respectively, if the public key is used for encrypting the data, only the corresponding private key is used for decrypting, and if the private key is used for encrypting the data, only the corresponding public key is used for decrypting. In the embodiment of the present application, the encryption manner is not limited.

It should be further noted that, in some embodiments of the present application, after the DCU receives the first calculation force configuration data sent by the host computer or the cloud server, the first calculation force configuration data may be stored in the DCU storage module in a persistent manner, for example, the storage module may be a charged erasable programmable read-only memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY, EEPROM), flash memory, etc., where the persistent storage in the embodiment of the present application refers to storing the data (the first calculation force configuration data in the embodiment of the present application) in the storage module (such as a magnetic disk) that can be stored permanently, and the main application of the persistent storage is storing the object in the memory in the database, or storing the object in the magnetic disk file, the XML data file, etc. In the embodiment of the application, the original first computing power configuration data stored in the DCU memory module in a lasting manner is updated into the new first computing power configuration data only when the DCU receives the new first computing power configuration data again.

It should be further noted that, in some embodiments of the present application, in order to improve the reliability of data storage, the DCU may also perform redundancy backup on the received first computing force configuration data, specifically, when the DCU receives the first computing force configuration data, the first computing force configuration data is backed up at a first moment to obtain first backup data, and the first computing force configuration data and the first backup data are respectively stored in different storage modules in the DCU, for example, respectively stored in different storage media within the DCU or different blocks in the same storage medium.

It should be further noted that, in some embodiments of the present application, the checking and checking may be performed periodically with respect to the first computing power configuration data and the first backup data in different storage modules in the DCU. The purpose of the checking and checking is to ensure the accuracy of the first calculation configuration data, and meanwhile, when the data is wrong, the data can be found and corrected in time. For example, assuming that the setup period is 2 hours, assuming that the DCU receives the first calculation force configuration data and stores the first calculation force configuration data and the first backup data in the storage module 1 and the storage module 2 in the DCU at the first time 8:00, when the time is 10:00, the DCU may determine whether the first calculation force configuration data in the storage module 1 at the current time 10:00 (the first calculation force configuration data at the current time may be referred to as the second calculation force 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 may be referred to as the second backup data) are consistent, and if the second calculation force configuration data and the second backup data are inconsistent, the DCU performs verification alignment on the second calculation force configuration data and the second backup data so that the second calculation force configuration data and the second backup data are consistent with the first calculation force configuration data.

In some embodiments of the present application, the DCU has an automatic recovery capability, the DCU may detect which data has an error, assume that the DCU determines that the second computing power configuration data is inconsistent with the first computing power configuration data, indicate that the second computing power configuration data is inconsistent with the second backup data and the second computing power configuration data is correct, and perform backup on the second computing power configuration data to obtain corrected second backup data, thereby completing verification alignment of the second computing power configuration data and the second backup data, similarly, assume that the DCU determines that the second computing power configuration data is inconsistent with the first computing power configuration data, and indicate that the second computing power configuration data is inconsistent with the second backup data and the second backup data is correct, and perform backup on the second computing power configuration data as corrected second computing power configuration data, thereby completing the backup on the second computing power configuration data and the second backup data, and starting up the service from the remote end when the DCU is inconsistent with the first computing power configuration data or the second computing power configuration data is inconsistent with the first backup data, and the remote end is updated.

It should be noted that, in the embodiment of the present application, the DCU is any one DCU in the automatic driving vehicle, and in some embodiments of the present application, each DCU that works independently in the automatic driving vehicle may be used as the DCU to execute the process of step 701, so as to obtain the respective corresponding calculation force configuration data of each DCU in the automatic driving vehicle, and the specific process is similar to that of step 701 and will not be repeated herein.

702. And the DCU resets the target processor in the DCU according to the first computing power configuration data to obtain the reset target processor.

After the DCU receives the first computing power configuration data corresponding to the DCU sent by the upper computer or the cloud server, the DCU can reset the corresponding processor (which may be referred to as a target processor) in the DCU according to the first computing power configuration data, so as to obtain the target processor after the reset.

For ease of understanding, the following is still illustrated by way of example in FIG. 1, assuming 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 x ₀ ISPs, y ₀ GPUs, respectively, m ₀ CPUs and n ₀ AI cores, where 0≤x ₀≤x+1,0≤y₀≤y+1,0≤m₀≤m+1,0≤n₀≤n+1, that is, the first power configuration data of the DCU is x ₀ ISPs, y ₀ GPUs, m ₀ CPUs and n ₀ AI cores, and the first power configuration data is stored in a storage module in the DCU, and after the DCU is powered on, the first power configuration data is read from the storage module, and based on the first power configuration data, x ₀ ISPs are reset from the DCU, y ₀ GPUs, m ₀ CPUs and n ₀ AI cores, then during operation of the DCU, there are only x ₀ ISPs, y ₀ GPUs, m ₀ CPUs and n ₀ AI core participates, x ₀ ISPs, y ₀ GPUs, m ₀ CPUs and n ₀ AI cores are referred to as the target processor of the application, and the remaining processors are in a sleep state, thereby providing a system according to the x ₀ ISPs, The computing power resource of the DCU in the operation process can be estimated approximately by y ₀ GPUs, m ₀ CPUs and n ₀ AI cores, and when the preset configuration quantity of a certain processor is 0, the processor is not involved in the operation process of the DCU.

It should be noted that, in some embodiments of the present application, before the DCU decodes and resets the corresponding target processor in the DCU according to the first computing power configuration data, validity check needs to be performed on the first computing power configuration data, so that an error and illegal data can be avoided from entering into a service, or can be found in time when the data is in error. For example, the validity check may specifically be to check whether the first computing power configuration data is computing power configuration data corresponding to the DCU, check whether the first computing power configuration data has jump or falsification, check whether the first computing power configuration data has integrity, check whether the first file encryption process is abnormal when the first computing power configuration data is contained in the encrypted first file, check whether the encrypted first file can be decrypted, and check whether a data value range of the first computing power configuration data is within a normal range, or the like, if the DCU has 4 CPUs in total, and if the number of CPUs in the first computing power configuration data is 5, 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.

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

703. Under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category of the DCU, the DCU processes the perception information based on the target processor after the solution reset.

In some embodiments of the present application, after obtaining the target processor after the reset, step 703 may be further performed, that is, after the DCU resets the target processor in the DCU based on the first computing power configuration data, if the autonomous vehicle acquires the sensing information through the sensor and the sensing information belongs to the processing category of the DCU, the DCU processes the acquired sensing information based on the target processor obtained after the reset.

For ease of understanding, the following is still illustrated by way of example in FIG. 1, 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 power configuration data of the DCU is x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI cores, the target processors obtained by the reset are x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI cores, and finally the DCU processes the sensing information collected by the sensor (in the case that the sensing information belongs to the processing category of the DCU) based on the target processors (i.e., x ₀ ISPs, y ₀ GPUs, m ₀ CPUs, and n ₀ AI cores).

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

2. Controller in an autonomous vehicle is MDC

Referring to fig. 10, fig. 10 is another flow chart of a method for configuring computing power resources according to an embodiment of the present application, which specifically includes the following steps:

1001. The MDC receives third computing power configuration data corresponding to the MDC, which is sent by a cloud server or an upper computer, through a main DCU, wherein the MDC comprises a plurality of DCUs, the main DCU is one of the plurality of DCUs, each DCU of the plurality of DCUs comprises at least one processor, and the third computing power configuration data comprises preset configuration quantity of at least one type of processor in each DCU.

First, the MDC receives third calculation force configuration data corresponding to the MDC through a master DCU in the MDC, where the MDC is any one MDC on the vehicle (typically one MDC is deployed by one vehicle, and when only one MDC is deployed by the vehicle, the MDC is the one MDC), and the MDC includes a plurality of DCUs, where the master DCU is any one of the plurality of DCUs, each DCU includes at least one processor (e.g., a CPU), and the third calculation force configuration data includes a preset configuration number of processors of at least one type (e.g., may be of each type) in each DCU in the MDC.

For ease of understanding, the following is illustrated by way of example in FIG. 11 assuming that the MDC includes 3 DCUs, DCU ₁、DCU₂ and DCU ₃, respectively, wherein DCU ₁ includes m ₁ +1 CPUs, x ₁ +1 ISPs, y ₁ +1 GPUs and n ₁ +1 AI cores, the DCU ₂ includes m ₂ +1 CPUs, y ₂ +1 GPUs and n ₂ +1 Vector cores, DCU ₃ includes m ₃ +1 CPUs, x ₃ +1 ISPs, y ₃ +1 GPUs and n ₃ +1 Vector cores. Assume that the preset configuration number of each type of processor in the DCU ₁ in the MDC is m ₀₁ CPUs, x ₀₁ ISPs, respectively, y ₀₁ GPUs and n ₀₁ AI cores, wherein the preset configuration number of each type of processor in the DCU ₂ in the MDC is m ₀₂ CPUs respectively, y ₀₂ GPUs and n ₀₂ Vector cores, wherein the preset configuration number of each type of processor in the DCU ₃ in the MDC is m ₀₃ CPUs respectively, x ₀₃ ISPs, y ₀₃ GPUs and n ₀₃ Vector cores, wherein ,0≤m₀₁≤m₁+1,0≤x₀₁≤x₁+1,0≤y₀₁≤y₁+1,0≤n₀₁≤n₁+1,0≤m₀₂≤m₂+1,0≤y₀₂≤y₂+1,0≤n₀₂≤n₂+1,0≤m₀₃≤m₃+1,0≤x₀₃≤x₃+1,0≤y₀₃≤y₃+1,0≤n₀₃≤n₃+1. is only m ₀₁ CPUs in DCU ₁ during the MDC operation, x ₀₁ ISPs, y ₀₁ GPUs, n ₀₁ AI cores, and m ₀₂ CPUs in DCU ₂, y ₀₂ GPUs and n ₀₂ Vector cores, and m ₀₃ CPUs in DCU ₃, x ₀₃ ISPs, y ₀₃ GPUs and n ₀₃ Vector cores participate, and the remaining processors in each DCU are put into sleep, thereby providing a virtual machine according to m ₀₁ CPUs in the DCU ₁, x ₀₁ ISPs, y ₀₁ GPUs, n ₀₁ AI cores, and m ₀₂ CPUs in DCU ₂, y ₀₂ GPUs and n ₀₂ Vector cores, and m ₀₃ CPUs in DCU ₃, The computing power resources of the MDC during operation can be estimated approximately by x ₀₃ ISPs, y ₀₃ GPUs and n ₀₃ Vector cores, and when the preset configuration number of a certain processor in a certain DCU is 0, the processor is indicated not to participate in the MDC during operation.

It is also noted that in some embodiments of the present application, m ₀₁ CPUs, x ₀₁ ISPs, y ₀₁ GPUs, in the participating DCU ₁, n ₀₁ AI cores, m ₀₂ CPUs in DCU ₂, y ₀₂ GPUs and n ₀₂ Vector cores, and m ₀₃ CPUs in DCU ₃, x ₀₃ ISPs, y ₀₃ GPUs and n ₀₃ Vector cores are not limited to which of the DCUs ₁、DCU₂、DCU₃, for example, assuming a total of 3 ISPs in the DCU ₁ in the MDC, the preset configuration numbers of the respective types of processors in the DCU ₁ are respectively 2 ISPs, 2 GPUs, 1 CPU and 3 AI cores, that is, the portion of the third computing power configuration data corresponding to the DCU ₁ is2 ISPs, 2 GPUs, 1 CPU and 3 AI cores, so that the 2 ISPs may be any 2 of the total 3 ISPs, similarly, the 2 GPUs may be any 2 of the total 4 GPUs, the 1 CPU may be any 1 of the total 2 CPUs, and the 3 AI cores may be any 3 of the total 6 AI cores. Similarly, the portion of the third computing force configuration data corresponding to DCU ₂、DCU₃ is similar to DCU ₁ and is not described in detail herein.

It should also be noted that in some embodiments of the present application, the number of cores that may belong to the same type of processor may vary slightly, and in this case, taking DCU ₁ as an example, x ₀₁ ISPs, y ₀₁ GPUs, m ₀₁ CPUs, and n ₀₁ AI cores that participate in the operation may define which of x ₁ +1 ISPs, y ₁ +1 GPUs, m ₁ +1 CPUs, and n ₁ +1 AI cores.

It should be noted that, in some embodiments of the present application, the MDC receives the third calculation power configuration data corresponding to the MDC may be obtained in several ways as follows:

A. the third calculation force configuration data is sent by the upper computer.

The software or firmware refreshing of the ECU/DCU/MDC may be implemented by the diagnostic function support. Therefore, the third calculation configuration data may be included in the diagnostic service of the UDS, and when the host computer provides the diagnostic service to the MDC, the host computer sends the third calculation configuration data to the main DCU in the MDC, as shown in fig. 12, fig. 12 illustrates that the host computer (fig. 12 illustrates a PC as an example) sends the third calculation configuration data to the MDC in the autopilot through the CAN bus, specifically, the host computer sends the diagnostic request, and the MDC on the autopilot gives a response through the main DCU, where the host computer and the MDC are roles of clients and servers in computer network communication, respectively.

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

The software or firmware refreshing of the ECU/DCU/MDC may be carried out by the diagnostic function support (i.e. the near-end upgrade), but also by the OTA of the network remote channel (i.e. the far-end upgrade), so that the third calculation power configuration data may be stored on a cloud server providing OTA services, and when the cloud server provides OTA services to a vehicle in which the MDC is installed, the cloud server transmits the third calculation power configuration data to the MDC, as shown in fig. 13, and fig. 13 illustrates that the cloud server transmits the corresponding third calculation power configuration data to the main DCU in the MDC in the automatic driving vehicle by means of wireless communication.

It should be noted that, in some embodiments of the present application, whether the third calculation force configuration data is sent by the upper computer or by the cloud server, the third calculation force configuration data may be included in one target file (may be referred to as a second file), and then the upper computer or the cloud server sends the second file to the main DCU in the MDC, and the third calculation force configuration data is included in the second file, so that a one-to-one correspondence between each independent MDC and the third calculation force configuration data is achieved, which is convenient for control and management, and has feasibility.

It should be further noted that, the second file may be a License file of the MDC (each MDC has one License file), may be a file defined by the user in advance, or may be some files in the diagnostic service or related software update package of the OTA, and specifically, the type and format of the first file are not limited, so that the user may select what type of file the first computing configuration data is included in according to needs, which has flexibility and selectivity. In addition, the second file supports the upper computer to update in a near-end upgrading mode (namely UDS) or a far-end upgrading mode (namely OTA), so that the third calculation power configuration data can be updated conveniently according to the requirement, the adjustment of MDC calculation power resources can be realized, and the calculation power resources can be saved on the premise that the smooth operation of the service is ensured.

It should be further noted that, in some embodiments of the present application, the second file may be an encrypted file, so as to prevent the third computing power configuration data from being modified at will, thereby improving the security of the data.

It should be noted that the encryption mode of the second file may be symmetric encryption, that is, the same key is used for encryption and decryption, or asymmetric encryption, that is, asymmetric encryption requires two keys, namely, a public key and a private key, which are respectively used for encryption, and decryption is only performed with the corresponding private key if the data is encrypted with the public key, and decryption is only performed with the corresponding public key if the data is encrypted with the private key. In the embodiment of the present application, the encryption manner is not limited.

It should be further noted that, in some embodiments of the present application, after the MDC receives, through the main DCU, the third calculation power configuration data sent by the host computer or the cloud server, the third calculation power configuration data may be stored in the MDC memory module in a persistent manner, for example, the memory module may be an EEPROM, a Flash memory, etc., where in the persistent manner, the data (the first calculation power configuration data according to the embodiment of the present application) is stored in the permanently storable memory module (such as a disk), and the main application of the persistent manner is to store the object in the memory in the database, or store the object in the disk file, the XML data file, etc. In the embodiment of the application, the original third computing power configuration data stored in the MDC memory module in a lasting mode is updated into the new third computing power configuration data only when the MDC receives the new third computing power configuration data again.

1002. The MDC transmits the third computing power configuration data to other DCUs of the plurality of DCUs, except the master DCU, through the master DCU.

After the MDC receives the third calculation power configuration data from the host computer or the cloud server through the primary DCU, the third calculation power configuration data may be further sent to other DCUs except the primary DCU in the first DMC, still taking fig. 11 as an example, and assuming that DCU ₁ is the primary DCU, after the DCU ₁ receives the third calculation power configuration data, the third calculation power configuration data is sent to the DCU ₂ and the DCU ₃, and after the DCU ₂ and the DCU ₃ receive the third calculation power configuration data, the third calculation power configuration data are respectively stored in respective storage modules, so that redundant backup is implemented by storing the third calculation power configuration data in each DCU in the MDC, and the storage reliability of the data is improved.

It should be noted that, in some embodiments of the present application, in order to save storage space and realize redundancy backup of data, the MDC may also send the third calculation configuration data to one other DCU in the MDC except the main CDU through the main DCU, still taking fig. 11 as an example, and assuming that DCU ₁ is the main DCU, after DCU ₁ receives the third calculation configuration data, it may send the third calculation configuration data to DCU ₂ (or DCU ₃), and DCU ₂ (or DCU ₃) receives the third calculation configuration data and stores the third calculation configuration data in its own storage module, and when the MDC is powered on and works normally, DCU ₃ that does not obtain the third calculation configuration data reads the third calculation configuration data from DCU ₁ at any time. In summary, in the MDC, it is only necessary to ensure that the third computing power configuration data is stored in at least 2 storage modules of the DCU in the MDC.

It should also be noted that in some embodiments of the present application, the verification may also be performed periodically with respect to the third computing power configuration data stored in each of the different DCU storage modules in the MDC. The purpose of the checking and checking is to ensure the accuracy of the third calculation configuration data, and meanwhile, when the data is wrong, the data can be found and corrected in time. For example, still referring to FIG. 11, assuming that the setup period is 1 hour, assuming that the MDC receives the third calculation power configuration data through the DCU ₁ (i.e., the main DCU) and sends the third calculation power configuration data to the DCU ₂ and the DCU ₃, and the DCU ₁、DCU₂、DCU₃ stores the respective third calculation power configuration data in the respective storage modules at the first time 7:30, when the time is 8:30, the DCU ₁ acquires the third calculation power configuration data on the DCU ₂ and the DCU ₃, and determines whether the third calculation power configuration data in the current time 8:30DCU ₁ and the third calculation power configuration data in the current time 8:30DCU ₂、DCU₃ (the third calculation power configuration data in each DCU at the current time may be referred to as fourth calculation power configuration data) are consistent, and when the fourth calculation power configuration data in each DCU are inconsistent, the MDC checks the fourth calculation power configuration data in each DCU through the main DCU to keep the fourth calculation power configuration data consistent.

Similarly, the manner of checking and aligning the fourth computing force configuration data is similar to the manner of checking and aligning the second computing force configuration data and the second backup data by the DCU, which is described above, and detailed description thereof will be omitted herein.

It should be noted that, in the embodiment of the present application, the MDC is any MDC in the autonomous vehicle, and in some embodiments of the present application, each independently operating MDC in the autonomous vehicle may be used as the MDC to execute the process of steps 1001-1002, so as to obtain the calculation force configuration data corresponding to each MDC in the autonomous vehicle, and the specific process is similar to the steps 1001-1002 and is not repeated herein.

1003. And the MDC resets the target processor in each DCU according to the third calculation force configuration data through each of the plurality of DCUs to obtain the reset target processor.

After each DCU in the MDC obtains the third calculation power configuration data, each DCU will reset the target processor in the respective DCU according to the third calculation power configuration data obtained by each DCU, so as to obtain the target processor after the reset, and how the MDC resets the target processor in the respective DCU according to the third calculation power configuration data is similar to the step 702 described above, which is not repeated herein.

It should be noted that, in some embodiments of the present application, before each DCU in the MDC decodes and resets the corresponding target processor in the respective DCU according to the respective third computing power configuration data, the third computing power configuration data needs to be separately checked for validity, so that errors and illegal data can be avoided from entering into the service, or can be found in time when the data is in error. For example, the validity check may specifically be to check whether the third computing power configuration data is the computing power configuration data corresponding to the MDC, check whether the third computing power configuration data has jump or tampering, whether the third computing power configuration data has integrity, check whether the second file encryption process is abnormal, whether the encrypted second file is decryptable, and the like when the third computing power configuration data is included in the encrypted second file, and check whether the data value range of the third computing power configuration data is within a normal range, and the like. Only if the third computing power configuration data passes the validity check, each DCU in the MDC resets the corresponding target processor in the corresponding DCU according to the respective third computing power configuration data.

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

1004. Under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category of the MDC, the MDC processes the perception information based on the target processor after the reset.

In some embodiments of the present application, after obtaining the target processor in the MDC after the reset, step 1004 may further be performed, that is, after each DCU in the MDC resets the target processor in the MDC based on the third calculation power configuration data received by each DCU, when the autopilot vehicle collects the sensing information through the sensor and the sensing information belongs to the processing category of the MDC, the MDC processes the collected sensing information based on the target processor obtained after the reset.

To further understand the above solution, a specific configuration process of the DCU computing resource is described below in three stages by taking an example in which a controller in the autopilot vehicle is a DCU as an example, and referring to fig. 14, fig. 14 is a schematic flow chart of a specific configuration process of the DCU computing resource provided in an embodiment of the present application, where the configuration process specifically includes a computing configuration data storage stage, a computing configuration data loading stage, and a computing configuration data synchronization stage, the DCU _w is any one of DCUs ₀～DCU_v in the autopilot vehicle, the DCU _w includes a CPU ₀～CPU_m(CPU₀ as a main CPU)、Vector Core₀～Vector Core _k、AI Core₀～AI Core _k、ISP₀～ISP_x、GPU₀～GPU_y、 storage module and a hardware security module (hardware security module, HSM), and steps 1401-1403 are computing configuration data storage stages, steps 1404-1047 are computing configuration data loading stages, and steps are computing configuration data synchronization stage 1408.

1401. Proximal or distal upgrades.

The near-end upgrade process (or the far-end upgrade process) is triggered between the upper computer (or the cloud server) and the automatic driving vehicle, and the computing power configuration data corresponding to the DCU _w is contained in the License file encrypted by the DCU _w and sent to the CPU ₀ in the upgrade process, so that the one-to-one correspondence between the DCU _w and the computing power configuration data corresponding to the DCU is realized, the encrypted License file can prevent the computing power configuration data from being randomly modified, and the safety of the data is improved.

1402. CPU ₀ sends a secure access authentication to the HSM.

The CPU ₀ transmits the secure access authentication to the HSM, and after passing the authentication, performs step 1403.

1403. The CPU ₀ permanently stores the encrypted License file in the storage module.

The encrypted License file is sent to the storage module of the DCU _w in a mode of near-end upgrade or far-end upgrade, the License file is backed up to obtain a backup file, and the License file and the backup file are stored in different areas (or in different storage modules) in the storage module in a lasting mode.

1404. The CPU ₀ reads the encrypted License file from the storage module.

After DCU _w powers up, the DCU _w reads the encrypted License file from the memory module via CPU ₀ before the autopilot business model is loaded.

1405. CPU ₀ decrypts the License file.

After the CPU ₀ reads the License file from the storage module, it decrypts the License, and verifies whether the decrypted License file is the License file of the DCU _w.

1406. The CPU ₀ performs validity check on the calculation power configuration data.

In the case where the CPU ₀ verifies that the decrypted License file is the License file of the DCU _w, the CPU ₀ acquires the calculation power configuration data in the decrypted License file and performs validity verification on the calculation power configuration data.

1407. The CPU ₀ de-resets the corresponding target processor according to the computing power configuration data.

Specifically, the CPU ₀ sequentially resets the corresponding other CPUs, resets the corresponding Vector cores, resets the corresponding AI cores, resets the corresponding ISPs, and resets the corresponding GPUs according to the computing power configuration data. The target processor in the DCU _w after the solution reset can process the acquired sensing information, that is, load the driving business model based on the target processor after the solution reset.

1408. The CPU ₀ periodically checks the check against the License file and the backup file.

The CPU ₀ periodically checks and verifies the calculation force configuration data in the License file and the calculation force configuration data in the backup file, and automatically performs data alignment processing under the condition that the calculation force configuration data in the License file is inconsistent with the calculation force configuration data in the backup file.

In order to better implement the above-described scheme of the embodiment of the present application on the basis of the embodiments corresponding to fig. 7 and 14, a related apparatus for implementing the above-described scheme is further provided below. Referring to fig. 15 specifically, fig. 15 is a schematic structural diagram of a DCU provided by the embodiment of the present application, where the DCU1500 may be applied to a vehicle (e.g., an intelligent automobile, an automatic driving automobile, a network connection automobile, etc.), and the DCU1500 may specifically include a receiving module 1501 and a resetting module 1502, where the receiving module 1501 is configured to receive first calculation force configuration data corresponding to the DCU, the DCU is any DCU on the vehicle, the DCU includes at least one processor, the first calculation force configuration data includes a preset configuration number of at least one type of processor in the DCU, the preset configuration number may be set according to consumption conditions of historical calculation force resources of the DCU and specific conditions of operation services of the DCU, and the resetting module 1502 is configured to reset a corresponding processor (may be referred to as a target processor) in the DCU according to the first calculation force configuration data, so as to obtain a target processor after the resetting.

In one possible design, the DCU1500 may further include a processing module 1503, where the processing module 1503 is configured to process the acquired sensing information based on the target processor obtained after the resetting when the sensing information is acquired by the sensor of the autopilot vehicle and the sensing information belongs to the processing category of the DCU.

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

In the above embodiment of the present application, it is specifically explained that the first calculation force configuration data may be included in one target file (i.e., the first file), and then the upper computer or the cloud server sends the first file to the DCU, and the first calculation force configuration data is included in the first file, so that a one-to-one correspondence between each independent DCU and the first calculation force configuration data is achieved, which is convenient for control and management, and has feasibility.

In one possible design, the first file is an encrypted file.

In one possible design, the first file may be a License file of the DCU (each DCU has a License file), a file defined by the user in advance, or some files in the diagnostic service or related software update package of the OTA, where the type and format of the first file are not limited.

In one possible design, the de-reset module 1502 is specifically configured to perform a validity check on the first computing power configuration data, and de-reset the target processor in the DCU according to the first computing power configuration data if the first computing power configuration data passes the validity check. For example, the validity check may specifically be to check whether the first computing power configuration data is computing power configuration data corresponding to the DCU, check whether the first computing power configuration data has jump or falsification, check whether the first computing power configuration data has integrity, check whether the first file encryption process is abnormal when the first computing power configuration data is contained in the encrypted first file, check whether the encrypted first file can be decrypted, and check whether a data value range of the first computing power configuration data is within a normal range, or the like, if the DCU has 4 CPUs in total, and if the number of CPUs in the first computing power configuration data is 5, 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.

In the above embodiment of the present application, before the solution resetting module 1502 resets the corresponding target processor in the DCU according to the first computing power configuration data, validity check needs to be performed on the first computing power configuration data, so that errors and illegal data can be avoided from entering into the service, or can be found in time when the data is in error.

In one possible design, the receiving module 1501 is further configured to backup the first computing power configuration data at a first time to obtain first backup data, where the first computing power configuration data is computing power configuration data at a first time, and the first backup data is backup data at the first time, and store the first computing power configuration data and the first backup data in different storage modules in the DCU respectively.

In the above embodiment of the present application, the receiving module 1501 may further perform redundancy backup on the received first computing force configuration data, so as to improve the storage reliability of the data.

In one possible design, the receiving module 1501 is further configured to periodically determine whether second calculation force configuration data is consistent with second backup data, where the second calculation force configuration data is calculation force configuration data at a current time, and the second backup data is backup data at the current time, and if the second calculation force configuration data is inconsistent with the second backup data, check and align the second calculation force configuration data with the second backup data.

In the above embodiment of the present application, the receiving module 1501 may also perform checking and checking periodically on the first computing power configuration data and the first backup data in different storage modules in the DCU, where the purpose of the checking and checking is to ensure the accuracy of the first computing power configuration data, and meanwhile, when an error occurs in the data, the data can be found and corrected in time.

It should be noted that, in the DCU1500 according to the embodiment of fig. 15, the contents of information interaction and execution process between each module/unit are based on the same concept as those of the method embodiment of fig. 7 and 14, and specific contents may be referred to the description of the foregoing method embodiment of the present application, which is not repeated here.

Similarly, in order to better implement the above-described scheme of the embodiment of the present application on the basis of the embodiment corresponding to fig. 10, a related apparatus for implementing the above-described scheme is also provided below. Referring specifically to fig. 16, fig. 16 is a schematic structural diagram of an MDC provided in an embodiment of the present application, where the MDC1600 may be applied to a vehicle (e.g., an intelligent vehicle, an automatic driving vehicle, a network connection vehicle, etc.), and the MDC1600 may specifically include a receiving module 1601, a sending module 1602, and a resetting module 1603, where the receiving module 1601 is configured to receive, by a master DCU in the MDC, third calculation force configuration data corresponding to the MDC, where the MDC is any one MDC on the vehicle (typically, when the vehicle deploys only one MDC, the MDC is the one MDC), where the master DCU is any one of the plurality of DCUs, and each DCU includes at least one processor (e.g., a CPU), and the third calculation force configuration data includes a number of configurations of at least one type of processor in each DCU, and the sending module 1602 is configured to, by the master DCU, reset the third calculation force configuration data to the respective one DCU, to the respective other DCU is configured to obtain, by the respective resetting module 1603, by the respective reset data.

In one possible design, the MDC1600 may further include a processing module 1604, where the processing module 1604 is configured to process the perception information based on the target processor after the de-reset if the vehicle acquires the perception information through a sensor and the perception information falls into the processing category of the MDC.

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

In the above embodiment of the present application, it is specifically explained that the third calculation power configuration data may be included in one target file (i.e., the second file), and then the upper computer or the cloud server sends the second file to the MDC, and the third calculation power configuration data is included in the second file, so that a one-to-one correspondence between each independent MDC and the third calculation power configuration data is realized, which is convenient for control and management, and has feasibility.

In one possible design, the second file is an encrypted file.

In one possible design, the second file may be a License file of the MDC (each MDC has a License file), a file defined by the user in advance, or some files in the diagnostic service or related software update package of the OTA, where the type and format of the second file are not limited.

In one possible design, the de-reset module 1603 is specifically configured to perform validity check on the third computing power configuration data by using the DCUs, and in case that the third computing power configuration data passes the validity check, de-reset the target processor in the DCU by using the DCUs according to the third computing power configuration data.

In one possible design, the receiving module 1601 is further configured to periodically determine, by the master DCU, whether the fourth calculation force configuration data of each DCU in the plurality of DCUs at the current time is consistent, and if the fourth calculation force configuration data is inconsistent, check alignment of the fourth calculation force configuration data by the master DCU.

In the above embodiment of the present application, the receiving module 1601 may also perform a check for periodically checking the third calculation power configuration data stored in each of the different DCU storage modules in the MDC, where the purpose of the check is to ensure the accuracy of the third calculation power configuration data, and meanwhile, the third calculation power configuration data can be found and corrected in time when an error occurs in the data.

It should be noted that, in the MDC1600 according to the embodiment of fig. 16, the contents of information interaction and execution process between each module/unit are based on the same concept as the method embodiment of fig. 10, and specific contents may be referred to the description in the foregoing method embodiment of the present application, which is not repeated here.

The embodiment of the present application further provides a device, which may be a DCU or an MDC, and referring to fig. 17, fig. 17 is a schematic structural diagram of the device (DCU or MDC) provided in the embodiment of the present application, and for convenience of explanation, only the portion relevant to the embodiment of the present application is shown, and specific technical details are not disclosed, and reference is made to a method portion of the embodiment of the present application. The module of the DCU described in the corresponding embodiment of fig. 15 may be deployed on the device 1700, for implementing the function of the DCU in the corresponding embodiment of fig. 7 or fig. 14, and the module of the MDC described in the corresponding embodiment of fig. 16 may also be deployed on the device 1700, for implementing the function of the MDC in the corresponding embodiment of fig. 10, which is not limited herein specifically.

In particular, device 1700 is implemented by one or more servers, which device 1700 may vary considerably in configuration or performance, and may include one or more central processing units (central processing units, CPUs) 1722 (e.g., one or more) and memory 1732, one or more storage mediums 1730 (e.g., one or more mass storage devices) that store applications 1742 or data 1744. Wherein the memory 1732 and storage medium 1730 may be transitory or persistent storage. The program stored on the storage medium 1730 may include one or more modules (not shown), each of which may include a series of instruction operations in the device 1700. Further, the central processor 1722 may be arranged to communicate with a storage medium 1730 to execute a series of instruction operations in the storage medium 1730 on the device 1700.

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/output interfaces 1758, and/or one or more operating systems 1741, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, and the like.

In the embodiment of the present application, if the device 1700 is a DCU, the steps performed by the DCU in the embodiments corresponding to fig. 7 and 14 may be implemented based on the structure shown in fig. 17, and if the device 1700 is an MDC, the steps performed by the MDC in the embodiment corresponding to fig. 10 may be implemented based on the structure shown in fig. 17, which is not described herein in detail.

It should be further noted that the above-described apparatus embodiments are merely illustrative, and that the units described as separate units may or may not be physically separate, and that units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the embodiment of the device provided by the application, the connection relation between the modules represents that the modules have communication connection, and can be specifically implemented as one or more communication buses or signal lines.

From the above description of the embodiments, it will be apparent to those skilled in the art that the present application may be implemented by means of software plus necessary general purpose hardware, or of course by means of special purpose hardware including application specific integrated circuits, special purpose CPUs, special purpose memories, special purpose components, etc. Generally, functions performed by computer programs can be easily implemented by corresponding hardware, and specific hardware structures for implementing the same functions can be varied, such as analog circuits, digital circuits, or dedicated circuits. But a software program implementation is a preferred embodiment for many more of the cases of the present application. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a readable storage medium, such as a floppy disk, a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk or an optical disk of a computer, etc., including instructions for causing a computer device (which may be a personal computer, a training device, a network device, etc.) to execute the method according to the embodiments of the present application.

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

The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may 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 may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be stored by a computer or a data storage device such as a training device, a data center, or the like that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a solid-state disk (solid-state drive STATE DISK, SSD)), or the like.

Claims

1. A method for configuring a computing power resource, applied to a vehicle, comprising:

the method comprises the steps that a domain controller DCU receives first calculation force configuration data which is sent by a cloud server or an upper computer and corresponds to the DCU, the DCU is any one DCU on a vehicle, the DCU comprises at least one processor, the first calculation force configuration data comprises preset configuration quantity of at least one type of processor in the DCU, and the first calculation force configuration data is updated through near-end upgrade or far-end upgrade;

And the DCU resets the target processors in the DCU according to the first computing power configuration data to obtain the reset target processors, and the processors except the target processors in the DCU are in a dormant state.

2. The method according to claim 1, wherein the method further comprises:

And under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category of the DCU, the DCU processes the perception information based on the target processor after the reset.

3. The method according to any one of claims 1-2, wherein the receiving, by the domain controller DCU, first computing power configuration data corresponding to the DCU sent by a cloud server or an upper computer includes:

The DCU receives a first file corresponding to the DCU, which is sent by a cloud server or an upper computer, wherein the first file contains the first computing power configuration data.

4. A method according to claim 3, wherein the first file is an encrypted file.

5. The method of any of claims 3-4, wherein the first file comprises:

license file or custom file.

6. The method of any of claims 1-5, wherein the DCU de-resetting a target processor in the DCU from the first computing power configuration data comprises:

the DCU performs validity check on the first calculation power configuration data;

and under the condition that the first computing power configuration data passes the validity check, the DCU de-resets the target processor in the DCU according to the first computing power configuration data.

7. The method of any of claims 1-6, wherein prior to the DCU de-resetting a target processor in the DCU according to the first computing power configuration data, the method further comprises:

The DCU backs up the first calculation force configuration data at a first moment to obtain first backup data, wherein the first calculation force configuration data is calculation force 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 in the DCU respectively.

8. The method of claim 7, wherein after the DCU stores the first computing force configuration data and the first backup data separately in different storage modules within the DCU, the method further comprises:

The DCU periodically judges whether second calculation force configuration data is consistent with second backup data or not, wherein the second calculation force configuration data is calculation force configuration data at the current time, and the second backup data is backup data at the current time;

and in the case that the second computing force configuration data is inconsistent with the second backup data, checking and aligning the second computing force configuration data with the second backup data.

9. A method for configuring a computing power resource, applied to a vehicle, comprising:

The method comprises the steps that a multi-domain controller MDC receives third calculation force configuration data corresponding to an MDC sent by a cloud server or an upper computer through a main domain controller DCU, the MDC is any one of the MDCs on a vehicle, the MDC comprises a plurality of DCUs, the main DCU is one of the plurality of DCUs, each of the plurality of DCUs comprises at least one processor, the third calculation force configuration data comprises preset configuration quantity of at least one type of processor in each DCU, and the third calculation force configuration data is updated through near-end upgrade or far-end upgrade;

The MDC sends the third computing power configuration data to other DCUs except the main DCU in the plurality of DCUs through the main DCU;

And the MDC resets the target processor in each DCU through the plurality of DCUs according to the third computing power configuration data to obtain the reset target processor, and the processors in each DCU except the target processor in each DCU are in a dormant state.

10. The method according to claim 9, wherein the method further comprises:

And under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category 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-10, wherein the receiving, by the multi-domain controller MDC via the main domain controller DCU, third computing power configuration data corresponding to the MDC, sent by the cloud server or by the host computer, comprises:

And the MDC receives a second file corresponding to the MDC, which is sent by a cloud server or an upper computer, through the main DCU, wherein the second file contains the third computing power configuration data.

12. The method of claim 11, wherein the second file is an encrypted file.

13. The method of any of claims 11-12, wherein the second file comprises:

license file or custom file.

14. The method of any of claims 9-13, wherein the MDC, through the plurality of DCUs, each de-resetting a target processor in a respective DCU according to the third computing power configuration data comprises:

The MDC performs validity check on the third calculation power configuration data through the DCUs respectively;

And under the condition that the third calculation force configuration data passes the validity check, the MDC de-resets the target processor in each DCU through each of the plurality of DCUs according to the third calculation force configuration data.

15. The method according to any one of claims 9-14, further comprising:

the MDC periodically judges whether the fourth calculation force configuration data of each DCU in the plurality of DCUs at the current moment is consistent or not through the main DCU;

And in the case that the fourth calculation force configuration data are inconsistent, the MDC performs verification alignment on the fourth calculation force configuration data through the main DCU.

16. A domain controller DCU for use in a vehicle, the DCU comprising:

The system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving first computing power configuration data which is sent by a cloud server or an upper computer and corresponds to the DCU, the DCU is any DCU on the vehicle, the DCU comprises at least one processor, the first computing power configuration data comprises preset configuration quantity of at least one type of processor in the DCU, and the first computing power configuration data is updated through near-end upgrade or far-end upgrade;

And the resetting module is used for resetting the target processor in the DCU according to the first computing power configuration data to obtain the reset target processor, and the processors except the target processor in the DCU are in a dormant state.

17. The DCU of claim 16, wherein the DCU further comprises:

and the processing module is used for processing the perception information based on the target processor after the solution reset under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category of the DCU.

18. The DCU according to any of the claims 16-17, wherein the receiving module is specifically configured to:

and receiving a first file corresponding to the DCU, which is sent by a cloud server or an upper computer, wherein the first file contains the first computing power configuration data.

19. The DCU of claim 18, wherein the first file is an encrypted file.

20. The DCU of any of claims 18-19, wherein the first file comprises:

license file or custom file.

21. The DCU of any of claims 16-20, wherein the de-reset module is specifically configured to:

Performing validity check on the first calculation force configuration data;

And under the condition that the first computing power configuration data passes the validity check, resetting the target processor in the DCU according to the first computing power configuration data.

22. The DCU of any of claims 16-21, wherein the receiving module is further configured to:

Backing up the first calculation force configuration data at a first moment to obtain first backup data, wherein the first calculation force configuration data is calculation force configuration data at the first moment, and the first backup data is backup data at the first moment;

And respectively storing the first computing power configuration data and the first backup data in different storage modules in the DCU.

23. The DCU of claim 22, wherein the receiving module is further configured to:

periodically judging whether second calculation force configuration data is consistent with second backup data, wherein the second calculation force configuration data is calculation force configuration data at the current time, and the second backup data is backup data at the current time;

24. A multi-domain controller MDC for use in a vehicle, the MDC comprising:

The system comprises a receiving module, a cloud server and a host computer, wherein the receiving module is used for receiving third calculation force configuration data corresponding to MDC (MDC) sent by the cloud server or the host computer through a main Domain Controller (DCU), the MDC is any one of the MDCs on the vehicle, the MDC comprises a plurality of DCUs, the main DCU is one of the plurality of DCUs, each of the plurality of DCUs comprises at least one processor, the third calculation force configuration data comprises preset configuration quantity of at least one type of processor in each DCU, and the third calculation force configuration data is updated through near-end upgrade or far-end upgrade;

a sending module, configured to send, by the master DCU, the third computing power configuration data to other DCUs of the plurality of DCUs except the master DCU;

and the resetting module is used for resetting the target processors in the DCUs according to the third computing power configuration data respectively to obtain the reset target processors, and the processors in the DCUs except the target processors in the DCUs are in a dormant state.

25. The MDC of claim 24, wherein the MDC further comprises:

and the processing module is used for processing the perception information based on the target processor after the solution reset under the condition that the vehicle acquires the perception information through the sensor and the perception information belongs to the processing category of the MDC.

26. The MDC according to any of claims 24-25, wherein the receiving module is specifically configured to:

and receiving a second file corresponding to the MDC, which is sent by a cloud server or an upper computer, through the main DCU, wherein the second file contains the third computing power configuration data.

27. The MDC of claim 26, wherein the second file is an encrypted file.

28. The MDC of any of claims 26-27, wherein the second file comprises:

license file or custom file.

29. The MDC of any of claims 24-28, wherein the de-reset module is specifically configured to:

performing validity check on the third calculation power configuration data through each of the plurality of DCUs;

And under the condition that the third computing power configuration data passes the validity check, the target processor in each DCU is reset through each DCU according to the third computing power configuration data.

30. The MDC of any of claims 24-29, wherein the receiving module is further configured to:

periodically judging whether the fourth calculation force configuration data of each DCU in the plurality of DCUs at the current time is consistent or not through the main DCU;

and under the condition that the fourth calculation force configuration data are inconsistent, checking and aligning the fourth calculation force configuration data through the main DCU.

31. A domain controller DCU comprising a processor and a memory, said processor being coupled to said memory, characterized in that,

The memory is used for storing programs;

The processor configured to execute a program in the memory, so that the DCU performs the method according to any of claims 1-8.

32. A multi-domain controller MDC comprising a domain controller DCU and a memory, said DCU comprising a processor, said processor being coupled to said memory, characterized in that,

The memory is used for storing programs;

the DCU for executing a program in the memory by the processor, causing the MDC to perform the method of any of claims 9-15.

33. A computer readable storage medium comprising a program which, when run on a computer, causes the computer to perform the method of any one of claims 1-8 or causes the computer to perform the method of any one of claims 9-15.

34. A computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any one of claims 1-8 or cause the computer to perform the method of any one of claims 9-15.