WO2022134965A1 - 一种算力资源的配置方法及设备 - Google Patents

一种算力资源的配置方法及设备 Download PDF

Info

Publication number
WO2022134965A1
WO2022134965A1 PCT/CN2021/131386 CN2021131386W WO2022134965A1 WO 2022134965 A1 WO2022134965 A1 WO 2022134965A1 CN 2021131386 W CN2021131386 W CN 2021131386W WO 2022134965 A1 WO2022134965 A1 WO 2022134965A1
Authority
WO
WIPO (PCT)
Prior art keywords
dcu
configuration data
computing power
power configuration
mdc
Prior art date
Application number
PCT/CN2021/131386
Other languages
English (en)
French (fr)
Inventor
周慧强
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2022134965A1 publication Critical patent/WO2022134965A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present application relates to the field of autonomous driving, and in particular, to a method and device for configuring computing resources.
  • processors for autonomous driving usually multi-core central processing unit (CPU), graphics processing unit (GPU), video processing unit (VPU), neural network processing unit (neural network processing) unit, NPU), tensor processing unit (tensor processing unit, TPU), digital signal processing (digital signal processing, DSP) unit, image signal processing (image signal processing, ISP) unit, AI core, Vector core, etc.
  • a DCU One or more of the processors described above may be included (a processor core is also considered a type of processor).
  • the DCU shown in Figure 1 includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. When the structure of a DCU is fixed, it means that the DCU includes processors.
  • the type and the number of processors of each type have also been fixed. Since the computing power resources of each type of processor are determined by the structure of the processor itself, the computing power of the corresponding processor can be roughly estimated according to the type and structure of the processor. resource. Therefore, before the DCU leaves the factory, the total number of processors of various types included in the DCU is used as the computing power configuration data to be programmed into the eFuse in the DCU, as shown in Figure 1. x+1 ISP, y+1 GPU , m+1 CPUs and n+1 AI cores are the computing power configuration data.
  • the above computing power resource allocation method is to configure all processors (including processor cores) in the DCU. This is because the computing power required by different automatic driving functions cannot be accurately estimated before the DCU leaves the factory.
  • the programming configuration is performed according to the maximum computing power resources. In the actual application process of the DCU, it may not need to use such a large computing power resource, resulting in a waste of resources; secondly, the computing power configuration data is programmed in eFuse, eFuse As a one-time programmable memory, it cannot be changed later.
  • Embodiments of the present application provide a method and device for configuring computing power resources.
  • the computing power configuration data in the method can be sent by a host computer that provides unified diagnostic services (UDS) when performing a near-end upgrade, or can be sent over the air by a host computer that provides unified diagnostic services (UDS). It is sent when the downloaded (over the air, OTA) cloud server performs a remote upgrade, and is used to adjust the computing power resources of the DCU by adjusting the computing power configuration data as needed.
  • UDS unified diagnostic services
  • OTA unified diagnostic services
  • the embodiments of the present application first provide a method for configuring computing resources, which can be applied to the field of autonomous driving, and can be applied to smart cars, autonomous vehicles, connected cars, etc.
  • the method includes: first, the DCU receives The first computing power configuration data corresponding to the DCU sent by the host computer or the cloud server, where the DCU is any DCU on the vehicle, the DCU includes at least one processor, and the first computing power configuration data includes each type of the DCU
  • the preset configuration number of the processor, the preset configuration number can be set according to the consumption of historical computing power resources of the DCU and the specific situation of the running business of the DCU. It should be noted that due to the various types of The processor can be a multi-core processor.
  • each type of processor may also include multiple CPU Cores, GPU Cores, ISP Cores, Vector Cores, etc. that is, in some embodiments of the present application, the processor may refer to not only ordinary processors such as CPUs and GPUs, but also processor cores, that is, the above-mentioned various Cores. It is understood that, in the embodiments of the present application, a common processor and a processor core are collectively referred to as a processor.
  • the operating frequency of each type of processor can also be configured in the computing power configuration data, which is not specifically limited, that is, the computing power configuration data can be configured by configuring the number of processors of each type in the DCU, The main frequency and the number of cores in the processor are characterized.
  • the DCU After the DCU receives the first computing power configuration data corresponding to the DCU sent by the host computer or the cloud server, it can de-reset the corresponding processor (which may be called the target processor) in the DCU according to the first computing power configuration data. , so as to obtain the de-reset target processor.
  • the corresponding processor which may be called the target processor
  • the first computing power configuration data supports the upper computer to be updated through a near-end upgrade method (ie UDS) or a remote upgrade method (ie OTA), so that subsequent
  • the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, which avoids the situation that the corresponding computing power configuration data of the DCU can only be fixed in the eFuse and cannot be modified, and enhances the adaptability of the changing driving business scenarios in the follow-up.
  • the autonomous vehicle collects sensing information through sensors, and the sensing information belongs to the DCU.
  • the DCU processes the collected sensing information based on the target processor obtained after the above-mentioned de-reset.
  • the DCU can process the corresponding perception information based on the de-reset target processor, and the perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of changing driving business scenarios.
  • the first computing power configuration data may be included in a target file (which may be referred to as the first file), then the host computer or the cloud server sends the first file to the DCU.
  • the first computing power configuration data can be included in the first file, and the one-to-one correspondence between each independent DCU and the first computing power configuration data is realized, which is convenient for control and management. , is achievable.
  • the first file is an encrypted file.
  • the encryption method of the first file can be symmetric encryption, that is, the same secret key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two secret keys. The two keys are the public key and the private key. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the corresponding public key can be used to decrypt the data. key to decrypt.
  • the encryption method is not limited.
  • the first file may be an encrypted file, so as to prevent the first computing power configuration data from being arbitrarily modified, thereby improving the security of the data.
  • the first file may be a license file of the DCU (each DCU has a license file), or a file defined by the user in advance, or a file in the diagnostic service or For some files in the relevant software update package of the OTA, the type and format of the first file are not limited here.
  • the user can choose what type of file the first computing power configuration data is included in according to needs, which has flexibility and selectivity.
  • the DCU may further perform validity check on the first computing power configuration data, and in the case that the first computing power configuration data passes the validity check, according to the first computing power
  • the configuration data de-resets the target processor in the DCU.
  • the validity check may specifically include: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether the first computing power configuration data has jumps or tampering; the first computing power configuration data Whether it has integrity; when the first computing power configuration data is included in the encrypted first file, check whether the encryption process of the first file is abnormal, whether the encrypted first file can be decrypted, etc.; Whether the data value range of the power configuration data is within the normal range, etc.
  • the DCU de-resets the corresponding target processor in the DCU according to the first computing power configuration data.
  • the DCU before the DCU de-resets the corresponding target processor in the DCU according to the first computing power configuration data, it is also necessary to check the validity of the first computing power configuration data, which can avoid errors and illegality.
  • the data enters the service, or can be detected in time when the data is wrong.
  • the DCU when the DCU receives the first computing power configuration data, it backs up the first computing power configuration data at the first moment to obtain the first backup data, and stores the first computing power configuration data.
  • the computing power configuration data and the first backup data are respectively stored in different storage modules in the DCU, for example, in different storage media in the DCU or different blocks in the same storage medium.
  • the DCU may further perform redundant backup on the received first computing power configuration data, so as to improve the storage reliability of the data.
  • the DCU may also periodically determine whether the second computing power configuration data is different from the second computing power configuration data. Whether the second backup data is consistent, the second computing power configuration data is the computing power configuration data at the current moment, the second backup data is the backup data at the current moment, and between the second computing power configuration data and the second backup data In the case of inconsistency, the DCU verifies and aligns the second computing power configuration data and the second backup data.
  • the DCU receives the first computing power configuration data and stores the first computing power configuration data and the first backup data in the storage module 1 in the DCU at 8:00 at the first time. And in the storage module 2, when the time is 10:00, the DCU will judge the first computing power configuration data in the storage module 1 at 10:00 at the current time (the first computing power configuration data at the current moment can be called the first computing power configuration data.
  • the DCU verifies and aligns the second computing power configuration data and the second backup data, so that the second computing power configuration data and the second backup data are kept with the first computing power configuration data. Consistent.
  • the DCU may also periodically check and verify the first computing power configuration data and the first backup data in different storage modules in the DCU.
  • the purpose of checking and checking is to ensure the first computing power configuration The accuracy of the data, and at the same time, when the data is wrong, it can be detected and corrected in time.
  • the embodiments of this application first provide a method for configuring computing resources, which can be applied to the field of autonomous driving, and can be applied to smart cars, autonomous vehicles, connected cars, etc.
  • the method includes: first, MDC passes The main DCU in the MDC receives the third computing power configuration data corresponding to the MDC sent by the host computer or the cloud server. , then the MDC is the one MDC), the MDC includes multiple DCUs, wherein the main DCU is any one of the multiple DCUs, each DCU includes at least one processor (eg, CPU), the third computing power configuration data It includes the preset configuration number of each type of processor in each DCU in the MDC.
  • MDC passes The main DCU in the MDC receives the third computing power configuration data corresponding to the MDC sent by the host computer or the cloud server.
  • the MDC is the one MDC
  • the MDC includes multiple DCUs, wherein the main DCU is any one of the multiple DCUs, each DCU includes at least one processor (eg, CPU), the
  • the MDC may further send the third computing power configuration data to other DCUs in the first DMC except the main DCU.
  • each DCU in the MDC After each DCU in the MDC has obtained the third computing power configuration data, then each DCU will de-reset the target processor in the respective DCU according to the third computing power configuration data obtained, and obtain the de-reset target processor .
  • the third computing power configuration data supports the host computer to update through the near-end upgrade method (ie UDS) or the remote upgrade method (ie OTA), so that subsequent The third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, and solves the combined application scenario that the existing solution can only configure the computing resources of the DCU but cannot support the MDC composed of multiple DCUs.
  • the MDC processes the collected sensing information based on the target processor obtained after the above-mentioned de-reset.
  • the corresponding perception information can also be processed based on the target processor after reset, and the perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of the constantly changing driving business scenario.
  • the third computing power configuration data may be included in a target file (which may be referred to as the second file), and then the host computer or the cloud server sends the second file to the DCU.
  • the third computing power configuration data can be included in the second file, which realizes the one-to-one correspondence between each independent MDC and the third computing power configuration data, which is convenient for control and management. , is achievable.
  • the second file is an encrypted file.
  • the encryption method of the second file can be symmetric encryption, that is, the same secret key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two secret keys. The two keys are the public key and the private key. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the corresponding public key can be used to decrypt the data. key to decrypt.
  • the encryption method is not limited.
  • the second file may be an encrypted file, so as to prevent the third computing power configuration data from being arbitrarily modified, thereby improving the security of the data.
  • the second file may be a license file of the MDC (each MDC has a license file), or a file defined by the user in advance, or a file in the diagnostic service or For some files in the relevant software update package of the OTA, the type and format of the second file are not limited here.
  • the user can choose what type of file the third computing power configuration data is included in according to needs, which has flexibility and selectivity.
  • the MDC may further perform legality verification on the third computing power configuration data through multiple DCUs in the MDC, and when each third computing power configuration data passes the legality verification In this case, each of the multiple DCUs de-resets the target processors in the respective DCUs according to the third computing power configuration data.
  • the validity check may specifically be: checking whether the third computing power configuration data is the computing power configuration data corresponding to the MDC; checking whether the third computing power configuration data has jumps or tampering; the third computing power configuration data Whether it has integrity; when the third computing power configuration data is included in the encrypted second file, check whether the encryption process of the second file is abnormal, whether the encrypted second file can be decrypted, etc.; Whether the data value range of the force configuration data is within the normal range, etc. Only when the third computing power configuration data passes the validity check, each DCU in the MDC de-resets the corresponding target processors in the respective DCUs according to the respective third computing power configuration data.
  • the third computing power configuration data needs to be checked for validity. , which can prevent erroneous and illegal data from entering the service, or can be detected in time when the data is wrong.
  • the MDC may also periodically determine through the main DCU whether the configuration data of each fourth computing power at the current moment in each DCU in the multiple DCUs is consistent. If the configuration data is inconsistent, the main DCU verifies and aligns each fourth computing power configuration data.
  • the MDC includes 3 DCUs, namely DCU 1 , DCU 2 , and DCU 3 , and the setting period is 1 hour
  • the MDC receives the third computing power configuration data through DCU 1 (ie, the main DCU) and calculates the third computing power
  • the power configuration data is sent to DCU 2 and DCU 3 , and DCU 1 , DCU 2 , and DCU 3 store their respective third computing power configuration data in their respective storage modules at the first time 7:30, which is 8:30: At 30:00, DCU 1 will obtain the third computing power configuration data on DCU 2 and DCU 3 , and determine the third computing power configuration data in DCU 1 at the current time 8:30 and the third computing power configuration data in DCU 2 and DCU 3 at the current time 8:30.
  • the third computing power configuration data (the third computing power configuration data in each DCU at the current moment may be referred to as the fourth computing power configuration data) is consistent, and in the case that the fourth computing power configuration data in each DCU is inconsistent,
  • the MDC verifies and aligns the fourth computing power configuration data in each DCU through the main DCU, so that the fourth computing power configuration data in each DCU is consistent.
  • the MDC may also periodically check and verify the third computing power configuration data stored in different DCU storage modules in the MDC.
  • the purpose of checking and verifying is to ensure the third computing power configuration data.
  • the accuracy of the data can also be detected and corrected in time when data errors occur.
  • a third aspect of the embodiments of the present application provides a DCU, the DCU can be applied to a smart car, an autonomous car, a connected car, etc., and the DCU has a method for implementing the first aspect or any possible implementation manner of the first aspect function.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a fourth aspect of the embodiments of the present application provides an MDC, which can be applied to smart cars, self-driving cars, connected cars, etc., and the MDC has a method for implementing the second aspect or any possible implementation manner of the second aspect function.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a fifth aspect of an embodiment of the present application provides a DCU, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call a program stored in the memory to execute the first aspect of the embodiment of the present application or A method for any possible implementation of the first aspect.
  • a sixth aspect of an embodiment of the present application provides an MDC, which may include a memory, a DCU, and a bus system, where the DCU includes a processor, the memory is used to store a program, and the processor is used to call a program stored in the memory to execute the embodiments of the present application.
  • the DCU includes a processor
  • the memory is used to store a program
  • the processor is used to call a program stored in the memory to execute the embodiments of the present application.
  • a seventh aspect of the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer can execute the first aspect or any one of the possible implementations of the first aspect
  • the method of the second aspect, or the method that enables a computer to execute the second aspect or any one of the possible implementations of the second aspect are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer can execute the first aspect or any one of the possible implementations of the first aspect.
  • An eighth aspect of the embodiments of the present application provides a computer program, which, when running on a computer, enables the computer to execute the method of the first aspect or any possible implementation manner of the first aspect, or enables the computer to execute the above-mentioned first aspect.
  • Fig. 1 is a kind of schematic diagram of the processor type that a kind of DCU comprises and the quantity of each type processor;
  • FIG. 2 is a schematic structural diagram of a distributed automotive ECU provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of an architecture of an automotive DCU provided by an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of an automotive MDC provided by an embodiment of the present application.
  • FIG. 5 is a schematic flowchart of a configuration method of computing resources currently applied to vehicles
  • FIG. 6 is a schematic structural diagram of an automatic driving vehicle provided by an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of a method for configuring computing resources provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a host computer sending corresponding first computing power configuration data to a DCU in an autonomous driving vehicle through a CAN bus provided by an embodiment of the present application;
  • FIG. 9 is a schematic diagram of a cloud server sending corresponding first computing power configuration data to a DCU in an autonomous driving vehicle through wireless communication provided by an embodiment of the present application;
  • FIG. 10 is another schematic flowchart of a method for configuring computing resources provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of an MDC provided by an embodiment of the present application.
  • FIG. 12 is a schematic diagram of the host computer sending corresponding third computing power configuration data to the MDC in the autonomous vehicle through the CAN bus provided by the embodiment of the application;
  • FIG. 13 is a schematic diagram of a cloud server sending corresponding third computing power configuration data to an MDC in an autonomous vehicle through wireless communication provided by an embodiment of the present application;
  • FIG. 14 is a schematic flowchart of a specific configuration process of computing resources provided by an embodiment of the present application.
  • FIG. 15 is a schematic structural diagram of a DCU provided by an embodiment of the present application.
  • 16 is a schematic structural diagram of an MDC provided by an embodiment of the present application.
  • FIG. 17 is a schematic structural diagram of a device (DCU or MDC) provided by an embodiment of the present application.
  • Embodiments of the present application provide a method and device for configuring computing power resources.
  • the computing power configuration data in the method can be sent by a host computer that provides unified diagnostic services (UDS) when performing a near-end upgrade, or can be sent over the air by a host computer that provides unified diagnostic services (UDS). It is sent when the downloaded (over the air, OTA) cloud server performs a remote upgrade, and is used to adjust the computing power resources of the DCU by adjusting the computing power configuration data as needed.
  • UDS unified diagnostic services
  • OTA unified diagnostic services
  • ECU Electronic control unit
  • ECU is also known as on-board computer, on-board computer, etc. In terms of use, it is a special-purpose microcomputer controller for automobiles, also called a special-purpose single-chip microcomputer for automobiles. (read-only memory, ROM), random access memory (random access memory, RAM), input/output interface (I/O), analog-to-digital converter (A/D) and large-scale integrated circuits such as shaping and driving .
  • ROM read-only memory
  • RAM random access memory
  • I/O input/output interface
  • A/D analog-to-digital converter
  • large-scale integrated circuits such as shaping and driving .
  • the ECU was relatively simple in structure and was mainly used to control the work of the generator. Later, with the electronic development of the vehicle, the ECU gradually occupied the entire vehicle, from anti-lock braking system, four-wheel drive system, electronically controlled automatic transmission , active suspension systems, airbag systems, etc.
  • FIG. 2 is a schematic diagram of the architecture of the distributed automotive ECU provided by the embodiment of the application, and the functions of each ECU are Relatively independent, with the development of digital cars, especially autonomous driving technology, the ECUs on the car have gradually become more complex and tend to be concentrated on a super ECU.
  • FIG. 3 is a schematic diagram of an automotive DCU provided by an embodiment of the present application.
  • one DCU is used to control one domain.
  • DCU The reason for the emergence of DCU is to integrate functional classification control, reduce line speed, modularize the automotive control system, and use high-speed vehicle Ethernet for data exchange between different DCUs.
  • DCU functional classification control
  • Multi domain controller multi domain controller, MDC
  • FIG. 4 is a schematic structural diagram of the automotive MDC provided by the embodiment of the present application.
  • the zFAS jointly developed by Audi and Delphi uses an ECU to access the sensing information collected by different sensors, analyze and process the sensing information, and finally issue control commands.
  • an MDC is composed of multiple DCUs. Among the multiple DCUs, one of the DCUs serves as the main DCU and is used to send instructions to other DCUs in the MDC for data interaction.
  • Computing power is often used to estimate the execution capability of a processor (eg, CPU) and is usually measured in units of operations per second, such as “tera operations per second (TOPS)” , “floating-point operations per second (FLOPS)", “million instructions per second (MIPS)”, etc.
  • TOPS tera operations per second
  • FLOPS floating-point operations per second
  • MIPS million instructions per second
  • 1TOPS represents the processor per second One trillion (10 ⁇ 12) operations can be performed.
  • the computing power configuration data described in this application refers to the preset configuration number of processors of various types in the DCU.
  • the DCU includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. Since the computing resources of each type of processor are determined by The structure of the processor itself is determined. According to the type and structure of the processor, the computing resources of the corresponding processor can be roughly estimated. It is assumed that the preset configuration quantities of each type of processor in the DCU are x 0 ISPs and y 0 respectively.
  • how to preset the number of processor configurations of various types in the DCU can be estimated according to the computing power resources consumed by the historical operation of the DCU, so as to ensure the normal operation of the DCU. Running, and saving computing resources.
  • 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., in some implementations In the method, the number of Cores inside each type of processor can also be configured.
  • the operating frequency of each type of processor may also be configured in the computing power configuration data, which is not specifically limited. That is, by configuring the number of processors of various types in the DCU, the operating frequency of the processor, and the number of cores in the processor, participating in specific autonomous driving services, and realizing the controllable configuration of computing resources in the DCU.
  • the computing power configuration data described in this application refers to the preset configuration quantity of each type of processor in each DCU in the MDC.
  • the manner of presetting the number of processors of each type in each DCU in the MDC is similar to the manner of presetting the number of processors of each type in the DCU, which is not repeated here.
  • the host computer refers to a computer device that can directly issue control commands.
  • the computer device that can communicate with the ECU, DCU or MDC based on the unified diagnosis service protocol (unified diagnosis service, UDS) can be called the host computer.
  • UDS unified diagnosis service
  • the host computer also known as diagnostic instruments, diagnostic machines, diagnostic tools, etc.
  • smart handheld terminal devices such as personal computers (PCs), mobile phones, and tablet computers, as well as smart wearable devices such as smart bracelets and smart watches
  • Even a single-chip microcomputer as long as the device can run the corresponding diagnostic software and can communicate with the ECU, DCU or MDC based on the UDS protocol, can be used as the host computer in this embodiment of the application, which is not specifically limited here.
  • Unified diagnosis service (UDS)
  • diagnostic function is one of the basic functions of ECU/DCU/MDC.
  • the software or firmware update of ECU/DCU/MDC can be supported by the diagnostic function.
  • UDS also known as ISO 14229-1
  • Table 1 is the protocol applied at each layer of the open system interconnection (OSI) model, in which UDS is oriented to the application layer in the OSI model, and it can be used in different automotive buses (such as, CAN, LIN, Flexray, Ethernet, K-line, etc.).
  • OSI open system interconnection
  • UDS is essentially a series of diagnostic services. Such diagnostic services defined by UDS can be called standard diagnostic services. Standard diagnostic services include 6 categories and a total of 26 types. Each standard diagnostic service has its own independent service identifier.
  • Service identifier SID
  • SID is essentially a directional communication and an interactive protocol, that is, the upper computer sends a specified diagnostic request (request) to the ECU/DCU/MDC. This request needs to contain the SID. If it is a positive response, the ECU/DCU/MDC returns [SID+0x40] to the host computer. For example, the SID of the sent diagnostic request is 0x10, and the positive response is 0x50; if the response is negative, the ECU returns to the host computer.
  • NRC Negative Response Code
  • the UDS-based diagnostic communication process is: the host computer sends a diagnostic request (request) to the ECU/DCU/MDC, and the ECU/DCU/MDC gives a diagnostic response (response).
  • the diagnostic response includes a positive response and a negative response, and the UDS is different
  • the request and response of the diagnostic service define a unified protocol format.
  • OTA refers to downloading a new software update package from a remote server (also known as a cloud server) through a network to upgrade its own system. That is to say, the software or firmware update of ECU/DCU/MDC can be upgraded through OTA of network remote channel (ie, remote upgrade) in addition to being supported by the diagnostic function (ie, near-end upgrade).
  • a remote server also known as a cloud server
  • the software or firmware update of ECU/DCU/MDC can be upgraded through OTA of network remote channel (ie, remote upgrade) in addition to being supported by the diagnostic function (ie, near-end upgrade).
  • the processor may refer to a processor in the traditional sense such as a CPU, GPU, and NPU, or may refer to one or more CPU Core, GPU Core, ISP Core, Vector, etc. included in the traditional processor.
  • Core, etc. the arithmetic unit, instruction fetching and decoding hardware, instruction pipeline, and some cache memory are integrated into the "Core" described in this application, and the Core may also be referred to as a core.
  • 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., that is, In the examples of this application, the processor may refer to not only ordinary processors such as CPUs and GPUs, but also processor cores, that is, the above-mentioned various Cores.
  • processors the Common processors and processor cores are collectively referred to as processors.
  • the type and quantity of processors included in the DCU are m+1 CPUs, n+1 AI Cores, k+1 Vector Cores, and one eFuse, where the m+1 CPUs are respectively are CPU 0 , CPU 1 , ..., CPU m , these n+1 AI Cores are AI Core 0 , AI Core 1 , ... , AI Core n respectively, these k+1 Vector Cores are Vector Core 0 , Vector Core respectively 1 , ..., Vector Core k . Then, before the DCU leaves the factory, the total number of processors of each type in the DCU (i.e.
  • m+1 CPUs, n+1 AI Cores, k+1 Vector Cores will be programmed as the computing power configuration data.
  • one of the CPUs for example, CPU 0
  • the main CPU After the main CPU initializes the related peripherals, it reads the computing power configuration data from the eFuse, and then according to the read calculation
  • the force configuration data resets other CPUs, AI Cores, and Vector Cores, so that other processors complete their own initialization, so that when the DCU is running, all processors in the DCU are called to process related service data.
  • the computing power configuration scheme of eFuse can only be programmed and configured according to the maximum computing power resource. In the actual application process of DCU, it may not need to use such a large computing power resource, resulting in a waste of resources; in addition, the computing power configuration data is Program in eFuse, eFuse is a one-time programmable memory and cannot be changed later.
  • the embodiment of the present application first provides a configuration method for computing power resources.
  • the computing power configuration data in this method can be sent by the host computer that provides UDS when performing near-end upgrades or the cloud that provides OTA. Sent when the server performs a remote upgrade, it is used to adjust the computing power resources of the DCU by adjusting the computing power configuration data as needed.
  • FIG. 6 is a schematic structural diagram of an autonomous driving vehicle provided by an embodiment of the application.
  • the autonomous driving vehicle 100 is configured to be in a fully or partially autonomous driving mode.
  • the autonomous driving vehicle 100 can control the itself, and can determine the current state of the vehicle and its surrounding environment through human operation, determine the possible behavior of at least one other vehicle in the surrounding environment, and determine the confidence level corresponding to the possibility of the other vehicle performing the possible behavior, based on the determined information to control the autonomous vehicle 100.
  • the autonomous vehicle 100 may also be placed to operate without human interaction when the autonomous vehicle 100 is in the autonomous driving mode.
  • Autonomous vehicle 100 may include various subsystems, such as travel system 102 , sensor system 104 (eg, cameras, SICK, lidar, etc. are all modules within sensor system 104 ), control system 106 , one or more peripherals 108 As well as power supply 110 , computer system 112 and user interface 116 .
  • autonomous vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. Additionally, each of the subsystems and components of the autonomous vehicle 100 may be wired or wirelessly interconnected.
  • the travel system 102 may include components that provide powered motion for the autonomous vehicle 100 .
  • travel system 102 may include engine 118 , energy source 119 , 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 composed of a gasoline engine and an electric motor, and a hybrid engine composed 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 .
  • Transmission 120 may transmit mechanical power from engine 118 to wheels 121 .
  • Transmission 120 may include a gearbox, a differential, and a driveshaft. In one embodiment, transmission 120 may also include other devices, such as clutches.
  • the drive shaft may include 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 .
  • the sensor system 104 may include a positioning system 122 (the positioning system may be a global positioning GPS system, a Beidou system or other positioning systems), an inertial measurement unit (IMU) 124, a radar 126, a laser rangefinder 128 and camera 130.
  • the sensor system 104 may also include sensors that monitor the internal systems of the autonomous vehicle 100 (eg, an in-vehicle air quality monitor, a fuel gauge, an oil temperature gauge, etc.). Sensing data from one or more of these sensors can be used to detect objects and their corresponding properties (position, shape, orientation, velocity, etc.). This detection and identification is a critical function for the safe operation of the autonomous autonomous vehicle 100 .
  • the laser sensing module is a very important sensing module in the sensor system 104 .
  • the positioning system 122 may be used to estimate the geographic location of the autonomous vehicle 100 .
  • the IMU 124 is used to sense position and orientation changes of the autonomous vehicle 100 based on inertial acceleration.
  • IMU 124 may be a combination of an accelerometer and a gyroscope.
  • the radar 126 can use radio signals to perceive objects in the surrounding environment of the autonomous vehicle 100 , and can be embodied as a millimeter-wave radar or a lidar. In some embodiments, in addition to sensing objects, radar 126 may be used to sense the speed and/or heading of objects.
  • the laser rangefinder 128 may utilize the laser light to sense objects in the environment in which the autonomous vehicle 100 is located.
  • the laser rangefinder 128 may include one or more laser sources, laser scanners, and one or more detectors, among other system components.
  • Camera 130 may be used to capture multiple images of the surrounding environment of autonomous vehicle 100 .
  • Camera 130 may be a still camera or a video camera.
  • Control system 106 controls the operation of the autonomous vehicle 100 and its components.
  • Control system 106 may include various components including steering system 132 , throttle 134 , braking unit 136 , computer vision system 140 , line control system 142 , and obstacle avoidance system 144 .
  • the steering system 132 is operable to adjust the heading of the autonomous vehicle 100 .
  • the throttle 134 is used to control the operating speed of the engine 118 and thus the speed of the autonomous vehicle 100 .
  • the braking unit 136 is used to control the deceleration of the autonomous vehicle 100 .
  • the braking unit 136 may use friction to slow the wheels 121 .
  • the braking unit 136 may convert the kinetic energy of the wheels 121 into electrical current.
  • Braking unit 136 may also take other forms to slow down wheels 121 to control the speed of autonomous vehicle 100.
  • Computer vision system 140 may be operable to process and analyze images captured by camera 130 in order to identify objects and/or features in the environment surrounding autonomous vehicle 100 .
  • the objects and/or features may include traffic signals, road boundaries and obstacles.
  • Computer vision system 140 may use object recognition algorithms, Structure from Motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system 140 may be used to map the environment, track objects, estimate the speed of objects, and the like.
  • the route control system 142 is used to determine the travel route and 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, respectively, for combining information from the obstacle avoidance system 144, the GPS 122, and one or more predetermined maps The data for the autonomous vehicle 100 determines the driving route and driving speed.
  • Obstacle avoidance system 144 is used to identify, evaluate and avoid or otherwise traverse obstacles in the environment of autonomous vehicle 100 , which may be embodied as actual obstacles and virtual moving objects that may collide with autonomous vehicle 100 .
  • the control system 106 may additionally or alternatively include components in addition to those shown and described. Alternatively, some of the components shown above may be reduced.
  • Peripherals 108 may include a wireless communication system 146 , an onboard computer 148 , a microphone 150 and/or a speaker 152 .
  • peripherals 108 provide a means for a user of autonomous vehicle 100 to interact with user interface 116 .
  • the onboard computer 148 may provide information to a user of the autonomous vehicle 100 .
  • User interface 116 may also operate on-board computer 148 to receive user input.
  • the onboard computer 148 can be operated via a touch screen.
  • peripherals 108 may provide a means for autonomous vehicle 100 to communicate with other devices located within the vehicle.
  • Wireless communication system 146 may wirelessly communicate with one or more devices, either directly or via a communication network.
  • wireless communication system 146 may use 3G cellular communications, such as CDMA, EVDO, GSM/GPRS, or 4G cellular communications, such as LTE. Or 5G cellular communications.
  • the wireless communication system 146 may communicate using a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the wireless communication system 146 may communicate directly with the device using an infrared link, Bluetooth, or ZigBee.
  • Other wireless protocols, such as various vehicle communication systems, for example, wireless communication system 146 may include one or more dedicated short range communications (DSRC) devices, which may include communication between vehicles and/or roadside stations public and/or private data communications.
  • DSRC dedicated short range communications
  • the power source 110 may provide power to various components of the autonomous vehicle 100 .
  • 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 .
  • power source 110 and energy source 119 may be implemented together, such as in some all-electric vehicles.
  • Computer system 112 may include at least one DCU 116 including at least one processor 113 that executes instructions 115 stored in a non-transitory computer-readable medium such as memory 114 .
  • Computer system 112 may also be a plurality of computing devices that control individual components or subsystems of autonomous vehicle 100 in a distributed fashion.
  • the processor 113 may be any conventional processor, such as a commercially available CPU, GPU, VPU, NPU, DSP, ISP, etc. What type of processor and number of processors the DCU 116 includes depends on the domain that the DCU 116 controls.
  • the processor 113 may be a dedicated device such as an application specific integrated circuit (ASIC) or other hardware-based processor.
  • ASIC application specific integrated circuit
  • FIG. 6 functionally illustrates the processor, memory, and other components of the computer system 112 in the same block
  • the processor or memory may actually include a processor or memory that is not stored in the same physical enclosure multiple processors or memories within.
  • memory 114 may be a hard drive or other storage medium located within a different enclosure than computer system 112 .
  • references to processor 113 or memory 114 will be understood to include references to sets of processors or memories that may or may not operate in parallel.
  • some components such as the steering and deceleration components may each have their own processor that only performs computations related to component-specific functions .
  • the computer system 112 may further include at least one MDC (not shown in FIG. 6 ).
  • one MDC is composed of multiple DCUs. Among them, there is one DCU as the main DCU, which is used to send instructions to other DCUs in the MDC for data exchange.
  • the processor 113 may be located remotely from the autonomous vehicle 100 and in wireless communication with the autonomous vehicle 100 . In other aspects, some of the processes described herein are performed on the processor 113 disposed within the autonomous vehicle 100 while others are performed by the remote processor 113, including taking the necessary steps to perform a single maneuver.
  • memory 114 may include instructions 115 (eg, program logic) executable by processor 113 to perform various functions of autonomous vehicle 100 , including those described above.
  • Memory 114 may also contain additional instructions, including instructions to send data to, receive data from, interact with, and/or control one or more of travel system 102 , sensor system 104 , control system 106 , and peripherals 108 . instruction.
  • memory 114 may store data such as road maps, route information, vehicle location, direction, speed, and other such vehicle data, among other information. Such information may be used by the autonomous vehicle 100 and the computer system 112 during operation of the 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 .
  • user interface 116 may include one or more input/output devices within the set of peripheral devices 108 , such as wireless communication system 146 , onboard computer 148 , microphone 150 and speaker 152 .
  • Computer system 112 may control functions of autonomous vehicle 100 based on input received from various subsystems (eg, travel system 102 , sensor system 104 , and control system 106 ) and from user interface 116 .
  • computer system 112 may utilize input from control system 106 to control steering system 132 to avoid obstacles detected by sensor system 104 and obstacle avoidance system 144 .
  • computer system 112 is operable to provide control over many aspects of autonomous vehicle 100 and its subsystems.
  • one or more of these components described above may be installed or associated with the autonomous vehicle 100 separately.
  • memory 114 may exist partially or completely separate from autonomous vehicle 100 .
  • the above-described components may be communicatively coupled together in a wired and/or wireless manner.
  • An autonomous vehicle traveling on a road can identify objects within its surroundings to determine adjustments to current speed.
  • the objects may be other vehicles, traffic control equipment, or other types of objects.
  • each identified object may be considered independently, and based on the object's respective characteristics, such as its current speed, acceleration, distance from the vehicle, etc., may be used to determine the speed at which the autonomous vehicle is to adjust.
  • the autonomous vehicle 100 or a computing device associated with the autonomous vehicle 100 such as the computer system 112, computer vision system 140, and memory 114 of FIG. traffic, rain, ice on the road, etc.
  • each identified object is dependent on the behavior of the other, so it is also possible to predict the behavior of a single identified object by considering all identified objects together.
  • the autonomous vehicle 100 can adjust its speed based on the predicted behavior of the identified object. In other words, the autonomous vehicle 100 can determine what steady state the vehicle will need to adjust to (eg, accelerate, decelerate, or stop) based on the predicted behavior of the object.
  • the computing device may also provide instructions to modify the steering angle of the autonomous vehicle 100 so that the autonomous vehicle 100 follows a given trajectory and/or maintains a close proximity to the autonomous vehicle 100 safe lateral and longitudinal distances for objects that are not in use (for example, cars in adjacent lanes on the road).
  • the self-driving vehicle 100 can be a car, a truck, a motorcycle, a bus, a boat, an airplane, a helicopter, a lawn mower, a recreational vehicle, a playground vehicle, construction equipment, a tram, a golf cart, a train, a cart, etc. , the embodiments of the present application are not particularly limited.
  • the embodiments of the present application provide a method for configuring computing resources, which can be applied to various intelligent driving (eg, unmanned, assisted driving, etc.) agents (eg, the overall architecture of the autonomous vehicle corresponding to FIG. 6 ). ) for motion planning (eg, speed planning, driving behavior decision, global path planning, etc.), for ease of understanding, in the embodiments of the present application, the agent is an autonomous vehicle as an example for illustration.
  • various intelligent driving eg, unmanned, assisted driving, etc.
  • agents eg, the overall architecture of the autonomous vehicle corresponding to FIG. 6 ).
  • motion planning eg, speed planning, driving behavior decision, global path planning, etc.
  • the agent is an autonomous vehicle as an example for illustration.
  • the configuration methods of computing resources provided by the embodiments of the present application are slightly different, which will be described separately below.
  • the controller in the autonomous vehicle is the DCU
  • FIG. 7 is a schematic flowchart of a method for configuring computing resources provided by an embodiment of the present application, which specifically includes the following steps:
  • the DCU receives first computing power configuration data corresponding to the DCU sent by the cloud server or the host computer, where the DCU is any DCU on the vehicle, the DCU includes at least one processor, and the first computing power configuration data includes at least one of the DCUs.
  • the DCU receives first computing power configuration data corresponding to the DCU
  • the DCU is any DCU on the vehicle
  • the DCU includes at least one processor
  • the first computing power configuration data includes at least one type of the DCU (such as , can be the preset configuration quantity of processors of various types)
  • the preset configuration quantity can be set according to the consumption of historical computing power resources of the DCU and the specific situation of the running business of the DCU
  • the configuration data supports the host computer to be updated through the near-end upgrade method (that is, UDS) or the far-end upgrade method (that is, OTA). Save computing resources on the premise of smooth progress.
  • the computing power configuration data refers to the preset configuration quantity of each type of processor in the DCU.
  • the DCU includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores. Since the computing resources of each type of processor are determined by The structure of the processor itself is determined. According to the type and structure of the processor, the computing resources of the corresponding processor can be roughly estimated. It is assumed that the preset configuration quantities of each type of processor in the DCU are x 0 ISPs and y 0 respectively.
  • the x 0 ISPs, y 0 GPUs, m 0 CPUs, and n 0 AI cores participating in the operation are not limited to the x+1 ISPs, Which of y+1 GPUs, m+1 CPUs, and n+1 AI cores.
  • the preset configuration quantities of each type of processor in the DCU are 2 ISPs, 2 GPUs, and 1 CPU.
  • the computing power configuration data is 2 ISPs, 2 GPUs, 1 CPU and 3 AI cores
  • these 2 ISPs can be any 2 of the total 3 ISPs.
  • These 2 GPUs can also be any 2 of the total 4 GPUs
  • the 1 CPU can also be any 1 of the total 2 CPUs
  • the 3 AI cores can also be a total of 6 AI cores any 3 of the .
  • the number of Cores inside the processors that may belong to the same type may be slightly different.
  • x 0 ISPs and y 0 GPUs participate in the operation.
  • m 0 CPUs and n 0 AI cores can be defined as which of x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores.
  • 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., in some implementations
  • the number of Cores inside each type of processor can also be configured.
  • the operating frequency of each type of processor can also be configured in the computing power configuration data, which is not specifically limited, that is, the computing power configuration data can be configured by configuring the number of processors of each type in the DCU, The main frequency and the number of cores in the processor are characterized.
  • the DCU receiving the first computing power configuration data corresponding to the DCU can be obtained in the following ways:
  • the first computing power configuration data is sent by the upper computer.
  • the first computing power configuration data can be included in the diagnostic service of the UDS.
  • the host computer provides the diagnostic service to the DCU
  • the host computer sends the first computing power configuration data to the DCU, as shown in FIG. 8
  • Fig. 8 shows that the upper computer (Fig. 8 is illustrated by taking a PC as an example) sends the first computing power configuration data to the DCU in the autonomous driving vehicle through the controller area network (CAN) bus.
  • the computer sends a diagnostic request (request), and the DCU on the autonomous vehicle gives a response (response).
  • the host computer and the DCU are the roles of client and server in computer network communication, respectively.
  • the first computing power configuration data is sent by the cloud server.
  • the software or firmware update of ECU/DCU/MDC can not only be supported by the diagnostic function (that is, the near-end upgrade), but also can be upgraded through the OTA of the network remote channel (that is, the remote-end upgrade). Therefore, the first computing power
  • the configuration data can also be stored on a cloud server that provides OTA services.
  • the cloud server provides OTA services to the vehicle on which the DCU is installed, the cloud server sends the first computing power configuration data to the DCU, as shown in Figure 9 , FIG. 9 illustrates that the cloud server sends the corresponding first computing power configuration data to the DCU in the autonomous driving vehicle through wireless communication.
  • the first computing power configuration data may be included in a target file (which may be referred to as a The first file), then the host computer or the cloud server sends the first file to the DCU, and the first computing power configuration data is included in the first file, realizing that each independent DCU and the first computing power
  • a target file which may be referred to as a The first file
  • the first file can be a license file of the DCU (each DCU has a license file), a file defined by the user in advance, or a related software update package in the diagnostic service or OTA.
  • the type and format of the first file are not limited here, and the user can choose what type of file to include the first computing power configuration data in as needed, which is flexible and optional.
  • the first file supports the host computer to be updated through the near-end upgrade method (that is, UDS) or the far-end upgrade method (that is, OTA), so as to facilitate the subsequent update of the first computing power configuration data as needed to realize the adjustment of the DCU computing power resources, Save computing resources on the premise of ensuring the smooth operation of the business.
  • the first file may be an encrypted file, so as to prevent the first computing power configuration data from being arbitrarily modified, thereby improving the security of the data.
  • the encryption method for the first file can be symmetric encryption, that is, the same key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two secret keys, which The two keys are the public key and the private key. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the corresponding public key can be used to decrypt the data. key to decrypt. In this embodiment of the present application, the encryption method is not limited.
  • the DCU after the DCU receives the first computing power configuration data sent by the host computer or the cloud server, it can be persistently stored in the storage module in the DCU, for example, the storage module It can be electrically erasable programmable read only memory (electrically erasable programmable read only memory, EEPROM), Flash flash memory, etc.
  • the persistent storage described in the embodiments of the present application refers to storing data (such as the first described in the embodiments of the present application).
  • the main application of persistence is to store in-memory objects in the database, or in disk files, XML data files, etc.
  • the original first computing power configuration data persistently stored in the storage module in the DCU will be updated to the new first computing power configuration data. Computing power configuration data.
  • the DCU may also perform redundant backup of the received first computing power configuration data.
  • the first computing power configuration data is backed up at the first moment to obtain first backup data, and the first computing power configuration data and the first backup data are respectively stored in different storage modules in the DCU For example, they are respectively stored in different storage media in the DCU or different blocks in the same storage media.
  • the first computing power configuration data and the first backup data in different storage modules in the DCU may also be periodically checked and verified.
  • the purpose of verification is to ensure the accuracy of the first computing power configuration data, and at the same time, when errors occur in the data, they can be detected and corrected in time. For example, assuming that the setting period is 2 hours, it is assumed that the DCU receives the first computing power configuration data and stores the first computing power configuration data and the first backup data in the storage module 1 in the DCU at 8:00 at the first time.
  • the DCU when the time is 10:00, the DCU will judge the first computing power configuration data in the storage module 1 at 10:00 at the current time (the first computing power configuration data at the current moment can be called the first computing power configuration data. Whether the second computing power configuration data is consistent with the first backup data in the storage module 2 at 10:00 at the current time (the first backup data at the current moment may be referred to as the second backup data), in the second computing power configuration data In the case of inconsistency with the second backup data, the DCU verifies and aligns the second computing power configuration data and the second backup data, so that the second computing power configuration data and the second backup data are kept with the first computing power configuration data. Consistent.
  • the DCU has the capability of automatic recovery and self-healing, and the DCU can detect which data has an error. If the DCU determines that the second computing power configuration data is consistent with the first computing power configuration data, the second If the backup data is inconsistent with the first backup data, it means that the second computing power configuration data is inconsistent with the second backup data and the second computing power configuration data is correct data. The DCU can back up the second computing power configuration data again.
  • the corrected second backup data is obtained, thereby completing the verification and alignment of the second computing power configuration data and the second backup data; similarly, if the DCU judges that the second computing power configuration data is inconsistent with the first computing power configuration data, the first The second backup data is consistent with the first backup data, indicating that the second computing power configuration data is inconsistent with the second backup data and the second backup data is correct data, the DCU can back up the second backup data, and the backed up data As the corrected second computing power configuration data, the verification and alignment of the second computing power configuration data and the second backup data are completed; it is assumed that the DCU judges that the second computing power configuration data is inconsistent with the first computing power configuration data and the second The backup data is also inconsistent with the first backup data, indicating that both data are wrong. At this time, you can start the near-end upgrade or remote upgrade process, and receive a new first computing power from the host computer or cloud server. Configure data and make backups.
  • the DCU is any DCU in the autonomous driving vehicle, and in some embodiments of the present application, each independently working DCU in the autonomous driving vehicle can be used as a DCU
  • the process of step 701 is performed to obtain the computing power configuration data corresponding to each DCU in the autonomous vehicle.
  • the specific process is similar to that of step 701, and will not be repeated here.
  • the DCU de-resets the target processor in the DCU according to the first computing power configuration data, to obtain the de-reset target processor.
  • the DCU After the DCU receives the first computing power configuration data corresponding to the DCU sent by the host computer or the cloud server, it can de-reset the corresponding processor (which may be called the target processor) in the DCU according to the first computing power configuration data. , so as to obtain the de-reset target processor.
  • the corresponding processor which may be called the target processor
  • each type of The preset configuration numbers of processors are respectively x 0 ISPs, y 0 GPUs, m 0 CPUs, and n 0 AI cores, where 0 ⁇ x 0 ⁇ x+1, 0 ⁇ y 0 ⁇ y+1, 0 ⁇ m 0 ⁇ m+1, 0 ⁇ n 0 ⁇ n+1, that is to say, the first computing power configuration data of the DCU is x 0 ISPs, y 0 GPUs, m 0 CPUs, and n 0 AI core, and the first computing power configuration data is stored in the storage module in the DCU.
  • the DCU After the DCU is powered on, it will read the first computing power configuration data from the storage module, and based on the first computing power configuration The data is decompressed from the DCU to extract x 0 ISPs, y 0 GPUs, m 0 CPUs and n 0 AI cores, then during the operation of the DCU, there are only x 0 ISPs, y 0 GPUs, m 0 CPUs and n 0 AI cores participate, these x 0 ISPs, y 0 GPUs, m 0 CPUs and n 0 AI cores are called the target processors described in this application, and the remaining processors are In a dormant state, according to the x 0 ISPs, y 0 GPUs, m 0 CPUs and n 0 AI cores, the computing resources of the DCU during operation can be roughly estimated. When the configuration number is set to 0, it means that the processor does not participate in the running process of the DCU.
  • the validity check of the first computing power configuration data also needs to be performed, Erroneous, illegal data can be prevented from entering the service, or it can be detected in time when the data is wrong.
  • the validity check may specifically be: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether the first computing power configuration data has jumps or tampering; the first computing power configuration data Whether it has integrity; when the first computing power configuration data is included in the encrypted first file, check whether the encryption process of the first file is abnormal, whether the encrypted first file can be decrypted, etc.; Whether the data value range of the power configuration data is within the normal range, etc. For example, if the DCU has a total of 4 CPUs, and the number of CPUs in the first computing power configuration data is 5, the data value range is not within the normal range. Only when 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.
  • the DCU if the first computing power configuration data is included in the first file, the DCU performs legality verification on the first computing power configuration data by verifying the first computing power configuration data. File validity check is realized.
  • the DCU if the first file is an encrypted file, the DCU also needs to decrypt the encrypted first file to obtain the decrypted first file, and then decrypt the decrypted first file. Documents are checked for legality.
  • the DCU processes the sensing information based on the de-reset target processor.
  • step 703 may be continued, that is, after the DCU de-resets the target processor in the DCU based on the first computing power configuration data,
  • the DCU processes the collected sensing information based on the target processor obtained after de-resetting.
  • the DCU includes x+1 ISPs, y+1 GPUs, m+1 CPUs, and n+1 AI cores in total, and the first DCU
  • the computing power configuration data is x 0 ISPs, y 0 GPUs, m 0 CPUs, and n 0 AI cores
  • the target processor obtained by de-resetting is x 0 ISPs, y 0 GPUs, m 0 CPUs and n 0 AI cores
  • the DCU is based on the sensing information collected by the sensor (that is, the sensing information belongs to in the case of the processing category of the DCU) is processed.
  • the steps performed by the DCU are all implemented by the main CPU in the DCU.
  • the DCU receives the first computing power sent by the host computer or the cloud server through the main CPU in the DCU. Configuration Data.
  • the first computing power configuration data supports the upper computer to be updated through a near-end upgrade method (ie UDS) or a remote upgrade method (ie OTA), so that subsequent
  • the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, which avoids the situation that the corresponding computing power configuration data of the DCU can only be fixed in the eFuse and cannot be modified, and enhances the adaptability of the changing driving business scenarios in the follow-up.
  • the controller in the autonomous vehicle is MDC
  • FIG. 10 is a schematic flowchart of another method for configuring computing resources provided by an embodiment of the present application, which specifically includes the following steps:
  • the MDC receives, through the main DCU, third computing power configuration data corresponding to the MDC sent by the cloud server or the host computer.
  • the MDC includes a plurality of DCUs, the main DCU is one of the plurality of DCUs, and each of the plurality of DCUs.
  • Each of the DCUs includes at least one processor, and the third computing power configuration data includes a preset configuration number of processors of at least one type in each DCU.
  • the MDC receives the third computing power configuration data corresponding to the MDC through the main DCU in the MDC, and the MDC is any MDC on the vehicle (in general, one MDC is deployed on a vehicle, when only one MDC is deployed on the vehicle, the The MDC is this MDC), the MDC includes multiple DCUs, where the main DCU is any one of the multiple DCUs, each DCU includes at least one processor (eg, CPU), and the third computing power configuration data includes the MDC
  • the preset configuration number of processors of at least one type eg, may be each type) in each DCU within the system.
  • the MDC includes 3 DCUs, namely DCU 1 , DCU 2 and DCU 3 , wherein DCU 1 includes m 1 +1 CPUs, x 1 +1 ISPs, y 1 +1 GPU and n 1 +1 AI Core, DCU 2 includes m 2 +1 CPU, y 2 +1 GPU and n 2 +1 Vector Core, DCU 3 includes m 3 +1 CPU, x 3 +1 ISP, y 3 +1 GPU and n 3 +1 Vector Core.
  • each type of processing in DCU 2 in the MDC is m 01 CPUs, x 01 ISPs, y 01 GPUs, and n 01 AI cores
  • each type of processing in DCU 2 in the MDC The preset configuration quantities of the processors are respectively m 02 CPUs, y 02 GPUs and n 02 Vector cores.
  • the preset configuration quantities of each type of processor in the DCU 3 in the MDC are m 03 CPUs, x 03 CPUs, respectively.
  • ISP ISP, y 03 GPUs, and n 03 Vector cores, where 0 ⁇ m 01 ⁇ m 1 +1, 0 ⁇ x 01 ⁇ x 1 +1, 0 ⁇ y 01 ⁇ y 1 +1 , 0 ⁇ n 01 ⁇ n 1 +1, 0 ⁇ m 02 ⁇ m 2 +1, 0 ⁇ y 02 ⁇ y 2 +1, 0 ⁇ n 02 ⁇ n 2 +1, 0 ⁇ m 03 ⁇ m 3 +1, 0 ⁇ x 03 ⁇ x 3 +1, 0 ⁇ y 03 ⁇ y 3 +1, 0 ⁇ n 03 ⁇ n 3 +1.
  • m 01 CPUs, x 01 ISPs, y 01 GPUs, n 01 AI cores in DCU 1 participating in the operation, and m 02 in DCU 2 CPUs, y 02 GPUs and n 02 Vector cores, and m 03 CPUs, x 03 ISPs, y 03 GPUs and n 03 Vector cores in DCU 3 are not limited to DCU 1 , DCU 2 , DCU Which of 3 , for example, assuming that there are 3 ISPs, 4 GPUs, 2 CPUs, and 6 AI cores in DCU 1 in the MDC, the preset configuration quantities of each type of processor in the DCU 1 are respectively 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores, that is, the part corresponding to DCU 1 in the third computing power configuration data is 2 ISPs, 2 GPUs, 1 CPU, and 3 AI cores, then this The 2 ISPs can be any 2 of the total 3 ISPs, similarly, the 2 GPU
  • the number of Cores inside the processors that may belong to the same type may be slightly different.
  • the number of x 01 involved in the operation is ISP, y 01 GPUs, m 01 CPUs, and n 01 AI cores can be defined as x 1 +1 ISPs, y 1 +1 GPUs, m 1 +1 CPUs, and n 1 +1 AI cores which.
  • the MDC can obtain the third computing power configuration data corresponding to the MDC in the following ways:
  • the third computing power configuration data is sent by the upper computer.
  • the third computing power configuration data can be included in the diagnostic service of the UDS.
  • the host computer provides the diagnostic service to the MDC
  • the host computer sends the third computing power configuration data to the main DCU in the MDC, as shown in the figure
  • Figure 12 shows that the host computer ( Figure 12 is illustrated by taking a PC as an example) sends the third computing power configuration data to the MDC in the autonomous driving vehicle through the CAN bus.
  • the host computer sends out a diagnosis request, and automatically
  • the MDC on the driving vehicle responds through the main DCU.
  • the host computer and the MDC are the roles of client and server respectively in the computer network communication.
  • the third computing power configuration data is sent by the cloud server.
  • the software or firmware update of ECU/DCU/MDC can not only be supported by the diagnostic function (that is, the near-end upgrade), but also can be upgraded through the OTA of the network remote channel (that is, the remote-end upgrade). Therefore, the third computing power Configuration data can also be stored on a cloud server that provides OTA services.
  • the cloud server provides OTA services to the vehicle on which the MDC is installed, the cloud server sends the third computing power configuration data to the MDC, as shown in Figure 13 , FIG. 13 illustrates that the cloud server sends the corresponding third computing power configuration data to the main DCU in the MDC in the autonomous driving vehicle through wireless communication.
  • the third computing power configuration data may be included in a target file (which may be referred to as a The second file), and then the host computer or the cloud server sends the second file to the main DCU in the MDC, and includes the third computing power configuration data in the second file.
  • a target file which may be referred to as a The second file
  • the host computer or the cloud server sends the second file to the main DCU in the MDC, and includes the third computing power configuration data in the second file.
  • the one-to-one correspondence of the configuration data of the third computing power is easy to control and manage, and is achievable.
  • the second file can be a license file of the MDC (each MDC has a license file), a file defined by the user in advance, or a related software update package in the diagnostic service or OTA.
  • the type and format of the first file are not limited here, and the user can choose what type of file to include the first computing power configuration data in as needed, which is flexible and optional.
  • the second file supports the host computer to be updated through the near-end upgrade method (ie UDS) or the remote upgrade method (ie OTA), which is convenient to update the third computing power configuration data as needed to realize the adjustment of the MDC computing power resources. Save computing resources on the premise of ensuring the smooth operation of the business.
  • the second file may be an encrypted file, so as to prevent the configuration data of the third computing power from being arbitrarily modified, thereby improving the security of the data.
  • the encryption method for the second file can be symmetric encryption, that is, the same key is used for encryption and decryption; the encryption method can also be asymmetric encryption, that is, asymmetric encryption requires two secret keys. The two keys are the public key and the private key. If the data is encrypted with the public key, it can only be decrypted with the corresponding private key. If the data is encrypted with the private key, only the The corresponding public key can be decrypted. In this embodiment of the present application, the encryption method is not limited.
  • the MDC after the MDC receives the third computing power configuration data sent by the host computer or the cloud server through the main DCU, it can be persistently stored in the storage module in the MDC, such as , the storage module may be EEPROM, Flash flash memory, etc.
  • the persistent storage described in the embodiment of the present application refers to saving data (such as the first computing power configuration data described in the embodiment of the present application) in a storage module that can be permanently saved (such as disk), the main application of persistence is to store in-memory objects in a database, or in disk files, XML data files, etc.
  • the original third computing power configuration data persistently stored in the storage module in the MDC will be updated to the new third computing power configuration data. Computing power configuration data.
  • the MDC sends the third computing power configuration data to other DCUs in the multiple DCUs except the main DCU through the main DCU.
  • the MDC After the MDC receives the third computing power configuration data from the host computer or the cloud server through the main DCU, it can further send the third computing power configuration data to other DCUs in the first DMC except the main DCU.
  • Figure 11 is still used as an example. , assuming that DCU 1 is the main DCU, then after receiving the third computing power configuration data, DCU 1 sends the third computing power configuration data to DCU 2 and DCU 3 , and DCU 2 and DCU 3 receive the third computing power After the configuration data are stored in their respective storage modules, redundancy backup is realized by storing the third computing power configuration data in each DCU in the MDC, thereby improving the storage reliability of the data.
  • the MDC can also send the third computing power configuration data to the MDC through the main DCU except the main CDU. 11 is still taken as an example. Assuming that DCU 1 is the main DCU, after receiving the third computing power configuration data, DCU 1 can send the third computing power configuration data to DCU 2 (or DCU 3) . ) to send, DCU 2 (or DCU 3 ) stores the third computing power configuration data in its own storage module after receiving the third computing power configuration data, when the MDC works normally after being powered on, the DCU 3 that does not obtain the third computing power configuration data will not be able to obtain the third computing power configuration data. Read the third computing power configuration data from DCU 1 . In a word, in the MDC, it is only necessary to ensure that the third computing power configuration data is stored in the storage modules of at least two DCUs in the MDC.
  • the third computing power configuration data stored in different DCU storage modules in the MDC may also be periodically checked and verified.
  • the purpose of verification is to ensure the accuracy of the third computing power configuration data, and at the same time, when the data is wrong, it can be detected and corrected in time. For example, still take FIG.
  • DCU 1 ie, the main DCU
  • DCU 1 , DCU 2 , and DCU 3 store their respective third computing power configuration data in their respective storage modules at the first time 7:30, and when the time is 8:30, DCU 1 will obtain the DCU 2 and the third computing power configuration data on DCU 3 , and determine the third computing power configuration data in DCU 1 at the current time 8:30 and the third computing power configuration data in DCU 2 and DCU 3 at the current time 8:30 (the current time 8:30).
  • the MDC uses the main DCU to compare the Verify and align the fourth computing power configuration data of each DCU, so that the fourth computing power configuration data in each DCU is consistent.
  • each fourth computing power configuration data is similar to the above-mentioned method of verifying and aligning the second computing power configuration data and the second backup data by the DCU. Please refer to the above description. To repeat.
  • the MDC is any MDC in the autonomous driving vehicle.
  • each independently working MDC in the autonomous driving vehicle can be used as the MDC.
  • the MDC de-resets the target processors in the respective DCUs according to the third computing power configuration data through the multiple DCUs, to obtain the de-reset target processors.
  • each DCU in the MDC After each DCU in the MDC has obtained the third computing power configuration data, then each DCU will de-reset the target processor in the respective DCU according to the third computing power configuration data obtained, and obtain the de-reset target processor , how the MDC de-resets the target processors in the respective DCUs according to the third computing power configuration data is similar to the above step 702, and details are not described here.
  • each DCU in the MDC de-resets the corresponding target processor in the respective DCU according to the third computing power configuration data, it is also necessary to configure the third computing power respectively.
  • the validity of the data is checked to prevent errors and illegal data from entering the service, or to be discovered in time when the data is wrong.
  • the validity check may specifically be: checking whether the third computing power configuration data is the computing power configuration data corresponding to the MDC; checking whether the third computing power configuration data has jumps or tampering; the third computing power configuration data Whether it has integrity; when the third computing power configuration data is included in the encrypted second file, check whether the encryption process of the second file is abnormal, whether the encrypted second file can be decrypted, etc.; Whether the data value range of the force configuration data is within the normal range, etc. Only when the third computing power configuration data passes the validity check, each DCU in the MDC de-resets the corresponding target processors in the respective DCUs according to the respective third computing power configuration data.
  • each DCU if the third computing power configuration data is included in the second file, each DCU performs legality verification on the third computing power configuration data by checking the third computing power configuration data. The validity of the two files is verified.
  • the second file is an encrypted file
  • each DCU also needs to decrypt the encrypted second file first to obtain the decrypted second file, and then decrypt the decrypted second file. Check the validity of the second document.
  • the MDC processes the sensing information based on the de-reset target processor.
  • step 1004 may be continued, that is, each DCU in the MDC is de-reset based on the third computing power configuration data received by them.
  • the target processor in the MDC when the autonomous vehicle collects sensing information through the sensor, and the sensing information belongs to the processing category of the MDC, the MDC based on the target processor obtained after de-resetting the collected data. Process the sensory information.
  • the third computing power configuration data supports the host computer to update through the near-end upgrade method (ie UDS) or the remote upgrade method (ie OTA), so that subsequent The third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, and solves the combined application scenario that the existing solution can only configure the computing resources of the DCU but cannot support the MDC composed of multiple DCUs.
  • the controller in the autonomous driving vehicle is a DCU as an example, and describes the specific configuration process of the DCU computing resources in three stages.
  • FIG. 14 which is the present application.
  • DCU 0 ⁇ DCU v in the DCU includes CPU 0 ⁇ CPU m (CPU 0 is the main CPU), Vector Core 0 ⁇ Vector Core k , AI Core 0 ⁇ AI Core k , ISP 0 ⁇ ISP x , GPU 0 -GPU y , a storage module and a hardware security module (hardware security module, HSM), may specifically include the following steps: wherein, steps 1401-1403 are the computing power configuration data storage stage, and steps 1404-1047 are computing power configuration data loading. stage, step 1408 is the data synchronization stage for computing power configuration.
  • the near-end upgrade process (or the far-end upgrade process) is triggered between the host computer (or cloud server) and the autonomous vehicle, and during the upgrade process, the computing power configuration data corresponding to the DCU w is included in the encrypted data of the DCU w .
  • the license file is sent to CPU 0 to realize the one-to-one correspondence between the DCU w and its corresponding computing power configuration data, and the encrypted license file can prevent the computing power configuration data from being arbitrarily modified, improving data security.
  • the CPU 0 sends the security access authentication to the HSM.
  • CPU 0 sends the secure access authentication to the HSM, and after passing the authentication, executes step 1403 .
  • the CPU 0 persistently stores the encrypted license file in the storage module.
  • the encrypted license file is sent to the storage module of the DCU w through a near-end upgrade or a remote-end upgrade, and the license file is backed up to obtain a backup file, and the license file and the backup file are persistently stored in the storage module Different areas within the module (or stored in different storage modules).
  • the CPU 0 reads the encrypted license file from the storage module.
  • the DCU w After the DCU w is powered on, before the automatic driving service model is loaded, the DCU w reads the encrypted license file from the storage module through CPU 0 .
  • the CPU 0 decrypts the license file.
  • CPU 0 After CPU 0 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 .
  • the CPU 0 performs a validity check on the computing power configuration data.
  • CPU 0 verifies that the decrypted license file is the license file of the DCU w , CPU 0 obtains the computing power configuration data in the decrypted license file, and verifies the validity of the computing power configuration data.
  • CPU 0 de-resets the corresponding target processor according to the computing power configuration data.
  • CPU 0 sequentially de-resets other corresponding CPUs, de-resets corresponding Vector Cores, de-resets corresponding AI Cores, de-resets corresponding ISPs, and de-resets corresponding GPUs according to the computing power configuration data.
  • the target processor in the DCU w after de-reset can process the collected perception information, that is, the driving service model is loaded based on the de-reset target processor.
  • the CPU 0 periodically checks and checks the license file and the backup file.
  • CPU 0 periodically checks the computing power configuration data in the license file and the computing power configuration data in the backup file, and automatically checks the computing power configuration data in the license file and the computing power configuration data in the backup file if they are inconsistent Perform data alignment processing.
  • FIG. 15 is a schematic structural diagram of a DCU provided by an embodiment of the application.
  • the DCU 1500 can be applied to a vehicle (eg, a smart car, an autonomous car, a connected car, etc.), and the DCU 1500 may specifically include: The receiving module 1501 and the de-resetting module 1502, wherein the receiving module 1501 is used to receive the first computing power configuration data corresponding to the DCU, the DCU is any DCU on the vehicle, the DCU includes at least one processor, the first A computing power configuration data includes the preset configuration quantity of at least one type of processor in the DCU, and the preset configuration quantity can be set according to the consumption of historical computing power resources of the DCU and the specific situation of the running service of the DCU;
  • the de-reset module 1502 is configured to de-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 de-reset target processor.
  • the first computing power configuration data supports the upper computer to be updated through a near-end upgrade method (ie UDS) or a remote upgrade method (ie OTA), so that subsequent
  • the first computing power configuration data can be updated as needed to adjust the computing power resources in the DCU, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, which avoids the situation that the corresponding computing power configuration data of the DCU can only be fixed in the eFuse and cannot be modified, and enhances the adaptability of the changing driving business scenarios in the follow-up.
  • the DCU 1500 may further include a processing module 1503, and the processing module 1503 is configured to, when the autonomous vehicle collects perception information through sensors, and the perception information belongs to the processing category of the DCU, based on the above The target processor obtained after de-resetting processes the collected sensing information.
  • the DCU can process the corresponding perception information based on the de-reset target processor, and the perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of changing driving business scenarios.
  • the receiving module 1501 is specifically configured to: receive the first file corresponding to the DCU sent by the cloud server or the upper computer, and the first computing power configuration data is included in the first file.
  • the first computing power configuration data can be included in a target file (ie, the first file), and then the first file is sent to the DCU by the host computer or the cloud server, Including the first computing power configuration data in the first file realizes a one-to-one correspondence between each independent DCU and the first computing power configuration data, which is convenient for control and management, and has practicability.
  • a target file ie, the first file
  • the first file is an encrypted file.
  • the first file may be an encrypted file, so as to prevent the first computing power configuration data from being arbitrarily modified, thereby improving the security of the data.
  • 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 a related software in the diagnostic service or OTA
  • the type and format of the first file are not specifically limited here.
  • the user can choose what type of file the first computing power configuration data is included in according to needs, which has flexibility and selectivity.
  • the de-reset module 1502 is specifically configured to: verify the validity of the first computing power configuration data, and in the case that the first computing power configuration data passes the validity check, according to the first computing power configuration data
  • the computing power configuration data de-resets the target processor in the DCU.
  • the validity check may specifically include: checking whether the first computing power configuration data is the computing power configuration data corresponding to the DCU; checking whether the first computing power configuration data has jumps or tampering; the first computing power configuration data Whether it has integrity; when the first computing power configuration data is included in the encrypted first file, check whether the encryption process of the first file is abnormal, whether the encrypted first file can be decrypted, etc.; Whether the data value range of the power configuration data is within the normal range, etc. For example, if the DCU has a total of 4 CPUs, and the number of CPUs in the first computing power configuration data is 5, the data value range is not within the normal range. Only when 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.
  • the de-resetting module 1502 before the de-resetting module 1502 de-resets the corresponding target processor in the DCU according to the first computing power configuration data, it also needs to check the validity of the first computing power configuration data, which can avoid Incorrect, illegal data enters the service, or can be detected in a timely manner when data is erroneous.
  • the receiving module 1501 is further configured to: back up the first computing power configuration data at the first moment to obtain first backup data, where the first computing power configuration data is in the first The computing power configuration data at the moment, the first backup data is the backup data at the first moment; the first computing power configuration data and the first backup data are stored in the DCU respectively. different storage modules.
  • the receiving module 1501 may further perform redundant backup on the received first computing power configuration data, so as to improve the storage reliability of the data.
  • the receiving module 1501 is further configured to: periodically determine whether the second computing power configuration data is consistent with the second backup data, where the second computing power configuration data is the computing power configuration at the current moment data, the second backup data is the backup data at the current moment; if the second computing power configuration data is inconsistent with the second backup data, the second computing power configuration data and the second backup data are inconsistent.
  • the second backup data is checked and aligned.
  • the receiving module 1501 may also periodically check and verify the first computing power configuration data and the first backup data in different storage modules in the DCU.
  • the purpose of checking and checking is to ensure the first computing power
  • the accuracy of the configuration data can be improved, and when the data is wrong, it can be detected and corrected in time.
  • FIG. 16 is a schematic structural diagram of an MDC provided by an embodiment of the application.
  • the MDC 1600 can be applied to a vehicle (eg, a smart car, an autonomous car, a connected car, etc.), and the MDC 1600 can specifically include: The receiving module 1601, the sending module 1602, and the de-resetting module 1603, wherein the receiving module 1601 is used to receive the third computing power configuration data corresponding to the MDC through the main DCU in the MDC, and the MDC is any MDC ( In general, a vehicle deploys one MDC.
  • the MDC includes multiple DCUs, wherein the main DCU is any one of the multiple DCUs, and each DCU includes at least one processor (eg, CPU), the third computing power configuration data includes the preset configuration quantity of at least one type of processor in each DCU in the MDC; the sending module 1602 is configured to send the first The third computing power configuration data is sent to other DCUs in the multiple DCUs except the main DCU; the de-resetting module 1603 is used to de-reset the respective DCUs according to the third computing power configuration data through the multiple DCUs.
  • the target processor in the DCU obtains the de-reset target processor.
  • the third computing power configuration data supports the host computer to update through the near-end upgrade method (ie UDS) or the remote upgrade method (ie OTA), so that subsequent The third computing power configuration data can be updated as needed to adjust the computing power resources in the MDC, which can support the dynamic configuration requirements of the processor in subsequent driving business scenarios of different specifications, and save computing power on the premise of ensuring the smooth operation of the business. resources, and solves the combined application scenario that the existing solution can only configure the computing resources of the DCU but cannot support the MDC composed of multiple DCUs.
  • the MDC 1600 may further include a processing module 1604, and the processing module 1604 is configured to, when the vehicle collects sensing information through sensors, and the sensing information belongs to the processing category of the MDC , and process the sensing information based on the de-reset target processor.
  • the corresponding perception information can also be processed based on the target processor after reset, and the perception information reflects the driving business scenario. Therefore, the embodiment of the present application can enhance the adaptability of the constantly changing driving business scenario.
  • the receiving module 1601 is specifically configured to: receive the second file corresponding to the MDC sent by the cloud server or the upper computer, and the third computing power configuration data is included in the second file.
  • the third computing power configuration data can be included in a target file (ie, the second file), and then the second file is sent to the MDC by the host computer or the cloud server,
  • the third computing power configuration data is included in the second file, which realizes the one-to-one correspondence between each independent MDC and the third computing power configuration data, which is convenient for control and management, and has practicability.
  • the second file is an encrypted file.
  • the second file may be an encrypted file, so as to prevent the third computing power configuration data from being arbitrarily modified, thereby improving the security of the data.
  • 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 a related software in the diagnostic service or OTA
  • the type and format of the second file are not limited here.
  • the user can choose what type of file the third computing power configuration data is included in according to needs, which has flexibility and selectivity.
  • the de-resetting module 1603 is specifically configured to: verify the validity of the third computing power configuration data through each of the plurality of DCUs; In the case of performance verification, each of the multiple DCUs de-resets the target processor in the respective DCU according to the third computing power configuration data.
  • the third computing power configuration data needs to be checked for validity. , which can prevent erroneous and illegal data from entering the service, or can be detected in time when the data is wrong.
  • the receiving module 1601 is further configured to: periodically determine whether each of the fourth computing power configuration data at the current moment in each DCU in the multiple DCUs is consistent through the main DCU; When the respective fourth computing power configuration data is inconsistent, the main DCU verifies and aligns the respective fourth computing power configuration data.
  • the receiving module 1601 may also periodically check and verify the third computing power configuration data stored in different DCU storage modules in the MDC, and the purpose of checking and checking is to ensure the third computing power Configure the accuracy of the data, and at the same time, when the data is wrong, it can be detected and corrected in time.
  • FIG. 17 is a schematic structural diagram of the device (DCU or MDC) provided by the embodiment of the present application, for the convenience of description , only the parts related to the embodiments of the present application are shown. If the specific technical details are not disclosed, please refer to the method part of the embodiments of the present application.
  • the modules of the DCU described in the embodiment corresponding to FIG. 15 may be deployed on the device 1700 to implement the functions of the DCU in the embodiment corresponding to FIG. 7 or FIG. 14 .
  • the device 1700 may also be deployed on the device 1700 described in the embodiment corresponding to FIG. 16 .
  • the module of the MDC is used to implement the function of the MDC in the embodiment corresponding to FIG. 10 , which is not specifically limited here.
  • the device 1700 is implemented by one or more servers, and the device 1700 may vary greatly due to different configurations or performance, and may include one or more central processing units (CPU) 1722 (for example, one or more one or more) and memory 1732, one or more storage media 1730 (eg, one or more mass storage devices) that store applications 1742 or data 1744.
  • the memory 1732 and the storage medium 1730 may be short-term storage or persistent storage.
  • the program stored in the storage medium 1730 may include one or more modules (not shown in the figure), and each module may include a series of instructions to operate on the device 1700 .
  • the central processing unit 1722 may be configured to communicate with the storage medium 1730 to execute a series of instruction operations in the storage medium 1730 on the device 1700.
  • Device 1700 may also include one or more power supplies 1726, one or more wired or wireless network interfaces 1750, one or more input and output interfaces 1758, and/or, one or more operating systems 1741, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • operating systems 1741 such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • the steps performed by the DCU in the embodiments corresponding to FIG. 7 and FIG. 14 can be implemented based on the structure shown in FIG. 17 ; if the device 1700 is an MDC, the above steps The steps performed by the MDC in the embodiment corresponding to FIG. 10 may also be implemented based on the structure shown in FIG. 17 , which will not be described in detail here.
  • the device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be A physical unit, which can be located in one place or distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.
  • U disk U disk
  • mobile hard disk ROM
  • RAM random access memory
  • disk or CD etc.
  • a computer device which can be a personal computer, training equipment, or network equipment, etc. to execute the methods described in the various embodiments of the present application.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be retrieved from a website, computer, training device, or data
  • the center transmits to another website site, computer, training equipment, or data center by wire (eg, coaxial cable, optical fiber, digital subscriber line) or wireless (eg, 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 includes an integration of one or more available media.
  • the available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, high-density digital video discs (DVDs)), or semiconductor media (eg, solid state disks) , SSD)) etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例公开了一种算力资源的配置方法及设备，可应用于自动驾驶领域，可应用在智能汽车、自动驾驶汽车、网联汽车等上，包括：车辆任意一个域控制器(DCU)接收云服务器或上位机发送的与DCU对应的算力配置数据，算力配置数据包括该DCU中各类型处理器(包括处理器核)的预设配置数量，DCU根据算力配置数据解复位DCU中的目标处理器，并在车辆采集到的感知信息属于该DCU处理范畴情况下，基于解复位的目标处理器处理该感知信息。算力配置数据支持近端升级(UDS)或远端升级(OTA)进行更新，可按需更新算力配置数据以实现对DCU中算力资源的调整，在保证业务顺利进行的前提下节约算力资源，避免DCU出厂时对应的算力配置数据只能固化于eFuse中无法修改的情形。

Description

一种算力资源的配置方法及设备
本申请要求于2020年12月25日提交中国专利局、申请号为202011567735.4、申请名称为“一种算力资源的配置方法及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及自动驾驶领域，尤其涉及一种算力资源的配置方法及设备。
背景技术
汽车自发明以来，经历一百多年的发展，已经成为人们生活中不可或缺的一部分，随着生活水平的提高，人们对出行的舒适性、便捷性等要求越来越高，汽车随之朝着智能化方向演进。随着自动驾驶的来临，由于需要实现多传感器接入、融合、感知、定位、规控等功能，就需要硬件提供大量的算力，原有的一个功能对应一个电子控制单元(electronic control unit，ECU)的分布式计算架构已经无法适应需求，比如GPS、摄像头、激光雷达、毫米波雷达以及轮速传感器等数据(也可称为感知信息)都要在一个计算中心内进行处理以保证输出结果对整车自动驾驶的最优，因此中心化结构的域控制器(domain control unit，DCU)、多域控制器(multi domain controller，MDC)等逐步成为了发展趋势。
自动驾驶的处理器，通常有多核中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、视频处理器(video processing unit，VPU)、神经网络处理器(neural network processing unit，NPU)、张量处理单元(tensor processing unit，TPU)、数字信号处理(digital signal processing，DSP)单元、图像信号处理(image signal processing，ISP)单元、AI core、Vector core等，一个DCU可包括上述一种或多种处理器(处理器核也看作是一种处理器)。如图1所示的DCU就包括x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core，当一个DCU的结构固定后，意味着该DCU包括的处理器类型及各类型处理器的数量也已固定，由于每种类型的处理器具备的算力资源是由处理器本身结构决定，根据处理器类型和结构就可大致估算出对应处理器具备的算力资源。因此，在DCU出厂前，将该DCU包括的各个类型处理器的总数量作为算力配置数据烧写在该DCU中的eFuse内，如图1中的x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core就是所述的算力配置数据。
上述这种算力资源配置方法是将DCU内所有处理器(包括处理器核)都进行了配置，这是因为在DCU出厂前无法准确预估后续不同自动驾驶功能所需的算力，只能按最大算力资源进行烧写配置，而在DCU的实际应用过程中，可能并不需要用到这么大的算力资源，造成资源浪费；其次，算力配置数据是烧写在eFuse中，eFuse作为一次性可编程存储器，后续无法更改。
发明内容
本申请实施例提供了一种算力资源的配置方法及设备，该方法中的算力配置数据可由 提供统一诊断服务(unified diagnostic services，UDS)的上位机进行近端升级时发送或由提供空中下载(over the air，OTA)的云服务器进行远端升级时发送，用于通过按需调整算力配置数据实现对DCU算力资源的调整。
基于此，本申请实施例提供以下技术方案：
第一方面，本申请实施例首先提供一种算力资源的配置方法，可应用于自动驾驶领域，可应用在智能汽车、自动驾驶汽车、网联汽车等上，该方法包括：首先，DCU接收上位机或云服务器发送的与该DCU对应的第一算力配置数据，该DCU为车辆上的任意一个DCU，该DCU包括至少一个处理器，该第一算力配置数据包括该DCU中各个类型的处理器的预设配置数量，该预设配置数量可根据该DCU的历史算力资源的消耗情况以及该DCU的运行业务的具体情况进行设置，需要注意的是，由于DCU中包括的各个类型的处理器可以是多核处理器，例如，各个类型处理器内部还可能包括多个CPU Core、GPU Core、ISP Core、Vector Core等，在一些实施方式中，还可以对各个类型处理器内部的Core数进行配置，也就是在本申请的一些实施方式中，所述的处理器除了可以是指普通的CPU、GPU等处理器外，还可以是指处理器核，即上述各种Core，为便于理解，在本申请实施例中，将普通处理器以及处理器核统称为处理器。此外，各个类型的处理器的运行主频也可配置在该算力配置数据中，具体不做限定，也就是说，算力配置数据可以通过配置DCU中各个类型处理器个数、处理器运行主频及处理器内各Core数进行表征。DCU接收到上位机或云服务器发送的与该DCU对应的第一算力配置数据后，就可根据该第一算力配置数据解复位该DCU内对应的处理器(可称为目标处理器)，从而得到解复位后的目标处理器。
在本申请上述实施方式中，当自动驾驶车辆的控制器为DCU，第一算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按需更新第一算力配置数据以实现对DCU中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，避免了DCU出厂时对应的算力配置数据只能固化于eFuse中无法修改的情形，增强了后续驾驶业务场景不断变化的适应性。
在第一方面的一种可能的设计中，DCU基于第一算力配置数据解复位出该DCU内的目标处理器后，在自动驾驶车辆通过传感器采集到感知信息，且感知信息属于该DCU的处理范畴的情况下，该DCU就基于上述解复位后得到的目标处理器对采集到的感知信息进行处理。
在本申请上述实施方式中，DCU可基于解复位后的目标处理器处理对应的感知信息，感知信息反映了驾驶业务场景，因此，本申请实施例可增强驾驶业务场景不断变化的适应性。
在第一方面的一种可能的设计中，不管第一算力配置数据是由上位机发送还是由云服务器发送，该第一算力配置数据可以包含在在一个目标文件(可称为第一文件)中，然后由上位机或由云服务器将该第一文件向DCU发送。
在本申请上述实施方式中，具体阐述了可将第一算力配置数据包含在在第一文件中，实现了每个独立的DCU与第一算力配置数据的一一对应，便于控制和管理，具备可实现性。
在第一方面的一种可能的设计中，第一文件为经过加密的文件。需要说明的是，第一文件的加密的方式可以是对称加密，即加密和解密的秘钥使用的是同一个；加密的方式也可以是非对称加密，即非对称加密需要两个秘钥，这两个秘钥分别为公开秘钥和私有秘钥，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密，如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。在本申请实施例中，对加密的方式不做限定。
在本申请上述实施方式中，该第一文件可以是经过了加密的文件，以防止第一算力配置数据被随意修改，提高了数据的安全性。
在第一方面的一种可能的设计中，该第一文件可以是DCU的License文件(每个DCU都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第一文件的类型和格式均不做限定。
在本申请上述实施方式中，用户可根据需要选择将第一算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。
在第一方面的一种可能的设计中，DCU还可以对第一算力配置数据进行合法性校验，且在第一算力配置数据通过合法性校验的情况下，根据第一算力配置数据解复位DCU中的目标处理器。例如，合法性校验具体可以是：校验第一算力配置数据是否为该DCU对应的算力配置数据；校验第一算力配置数据是否存在跳变或篡改；第一算力配置数据是否具备完整性；当第一算力配置数据是包含在在加密的第一文件中时，校验第一文件加密过程是否异常、加密后的第一文件是否可解密等；校验第一算力配置数据的数据取值范围是否在正常范围内等，如，DCU总共有4个CPU，而第一算力配置数据中的CPU数量为5个，则数据取值范围不在正常范围内。只有在第一算力配置数据通过合法性校验的情况下，DCU才根据第一算力配置数据解复位该DCU内对应的目标处理器。
在本申请上述实施方式中，DCU在根据第一算力配置数据解复位该DCU内对应的目标处理器之前，还需要对该第一算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。
在第一方面的一种可能的设计中，当DCU接收到第一算力配置数据时，在第一时刻将该第一算力配置数据进行备份，得到第一备份数据，并将该第一算力配置数据和第一备份数据分别存储在DCU中的不同存储模块中，如，分别存储在DCU内不同存储介质或相同存储介质中的不同块中。
在本申请上述实施方式中，DCU还可以对接收到的第一算力配置数据进行冗余备份，以提高数据的存储可靠性。
在第一方面的一种可能的设计中，在DCU将第一算力配置数据和第一备份数据分别存储于DCU内的不同存储模块之后，DCU还可以周期性判断第二算力配置数据与第二备份数据是否一致，第二算力配置数据为处于当前时刻下的算力配置数据，第二备份数据为处于当前时刻下的备份数据，且在第二算力配置数据与第二备份数据不一致的情况下，DCU对第二算力配置数据与第二备份数据进行校验对齐。例如，假设设置周期为2小时，假设DCU接收到第一算力配置数据并在第一时刻8:00分别将该第一算力配置数据和第一备份 数据存储在该DCU内的存储模块1和存储模块2中，当时刻为10:00时，该DCU会判断当前时刻10:00存储模块1中的第一算力配置数据(该当前时刻下的第一算力配置数据可称为第二算力配置数据)和当前时刻10:00存储模块2中的第一备份数据(该当前时刻下的第一备份数据可称为第二备份数据)是否一致，在该第二算力配置数据与该第二备份数据不一致的情况下，DCU对第二算力配置数据和第二备份数据进行校验对齐，使得该第二算力配置数据和第二备份数据与第一算力配置数据保持一致。
在本申请上述实施方式中，DCU还可以针对DCU内不同存储模块内的第一算力配置数据和第一备份数据周期性进行核查校验，核查校验的目的是为了保障第一算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。
第二方面，本申请实施例首先提供一种算力资源的配置方法，可应用于自动驾驶领域，可应用在智能汽车、自动驾驶汽车、网联汽车等上，该方法包括：首先，MDC通过MDC中的主DCU接收上位机或云服务器发送的与该MDC对应的第三算力配置数据，该MDC为车辆上的任意一个MDC(一般情况下一个车辆部署一个MDC，当车辆仅部署一个MDC，则该MDC就是这一个MDC)，MDC包括多个DCU，其中主DCU为这多个DCU中的任意一个，每个DCU包括至少一个处理器(如，CPU)，该第三算力配置数据就包括MDC内每个DCU中各个类型的处理器的预设配置数量。MDC通过主DCU从上位机或云服务器接收到第三算力配置数据后，可进一步将该第三算力配置数据向第一DMC中除主DCU外的其他DCU发送。MDC中的各个DCU均获取到第三算力配置数据后，那么每个DCU将根据各自获取到的第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器。
在本申请上述实施方式中，当自动驾驶车辆的控制器为MDC，第三算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按需更新第三算力配置数据以实现对MDC中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，并且解决了现有方案只能配置本DCU的算力资源而无法支持多个DCU组成的MDC的组合应用场景。
在第一方面的一种可能的设计中，MDC中的各个DCU基于各自接收到的第三算力配置数据解复位出该MDC内的目标处理器后，在自动驾驶车辆通过传感器采集到感知信息，且感知信息属于该MDC的处理范畴的情况下，该MDC就基于上述解复位后得到的目标处理器对采集到的感知信息进行处理。
在本申请上述实施方式中，同样可基于解复位后的目标处理器处理对应的感知信息，感知信息反映了驾驶业务场景，因此，本申请实施例可增强驾驶业务场景不断变化的适应性。
在第二方面的一种可能的设计中，不管第三算力配置数据是由上位机发送还是由云服务器发送，该第三算力配置数据可以包含在在一个目标文件(可称为第二文件)中，然后由上位机或由云服务器将该第二文件向DCU发送。
在本申请上述实施方式中，具体阐述了可将第三算力配置数据包含在在第二文件中， 实现了每个独立的MDC与第三算力配置数据的一一对应，便于控制和管理，具备可实现性。
在第二方面的一种可能的设计中，第二文件为经过加密的文件。需要说明的是，第二文件的加密的方式可以是对称加密，即加密和解密的秘钥使用的是同一个；加密的方式也可以是非对称加密，即非对称加密需要两个秘钥，这两个秘钥分别为公开秘钥和私有秘钥，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密，如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。在本申请实施例中，对加密的方式不做限定。
在本申请上述实施方式中，该第二文件可以是经过了加密的文件，以防止第三算力配置数据被随意修改，提高了数据的安全性。
在第二方面的一种可能的设计中，该第二文件可以是MDC的License文件(每个MDC都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第二文件的类型和格式均不做限定。
在本申请上述实施方式中，用户可根据需要选择将第三算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。
在第二方面的一种可能的设计中，MDC还可以通过MDC中多个DCU各自对第三算力配置数据进行合法性校验，且在各个第三算力配置数据通过合法性校验的情况下，通过多个DCU各自根据第三算力配置数据解复位各自DCU中的目标处理器。例如，合法性校验具体可以是：校验第三算力配置数据是否为该MDC对应的算力配置数据；校验第三算力配置数据是否存在跳变或篡改；第三算力配置数据是否具备完整性；当第三算力配置数据是包含在在加密的第二文件中时，校验第二文件加密过程是否异常、加密后的第二文件是否可解密等；校验第三算力配置数据的数据取值范围是否在正常范围内等。只有在第三算力配置数据通过合法性校验的情况下，MDC中的各个DCU才根据各自的第三算力配置数据解复位各自DCU内对应的目标处理器。
在本申请上述实施方式中，MDC中的各个DCU根据各自的第三算力配置数据解复位各自DCU内对应的目标处理器之前，还需要各自对该第三算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。
在第二方面的一种可能的设计中，MDC还可以通过主DCU周期性判断多个DCU内每个DCU中处于当前时刻下的各个第四算力配置数据是否一致，在各个第四算力配置数据存在不一致的情况下，通过主DCU对各个第四算力配置数据进行校验对齐。例如，假设MDC包括3个DCU，分别为DCU 1、DCU 2、DCU 3，设置周期为1小时，假设MDC通过DCU 1(即主DCU)接收到第三算力配置数据并将该第三算力配置数据发送给DCU 2和DCU 3，且DCU 1、DCU 2、DCU 3在第一时刻7:30分别将各自的第三算力配置数据存储在各自的存储模块中，当时刻为8:30时，DCU 1会获取DCU 2和DCU 3上的第三算力配置数据，并判断当前时刻8:30DCU 1中的第三算力配置数据和当前时刻8:30DCU 2、DCU 3中的第三算力配置数据(该当前时刻下的各个DCU中的第三算力配置数据可称为第四算力配置数据)是否一致，在各个DCU中的第四算力配置数据不一致的情况下，MDC通过主DCU 对各个DCU中的第四算力配置数据进行校验对齐，使得各个DCU中的第四算力配置数据保持一致。
在本申请上述实施方式中，MDC还可以针对MDC内不同DCU存储模块内的各自存储的第三算力配置数据周期性进行核查校验，核查校验的目的是为了保障第三算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。
本申请实施例第三方面提供一种DCU，该DCU可应用在智能汽车、自动驾驶汽车、网联汽车等上，该DCU具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第四方面提供一种MDC，该MDC可应用在智能汽车、自动驾驶汽车、网联汽车等上，该MDC具有实现上述第二方面或第二面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第五方面提供一种DCU，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第一方面或第一方面任意一种可能实现方式的方法。
本申请实施例第六方面提供一种MDC，可以包括存储器、DCU以及总线系统，其中，DCU包括处理器，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式的方法。
本申请第七方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。
本申请实施例第八方面提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第一方面或第一方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第二方面或第二方面任意一种可能实现方式的方法。
附图说明
图1为一种DCU包括的处理器类型和各个类型处理器的数量的一个示意图；
图2为本申请实施例提供的分布式汽车ECU的一个架构示意图；
图3为本申请实施例提供的汽车DCU的一个架构示意图；
图4为本申请实施例提供的汽车MDC的一个架构示意图；
图5为目前应用于车辆上的算力资源的配置方式的一个流程示意图；
图6为本申请实施例提供的自动驾驶车辆的一种结构示意图；
图7为本申请实施例提供的算力资源的配置方法的一个流程示意图；
图8为本申请实施例提供的上位机通过CAN总线向自动驾驶车辆内的DCU发送对应的第一算力配置数据的一个示意图；
图9为本申请实施例提供的云服务器通过无线通信方式向自动驾驶车辆内的DCU发送对应的第一算力配置数据的一个示意图；
图10为本申请实施例提供的算力资源的配置方法的另一个流程示意图；
图11为本申请实施例提供的MDC的一个示意图；
图12为本申请实施例提供的上位机通过CAN总线向自动驾驶车辆内的MDC发送对应的第三算力配置数据的一个示意图；
图13为本申请实施例提供的云服务器通过无线通信方式向自动驾驶车辆内的MDC发送对应的第三算力配置数据的一个示意图；
图14为本申请实施例提供的算力资源的具体配置过程的一个流程示意图；
图15为本申请实施例提供的DCU的一种结构示意图；
图16为本申请实施例提供的MDC的一种结构示意图；
图17为本申请实施例提供的设备(DCU或MDC)一种结构示意图。
具体实施方式
本申请实施例提供了一种算力资源的配置方法及设备，该方法中的算力配置数据可由提供统一诊断服务(unified diagnostic services，UDS)的上位机进行近端升级时发送或由提供空中下载(over the air，OTA)的云服务器进行远端升级时发送，用于通过按需调整算力配置数据实现对DCU算力资源的调整。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
本申请实施例涉及了许多关于算力的相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。应理解的是，相关的概念解释可能会因为本申请实施例的具体情况有所限制，但并不代表本申请仅能局限于该具体情况，在不同实施例的具体情况可能也会存在差异，具体此处不做限定。
(1)电子控制单元(electronic control unit，ECU)
ECU又称为行车电脑、车载电脑等，从用途上讲则是汽车专用微机控制器，也叫汽车专用单片机，它和普通的电脑一样，由微处理器(microcontroller Unit，MCU)、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、输入/输出接口(I/O)、模数转换器(A/D)以及整形、驱动等大规模集成电路组成。最开始ECU相对来说结构比较简单，主要用于控制发电机工作，后来随着车辆的电子化发展，ECU逐渐占领整个车辆，从防抱死制动系统、四轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统等逐渐延伸到现在车身各类安全、网络、娱乐、传感控制、动力总成、车辆运动系统等，整车上面可能会有几十上百个ECU，例如，发动机上应用的ECU、防抱死制 动系统上应用的ECU等，如图2所示，图2为本申请实施例提供的分布式汽车ECU的一个架构示意图，每个ECU的功能都是相对独立的，随着数字汽车尤其是自动驾驶技术的发展，汽车上的ECU逐渐变得复杂并有集中在一个超级ECU上的趋势。
(2)域控制器(domain control unit，DCU)
DCU是根据汽车电子部件功能将整车划分为动力总成、车辆安全、车身电子、智能座舱、智能驾驶等几个域，利用处理能力更强的多核CPU、GPU等处理器相对集中的去控制每个域，以取代目前分布式汽车电子电子架构，如图3所示，图3为本申请实施例提供的汽车DCU的一个架构示意图，一般来说，一个DCU用于控制一个域。
DCU出现的原因是整合功能分类控制、减少线速，将汽车控制系统模块化，不同DCU之间用高速车载以太网进行数据交换，这里说的都是单个独立工作的DCU。
(3)多域控制器(multi domain controller，MDC)
随着汽车自动化程度的不断提升，其中一些控制域之间的数据交换日益频繁，要求较高的实时性。例如，自动驾驶模块需要实时检测汽车的时速并跟据自动驾驶策略实时进行调整和控制，并且需要在一个高性能的域控制器内完成计算，因此一个包含多个域的控制器，即MDC就出现了，如图4所示，图4为本申请实施例提供的汽车MDC的一个架构示意图。例如，奥迪和德尔福共同开发的zFAS，是通过一块ECU，能够接入不同传感器采集到的感知信息并对感知信息进行分析和处理，最终发出控制命令。一般来说，一个MDC是由多个DCU构成，在这多个DCU中，其中有一个DCU作为主DCU，用于向MDC内的其他DCU发送指令进行数据交互。
(4)算力
算力通常被用来估算处理器(如，CPU)的执行能力，通常以每秒可执行的运算操作次数为单位进行衡量，如“每秒万亿次运算(tera operations per second，TOPS)”、“每秒所执行的浮点运算次数(floating-point operations per second，FLOPS)”、“每秒百万条指令(million instructions per second，MIPS)”等，例如，1TOPS代表处理器每秒钟可进行一万亿次(10^12)操作。
(5)算力配置数据
在本申请实施例中，若是单个独立工作的DCU，则本申请所述的算力配置数据是指该DCU中各个类型的处理器的预设配置数量。以图1为例，假设该DCU总共包括x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core，由于每种类型的处理器具备的算力资源是由处理器本身结构决定，根据处理器类型和结构就可大致估算出对应处理器具备的算力资源，假设该DCU中各个类型的处理器的预设配置数量分别为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，其中，0≤x 0≤x+1，0≤y 0≤y+1，0≤m 0≤x+1，0≤n 0≤y+1，那么在该DCU运行过程中，就只有x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core参与，剩下的处理器则处于休眠状态，从而根据这x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core就可大致估算到该DCU在运行过程中的算力资源，当某个处理器的预设配置数量为0时，说明该处理器在该DCU运行过程中不参与。
需要注意的是，在本申请实施例中，如何预设该DCU中各个类型的处理器配置数量， 可根据该DCU历史运行所消耗的算力资源来预估，从而既可保证该DCU的正常运行，又节省了算力资源。
还需要注意的是，由于DCU中包括的各个类型的处理器可以是多核处理器，例如，各个类型处理器内部还可能包括多个CPU Core、GPU Core、ISP Core、Vector Core等，在一些实施方式中，还可以对各个类型处理器内部的Core数进行配置。此外，各个类型的处理器的运行主频也可配置在该算力配置数据中，具体不做限定。也就是通过配置DCU中各个类型处理器个数、处理器运行主频及处理器内各Core数，参与具体的自动驾驶业务，实现DCU中算力资源的可控配置能力。
类似地，在本申请实施例中，若是单个独立工作的MDC，则本申请所述的算力配置数据是指该MDC内每个DCU中各个类型的处理器的预设配置数量。预设该MDC内每个DCU中各个类型的处理器配置数量的方式与上述预设该DCU中各个类型的处理器配置数量的方式类似，此处不予赘述。
(6)上位机
上位机是指可以直接发出操控命令的计算机设备，在本申请实施例中，能够对ECU、DCU或MDC基于统一诊断服务协议(unified diagnosis service，UDS)进行通信的计算机设备都可称为上位机(也可称为诊断仪、诊断机、诊断工具等)，例如，个人计算机(personal computer，PC)、手机、平板电脑等智能手持终端设备，以及智能手环、智能手表等智能可穿戴设备，甚至是单片机，只要该设备能够运行相应的诊断软件，且能与ECU、DCU或MDC基于UDS协议进行通信的设备都可作为本申请实施例中的上位机，具体此处不做限定。
(7)统一诊断服务(unified diagnosis service，UDS)
在汽车电子电气(electrical electronics)领域，诊断功能是ECU/DCU/MDC的基本功能之一。ECU/DCU/MDC的软件或固件刷新，可由诊断功能支撑实现。
不同诊断通信协议的开发、调整、实施和维护会给车辆制造商、系统供应商和ECU/DCU/MDC供应商带来不必要的成本。为了解决此问题，将不同的技术协议和数据通信原理编译为一个国际ISO标准，通常称为UDS(也可称为ISO 14229-1)，UDS是一种汽车通用诊断协议，与数据链路无关，如表1所示，表1为开放式系统互联(open system interconnection，OSI)模型各层应用的协议，其中，UDS面向于OSI模型中的应用层，它可在不同的汽车总线(如，CAN、LIN、Flexray、Ethernet、K-line等)上实现。目前，大部分汽车厂商均采用UDS on CAN的诊断协议，形象的说，就是使用一套仪器(一般称为上位机)，对当前汽车上ECU/DCU/MDC内部的信息/数据进行分析，而这套仪器与ECU/DCU/MDC交谈所使用的语言就是UDS(不是唯一方法)。
表1：OSI模型各层应用的协议
OSI各层 协议类型
应用层 ISO 14229-1(UDS)
表示层 ---
会话层 ISO 15765-3
传输层 ISO 15765-2
网络层 ISO 15765-2
数据链路层 ISO 11898-1
物理层 ISO 11898
UDS本质上是一系列的诊断服务，这种由UDS定义好的诊断服务可称为标准诊断服务，标准诊断服务共包括6大类共26种，每种标准诊断服务都有自己独立的服务标识符(service identifier，SID)，SID本质上是一种定向的通信，是一种交互协议，即上位机给ECU/DCU/MDC发送指定的诊断请求(request)，这条请求中需要包含SID，如果是肯定响应，ECU/DCU/MDC给上位机返回的是[SID+0x40]，如，发送的诊断请求的SID是0x10，肯定响应则是0x50；如果是否定响应，ECU给上位机返回的是0x7F+SID+NRC，返回的是一个声明，NRC的全称是Negative Response Code，即否定响应码，也就是说，如果ECU拒绝了一个请求，它会向上位机返回一个NRC，不同的诊断服务，可能包含不同的NRC，不同的NRC有不同的含义。
因此，基于UDS的诊断通信过程是：上位机向ECU/DCU/MDC发送诊断请求(request)，ECU/DCU/MDC给出诊断响应(response)，诊断响应包括肯定响应和否定响应，UDS为不同诊断服务的request和response定义了统一的协议格式。
(8)空中下载(over the air，OTA)
OTA是指通过网络从远程服务器(也可称为云服务器)下载新的软件更新包对自身系统进行升级。也就是说，ECU/DCU/MDC的软件或固件刷新，除了可由诊断功能支撑实现(即近端升级)之外，还可以通过网络远程通道的OTA进行升级(即远端升级)。
在智能车领域中，传统汽车在用户行驶验证中出现了系统方面的缺陷，而这些问题的解决办法只有一个，汽车厂家启动召回程序，在用户收到召回程序后返厂进行系统的统一升级，而OTA技术则可以远程通过数据包的形式完成缺陷修复，避免了持续数月的进厂召回带来的风险。此外，由于在产品设计中硬件的超前配备，智能车操作系统可以通过一次次OTA升级，不断给车主逐步开启新功能，优化产品体验，进行快速迭代，提供更加优质的系统服务。
(9)处理器
在本申请实施例中，处理器可以是指CPU、GPU、NPU等传统意义上的处理器，也可以是指传统处理器内部包括的一个或多个的CPU Core、GPU Core、ISP Core、Vector Core等，运算器、取指令和解码硬件、指令管道以及一些cache内存被整合起来成为本申请所述的“Core”，Core也可称为核。在本申请实施例中，由于DCU中包括的各个类型的处理器可以是多核处理器，例如，各个类型处理器内部还可能包括多个CPU Core、GPU Core、ISP Core、Vector Core等，也就是在本申请例中，所述处理器除了可以是指普通的CPU、GPU等处理器外，还可以是指处理器核，即上述各种Core，为便于理解，在本申请实施例 中，将普通处理器以及处理器核统称为处理器。
此外，在介绍本申请实施例之前，先对目前应用于车辆上的算力资源的配置方式进行简单介绍，使得后续便于理解本申请实施例。
具体如图5所示，假设DCU中包括的处理器类型和数量为m+1个CPU、n+1个AI Core、k+1个Vector Core和一个eFuse，其中，这m+1个CPU分别为CPU 0、CPU 1、…、CPU m，这n+1个AI Core分别为AI Core 0、AI Core 1、…、AI Core n，这k+1个Vector Core分别为Vector Core 0、Vector Core 1、…、Vector Core k。那么在该DCU出厂前，就会将该DCU中各个类型的处理器的总数量(即m+1个CPU、n+1个AI Core、k+1个Vector Core)作为算力配置数据烧写在eFuse中，当DCU启动上电时，选取其中一个CPU(比如，CPU 0)作为主CPU，主CPU初始化相关外设后，从eFuse中读取算力配置数据，然后根据读取到的算力配置数据解复位其他的CPU、AI Core和Vector Core，使得其他各个处理器各自完成自身的初始化，这样当DCU运行时，该DCU内的所有处理器都被调用起来处理相关业务数据。
由于自动驾驶的功能应用场景非常复杂，导致DCU在出厂前，无法完整确定后续自动驾驶功能所需要的算力资源以及各个处理器的具体配置数量，当前这种通过将算力配置数据烧写进eFuse的算力配置方案只能按最大算力资源进行烧写配置，而在DCU的实际应用过程中，可能并不需要用到这么大的算力资源，造成资源浪费；此外算力配置数据是烧写在eFuse中，eFuse作为一次性可编程存储器，后续无法更改。
基于此，为解决上述所述问题，本申请实施例首先提供了算力资源的配置方法，该方法中的算力配置数据可由提供UDS的上位机进行近端升级时发送或由提供OTA的云服务器进行远端升级时发送，用于通过按需调整算力配置数据实现对DCU算力资源的调整。
下面结合附图，对本申请的实施例进行详细描述。本领域普通技术人员可知，随着技术的发展和新的场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
本申请实施例所提供的算力资源的配置方法可以应用于对各种智能行驶(如，无人驾驶、辅助驾驶等)的智能体(如，智能汽车、自动驾驶汽车、网联汽车等)进行运动规划(如，速度规划、驾驶行为决策、全局路径规划等)的场景中，以该智能体为自动驾驶车辆为例，对自动驾驶车辆内部各个结构的具体功能进行介绍，具体请参阅图6，图6为本申请实施例提供的自动驾驶车辆的一种结构示意图，自动驾驶车辆100配置为完全或部分地自动驾驶模式，例如，自动驾驶车辆100可以在处于自动驾驶模式中的同时控制自身，并且可通过人为操作来确定车辆及其周边环境的当前状态，确定周边环境中的至少一个其他车辆的可能行为，并确定其他车辆执行可能行为的可能性相对应的置信水平，基于所确定的信息来控制自动驾驶车辆100。在自动驾驶车辆100处于自动驾驶模式中时，也可以将自动驾驶车辆100置为在没有和人交互的情况下操作。
自动驾驶车辆100可包括各种子系统，例如行进系统102、传感器系统104(如，摄像机、SICK、激光雷达等均属于传感器系统104中的模块)、控制系统106、一个或多个外围设备108以及电源110、计算机系统112和用户接口116。可选地，自动驾驶车辆100可包 括更多或更少的子系统，并且每个子系统可包括多个部件。另外，自动驾驶车辆100的每个子系统和部件可以通过有线或者无线互连。
行进系统102可包括为自动驾驶车辆100提供动力运动的组件。
在一个实施例中，行进系统102可包括引擎118、能量源119、传动装置120和车轮/轮胎121。
其中，引擎118可以是内燃引擎、电动机、空气压缩引擎或其他类型的引擎组合，例如，汽油发动机和电动机组成的混动引擎，内燃引擎和空气压缩引擎组成的混动引擎。引擎118将能量源119转换成机械能量。能量源119的示例包括汽油、柴油、其他基于石油的燃料、丙烷、其他基于压缩气体的燃料、乙醇、太阳能电池板、电池和其他电力来源。能量源119也可以为自动驾驶车辆100的其他系统提供能量。传动装置120可以将来自引擎118的机械动力传送到车轮121。传动装置120可包括变速箱、差速器和驱动轴。在一个实施例中，传动装置120还可以包括其他器件，比如离合器。其中，驱动轴可包括可耦合到一个或多个车轮121的一个或多个轴。
传感器系统104可包括感测关于自动驾驶车辆100周边的环境的信息的若干个传感器。例如，传感器系统104可包括定位系统122(定位系统可以是全球定位GPS系统，也可以是北斗系统或者其他定位系统)、惯性测量单元(inertial measurement unit，IMU)124、雷达126、激光测距仪128以及相机130。传感器系统104还可包括被监视自动驾驶车辆100的内部系统的传感器(例如，车内空气质量监测器、燃油量表、机油温度表等)。来自这些传感器中的一个或多个的传感数据可用于检测对象及其相应特性(位置、形状、方向、速度等)。这种检测和识别是自主自动驾驶车辆100的安全操作的关键功能。在本申请实施例中，激光感知模块是属于传感器系统104中非常重要的一个感知模块。
其中，定位系统122可用于估计自动驾驶车辆100的地理位置。IMU 124用于基于惯性加速度来感知自动驾驶车辆100的位置和朝向变化。在一个实施例中，IMU 124可以是加速度计和陀螺仪的组合。雷达126可利用无线电信号来感知自动驾驶车辆100的周边环境内的物体，具体可以表现为毫米波雷达或激光雷达。在一些实施例中，除了感知物体以外，雷达126还可用于感知物体的速度和/或前进方向。激光测距仪128可利用激光来感知自动驾驶车辆100所位于的环境中的物体。在一些实施例中，激光测距仪128可包括一个或多个激光源、激光扫描器以及一个或多个检测器，以及其他系统组件。相机130可用于捕捉自动驾驶车辆100的周边环境的多个图像。相机130可以是静态相机或视频相机。
控制系统106为控制自动驾驶车辆100及其组件的操作。控制系统106可包括各种部件，其中包括转向系统132、油门134、制动单元136、计算机视觉系统140、线路控制系统142以及障碍避免系统144。
其中，转向系统132可操作来调整自动驾驶车辆100的前进方向。
例如在一个实施例中可以为方向盘系统。油门134用于控制引擎118的操作速度并进而控制自动驾驶车辆100的速度。制动单元136用于控制自动驾驶车辆100减速。制动单元136可使用摩擦力来减慢车轮121。在其他实施例中，制动单元136可将车轮121的动能转换为电流。制动单元136也可采取其他形式来减慢车轮121转速从而控制自动驾驶车 辆100的速度。计算机视觉系统140可以操作来处理和分析由相机130捕捉的图像以便识别自动驾驶车辆100周边环境中的物体和/或特征。所述物体和/或特征可包括交通信号、道路边界和障碍体。计算机视觉系统140可使用物体识别算法、运动中恢复结构(Structure from Motion，SFM)算法、视频跟踪和其他计算机视觉技术。在一些实施例中，计算机视觉系统140可以用于为环境绘制地图、跟踪物体、估计物体的速度等等。线路控制系统142用于确定自动驾驶车辆100的行驶路线以及行驶速度。在一些实施例中，线路控制系统142可以包括横向规划模块1421和纵向规划模块1422，横向规划模块1421和纵向规划模块1422分别用于结合来自障碍避免系统144、GPS 122和一个或多个预定地图的数据为自动驾驶车辆100确定行驶路线和行驶速度。障碍避免系统144用于识别、评估和避免或者以其他方式越过自动驾驶车辆100的环境中的障碍体，前述障碍体具体可以表现为实际障碍体和可能与自动驾驶车辆100发生碰撞的虚拟移动体。在一个实例中，控制系统106可以增加或替换地包括除了所示出和描述的那些以外的组件。或者也可以减少一部分上述示出的组件。
自动驾驶车辆100通过外围设备108与外部传感器、其他车辆、其他计算机系统或用户之间进行交互。外围设备108可包括无线通信系统146、车载电脑148、麦克风150和/或扬声器152。在一些实施例中，外围设备108为自动驾驶车辆100的用户提供与用户接口116交互的手段。例如，车载电脑148可向自动驾驶车辆100的用户提供信息。用户接口116还可操作车载电脑148来接收用户的输入。车载电脑148可以通过触摸屏进行操作。在其他情况中，外围设备108可提供用于自动驾驶车辆100与位于车内的其它设备通信的手段。例如，麦克风150可从自动驾驶车辆100的用户接收音频(例如，语音命令或其他音频输入)。类似地，扬声器152可向自动驾驶车辆100的用户输出音频。无线通信系统146可以直接地或者经由通信网络来与一个或多个设备无线通信。例如，无线通信系统146可使用3G蜂窝通信，例如CDMA、EVD0、GSM/GPRS，或者4G蜂窝通信，例如LTE。或者5G蜂窝通信。无线通信系统146可利用无线局域网(wireless local area network，WLAN)通信。在一些实施例中，无线通信系统146可利用红外链路、蓝牙或ZigBee与设备直接通信。其他无线协议，例如各种车辆通信系统，例如，无线通信系统146可包括一个或多个专用短程通信(dedicated short range communications，DSRC)设备，这些设备可包括车辆和/或路边台站之间的公共和/或私有数据通信。
电源110可向自动驾驶车辆100的各种组件提供电力。在一个实施例中，电源110可以为可再充电锂离子或铅酸电池。这种电池的一个或多个电池组可被配置为电源为自动驾驶车辆100的各种组件提供电力。在一些实施例中，电源110和能量源119可一起实现，例如一些全电动车中那样。
自动驾驶车辆100的部分或所有功能受计算机系统112控制。计算机系统112可包括至少一个DCU116，该DCU116中包括至少一个处理器113，处理器113执行存储在例如存储器114这样的非暂态计算机可读介质中的指令115。计算机系统112还可以是采用分布式方式控制自动驾驶车辆100的个体组件或子系统的多个计算设备。处理器113可以是任何常规的处理器，诸如商业可获得的CPU、GPU、VPU、NPU、DSP、ISP等，DCU116包括 什么类型的处理器以及处理器的数量取决于DCU116所控制的域。可选地，处理器113可以是诸如专用集成电路(application specific integrated circuit，ASIC)或其它基于硬件的处理器的专用设备。尽管图6功能性地图示了处理器、存储器和在相同块中的计算机系统112的其它部件，但是本领域的普通技术人员应该理解该处理器或存储器实际上可以包括不存储在相同的物理外壳内的多个处理器或存储器。例如，存储器114可以是硬盘驱动器或位于不同于计算机系统112的外壳内的其它存储介质。因此，对处理器113或存储器114的引用将被理解为包括可以并行操作或者可以不并行操作的处理器或存储器的集合的引用。不同于使用单一的处理器来执行此处所描述的步骤，诸如转向组件和减速组件的一些组件每个都可以具有其自己的处理器，所述处理器只执行与特定于组件的功能相关的计算。
需要说明的是，在本申请的一些实施方式中，计算机系统112还可以包括至少一个MDC(图6中未示出)，一般来说，一个MDC是由多个DCU构成，在这多个DCU中，其中有一个DCU作为主DCU，用于向MDC内的其他DCU发送指令进行数据交互。
在此处所描述的各个方面中，处理器113可以位于远离自动驾驶车辆100并且与自动驾驶车辆100进行无线通信。在其它方面中，此处所描述的过程中的一些在布置于自动驾驶车辆100内的处理器113上执行而其它则由远程处理器113执行，包括采取执行单一操纵的必要步骤。
在一些实施例中，存储器114可包含指令115(例如，程序逻辑)，指令115可被处理器113执行来执行自动驾驶车辆100的各种功能，包括以上描述的那些功能。存储器114也可包含额外的指令，包括向行进系统102、传感器系统104、控制系统106和外围设备108中的一个或多个发送数据、从其接收数据、与其交互和/或对其进行控制的指令。除了指令115以外，存储器114还可存储数据，例如道路地图、路线信息，车辆的位置、方向、速度以及其它这样的车辆数据，以及其他信息。这种信息可在自动驾驶车辆100在自主、半自主和/或手动模式中操作期间被自动驾驶车辆100和计算机系统112使用。用户接口116，用于向自动驾驶车辆100的用户提供信息或从其接收信息。可选地，用户接口116可包括在外围设备108的集合内的一个或多个输入/输出设备，例如无线通信系统146、车载电脑148、麦克风150和扬声器152。
计算机系统112可基于从各种子系统(例如，行进系统102、传感器系统104和控制系统106)以及从用户接口116接收的输入来控制自动驾驶车辆100的功能。例如，计算机系统112可利用来自控制系统106的输入以便控制转向系统132来避免由传感器系统104和障碍避免系统144检测到的障碍体。在一些实施例中，计算机系统112可操作来对自动驾驶车辆100及其子系统的许多方面提供控制。
可选地，上述这些组件中的一个或多个可与自动驾驶车辆100分开安装或关联。例如，存储器114可以部分或完全地与自动驾驶车辆100分开存在。上述组件可以按有线和/或无线方式来通信地耦合在一起。
可选地，上述组件只是一个示例，实际应用中，上述各个模块中的组件有可能根据实际需要增添或者删除，图6不应理解为对本申请实施例的限制。在道路行进的自动驾驶车辆，如上面的自动驾驶车辆100，可以识别其周围环境内的物体以确定对当前速度的调整。 所述物体可以是其它车辆、交通控制设备、或者其它类型的物体。在一些示例中，可以独立地考虑每个识别的物体，并且基于物体的各自的特性，诸如它的当前速度、加速度、与车辆的间距等，可以用来确定自动驾驶车辆所要调整的速度。
可选地，自动驾驶车辆100或者与自动驾驶车辆100相关联的计算设备如图6的计算机系统112、计算机视觉系统140、存储器114可以基于所识别的物体的特性和周围环境的状态(例如，交通、雨、道路上的冰、等等)来预测所识别的物体的行为。可选地，每一个所识别的物体都依赖于彼此的行为，因此还可以将所识别的所有物体全部一起考虑来预测单个识别的物体的行为。自动驾驶车辆100能够基于预测的所识别的物体的行为来调整它的速度。换句话说，自动驾驶车辆100能够基于所预测的物体的行为来确定车辆将需要调整到(例如，加速、减速、或者停止)什么稳定状态。在这个过程中，也可以考虑其它因素来确定自动驾驶车辆100的速度，诸如，自动驾驶车辆100在行驶的道路中的横向位置、道路的曲率、静态和动态物体的接近度等等。除了提供调整自动驾驶车辆的速度的指令之外，计算设备还可以提供修改自动驾驶车辆100的转向角的指令，以使得自动驾驶车辆100遵循给定的轨迹和/或维持与自动驾驶车辆100附近的物体(例如，道路上的相邻车道中的轿车)的安全横向和纵向距离。
上述自动驾驶车辆100可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车、和手推车等，本申请实施例不做特别的限定。
本申请实施例提供了一种算力资源的配置方法，可应用于对各种智能行驶(如，无人驾驶、辅助驾驶等)的智能体(如，图6对应的自动驾驶车辆的总体架构)进行运动规划(如，速度规划、驾驶行为决策、全局路径规划等)的场景中，为便于理解，在本申请实施例中，均以智能体为自动驾驶车辆为例进行示意。此外，当自动驾驶车辆中包括的是DCU或MDC时，本申请实施例提供的算力资源的配置方法略有不同，下面分别进行说明。
一、自动驾驶车辆内的控制器为DCU
请参阅图7，图7为本申请实施例提供的算力资源的配置方法的一种流程示意图，具体包括如下步骤：
701、DCU接收云服务器或上位机发送的与该DCU对应的第一算力配置数据，DCU为车辆上的任意一个DCU，DCU包括至少一个处理器，该第一算力配置数据包括DCU中至少一个类型的处理器的预设配置数量。
首先，DCU接收与该DCU对应的第一算力配置数据，该DCU为车辆上的任意一个DCU，该DCU包括至少一个处理器，该第一算力配置数据包括该DCU中至少一个类型(如，可以是各个类型)的处理器的预设配置数量，该预设配置数量可根据该DCU的历史算力资源的消耗情况以及该DCU的运行业务的具体情况进行设置，并且该第一算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，便于后续按需更新第一算力配置数据以实现对DCU算力资源的调整，在保证业务顺利进行的前提下节约算力资源。
需要注意的是，在本申请实施例中，所述的算力配置数据是指该DCU中各个类型的处 理器的预设配置数量。以图1为例，假设该DCU总共包括x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core，由于每种类型的处理器具备的算力资源是由处理器本身结构决定，根据处理器类型和结构就可大致估算出对应处理器具备的算力资源，假设该DCU中各个类型的处理器的预设配置数量分别为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，其中，0≤x 0≤x+1，0≤y 0≤y+1，0≤m 0≤m+1，0≤n 0≤n+1，那么在该DCU运行过程中，就只有x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core参与，剩下的处理器则处于休眠状态，从而根据这x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core就可大致估算到该DCU在运行过程中的算力资源，当某个处理器的预设配置数量为0时，说明该处理器在该DCU运行过程中不参与。
还需要注意的是，在本申请的一些实施方式中，参与运算的这x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core并不限定是这x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core中的哪些。例如，假设DCU中一共有3个ISP、4个GPU、2个CPU和6个AI core，该DCU中各个类型的处理器的预设配置数量分别为2个ISP、2个GPU、1个CPU和3个AI core，即算力配置数据为2个ISP、2个GPU、1个CPU和3个AI core，那么这2个ISP可以是总的3个ISP中的任意2个，类似地，这2个GPU也可以是总的4个GPU中的任意2个，这1个CPU也可以是总的2个CPU中的任意1个，这3个AI core也可以是总的6个AI core中的任意3个。
还需要注意的是，在本申请的一些实施方式中，可能属于同一类型的处理器内部的Core数会略有不同，那么在这种情况下，参与运算的x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core可以限定是x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core中的哪些。
还需要注意的是，由于DCU中包括的各个类型的处理器可以是多核处理器，例如，各个类型处理器内部还可能包括多个CPU Core、GPU Core、ISP Core、Vector Core等，在一些实施方式中，还可以对各个类型处理器内部的Core数进行配置。此外，各个类型的处理器的运行主频也可配置在该算力配置数据中，具体不做限定，也就是说，算力配置数据可以通过配置DCU中各个类型处理器个数、处理器运行主频及处理器内各Core数进行表征。
需要说明的是，在本申请的一些实施方式中，DCU接收与该DCU对应的第一算力配置数据可通过如下几种方式得到：
A、该第一算力配置数据由上位机发送。
由于ECU/DCU/MDC的软件或固件刷新，可由诊断功能支撑实现。因此，该第一算力配置数据可包含在在UDS的诊断服务，当上位机向该DCU提供诊断服务时，由上位机向该DCU发送该第一算力配置数据，如图8所示，图8示意的是上位机(图8以PC为例进行示意)通过控制器局域网络(controller area network，CAN)总线向自动驾驶车辆内的DCU发送第一算力配置数据，具体地，由上位机发出诊断请求(request)，自动驾驶车辆上的DCU给出响应(response)，在此通信过程中，上位机和DCU分别是计算机网络通信中的client和server的角色。
B、第一算力配置数据由云服务器发送。
ECU/DCU/MDC的软件或固件刷新，除了可由诊断功能支撑实现(即近端升级)之外， 还可以通过网络远程通道的OTA进行升级(即远端升级)，因此，该第一算力配置数据还可存储在提供OTA服务的云服务器上，当该云服务器对安装该DCU的车辆提供OTA服务时，由该云服务器向该DCU发送该第一算力配置数据，如图9所示，图9示意的是云服务器通过无线通信的方式向自动驾驶车辆内的DCU发送对应的第一算力配置数据。
需要说明的是，在本申请的一些实施方式中，不管第一算力配置数据是由上位机发送还是由云服务器发送，该第一算力配置数据可以包含在在一个目标文件(可称为第一文件)中，然后由上位机或由云服务器将该第一文件向DCU发送，将第一算力配置数据包含在在第一文件中，实现了每个独立的DCU与第一算力配置数据的一一对应，便于控制和管理，且具备可实现性。
还需要说明的是，该第一文件可以是DCU的License文件(每个DCU都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第一文件的类型和格式均不做限定，用户可根据需要选择将第一算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。此外，第一文件支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，便于后续按需更新第一算力配置数据以实现对DCU算力资源的调整，在保证业务顺利进行的前提下节约算力资源。
还需要说明的是，在本申请的一些实施方式中，该第一文件可以是经过了加密的文件，以防止第一算力配置数据被随意修改，提高了数据的安全性。
需要注意的是，对第一文件的加密方式可以是对称加密，即加密和解密的秘钥使用的是同一个；加密的方式也可以是非对称加密，即非对称加密需要两个秘钥，这两个秘钥分别为公开秘钥和私有秘钥，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密，如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。在本申请实施例中，对加密的方式不做限定。
还需要说明的是，在本申请的一些实施方式中，DCU接收到上位机或云服务器发送的第一算力配置数据后，就可持久化存储于该DCU内存储模块中，如，存储模块可以是带电可擦可编程只读存储器(electrically erasable programmable read only memory，EEPROM)、Flash闪存等，本申请实施例所述的持久化存储是指把数据(如本申请实施例所述的第一算力配置数据)保存到可永久保存的存储模块中(如磁盘)，持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等。在本申请实施例中，只有当DCU再次接收到新的第一算力配置数据时，该持久化存储于DCU内存储模块中的原第一算力配置数据才会被更新为新的第一算力配置数据。
还需要说明的是，在本申请的一些实施方式中，为了提高数据的存储可靠性，DCU还可以对接收到的第一算力配置数据进行冗余备份，具体地，当DCU接收到第一算力配置数据时，在第一时刻将该第一算力配置数据进行备份，得到第一备份数据，并将该第一算力配置数据和第一备份数据分别存储在DCU中的不同存储模块中，如，分别存储在DCU内不同存储介质或相同存储介质中的不同块中。
还需要说明的是，在本申请的一些实施方式中，还可以针对DCU内不同存储模块内的 第一算力配置数据和第一备份数据周期性进行核查校验。核查校验的目的是为了保障第一算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。例如，假设设置周期为2小时，假设DCU接收到第一算力配置数据并在第一时刻8:00分别将该第一算力配置数据和第一备份数据存储在该DCU内的存储模块1和存储模块2中，当时刻为10:00时，该DCU会判断当前时刻10:00存储模块1中的第一算力配置数据(该当前时刻下的第一算力配置数据可称为第二算力配置数据)和当前时刻10:00存储模块2中的第一备份数据(该当前时刻下的第一备份数据可称为第二备份数据)是否一致，在该第二算力配置数据与该第二备份数据不一致的情况下，DCU对第二算力配置数据和第二备份数据进行校验对齐，使得该第二算力配置数据和第二备份数据与第一算力配置数据保持一致。
具体地，在本申请的一些实施方式中，DCU具有自动恢复自愈能力，DCU可检测到哪份数据存在错误，假设DCU判断第二算力配置数据与第一算力配置数据一致，第二备份数据与第一备份数据不一致，说明该第二算力配置数据与该第二备份数据不一致且第二算力配置数据是正确的数据，DCU可将该第二算力配置数据重新进行备份，得到更正后的第二备份数据，从而完成对第二算力配置数据与第二备份数据的校验对齐；类似地，假设DCU判断第二算力配置数据与第一算力配置数据不一致，第二备份数据与第一备份数据一致，说明该第二算力配置数据与该第二备份数据不一致且第二备份数据是正确的数据，DCU可将该第二备份数据进行备份，备份后的数据作为更正后的第二算力配置数据，从而完成对第二算力配置数据与第二备份数据的校验对齐；假设DCU判断第二算力配置数据与第一算力配置数据不一致且第二备份数据与第一备份数据也不一致，说明这两份数据都是错误的，此时可启动近端升级或远端升级流程，从上位机或云服务器处重新接收一份新的第一算力配置数据并进行备份。
需要说明的是，在本申请实施例中，该DCU为自动驾驶车辆内的任意一个DCU，在本申请的一些实施方式中，该自动驾驶车辆内的每个独立工作的DCU，都可作为DCU执行该步骤701的过程，从而得到该自动驾驶车辆内每个DCU各自对应的算力配置数据，具体过程与该步骤701类似，此处不予赘述。
702、DCU根据该第一算力配置数据解复位该DCU中的目标处理器，得到解复位后的目标处理器。
DCU接收到上位机或云服务器发送的与该DCU对应的第一算力配置数据后，就可根据该第一算力配置数据解复位该DCU内对应的处理器(可称为目标处理器)，从而得到解复位后的目标处理器。
为便于理解，下面依然以图1为例进行示意：假设该DCU总共包括x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core，该DCU中各个类型的处理器的预设配置数量分别为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，其中，0≤x 0≤x+1，0≤y 0≤y+1，0≤m 0≤m+1，0≤n 0≤n+1，也就是说，该DCU的第一算力配置数据为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，且该第一算力配置数据被存储在该DCU内的存储模中，DCU上电后，会从存储模块中读取该第一算力配置数据，并基于该第一算力配置数据从该DCU中解复位出x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，那么在该DCU运行过程中， 就只有x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core参与，这x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core就称为本申请所述的目标处理器，剩下的处理器则处于休眠状态，从而根据这x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core就可大致估算到该DCU在运行过程中的算力资源，当某个处理器的预设配置数量为0时，说明该处理器在该DCU运行过程中不参与。
需要说明的是，在本申请的一些实施方式中，DCU根据第一算力配置数据解复位该DCU内对应的目标处理器之前，还需要对该第一算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。例如，合法性校验具体可以是：校验第一算力配置数据是否为该DCU对应的算力配置数据；校验第一算力配置数据是否存在跳变或篡改；第一算力配置数据是否具备完整性；当第一算力配置数据是包含在在加密的第一文件中时，校验第一文件加密过程是否异常、加密后的第一文件是否可解密等；校验第一算力配置数据的数据取值范围是否在正常范围内等，如，DCU总共有4个CPU，而第一算力配置数据中的CPU数量为5个，则数据取值范围不在正常范围内。只有在第一算力配置数据通过合法性校验的情况下，DCU才根据第一算力配置数据解复位该DCU内对应的目标处理器。
还需要说明的是，在本申请的一些实施方式中，若第一算力配置数据是包含在在第一文件中，那么DCU对第一算力配置数据进行合法性校验是通过对第一文件进行合法性校验实现的。在本申请的另一些实施方式中，若第一文件是经过加密的文件，那么DCU还需要先对该加密的第一文件进行解密，得到解密后的第一文件，再对解密后的第一文件进行合法性校验。
703、在车辆通过传感器采集到感知信息，且所述感知信息属于该DCU的处理范畴的情况下，该DCU基于所述解复位后的目标处理器处理该感知信息。
在本申请的一些实施方式中，在得到解复位后的目标处理器后，还可以继续执行步骤703，也就是DCU基于第一算力配置数据解复位出该DCU内的目标处理器后，在自动驾驶车辆通过传感器采集到感知信息，且感知信息属于该DCU的处理范畴的情况下，该DCU就基于上述解复位后得到的目标处理器对采集到的感知信息进行处理。
为便于理解，下面依然以图1为例进行示意：假设该DCU总共包括x+1个ISP、y+1个GPU、m+1个CPU和n+1个AI core，且该DCU的第一算力配置数据为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，那么解复位得到的目标处理器就为x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core，最后该DCU基于这些目标处理器(即x 0个ISP、y 0个GPU、m 0个CPU和n 0个AI core)对传感器采集到的感知信息(该感知信息属于该DCU的处理范畴的情况下)进行处理。
需要注意的是，在本申请实施例中，DCU所执行的步骤均是通过DCU中的主CPU实现的，例如，DCU是通过DCU中的主CPU接收上位机或云服务器发送的第一算力配置数据。
在本申请上述实施方式中，当自动驾驶车辆的控制器为DCU，第一算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按 需更新第一算力配置数据以实现对DCU中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，避免了DCU出厂时对应的算力配置数据只能固化于eFuse中无法修改的情形，增强了后续驾驶业务场景不断变化的适应性。
二、自动驾驶车辆内的控制器为MDC
请参阅图10，图10为本申请实施例提供的算力资源的配置方法的另一种流程示意图，具体包括如下步骤：
1001、MDC通过主DCU接收云服务器或上位机发送的与MDC对应的第三算力配置数据，MDC包括多个DCU，该主DCU为该多个DCU中的一个，该多个DCU中的每个DCU包括至少一个处理器，该第三算力配置数据包括该每个DCU中至少一个类型的处理器的预设配置数量。
首先，MDC通过MDC中的主DCU接收与该MDC对应的第三算力配置数据，该MDC为车辆上的任意一个MDC(一般情况下一个车辆部署一个MDC，当车辆仅部署一个MDC，则该MDC就是这一个MDC)，MDC包括多个DCU，其中主DCU为这多个DCU中的任意一个，每个DCU包括至少一个处理器(如，CPU)，该第三算力配置数据就包括MDC内每个DCU中至少一个类型(如，可以是各个类型)的处理器的预设配置数量。
为便于理解，下面以图11为例进行示意：假设MDC包括3个DCU，分别为DCU 1、DCU 2和DCU 3，其中，DCU 1包括m 1+1个CPU、x 1+1个ISP、y 1+1个GPU和n 1+1个AI Core，DCU 2包括m 2+1个CPU、y 2+1个GPU和n 2+1个Vector Core，DCU 3包括m 3+1个CPU、x 3+1个ISP、y 3+1个GPU和n 3+1个Vector Core。假设该MDC内DCU 1中各个类型的处理器的预设配置数量分别为m 01个CPU、x 01个ISP、y 01个GPU和n 01个AI core，该MDC内DCU 2中各个类型的处理器的预设配置数量分别为m 02个CPU、y 02个GPU和n 02个Vector core，该MDC内DCU 3中各个类型的处理器的预设配置数量分别为m 03个CPU、x 03个ISP、y 03个GPU和n 03个Vector core，其中，0≤m 01≤m 1+1，0≤x 01≤x 1+1，0≤y 01≤y 1+1，0≤n 01≤n 1+1，0≤m 02≤m 2+1，0≤y 02≤y 2+1，0≤n 02≤n 2+1，0≤m 03≤m 3+1，0≤x 03≤x 3+1，0≤y 03≤y 3+1，0≤n 03≤n 3+1。那么在该MDC运行过程中，就只有DCU 1中的m 01个CPU、x 01个ISP、y 01个GPU、n 01个AI core，以及DCU 2中的m 02个CPU、y 02个GPU和n 02个Vector core，以及DCU 3中的m 03个CPU、x 03个ISP、y 03个GPU和n 03个Vector core参与，各个DCU中剩下的处理器则处于休眠状态，从而根据这DCU 1中的m 01个CPU、x 01个ISP、y 01个GPU、n 01个AI core，以及DCU 2中的m 02个CPU、y 02个GPU和n 02个Vector core，以及DCU 3中的m 03个CPU、x 03个ISP、y 03个GPU和n 03个Vector core就可大致估算到该MDC在运行过程中的算力资源，当某个DCU中的某个处理器的预设配置数量为0时，说明该处理器在该MDC运行过程中不参与。
还需要注意的是，在本申请的一些实施方式中，参与运算的DCU 1中的m 01个CPU、x 01个ISP、y 01个GPU、n 01个AI core，以及DCU 2中的m 02个CPU、y 02个GPU和n 02个Vector core，以及DCU 3中的m 03个CPU、x 03个ISP、y 03个GPU和n 03个Vector core并不限定是DCU 1、DCU 2、DCU 3中的哪些，例如，假设该MDC中的DCU 1中一共有3个ISP、 4个GPU、2个CPU和6个AI core，该DCU 1中各个类型的处理器的预设配置数量分别为2个ISP、2个GPU、1个CPU和3个AI core，即第三算力配置数据中对应DCU 1的部分为2个ISP、2个GPU、1个CPU和3个AI core，那么这2个ISP可以是总的3个ISP中的任意2个，类似地，这2个GPU也可以是总的4个GPU中的任意2个，这1个CPU也可以是总的2个CPU中的任意1个，这3个AI core也可以是总的6个AI core中的任意3个。类似地，第三算力配置数据中对应DCU 2、DCU 3的部分的情况与DCU 1类似，具体此处不予赘述。
还需要注意的是，在本申请的一些实施方式中，可能属于同一类型的处理器内部的Core数会略有不同，那么在这种情况下，以DCU 1为例，参与运算的x 01个ISP、y 01个GPU、m 01个CPU和n 01个AI core可以限定是x 1+1个ISP、y 1+1个GPU、m 1+1个CPU和n 1+1个AI core中的哪些。
需要说明的是，在本申请的一些实施方式中，MDC接收与该MDC对应的第三算力配置数据可通过如下几种方式得到：
A、该第三算力配置数据由上位机发送。
由于ECU/DCU/MDC的软件或固件刷新，可由诊断功能支撑实现。因此，该第三算力配置数据可包含在在UDS的诊断服务，当上位机向该MDC提供诊断服务时，由上位机向该MDC中的主DCU发送该第三算力配置数据，如图12所示，图12示意的是上位机(图12以PC为例进行示意)通过CAN总线向自动驾驶车辆内的MDC发送第三算力配置数据，具体地，由上位机发出诊断请求，自动驾驶车辆上的MDC通过主DCU给出响应，在此通信过程中，上位机和MDC分别是计算机网络通信中的client和server的角色。
B、第三算力配置数据由云服务器发送。
ECU/DCU/MDC的软件或固件刷新，除了可由诊断功能支撑实现(即近端升级)之外，还可以通过网络远程通道的OTA进行升级(即远端升级)，因此，该第三算力配置数据还可存储在提供OTA服务的云服务器上，当该云服务器对安装该MDC的车辆提供OTA服务时，由该云服务器向该MDC发送该第三算力配置数据，如图13所示，图13示意的是云服务器通过无线通信的方式向自动驾驶车辆内MDC中的主DCU发送对应的第三算力配置数据。
需要说明的是，在本申请的一些实施方式中，不管第三算力配置数据是由上位机发送还是由云服务器发送，该第三算力配置数据可以包含在在一个目标文件(可称为第二文件)中，然后由上位机或由云服务器将该第二文件向MDC中的主DCU发送，将第三算力配置数据包含在在第二文件中，实现了每个独立的MDC与第三算力配置数据的一一对应，便于控制和管理，且具备可实现性。
还需要说明的是，该第二文件可以是MDC的License文件(每个MDC都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第一文件的类型和格式均不做限定，用户可根据需要选择将第一算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。此外，第二文件支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，便 于后续按需更新第三算力配置数据以实现对MDC算力资源的调整，在保证业务顺利进行的前提下节约算力资源。
还需要说明的是，在本申请的一些实施方式中，该第二文件可以是经过了加密的文件，以防止第三算力配置数据被随意修改，提高了数据的安全性。
需要注意的是，类似地，对第二文件的加密方式可以是对称加密，即加密和解密的秘钥使用的是同一个；加密的方式也可以是非对称加密，即非对称加密需要两个秘钥，这两个秘钥分别为公开秘钥和私有秘钥，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密，如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。在本申请实施例中，对加密的方式不做限定。
还需要说明的是，在本申请的一些实施方式中，MDC通过主DCU接收到上位机或云服务器发送的第三算力配置数据后，就可持久化存储于该MDC内存储模块中，如，存储模块可以是EEPROM、Flash闪存等，本申请实施例所述的持久化存储是指把数据(如本申请实施例所述的第一算力配置数据)保存到可永久保存的存储模块中(如磁盘)，持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等。在本申请实施例中，只有当MDC再次接收到新的第三算力配置数据时，该持久化存储于MDC内存储模块中的原第三算力配置数据才会被更新为新的第三算力配置数据。
1002、MDC通过主DCU将第三算力配置数据向该多个DCU中除主DCU之外的其他DCU发送。
MDC通过主DCU从上位机或云服务器接收到第三算力配置数据后，可进一步将该第三算力配置数据向第一DMC中除主DCU外的其他DCU发送，依然以图11为例，假设DCU 1为主DCU，那么DCU 1接收到第三算力配置数据后，将该第三算力配置数据再向DCU 2和DCU 3发送，DCU 2和DCU 3接收到该第三算力配置数据后各自存储在各自的存储模块中，通过在MDC中的各个DCU中均存储第三算力配置数据的方式实现冗余备份，提高了数据的存储可靠性。
需要注意的是，在本申请的一些实施方式中，为了节省存储空间同时又能实现数据的冗余备份，那么MDC也可以通过主DCU将第三算力配置数据向MDC中除主CDU之外的其他一个DCU发送，依然以图11为例，假设DCU 1为主DCU，那么DCU 1接收到第三算力配置数据后，可以将该第三算力配置数据再向DCU 2(或DCU 3)发送，DCU 2(或DCU 3)接收到该第三算力配置数据后存储在自身存储模块中，当MDC上电后正常工作时，没有获取到第三算力配置数据的DCU 3再随时从DCU 1上读取第三算力配置数据。总之，在MDC中，保证该MDC中至少在2个DCU的存储模块中存有第三算力配置数据即可。
还需要说明的是，在本申请的一些实施方式中，还可以针对MDC内不同DCU存储模块内的各自存储的第三算力配置数据周期性进行核查校验。核查校验的目的是为了保障第三算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。例如，依然以图11为例进行示意：假设设置周期为1小时，假设MDC通过DCU 1(即主DCU)接收到第三算力配置数据并将该第三算力配置数据发送给DCU 2和DCU 3，且DCU 1、DCU 2、DCU 3在第一时刻7:30分别将各自的第三算力配置数据存储在各自的存储模块中，当时刻为8:30 时，DCU 1会获取DCU 2和DCU 3上的第三算力配置数据，并判断当前时刻8:30DCU 1中的第三算力配置数据和当前时刻8:30DCU 2、DCU 3中的第三算力配置数据(该当前时刻下的各个DCU中的第三算力配置数据可称为第四算力配置数据)是否一致，在各个DCU中的第四算力配置数据不一致的情况下，MDC通过主DCU对各个DCU中的第四算力配置数据进行校验对齐，使得各个DCU中的第四算力配置数据保持一致。
类似地，对各个第四算力配置数据进行校验对齐的方式与上述DCU对第二算力配置数据和第二备份数据进行校验对齐的方式类似，可参阅上述所述，具体此处不予赘述。
需要说明的是，在本申请实施例中，该MDC为自动驾驶车辆内的任意一个MDC，在本申请的一些实施方式中，该自动驾驶车辆内的每个独立工作的MDC，都可作为MDC执行该步骤1001-1002的过程，从而得到该自动驾驶车辆内每个MDC各自对应的算力配置数据，具体过程与该步骤1001-1002类似，此处不予赘述。
1003、MDC通过该多个DCU各自根据第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器。
MDC中的各个DCU均获取到第三算力配置数据后，那么每个DCU将根据各自获取到的第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器，MDC如何根据第三算力配置数据解复位各自DCU中的目标处理器与上述步骤702类似，具体此处不予赘述。
需要说明的是，在本申请的一些实施方式中，MDC中的各个DCU根据各自的第三算力配置数据解复位各自DCU内对应的目标处理器之前，还需要各自对该第三算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。例如，合法性校验具体可以是：校验第三算力配置数据是否为该MDC对应的算力配置数据；校验第三算力配置数据是否存在跳变或篡改；第三算力配置数据是否具备完整性；当第三算力配置数据是包含在在加密的第二文件中时，校验第二文件加密过程是否异常、加密后的第二文件是否可解密等；校验第三算力配置数据的数据取值范围是否在正常范围内等。只有在第三算力配置数据通过合法性校验的情况下，MDC中的各个DCU才根据各自的第三算力配置数据解复位各自DCU内对应的目标处理器。
还需要说明的是，在本申请的一些实施方式中，若第三算力配置数据是包含在在第二文件中，那么各个DCU对第三算力配置数据进行合法性校验是通过对第二文件进行合法性校验实现的。在本申请的另一些实施方式中，若第二文件是经过加密的文件，那么各个DCU还需要先对该加密的第二文件进行解密，得到解密后的第二文件，再对解密后的第二文件进行合法性校验。
1004、在车辆通过传感器采集到感知信息，且感知信息属于该MDC的处理范畴的情况下，该MDC基于解复位后的目标处理器处理该感知信息。
在本申请的一些实施方式中，在得到解复位后MDC内的目标处理器后，还可以继续执行步骤1004，也就是MDC中的各个DCU基于各自接收到的第三算力配置数据解复位出该MDC内的目标处理器后，在自动驾驶车辆通过传感器采集到感知信息，且感知信息属于该MDC的处理范畴的情况下，该MDC就基于上述解复位后得到的目标处理器对采集到 的感知信息进行处理。
在本申请上述实施方式中，当自动驾驶车辆的控制器为MDC，第三算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按需更新第三算力配置数据以实现对MDC中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，并且解决了现有方案只能配置本DCU的算力资源而无法支持多个DCU组成的MDC的组合应用场景。
为便于进一步理解上述方案，下面以自动驾驶车辆内的控制器为DCU的一个实例为例，分三个阶段对DCU算力资源的具体配置过程进行阐述，可参阅图14，图14为本申请实施例提供的算力资源的具体配置过程的一个流程示意图，该配置过程具体包括算力配置数据存储阶段、算力配置数据加载阶段和算力配置数据同步阶段，其中，DCU w为自动驾驶车辆中DCU 0～DCU v中的任意一个DCU，DCU w包括CPU 0～CPU m(CPU 0为主CPU)、Vector Core 0～Vector Core  k、AI Core 0～AI Core  k、ISP 0～ISP x、GPU 0～GPU y、存储模块和硬件安全模块(hardware security module，HSM)，具体可包括如下步骤：其中，步骤1401-1403为算力配置数据存储阶段，步骤1404-1047为算力配置数据加载阶段，步骤1408为算力配置数据同步阶段。
1401、近端或远端升级。
上位机(或云服务器)与自动驾驶车辆之间触发近端升级流程(或远端升级流程)，并在升级过程中将与该DCU w对应的算力配置数据包含在在该DCU w加密的License文件中发送至CPU 0，实现该DCU w与自身对应的算力配置数据的一一对应，并且加密了的License文件可防止算力配置数据被随意修改，提升了数据的安全性。
1402、CPU 0向HSM发送安全接入认证。
CPU 0向HSM发送安全接入认证，在通过认证后，执行步骤1403。
1403、CPU 0将加密后的License文件持久化存储于存储模块。
加密后的License文件，通过近端升级或远端升级的方式发送至该DCU w的存储模块，且将该License文件进行备份，得到备份文件，将该License文件和备份文件持久化存储于该存储模块内的不同区域(或存储于不同的存储模块)。
1404、CPU 0从存储模块中读取加密后的License文件。
DCU w上电后，在自动驾驶业务模型加载前，该DCU w通过CPU 0从存储模块中读取加密的License文件。
1405、CPU 0解密License文件。
CPU 0从存储模块中读取到License文件后，对该License进行解密，并校验解密后的License文件是否为该DCU w的License文件。
1406、CPU 0对算力配置数据进行合法性校验。
在CPU 0校验解密后的License文件为该DCU w的License文件的情况下，CPU 0获取解密后的License文件中的算力配置数据，并对该算力配置数据进行合法性校验。
1407、CPU 0根据算力配置数据解复位对应的目标处理器。
具体地，CPU 0根据算力配置数据依次解复位相应的其他CPU、解复位相应的Vector Core、解复位相应的AI Core、解复位相应的ISP以及解复位相应的GPU。解复位后的该DCU w中的目标处理器就可针对采集到感知信息进行处理，也就是基于解复位后的目标处理器加载驾驶业务模型。
1408、CPU 0针对License文件和备份文件周期性核查校验。
CPU 0对License文件中的算力配置数据和备份文件中的算力配置数据周期性核查校验，并在License文件中算力配置数据与备份文件中的算力配置数据不一致的情况下，自动进行数据对齐处理。
在图7和图14所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图15，图15为本申请实施例提供的DCU的一种结构示意图，该DCU1500可应用于车辆(如，智能汽车、自动驾驶汽车、网联汽车等)上，该DCU1500具体可以包括：接收模块1501、解复位模块1502，其中，接收模块1501，用于接收与该DCU对应的第一算力配置数据，该DCU为车辆上的任意一个DCU，该DCU包括至少一个处理器，该第一算力配置数据包括该DCU中至少一个类型的处理器的预设配置数量，该预设配置数量可根据该DCU的历史算力资源的消耗情况以及该DCU的运行业务的具体情况进行设置；解复位模块1502，用于根据该第一算力配置数据解复位该DCU内对应的处理器(可称为目标处理器)，从而得到解复位后的目标处理器。
在本申请上述实施方式中，当自动驾驶车辆的控制器为DCU，第一算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按需更新第一算力配置数据以实现对DCU中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，避免了DCU出厂时对应的算力配置数据只能固化于eFuse中无法修改的情形，增强了后续驾驶业务场景不断变化的适应性。
在一种可能的设计中，该DCU1500还可以包括处理模块1503，该处理模块1503，用于在自动驾驶车辆通过传感器采集到感知信息，且感知信息属于该DCU的处理范畴的情况下，基于上述解复位后得到的目标处理器对采集到的感知信息进行处理。
在本申请上述实施方式中，DCU可基于解复位后的目标处理器处理对应的感知信息，感知信息反映了驾驶业务场景，因此，本申请实施例可增强驾驶业务场景不断变化的适应性。
在一种可能的设计中，该接收模块1501，具体用于：接收云服务器或上位机发送的与DCU对应的第一文件，第一算力配置数据包含在在第一文件中。
在本申请上述实施方式中，具体阐述了该第一算力配置数据可以包含在在一个目标文件(即第一文件)中，然后由上位机或由云服务器将该第一文件向DCU发送，将第一算力配置数据包含在在第一文件中，实现了每个独立的DCU与第一算力配置数据的一一对应，便于控制和管理，具备可实现性。
在一种可能的设计中，第一文件为经过加密的文件。
在本申请上述实施方式中，该第一文件可以是经过了加密的文件，以防止第一算力配 置数据被随意修改，提高了数据的安全性。
在一种可能的设计中，该第一文件可以是DCU的License文件(每个DCU都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第一文件的类型和格式均不做限定。
在本申请上述实施方式中，用户可根据需要选择将第一算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。
在一种可能的设计中，解复位模块1502，具体用于：对第一算力配置数据进行合法性校验，且在第一算力配置数据通过合法性校验的情况下，根据第一算力配置数据解复位DCU中的目标处理器。例如，合法性校验具体可以是：校验第一算力配置数据是否为该DCU对应的算力配置数据；校验第一算力配置数据是否存在跳变或篡改；第一算力配置数据是否具备完整性；当第一算力配置数据是包含在在加密的第一文件中时，校验第一文件加密过程是否异常、加密后的第一文件是否可解密等；校验第一算力配置数据的数据取值范围是否在正常范围内等，如，DCU总共有4个CPU，而第一算力配置数据中的CPU数量为5个，则数据取值范围不在正常范围内。只有在第一算力配置数据通过合法性校验的情况下，DCU才根据第一算力配置数据解复位该DCU内对应的目标处理器。
在本申请上述实施方式中，解复位模块1502在根据第一算力配置数据解复位该DCU内对应的目标处理器之前，还需要对该第一算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。
在一种可能的设计中，接收模块1501，还用于：在第一时刻将所述第一算力配置数据进行备份，得到第一备份数据，所述第一算力配置数据为处于第一时刻下的算力配置数据，所述第一备份数据为处于所述第一时刻下的备份数据；将所述第一算力配置数据和所述第一备份数据分别存储于所述DCU内的不同存储模块。
在本申请上述实施方式中，接收模块1501还可以对接收到的第一算力配置数据进行冗余备份，以提高数据的存储可靠性。
在一种可能的设计中，接收模块1501，还用于：周期性判断第二算力配置数据与第二备份数据是否一致，所述第二算力配置数据为处于当前时刻下的算力配置数据，所述第二备份数据为处于所述当前时刻下的备份数据；在所述第二算力配置数据与所述第二备份数据不一致的情况下，对所述第二算力配置数据与所述第二备份数据进行校验对齐。
在本申请上述实施方式中，接收模块1501还可以针对DCU内不同存储模块内的第一算力配置数据和第一备份数据周期性进行核查校验，核查校验的目的是为了保障第一算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。
需要说明的是，图15对应实施例所述的DCU1500中各模块/单元之间的信息交互、执行过程等内容，与本申请中图7和图14对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
类似地，在图10所对应的实施例的基础上，为了更好的实施本申请实施例的上述方案，下面还提供用于实施上述方案的相关设备。具体参阅图16，图16为本申请实施例提供的MDC的一种结构示意图，该MDC1600可应用于车辆(如，智能汽车、自动驾驶汽车、网 联汽车等)上，该MDC1600具体可以包括：接收模块1601、发送模块1602、解复位模块1603，其中，接收模块1601，用于通过MDC中的主DCU接收与该MDC对应的第三算力配置数据，该MDC为车辆上的任意一个MDC(一般情况下一个车辆部署一个MDC，当车辆仅部署一个MDC，则该MDC就是这一个MDC)，MDC包括多个DCU，其中主DCU为这多个DCU中的任意一个，每个DCU包括至少一个处理器(如，CPU)，该第三算力配置数据就包括MDC内每个DCU中至少一个类型的处理器的预设配置数量；发送模块1602，用于通过所述主DCU将所述第三算力配置数据向所述多个DCU中除所述主DCU之外的其他DCU发送；解复位模块1603，用于通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器。
在本申请上述实施方式中，当自动驾驶车辆的控制器为MDC，第三算力配置数据支持上位机通过近端升级方式(即UDS)或远端升级方式(即OTA)进行更新，使得后续可按需更新第三算力配置数据以实现对MDC中算力资源的调整，从而可支持后续不同规格的驾驶业务场景时处理器的动态配置诉求，在保证业务顺利进行的前提下节约算力资源，并且解决了现有方案只能配置本DCU的算力资源而无法支持多个DCU组成的MDC的组合应用场景。
在一种可能的设计中，该MDC1600还可以包括处理模块1604，该处理模块1604，用于在所述车辆通过传感器采集到感知信息，且所述感知信息属于所述MDC的处理范畴的情况下，基于所述解复位后的目标处理器处理所述感知信息。
在本申请上述实施方式中，同样可基于解复位后的目标处理器处理对应的感知信息，感知信息反映了驾驶业务场景，因此，本申请实施例可增强驾驶业务场景不断变化的适应性。
在一种可能的设计中，该接收模块1601，具体用于：接收云服务器或上位机发送的与MDC对应的第二文件，第三算力配置数据包含在在第二文件中。
在本申请上述实施方式中，具体阐述了该第三算力配置数据可以包含在在一个目标文件(即第二文件)中，然后由上位机或由云服务器将该第二文件向MDC发送，将第三算力配置数据包含在在第二文件中，实现了每个独立的MDC与第三算力配置数据的一一对应，便于控制和管理，具备可实现性。
在一种可能的设计中，第二文件为经过加密的文件。
在本申请上述实施方式中，该第二文件可以是经过了加密的文件，以防止第三算力配置数据被随意修改，提高了数据的安全性。
在一种可能的设计中，该第二文件可以是MDC的License文件(每个MDC都具有一个License文件)，也可以是用户事先自行定义的文件，也可以是诊断服务中或OTA的相关软件更新包中的一些文件，具体此处对第二文件的类型和格式均不做限定。
在本申请上述实施方式中，用户可根据需要选择将第三算力配置数据包含在在什么类型的文件上，具备灵活性和可选择性。
在一种可能的设计中，解复位模块1603，具体用于：通过所述多个DCU各自对所述第三算力配置数据进行合法性校验；在所述第三算力配置数据通过合法性校验的情况下， 通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器。
在本申请上述实施方式中，MDC中的各个DCU根据各自的第三算力配置数据解复位各自DCU内对应的目标处理器之前，还需要各自对该第三算力配置数据进行合法性校验，可避免错误、非法的数据进入服务，或者在数据出错时能及时被发现。
在一种可能的设计中，接收模块1601，还用于：通过所述主DCU周期性判断所述多个DCU内每个DCU中处于当前时刻下的各个第四算力配置数据是否一致；在所述各个第四算力配置数据存在不一致的情况下，通过所述主DCU对所述各个第四算力配置数据进行校验对齐。
在本申请上述实施方式中，接收模块1601还可以针对MDC内不同DCU存储模块内的各自存储的第三算力配置数据周期性进行核查校验，核查校验的目的是为了保障第三算力配置数据的准确性，同时当数据出现错误时也能及时被发现并改正。
需要说明的是，图16对应实施例所述的MDC1600中各模块/单元之间的信息交互、执行过程等内容，与本申请中图10对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请实施例还提供了一种设备，该设备可以是DCU，也可以是MDC，请参阅图17，图17是本申请实施例提供的设备(DCU或MDC)一种结构示意图，为便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。设备1700上可以部署有图15对应实施例中所描述的DCU的模块，用于实现图7或图14对应实施例中DCU的功能，设备1700上也可以部署有图16对应实施例中所描述的MDC的模块，用于实现图10对应实施例中MDC的功能，具体此处不做限定。
具体的，设备1700由一个或多个服务器实现，设备1700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1722(例如，一个或一个以上)和存储器1732，一个或一个以上存储应用程序1742或数据1744的存储介质1730(例如一个或一个以上海量存储设备)。其中，存储器1732和存储介质1730可以是短暂存储或持久存储。存储在存储介质1730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对设备1700中的一系列指令操作。更进一步地，中央处理器1722可以设置为与存储介质1730通信，在设备1700上执行存储介质1730中的一系列指令操作。
设备1700还可以包括一个或一个以上电源1726，一个或一个以上有线或无线网络接口1750，一个或一个以上输入输出接口1758，和/或，一个或一个以上操作系统1741，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
在本申请实施例中，若设备1700为DCU，则上述图7和图14对应的实施例中由DCU所执行的步骤可以基于该图17所示的结构实现；若设备1700为MDC，则上述图10对应的实施例中由MDC所执行的步骤也可以基于该图17所示的结构实现，具体此处不予赘述。
另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际 的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

Claims (34)

  1. 一种算力资源的配置方法，应用于车辆，其特征在于，包括：
    域控制器(DCU)接收云服务器或上位机发送的与所述DCU对应的第一算力配置数据，所述DCU为所述车辆上的任意一个DCU，所述DCU包括至少一个处理器，所述第一算力配置数据包括所述DCU中至少一个类型的处理器的预设配置数量；
    所述DCU根据所述第一算力配置数据解复位所述DCU中的目标处理器，得到解复位后的目标处理器。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    在所述车辆通过传感器采集到感知信息，且所述感知信息属于所述DCU的处理范畴的情况下，所述DCU基于所述解复位后的目标处理器处理所述感知信息。
  3. 根据权利要求1-2中任一项所述的方法，其特征在于，所述域控制器(DCU)接收云服务器或上位机发送的与所述DCU对应的第一算力配置数据包括：
    所述DCU接收云服务器或上位机发送的与所述DCU对应的第一文件，所述第一文件内包含所述第一算力配置数据。
  4. 根据权利要求3所述的方法，其特征在于，所述第一文件为经过加密的文件。
  5. 根据权利要求3-4中任一项所述的方法，其特征在于，所述第一文件包括：
    License文件或自定义文件。
  6. 根据权利要求1-5中任一项所述的方法，其特征在于，所述DCU根据所述第一算力配置数据解复位所述DCU中的目标处理器包括：
    所述DCU对所述第一算力配置数据进行合法性校验；
    在所述第一算力配置数据通过合法性校验的情况下，所述DCU根据所述第一算力配置数据解复位所述DCU中的目标处理器。
  7. 根据权利要求1-6中任一项所述的方法，其特征在于，在所述DCU根据所述第一算力配置数据解复位所述DCU中的目标处理器之前，所述方法还包括：
    所述DCU在第一时刻将所述第一算力配置数据进行备份，得到第一备份数据，所述第一算力配置数据为处于第一时刻下的算力配置数据，所述第一备份数据为处于所述第一时刻下的备份数据；
    所述DCU将所述第一算力配置数据和所述第一备份数据分别存储于所述DCU内的不同存储模块。
  8. 根据权利要求7所述的方法，其特征在于，在所述DCU将所述第一算力配置数据和所述第一备份数据分别存储于所述DCU内的不同存储模块之后，所述方法还包括：
    所述DCU周期性判断第二算力配置数据与第二备份数据是否一致，所述第二算力配置数据为处于当前时刻下的算力配置数据，所述第二备份数据为处于所述当前时刻下的备份数据；
    在所述第二算力配置数据与所述第二备份数据不一致的情况下，对所述第二算力配置数据与所述第二备份数据进行校验对齐。
  9. 一种算力资源的配置方法，应用于车辆，其特征在于，包括：
    多域控制器(MDC)通过主域控制器(DCU)接收云服务器或上位机发送的与所述MDC对应的第三算力配置数据，所述MDC为所述车辆上的任意一个MDC，所述MDC包括多个DCU，所述主DCU为所述多个DCU中的一个，所述多个DCU中的每个DCU包括至少一个处理器，所述第三算力配置数据包括所述每个DCU中至少一个类型的处理器的预设配置数量；
    所述MDC通过所述主DCU将所述第三算力配置数据向所述多个DCU中除所述主DCU之外的其他DCU发送；
    所述MDC通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器。
  10. 根据权利要求9所述的方法，其特征在于，所述方法还包括：
    在所述车辆通过传感器采集到感知信息，且所述感知信息属于所述MDC的处理范畴的情况下，所述MDC基于所述解复位后的目标处理器处理所述感知信息。
  11. 根据权利要求9-10中任一项所述的方法，其特征在于，所述多域控制器(MDC)通过主域控制器(DCU)接收云服务器或上位机发送的与所述MDC对应的第三算力配置数据包括：
    所述MDC通过所述主DCU接收云服务器或上位机发送的与所述MDC对应的第二文件，所述第二文件内包含所述第三算力配置数据。
  12. 根据权利要求11所述的方法，其特征在于，所述第二文件为经过加密的文件。
  13. 根据权利要求11-12中任一项所述的方法，其特征在于，所述第二文件包括：
    License文件或自定义文件。
  14. 根据权利要求9-13中任一项所述的方法，其特征在于，所述MDC通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器包括：
    所述MDC通过所述多个DCU各自对所述第三算力配置数据进行合法性校验；
    在所述第三算力配置数据通过合法性校验的情况下，所述MDC通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器。
  15. 根据权利要求9-14中任一项所述的方法，其特征在于，所述方法还包括：
    所述MDC通过所述主DCU周期性判断所述多个DCU内每个DCU中处于当前时刻下的各个第四算力配置数据是否一致；
    在所述各个第四算力配置数据存在不一致的情况下，所述MDC通过所述主DCU对所述各个第四算力配置数据进行校验对齐。
  16. 一种域控制器(DCU)，应用于车辆，其特征在于，所述DCU包括：
    接收模块，用于接收云服务器或上位机发送的与所述DCU对应的第一算力配置数据，所述DCU为所述车辆上的任意一个DCU，所述DCU包括至少一个处理器，所述第一算力配置数据包括所述DCU中至少一个类型的处理器的预设配置数量；
    解复位模块，用于根据所述第一算力配置数据解复位所述DCU中的目标处理器，得到解复位后的目标处理器。
  17. 根据权利要求16所述的DCU，其特征在于，所述DCU还包括：
    处理模块，用于在所述车辆通过传感器采集到感知信息，且所述感知信息属于所述DCU的处理范畴的情况下，基于所述解复位后的目标处理器处理所述感知信息。
  18. 根据权利要求16-17中任一项所述的DCU，其特征在于，所述接收模块，具体用于：
    接收云服务器或上位机发送的与所述DCU对应的第一文件，所述第一文件内包含所述第一算力配置数据。
  19. 根据权利要求18所述的DCU，其特征在于，所述第一文件为经过加密的文件。
  20. 根据权利要求18-19中任一项所述的DCU，其特征在于，所述第一文件包括：
    License文件或自定义文件。
  21. 根据权利要求16-20中任一项所述的DCU，其特征在于，所述解复位模块，具体用于：
    对所述第一算力配置数据进行合法性校验；
    在所述第一算力配置数据通过合法性校验的情况下，根据所述第一算力配置数据解复位所述DCU中的目标处理器。
  22. 根据权利要求16-21中任一项所述的DCU，其特征在于，所述接收模块，还用于：
    在第一时刻将所述第一算力配置数据进行备份，得到第一备份数据，所述第一算力配置数据为处于第一时刻下的算力配置数据，所述第一备份数据为处于所述第一时刻下的备份数据；
    将所述第一算力配置数据和所述第一备份数据分别存储于所述DCU内的不同存储模块。
  23. 根据权利要求22所述的DCU，其特征在于，所述接收模块，还用于：
    周期性判断第二算力配置数据与第二备份数据是否一致，所述第二算力配置数据为处于当前时刻下的算力配置数据，所述第二备份数据为处于所述当前时刻下的备份数据；
    在所述第二算力配置数据与所述第二备份数据不一致的情况下，对所述第二算力配置数据与所述第二备份数据进行校验对齐。
  24. 一种多域控制器(MDC)，应用于车辆，其特征在于，所述MDC包括：
    接收模块，用于通过主域控制器(DCU)接收云服务器或上位机发送的与所述MDC对应的第三算力配置数据，所述MDC为所述车辆上的任意一个MDC，所述MDC包括多个DCU，所述主DCU为所述多个DCU中的一个，所述多个DCU中的每个DCU包括至少一个处理器，所述第三算力配置数据包括所述每个DCU中至少一个类型的处理器的预设配置数量；
    发送模块，用于通过所述主DCU将所述第三算力配置数据向所述多个DCU中除所述主DCU之外的其他DCU发送；
    解复位模块，用于通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器，得到解复位后的目标处理器。
  25. 根据权利要求24所述的MDC，其特征在于，所述MDC还包括：
    处理模块，用于在所述车辆通过传感器采集到感知信息，且所述感知信息属于所述 MDC的处理范畴的情况下，基于所述解复位后的目标处理器处理所述感知信息。
  26. 根据权利要求24-25中任一项所述的MDC，其特征在于，所述接收模块，具体用于：
    通过所述主DCU接收云服务器或上位机发送的与所述MDC对应的第二文件，所述第二文件内包含所述第三算力配置数据。
  27. 根据权利要求26所述的MDC，其特征在于，所述第二文件为经过加密的文件。
  28. 根据权利要求26-27中任一项所述的MDC，其特征在于，所述第二文件包括：
    License文件或自定义文件。
  29. 根据权利要求24-28中任一项所述的MDC，其特征在于，所述解复位模块，具体用于：
    通过所述多个DCU各自对所述第三算力配置数据进行合法性校验；
    在所述第三算力配置数据通过合法性校验的情况下，通过所述多个DCU各自根据所述第三算力配置数据解复位各自DCU中的目标处理器。
  30. 根据权利要求24-29中任一项所述的MDC，其特征在于，所述接收模块，还用于：
    通过所述主DCU周期性判断所述多个DCU内每个DCU中处于当前时刻下的各个第四算力配置数据是否一致；
    在所述各个第四算力配置数据存在不一致的情况下，通过所述主DCU对所述各个第四算力配置数据进行校验对齐。
  31. 一种域控制器(DCU)，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述处理器，用于执行所述存储器中的程序，使得所述DCU执行如权利要求1-8中任一项所述的方法。
  32. 一种多域控制器(MDC)，包括域控制器(DCU)和存储器，所述DCU包括处理器，所述处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述DCU，用于通过所述处理器执行所述存储器中的程序，使得所述MDC执行如权利要求9-15中任一项所述的方法。
  33. 一种计算机可读存储介质，包括程序，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-8中任一项所述的方法，或，使得计算机执行如权利要求9-15中任一项所述的方法。
  34. 一种包含指令的计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行如权利要求1-8中任一项所述的方法，或，使得计算机执行如权利要求9-15中任一项所述的方法。
PCT/CN2021/131386 2020-12-25 2021-11-18 一种算力资源的配置方法及设备 WO2022134965A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011567735.4A CN114691346A (zh) 2020-12-25 2020-12-25 一种算力资源的配置方法及设备
CN202011567735.4 2020-12-25

Publications (1)

Publication Number Publication Date
WO2022134965A1 true WO2022134965A1 (zh) 2022-06-30

Family

ID=82129031

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/131386 WO2022134965A1 (zh) 2020-12-25 2021-11-18 一种算力资源的配置方法及设备

Country Status (2)

Country Link
CN (1) CN114691346A (zh)
WO (1) WO2022134965A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941750A (zh) * 2023-01-18 2023-04-07 禾多科技（北京）有限公司 自动驾驶系统芯片的算力优化方法、设备和计算机介质
CN117149478A (zh) * 2023-06-14 2023-12-01 杭州迪为科技有限公司 汽车电子控制器的复位管理方法、装置和汽车电子控制器
CN117149478B (zh) * 2023-06-14 2024-06-04 杭州迪为科技有限公司 汽车电子控制器的复位管理方法、装置和汽车电子控制器

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109523019A (zh) * 2018-12-29 2019-03-26 百度在线网络技术（北京）有限公司 加速器、基于fpga的加速系统及控制方法、cnn网络系统
CN109995628A (zh) * 2018-01-03 2019-07-09 联合汽车电子有限公司 车用域控制器
CN111158714A (zh) * 2019-11-28 2020-05-15 上海能塔智能科技有限公司 车载域控制器ota升级软件的方法及装置、存储介质、终端
US20200183391A1 (en) * 2018-12-05 2020-06-11 Volkswagen Aktiengesellschaft Configuration of a control system for an at least partially autonomous transportation vehicle
US20200264864A1 (en) * 2017-10-24 2020-08-20 Huawei International Pte. Ltd. Vehicle-mounted device upgrade method and related device
CN111666140A (zh) * 2020-05-28 2020-09-15 北京百度网讯科技有限公司 资源调度方法、装置、设备和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200264864A1 (en) * 2017-10-24 2020-08-20 Huawei International Pte. Ltd. Vehicle-mounted device upgrade method and related device
CN109995628A (zh) * 2018-01-03 2019-07-09 联合汽车电子有限公司 车用域控制器
US20200183391A1 (en) * 2018-12-05 2020-06-11 Volkswagen Aktiengesellschaft Configuration of a control system for an at least partially autonomous transportation vehicle
CN109523019A (zh) * 2018-12-29 2019-03-26 百度在线网络技术（北京）有限公司 加速器、基于fpga的加速系统及控制方法、cnn网络系统
CN111158714A (zh) * 2019-11-28 2020-05-15 上海能塔智能科技有限公司 车载域控制器ota升级软件的方法及装置、存储介质、终端
CN111666140A (zh) * 2020-05-28 2020-09-15 北京百度网讯科技有限公司 资源调度方法、装置、设备和存储介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941750A (zh) * 2023-01-18 2023-04-07 禾多科技（北京）有限公司 自动驾驶系统芯片的算力优化方法、设备和计算机介质
CN115941750B (zh) * 2023-01-18 2023-05-23 禾多科技（北京）有限公司 自动驾驶系统芯片的算力优化方法、设备和计算机介质
CN117149478A (zh) * 2023-06-14 2023-12-01 杭州迪为科技有限公司 汽车电子控制器的复位管理方法、装置和汽车电子控制器
CN117149478B (zh) * 2023-06-14 2024-06-04 杭州迪为科技有限公司 汽车电子控制器的复位管理方法、装置和汽车电子控制器
CN117950879B (zh) * 2024-03-26 2024-06-07 深圳威尔视觉科技有限公司 自适应云服务器分布方法、装置及计算机设备

Also Published As

Publication number Publication date
CN114691346A (zh) 2022-07-01

Similar Documents

Publication Publication Date Title
CN109917765B (zh) 一种基于自动驾驶系统的网络架构的集散式域控制器系统
US11875686B2 (en) Systems and methods for managing communications between vehicles
WO2022056894A1 (zh) 车辆通信方法和通信装置
CN209842367U (zh) 一种基于自动驾驶系统的网络架构的集散式域控制器系统
CN110920619B (zh) 一种车辆调控方法、装置及电子设备
WO2022188043A1 (zh) 一种通过空中下载ota技术获取文件的方法及相关设备
KR101802858B1 (ko) 자동차용 통합데이터 처리 제어 시스템 및 방법
WO2022077195A1 (zh) 电子机械制动方法和电子机械制动装置
CN115179879B (zh) 车辆自唤醒方法、装置、车辆及存储介质
CN115348657B (zh) 用于车辆时间同步的系统、方法及车辆
WO2022134965A1 (zh) 一种算力资源的配置方法及设备
CN113859265B (zh) 一种驾驶过程中的提醒方法及设备
CN113359724A (zh) 基于无人机的车辆智能驾驶系统、方法及存储介质
CN112653726A (zh) 车载终端及其操作方法、计算机可读存储介质及处理器
WO2022268127A1 (zh) 一种ota升级方法、装置及计算机可读存储介质
WO2023202096A1 (zh) 一种车辆中数据的处理方法以及相关设备
CN115871523A (zh) 电池加热方法、装置、车辆、可读存储介质及芯片
CN114827108B (zh) 车辆升级方法、装置、存储介质、芯片及车辆
WO2024055654A1 (zh) 一种进程启动方法、进程管理方法以及管理装置
US11814086B1 (en) Middleware software layer for vehicle autonomy subsystems
WO2023087330A1 (zh) 一种应用显示方法和电子设备
US20240143311A1 (en) Mobile terminal and software update system
CN115730340A (zh) 一种数据处理方法及相关装置
WO2024045086A1 (zh) 一种惯性测量装置、控制系统和终端
WO2023096659A1 (en) Method for power states in vehicles

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21908964

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21908964

Country of ref document: EP

Kind code of ref document: A1