Vehicle OTA software upgrade system, vehicles and control methods

Abstract

The application relates to the technical field of vehicles, in particular to a vehicle OTA software upgrading system, a vehicle and a control method, wherein the system comprises an ADCC domain controller configured to acquire an OTA software upgrading package and an upgrading strategy issued, determine an upgrading mode and a self-upgrading flashing program according to the upgrading strategy, and issue the OTA software upgrading package to each corresponding electronic control unit according to the upgrading mode and the self-upgrading flashing program to perform corresponding upgrading operations; a VCC domain controller in communication connection with the ADCC domain controller, configured to acquire current version information feedback of each electronic control unit to a cloud end, receive an OTA software upgrading task issued by the cloud end through HTTP protocol interaction, analyze the OTA software upgrading task to generate an upgrading strategy, and issue the upgrading strategy to the ADCC domain controller to control vehicle upgrading. Thus, the problems that a communication link is too long, a TBOX load is too large, upgrading is stuck, and user experience is poor in the related art are solved.

Description

Technical Field

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

[0002] With the development of intelligent connected vehicles, for OEMs, vigorously developing and promoting OTA (Over-the-Air Technology) technology can help OEMs to remotely diagnose vehicles, collect logs, gather big data, and update and push new functions. In addition, OTA technology can also quickly fix system defects, thereby greatly reducing the risk of needing vehicle recalls for repair.

[0003] In related technologies, the number of ECU (Electronic Control Unit) nodes in the vehicle's electronic and electrical architecture is increasing. In the traditional master-slave upgrade mode, the TBOX of the VCC (Vehicle Central Computer) acts as the master control node for the vehicle's OTA upgrade and interacts with the cloud. At the same time, other ECU nodes are upgraded through the CGW (Central Gateway). The ADCC, as a slave node, is only responsible for self-upgrade. The TBOX is responsible for the upgrade of its subordinate ECU nodes such as FrontRadar, Corner Radar, and Camera. In this kind of vehicle OTA upgrade system, the communication link is too long. The processes of storing, transmitting, decompressing, decrypting, and verifying the OTA software upgrade package, as well as maintaining the upgrade sequence between the ADCC and its subordinate ECU nodes, are all handled by the TBOX. This leads to excessive upgrade load on the TBOX, insufficient resources, and OTA upgrade lag, freezing, or even failure, giving users a very poor OTA experience. Consequently, this master-slave node software upgrade system cannot achieve full-domain OTA upgrades of the entire vehicle's cockpit domain, intelligent driving domain, etc. Summary of the Invention

[0004] This application provides a vehicle OTA software upgrade system, a vehicle, and a control method to solve the problems in related technologies where the whole vehicle OTA upgrade system is handled by the TBOX, resulting in excessively long communication links, excessive load on the TBOX, lag during upgrades, and poor user experience.

[0005] The first aspect of this application provides a vehicle OTA software upgrade system, comprising: an ADCC domain controller, configured to acquire an OTA software upgrade package and a distributed upgrade strategy, determine an upgrade mode and a self-upgrade flashing program according to the upgrade strategy, and distribute the OTA software upgrade package to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and the self-upgrade flashing program; and a VCC domain controller communicatively connected to the ADCC domain controller, configured to acquire the current version information of each electronic control unit and feed it back to the cloud, and receive the OTA software upgrade task distributed by the cloud via HTTP protocol, parse the OTA software upgrade task to generate an upgrade strategy, and distribute the upgrade strategy to the ADCC domain controller to control the vehicle upgrade.

[0006] Optionally, the VCC domain controller includes: an upgrade configuration management main program module and a diagnostic engine. The upgrade configuration management main program module collects the hardware and software version information of each electronic control unit in the vehicle and reports it to the cloud, receives OTA upgrade tasks from the cloud, parses the OTA upgrade tasks to generate upgrade strategies, controls the download, verification, storage, and distribution of OTA upgrade packages according to the upgrade strategies, and collects the download progress and upgrade results of each electronic control unit and feeds them back to the cloud, realizing remote diagnostics, breakpoint resume, power-off resume, and OTA upgrade anomaly handling functions. The diagnostic engine is used to diagnose control nodes and send and receive different diagnostic-related commands from within the vehicle.

[0007] Optionally, the ADCC domain controller includes: an OTA Service module, a UDS Service module, an Internet Protocol-based diagnostic routing and forwarding program module, a differential engine, and storage space; wherein, the OTA Service module is used to implement self-flashing and upgrading of the internal system software of the ADCC domain controller; the UDS Service module interacts with the VCC domain controller, using a standard DoIP-UDS Service flashing program or a non-standard Http-UDS Service flashing program to achieve self-upgrading, so as to complete the corresponding electronic control unit upgrade operations in the pre-programming, reprogramming, and post-programming stages according to the upgrade strategy; the Internet Protocol-based diagnostic routing and forwarding program module is used to control the OTA upgrade of each electronic control unit node under the ADCC domain controller by interacting with the diagnostic engine or diagnostic tool, so as to realize the whole vehicle software upgrade; the differential engine is used to provide differential upgrade function for platform OTA based on open source differential restoration algorithm and cross-compilation, and control the ADCC domain controller to perform whole vehicle software upgrade operations; the storage space is used to store OTA upgrade packages.

[0008] Optionally, the OTA Service module further includes: an OTA management module, an OTA update management module, and an OTA partition update module. The OTA management module is used to obtain and report device information using an HTTP protocol interface, perform digital signature verification, control the self-upgrade process, and report upgrade progress and results to the UDS Service. The OTA update management module is responsible for OTA log initialization, system status and upgrade mode checks, and secondary digital signature verification to ensure the stability and security of the upgrade. The OTA partition update module is used to perform partition image verification and flashing according to the upgrade configuration file.

[0009] Optionally, the UDS Service module further includes: an Http-UDS Service flashing service program and a DoIP-UDS Service flashing service program. The Http-UDS Service flashing service program interacts with the UCMMaster program to handle the self-upgrade of the ADCC domain controller, downloads OTA software packages to a specified storage space via a URL link, and guides the OTA upgrade and obtains OTA upgrade status feedback to the UCM Master through an Http interaction protocol interface defined with the OTA Service. The DoIP-UDS Service flashing service program interacts with the Diagnostic Engine program to handle the self-upgrade of the ADCC domain controller, downloads OTA software packages to a specified storage space via the DoIP transport protocol, and guides the OTA upgrade and obtains OTA upgrade status feedback to the diagnostic engine through an Http interaction protocol interface defined with the OTA Service.

[0010] Optionally, the OTA Service module is also used to interact with the UDS Service program through a protocol interface, with the UDS Service guiding the OTA self-upgrade function of the ADCC domain controller, supporting A / B partition, single partition, and backup partition flashing functions, supporting OTA upgrade security protection functions, and supporting OTA log information recording and uploading functions.

[0011] Optionally, the DoIP Transceiver module further includes: a DiagCommMng module, a DoIP-DoIP node module, and a DoIP-Can node module. The DiagCommMng module parses the routing configuration table and determines whether the ECU node is a Can node or a DoIP node based on the routing configuration table, thereby distributing the request to the corresponding DoIP-DoIP node protocol stack or DoIP-Can node protocol stack. The DoIP-DoIP node module forwards DoIP diagnostic request commands to the Ethernet ECU node, receives DoIP responses, and forwards them to the Test Equipment via a DiagCommMng callback. The DoIP-Can node module converts DoIP diagnostic request commands into Can / CanFD messages and forwards them to the ECU node in the Can path, receives Can responses, converts them into DoIP responses, and forwards them to the Test Equipment via a DiagCommMng callback.

[0012] A second aspect of this application provides a vehicle including the vehicle OTA software upgrade system as described in the above embodiments.

[0013] A third aspect of this application provides a control method for a vehicle OTA software upgrade system. The method is implemented using the vehicle OTA software upgrade system described in the above embodiments. The method includes the following steps: identifying the current version information and current vehicle identifier of each electronic control unit; determining an OTA software upgrade task based on the current version information and the current vehicle identifier; generating a corresponding upgrade strategy based on the OTA software upgrade task; determining an upgrade mode and a self-upgrade flashing program according to the upgrade strategy; and distributing the OTA software upgrade package to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and the self-upgrade flashing program.

[0014] Optionally, the step of distributing the OTA software upgrade package to each corresponding electronic control unit according to the upgrade mode and the self-upgrade flashing program to perform the corresponding upgrade operation includes: determining whether the current system status of the ADCC domain controller supports OTA upgrade; if the current system status supports OTA upgrade, then distributing the path of the OTA upgrade package and the first-level encryption algorithm signature file to the ADCC domain controller, wherein after the ADCC domain controller successfully verifies the first-level encryption algorithm signature file, it decompresses the OTA upgrade package and distributes the OTA upgrade package to each corresponding electronic control unit to perform the self-upgrade.

[0015] Therefore, this application has at least the following beneficial effects:

[0016] This application enables the vehicle's OTA upgrade process to be jointly controlled by an ADCC domain controller and a VCC domain controller. The ADCC domain controller acts as a slave node in the vehicle's OTA process, directly interacting with the VCC domain controller as the master node. The ADCC domain controller acquires the OTA software upgrade package and the issued upgrade strategy, determines the upgrade mode and self-upgrade flashing program based on the upgrade strategy, and distributes the OTA software upgrade package to each corresponding electronic control unit (ECU) to execute the corresponding upgrade operation. The VCC domain controller acquires the current version information of each ECU and feeds it back to the cloud. It also receives OTA software upgrade tasks from the cloud via HTTP protocol, parses the OTA software upgrade tasks to generate an upgrade strategy, and distributes the upgrade strategy to the ADCC domain controller to control the vehicle upgrade. This shortens the communication link, improves the efficiency of the vehicle's OTA software upgrade, reduces the load and workload, and enhances the user experience.

[0017] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0018] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0019] Figure 1 This is a block diagram of a vehicle OTA software upgrade system according to an embodiment of this application;

[0020] Figure 2 This is a diagram of the platform OTA software architecture provided according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the OTA Service module design according to an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the UDS Service module design according to an embodiment of this application;

[0023] Figure 5 This is a schematic diagram of the DoIP Transceiver module design according to an embodiment of this application;

[0024] Figure 6 This is a flowchart of a control method for a vehicle OTA software upgrade system according to an embodiment of this application;

[0025] Figure 7 This is a timing diagram for OTA upgrades of a platform provided according to an embodiment of this application. Detailed Implementation

[0026] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0027] With the increasing number of ECU nodes in the current vehicle electronic and electrical architecture, the traditional master-slave upgrade mode uses the VCC's TBOX as the master control node for vehicle OTA upgrades, interacting with the cloud. At the same time, other ECU nodes are upgraded through the CGW central gateway. The ADCC, as a slave node, is only responsible for self-upgrades. Its subordinate ECU nodes, such as Front Radar, Corner Radar, and Camera, are all handled by the TBOX. In this type of vehicle OTA upgrade system, the communication link is too long. The processes of storing, transmitting, decompressing, decrypting, and verifying the OTA software upgrade package, as well as maintaining the upgrade sequence between the ADCC and its subordinate ECU nodes, are all handled by the TBOX. This leads to excessive upgrade load on the TBOX, insufficient resources, and OTA upgrade stuttering, freezing, or even failure, giving users a very poor OTA experience. Consequently, this master-slave node software upgrade system cannot achieve full-domain OTA upgrades for the entire vehicle cockpit domain, intelligent driving domain, and other domain controls.

[0028] Furthermore, because different car models may use domain controllers from different suppliers, their OTA flashing specifications vary, making it more complex for TBOX to achieve full-domain upgrades for the entire vehicle. This also prevents it from being extended and reused for other models, resulting in a massive workload for OTA development and debugging. Even though the industry has begun to reduce the size of OTA upgrade packages through differential upgrades, the generation of differential packages mostly involves processing the entire OTA upgrade package. This leads to excessive system resource consumption for differential restoration, causing failures and lengthy differential processes. In addition, existing OTA upgrade technologies have increasingly stringent information security requirements; protecting users' private information during OTA upgrades from theft is also a pressing issue that needs to be addressed.

[0029] The following issues also exist in the related technologies: During the OTA flashing and upgrading process, if there is a sudden power outage during the upgrade flashing, it is temporarily impossible to resume the upgrade from the breakpoint; Currently, it does not support the problem of diagnostic message conflict when diagnostic instrument diagnosis and OTA upgrade diagnosis occur simultaneously, which leads to OTA upgrade failure; DoIP routing forwarding currently only supports ECU upgrade nodes accessed via Ethernet and CAN / CANFD.

[0030] Therefore, to avoid the above problems, this application proposes a vehicle OTA software upgrade system. The Liyan ADCC intelligent driving domain controller acts as the slave node for the vehicle OTA, directly interacting with the VCC vehicle OTA master node. The OTA master node interacts with the cloud via HTTP, collecting and managing the hardware and software information of each ECU and reporting it to the cloud. The cloud then issues OTA upgrade tasks to the ADCC domain controller, and the OTA master node notifies the ADCC to perform the OTA upgrade. After issuing the OTA upgrade task, the system queries the progress and results of the upgrades for each ECU in the ADCC domain controller until the upgrade is complete, and then reports the final upgrade result and the upgraded ECU version to the cloud. This improves the efficiency of the vehicle OTA software upgrade, reduces the load and workload, and enhances the user experience.

[0031] The vehicle OTA software upgrade system, vehicle, and control method according to embodiments of this application are described below with reference to the accompanying drawings. Specifically... Figure 1 The vehicle OTA software upgrade system provided in this application embodiment.

[0032] Figure 1 This is a block diagram of a vehicle OTA software upgrade system according to an embodiment of this application.

[0033] like Figure 1 As shown, the vehicle OTA software upgrade system 10 includes: ADCC domain controller 100 and VCC domain controller 200.

[0034] The ADCC domain controller 100 is used to obtain the OTA software upgrade package and the issued upgrade strategy, determine the upgrade mode and self-upgrade flashing program according to the upgrade strategy, and issue the OTA software upgrade package to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and self-upgrade flashing program. The VCC domain controller 200, which is connected to the ADCC domain controller, is used to obtain the current version information of each electronic control unit and feed it back to the cloud, and receive the OTA software upgrade task issued by the cloud through HTTP protocol interaction, and parse the OTA software upgrade task to generate an upgrade strategy, and issue the upgrade strategy to the ADCC domain controller to control the vehicle upgrade.

[0035] It is understood that the embodiments of this application jointly control the OTA upgrade process of the entire vehicle through the ADCC domain controller and the VCC domain controller. The ADCC domain controller acts as the slave node for the vehicle's OTA, directly interacting with the VCC domain controller as the master node. The ADCC domain controller obtains the OTA software upgrade package and the issued upgrade strategy, determines the upgrade mode and self-upgrade flashing program based on the upgrade strategy, and sends the OTA software upgrade package to each corresponding electronic control unit to execute the corresponding upgrade operation. The VCC domain controller obtains the current version information of each electronic control unit and feeds it back to the cloud. It also receives the OTA software upgrade task sent from the cloud via HTTP protocol, parses the OTA software upgrade task to generate an upgrade strategy, and sends the upgrade strategy to the ADCC domain controller to control the vehicle upgrade. This shortens the communication link, improves the efficiency of the vehicle's OTA software upgrade, reduces the load and workload, and enhances the user experience.

[0036] It should be noted that ADCC intelligent driving domain control, as the slave node of the whole vehicle OTA, directly interacts with VCC whole vehicle OTA master node. The OTA master node interacts with the cloud using the HTTP protocol. It is responsible for collecting and managing the software and hardware information of each ECU and reporting it to the cloud. The cloud then issues ADCC domain control OTA upgrade tasks, and the OTA master node notifies ADCC to perform OTA upgrades. After issuing the OTA upgrade task, it queries the progress and results of the upgrade of each ECU in ADCC domain control until the upgrade is completed and reports the final upgrade results and the upgraded ECU version to the cloud.

[0037] In this embodiment, the VCC domain controller includes an upgrade configuration management main program module and a diagnostic engine. The upgrade configuration management main program module is used to collect the software and hardware version information of each electronic control unit in the vehicle and report it to the cloud, receive OTA upgrade tasks issued by the cloud, parse the OTA upgrade tasks to generate upgrade strategies, control the download, verification, storage and distribution functions of OTA upgrade packages according to the upgrade strategies, and collect the download progress and upgrade results of each electronic control unit and feed them back to the cloud, thereby realizing the functions of remote diagnosis, breakpoint resume, power failure resume upgrade and OTA upgrade anomaly handling. The diagnostic engine is used to diagnose control nodes and send and receive different in-vehicle diagnostic-related instructions.

[0038] It is understood that the VCC domain controller upgrade configuration management main program module in this application embodiment is used to collect the software and hardware version information of each electronic control unit in the vehicle and report it to the cloud, receive OTA upgrade tasks issued by the cloud, parse the OTA upgrade tasks to generate upgrade strategies, control the download, verification, storage and distribution functions of OTA upgrade packages according to the upgrade strategies, and collect the download progress and upgrade results of each electronic control unit and feed them back to the cloud, so as to realize the functions of remote diagnosis, breakpoint resume, power failure resume upgrade and OTA upgrade anomaly handling. The diagnostic engine is used to diagnose the control node and send and receive different instructions related to in-vehicle diagnosis in order to realize the processing flow of the OTA upgrade master control node and improve processing efficiency.

[0039] In this embodiment, the ADCC domain controller includes: an OTA Service module, a UDS Service module, an Internet Protocol-based diagnostic routing and forwarding program module, a differential engine, and storage space. The OTA Service module enables self-flashing and upgrading of the internal system software of the ADCC domain controller. The UDS Service module interacts with the VCC domain controller, using a standard DoIP-UDS Service flashing program or a non-standard Http-UDS Service flashing program to achieve self-upgrade, completing the corresponding electronic control unit upgrade operations in the pre-programming, reprogramming, and post-programming stages according to the upgrade strategy. The Internet Protocol-based diagnostic routing and forwarding program module interacts with the diagnostic engine or diagnostic tool to control the OTA upgrade of each electronic control unit node connected to the ADCC domain controller, achieving vehicle software upgrade. The differential engine provides differential upgrade functionality for the platform's OTA based on open-source differential restoration algorithms and cross-compilation, and controls the ADCC domain controller to perform vehicle software upgrade operations. The storage space stores OTA upgrade packages.

[0040] It is understood that the ADCC domain controller in this application embodiment includes: an OTA Service module, a UDSService module, an Internet Protocol-based diagnostic routing and forwarding program module, a differential engine, and storage space, thereby improving the efficiency of vehicle OTA upgrades.

[0041] In this embodiment, the OTA Service module further includes: an OTA management module, an OTA update management module, and an OTA partition update module. The OTA management module is used to obtain and report device information using the HTTP protocol interface, perform digital signature verification, control the self-upgrade process, and report the upgrade progress and results to the UDS Service. The OTA update management module is responsible for OTA log initialization, system status and upgrade mode checks, and secondary digital signature verification to ensure the stability and security of the upgrade. The OTA partition update module is used to perform partition image verification and flashing according to the upgrade configuration file.

[0042] It is understood that the OTA Service module in this application embodiment can support differential upgrade method, improve applicability, and ensure the stability and security of upgrade through multiple verification methods.

[0043] Specifically, such as Figure 3 As shown, the OTA Service module is primarily responsible for the self-flashing and upgrading of the internal system software of ADCC Intelligent Driving Domain Control. It also supports interaction with the Http-UDS Service or DoIP-UDS Service modules. The OTA Service mainly includes three functional modules: OTAmanager, OTAupdate, and partupdate.

[0044] (1)OTA_manager: As the OTA self-upgrade controller, it is mainly responsible for implementing the HTTP protocol interface, obtaining and reporting the hardware and software version information of the device, system status check, first-level RSA digital signature verification, triggering the OTA self-upgrade process, obtaining and reporting the progress and results of OTA self-upgrade to UDS Service.

[0045] (2)OTA_update_manager: As the OTA self-upgrade master control service, it is mainly responsible for OTA log system initialization, disk mode check, upgrade mode, secondary RSA digital signature verification, system environment check, configuration verification and upgrade image check to ensure the robustness of ADCC domain controller self-upgrade;

[0046] (3) OTA_partition_update: As an OTA upgrade slave service, it performs a series of verification checks according to the upgrade configuration file guidance information: configuration file check, GPT partition verification, partition image version number and integrity verification. If the verification is successful, it first switches OTA to the pre-upgrade state and starts to traverse and write the partition upgrade image. When the partition image upgrade method is differential upgrade, it calls the differential tool to perform differential upgrade. After the traversal and writing of the partition is completed, it switches OTA to the post-upgrade state. The upgrade configuration file can configure the upgraded partition, upgrade verification options and upgrade method.

[0047] In this embodiment, the UDS Service module further includes: an Http-UDS Service flashing service program and a DoIP-UDS Service flashing service program. The Http-UDS Service flashing service program interacts with the UCMMaster program to handle the self-upgrade of the ADCC domain controller, downloads OTA software packages to a specified storage space via a URL link, and guides the OTA upgrade and obtains OTA upgrade status feedback to the UCM Master through an Http interaction protocol interface defined with the OTA Service. The DoIP-UDS Service flashing service program interacts with the Diagnostic Engine program to handle the self-upgrade of the ADCC domain controller, downloads OTA software packages to a specified storage space via the DoIP transport protocol, and guides the OTA upgrade and obtains OTA upgrade status feedback to the diagnostic engine through an Http interaction protocol interface defined with the OTA Service.

[0048] It is understood that the embodiments of this application can utilize the Http-UDS Service flashing service program and the DoIP-UDS Service flashing service program to perform different self-upgrade flashing under different protocol methods, thereby improving upgrade efficiency and having high applicability.

[0049] It should be noted that ADCC provides OTA self-upgrade flashing via HTTP protocol. Its link is from the cloud to the upgrade master program UCM Master in the vehicle master node, to the Http-UDS Service in the vehicle slave node, and then to the OTA Service in the vehicle slave node. This is an efficient OTA upgrade method. ADCC provides OTA self-upgrade flashing via DoIP protocol. Its link is from the cloud to the upgrade master program UCM Master in the vehicle master node, to the Diagnostic Engine in the vehicle master node, to the DoIP-UDS Service in the vehicle slave node, and then to the OTA Service in the vehicle slave node. Compared with the HTTP protocol upgrade link, DoIP protocol upgrade packet transmission is longer and slower, but this OTA upgrade method is more universal.

[0050] Specifically, such as Figure 4 The UDS Service module shown is primarily responsible for interacting with the VCC master node. It can be either the standard DoIP-UDS Service flashing program or the non-standard Http-UDS Service flashing program. Both links implement the UDS flashing service, mainly involving diagnostic commands $10, $11, $22, $27, $28, $2E, $31, $34, $36, $37, $3E, and $85. These services are mainly related to upload / download and reprogramming order. Specific diagnostic service interface definitions are as follows:

[0051] (1) When the diagnostic ID is $10, the instruction is the diagnostic session control request instruction, and the corresponding mapping URL is ecuupgrade?dev={name};

[0052] (2) When the diagnostic ID is $11, the instruction is an ECU reset request instruction, and the corresponding mapping URL is ecureset?dev={name};

[0053] (3) When the diagnostic ID is $22, the instruction is the DID read data request instruction, and the corresponding mapping URL is ecureaddata? did={dataid};

[0054] (4) When the diagnostic ID is $27, the instruction is a secure access request instruction, and the corresponding mapping URL is / ecusecaccess?dev={name};

[0055] (5) When the diagnostic ID is $28, the instruction is a communication control request instruction, and the corresponding mapping URL is / ecucomcontrol?dev={name};

[0056] (6) When the diagnostic ID is $2E, the instruction is the DID write data request instruction, and the corresponding mapping URL is / ecuwritedata?did={datadid};

[0057] (7) When the diagnostic ID is $31, the instruction is a routine control request instruction, and the corresponding mapping URL is / ecuroutinecontrol?type={controltype};

[0058] (8) When the diagnostic ID is $34, the instruction is a download request instruction, and the corresponding mapped URL is / ecudownload?dev={name};

[0059] (9) When the diagnostic ID is $36, the instruction is a data transfer request instruction, and the corresponding mapping URL is / ecutransferdata?dev={name};

[0060] (10) When the diagnostic ID is $37, the instruction is a stop transfer request instruction, and the corresponding mapping URL is / ecutransferdateexit?dev={name};

[0061] (11) When the diagnostic ID is $3E, the instruction is a keep-alive status request instruction, and the corresponding mapping URL is / ecuupgraderesult?dev={name};

[0062] (12) When the diagnostic ID is $85, the instruction is the DTC setting request instruction, and the corresponding mapping URL is / ecuupgradefinish.

[0063] The UDS diagnostic flashing process is mainly divided into three stages: pre-programming, reprogramming, and post-programming. The main processing steps are as follows:

[0064] 1. Pre-programming stage: The pre-programming stage prepares the vehicle for programming one or more ECUs.

[0065] a. By requesting the diagnostic service '$10$03', a non-defaultsSession is started, and all ECUs are switched to extended diagnostic session mode;

[0066] b. By requesting the diagnostic service '$31$01$D003', the client checks the incomplete list of prerequisites (such as engine running, insufficient voltage, overheating) returned by the server. If the list is not empty, then the programming for this service cannot be executed. These prerequisites consist of general values ​​and ECU-specific values, and the values ​​and ranges defining the conditions are provided by the ECU supplier.

[0067] c. By requesting the diagnostic service `$85$02`, the client sets DTCSettingType to 'off', and the server disables DTC settings;

[0068] d. By requesting the diagnostic service '$28$01', non-diagnostic communication is disabled, and all ECUs stop normal communication with each other.

[0069] 2. Reprogramming Stage: The reprogramming stage is the ECU flashing and upgrade stage.

[0070] a. A request of $10 is made to enable reprogramming mode. When the server receives this request, it switches to the programming session and allocates all necessary resources for the reprogramming phase. The reprogramming session is protected by Seed-Key-Mechanism, which is implemented by requesting subservices '$27$07' and '$27$08'. Before downloading, any routines, programs, or fingerprint data are written to the server memory via $2E.

[0071] b. Before downloading, check if the same flash file exists in the server's memory via request sub-service '$31$01$D004'. If the flash file already exists, install it via request sub-service '$31$01$D005'. If it does not exist, download the flash file via requests to services $34, $36, and $37.

[0072] c. The flash driver file is downloaded via requests to services $34, $36, and $37. The flash bootloader can then execute programs and perform erase operations on the flash memory. If the MemoryAddresses in the flash file are not contiguous, multiple segmented executions are required. At the end of the download, sub-service '$31$01$D002' is requested to check if the flash download was successful. During runtime, the flash driver file is copied to RAM and executed.

[0073] d. After downloading the flash driver, the software module can write to the ECU flash memory. First, by requesting service $31, the server executes the memory erase routine. This service includes the parameter MemoryAddressIndex, and the server obtains the logical memory block to be erased based on this parameter. If the MemoryAddresses in the flash file are not contiguous, multiple erase operations are required.

[0074] e. Similar to downloading the flash driver file, the download of each consecutive segment of software modules follows the request sequence of services $34, $36, and $37. The transfer of a single segment may require multiple TransferData request messages to complete completely; if the MemoryAddresses in the flash file are not contiguous, multiple sectors may need to be executed. At the end of the segment, sub-service '$31$01$D002' is requested to check if the segment was downloaded successfully.

[0075] f. Once all components have been downloaded, the client requests the subservice '$31$01$D003', which triggers the server to execute a routine that verifies whether all downloads have been completed. This routine triggers the server to check the compatibility and consistency between the software and hardware.

[0076] g. After all Flash files have been downloaded, the server starts installing the Flash files by requesting service '$31$01$D005'. Installation takes some time, and the client retrieves the installation results from the server by requesting service '$31$03$D005'. When the installation progress bar shows 100%, the installation is successful.

[0077] h. When the reprogramming execution is complete, restart the server by requesting service '$11$01'. If the server receives the request, it will execute reset and start defaultSession.

[0078] 3. Post-programming stage:

[0079] The post-programming phase is executed after all services have been programmed. It requires requesting service '$10$01' to notify all relevant servers via an event to resume normal network communication and data transmission and begin entering the defaultSession.

[0080] In this embodiment, the OTA Service module is also used to interact with the UDS Service program through a protocol interface. The UDS Service guides the OTA self-upgrade function of the ADCC domain controller, supports A / B partition, single partition, and backup partition flashing functions, supports OTA upgrade security protection functions, and supports OTA log information recording and uploading functions.

[0081] The security protections include: integrity verification, data signature verification, image rollback prevention, OTA version verification, and GPT partition verification.

[0082] It is understood that the OTA Service module OTA self-upgrade program in this application embodiment serves as the execution node program for OTA self-upgrade on the ADCC platform, and is responsible for the OTA self-upgrade function within the ADCC domain controller, thereby improving upgrade efficiency.

[0083] In this embodiment, the DoIP Transceiver module further includes: a DiagCommMng module, a DoIP-DoIPnode module, and a DoIP-Can node module. The DiagCommMng module is used to parse the routing configuration table, determine whether the ECU node is a Can node or a DoIP node based on the routing configuration table, and then distribute it to the corresponding DoIP-DoIP node protocol stack or DoIP-Can node protocol stack. The DoIP-DoIP node module is used to forward DoIP diagnostic request commands to the Ethernet ECU node, and simultaneously receive DoIP responses, and forward them to the Test Equipment via DiagCommMng callback. The DoIP-Can node module is used to convert DoIP diagnostic request commands into Can / CanFD messages and forward them to the ECU node in the Can path, and simultaneously receive Can responses, convert them into DoIP responses, and forward them to the Test Equipment via DiagCommMng callback.

[0084] It is understood that in this embodiment of the application, the DoIP Transceiver module is mainly responsible for the OTA upgrade of the ECU nodes connected to the ADCC, so as to realize the full-domain upgrade of ADCC and support ECU nodes with different communication links, which is equivalent to a scaled-down CGW function.

[0085] It should be noted that ADCC provides the DoIP Transceiver module to support the upgrade of all ECU nodes connected to the ADCC domain controller. It supports DoIP to DoIP routing and DoIP to CAN / CANFD routing. The link is from the cloud to the upgrade master program UCM Master in the vehicle master node, to the diagnostic engine DiagnotiscEngine in the vehicle slave node, and then to the DoIP Transceiver in the vehicle slave node. According to the target address routing configuration table, it is then forwarded to the target ECU node connected to ADCC to guide the OTA upgrade of the target ECU node.

[0086] Specifically, such as Figure 5 As shown, the DoIP Transceiver mainly consists of the following parts:

[0087] (1) DiagCommMng: Diagnostic communication management module, an extensible routing conversion protocol stack management module, parses the routing configuration table, and performs doip routing function according to the routing configuration. It mainly determines whether the DoIP logical address of the target ECU of the diagnostic command issued by Test Equipment is physical addressing or functional addressing, and determines whether the ECU node is a Can node or a DoIP node according to the routing configuration table, so as to distribute it to the corresponding DoIP-DoIP node protocol stack or DoIP-Cannode protocol stack.

[0088] (2) DoIP-DoIP node: DoIP to DoIP routing and forwarding module, mainly responsible for forwarding DoIP diagnostic request commands to Ethernet ECU nodes, and receiving DoIP responses, and forwarding them to Test Equipment via DiagCommMng callback;

[0089] (3) DoIP-Can node: The DoIP to Can routing and forwarding module is mainly responsible for converting the DoIP diagnostic request command into a Can / CanFD message and forwarding it to the ECU node of the Can path. At the same time, it receives the Can response, converts it into a DoIP response, and forwards it to the Test Equipment via the DiagCommMng callback.

[0090] The vehicle OTA software upgrade system proposed in the embodiments of this application is XX.

[0091] The following will combine Figures 2 to 5 The vehicle OTA software upgrade system described in this application is described in detail below:

[0092] VCC Domain Controller (OTA Upgrade Master Node):

[0093] (1) UCM Master: The main program for upgrading configuration management, mainly responsible for vehicle-to-cloud interaction: by collecting the software and hardware version information of each ECU in the vehicle and reporting it to the OTA Server cloud, the cloud issues OTA upgrade tasks, and UCM Master is responsible for the analysis and execution of upgrade task strategies; downloading, verifying, storing and distributing upgrade packages; and collecting the download and upgrade results of each ECU and feeding them back to the cloud; in addition, UCM Master also supports advanced functions such as remote diagnosis, breakpoint resume, power failure resume upgrade, and OTA upgrade anomaly handling.

[0094] (2) Diagnostic Engine: The diagnostic engine and diagnostic control node are responsible for sending and receiving in-vehicle diagnostic-related commands, such as reading ECU information, controlling ECU upgrades and flashing, and obtaining vehicle upgrade-related status.

[0095] ADCC Domain Controller (OTA Upgrade Slave Node):

[0096] (1) Http-UDS Service: A non-standard UDS flashing service program implemented based on the HTTP protocol. It interacts with the UCM Master program to handle the self-upgrade of the ADCC domain controller. It downloads OTA software packages to a specified storage space via a URL link and guides the OTA upgrade through an HTTP interaction protocol interface defined with the OTA Service, obtaining OTA upgrade status feedback to the UCM Master. Due to its fast transmission speed and strong processing capabilities, the Http-UDS Service is often the preferred UDS Service for ADCC domain controller self-upgrades, provided that the VCC master node has deployed a UCM Master based on the HTTP protocol.

[0097] (2) DoIP-UDS Service: A standard UDS flashing service program implemented based on the DoIP protocol. It interacts with the Diagnostic Engine program to handle the self-upgrade of ADCC domain controllers. It downloads OTA software packages to designated storage space via the DoIP transport protocol and guides OTA upgrades through the HTTP interaction protocol interface defined by the OTA Service, obtaining OTA upgrade status feedback to the diagnostic engine. It can also connect to an external diagnostic instrument to guide the OTA self-upgrade of the ADCC domain controller.

[0098] (3) OTA Service: The OTA self-upgrade program serves as the execution node program for the ADCC platform's OTA self-upgrade, responsible for the OTA self-upgrade function within the ADCC domain controller. Its specific functional modules mainly include:

[0099] Defines the interaction protocol interface with the UDS Service program, which guides the OTA self-upgrade function of the ADCC domain controller; supports A / B partition, single partition, and backup partition flashing; supports OTA full upgrade and differential upgrade modes; supports OTA upgrade security protection, including integrity verification, data signature verification, image rollback prevention, OTA version verification, and GPT partition verification; supports OTA log information recording and uploading, which mainly includes upgrade process, upgrade progress, upgrade anomalies, upgrade results, and other information.

[0100] (4) DoIP Transceiver: The DoIP routing and forwarding program interacts with the diagnostic engine or diagnostic tool to control and guide the OTA upgrades of the ECU nodes connected to the ADCC, realizing full-domain OTA upgrades of the ADCC. The DoIP routing and forwarding is equivalent to the CGW, which can support different communication links, including Ethernet nodes, CAN / CANFD nodes, etc. According to the actual vehicle EE architecture scheme of the project, if the ADCC domain controller does not have any connected ECU nodes, then this gateway routing does not need to be deployed.

[0101] (5) Differential Engine: Based on the open-source differential restoration algorithm, cross-compile to provide cross-platform differential restoration tools. It mainly provides differential upgrade capabilities for platform OTA and is responsible for the organization and management of ADCC domain controller upgrades. It is divided into two parts: cloud differential package generation tool and vehicle differential package restoration engine.

[0102] A vehicle includes an OTA software upgrade system as described in the above embodiments.

[0103] Specifically, Figure 6 This is a flowchart illustrating a control method for a vehicle OTA software upgrade system provided in an embodiment of this application.

[0104] like Figure 6 As shown, the control method of the vehicle OTA software upgrade system is implemented using the aforementioned vehicle OTA software upgrade system, and includes the following steps:

[0105] In step S101, the current version information and current vehicle identifier of each electronic control unit are identified.

[0106] It is understood that the embodiments of this application can identify the current version information and current vehicle identifier of each electronic control unit in order to determine the OTA software upgrade task based on the current version information and current vehicle identifier.

[0107] In step S102, an OTA software upgrade task is determined based on the current version information and the current vehicle identifier, and a corresponding upgrade strategy is generated based on the OTA software upgrade task.

[0108] It is understood that the embodiments of this application can determine the OTA software upgrade task based on the current version information and the current vehicle identifier, and generate a corresponding upgrade strategy based on the OTA software upgrade task, so as to determine the upgrade mode and self-upgrade flashing program according to the upgrade strategy.

[0109] In step S103, the upgrade mode and self-upgrade flashing program are determined according to the upgrade strategy, and the OTA software upgrade package is sent to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and self-upgrade flashing program.

[0110] It is understood that the embodiments of this application can determine the upgrade mode and self-upgrade flashing program according to the upgrade strategy, and distribute the OTA software upgrade package to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and self-upgrade flashing program, so as to improve the software upgrade efficiency and improve the user experience.

[0111] In this embodiment, the OTA software upgrade package is distributed to each corresponding electronic control unit according to the upgrade mode and the self-upgrade flashing program to perform the corresponding upgrade operation, including: determining whether the current system status of the ADCC domain controller supports OTA upgrade; if the current system status supports OTA upgrade, the path of the OTA upgrade package and the first-level encryption algorithm signature file are distributed to the ADCC domain controller, wherein, after the ADCC domain controller successfully verifies the first-level encryption algorithm signature file, it decompresses the OTA upgrade package and distributes the OTA upgrade package to each corresponding electronic control unit to perform self-upgrade.

[0112] It is understood that, in the embodiments of this application, if OTA upgrades are supported in the current system state, the path of the OTA upgrade package and the first-level encryption algorithm signature file are sent to the ADCC domain controller, which can improve the security of software download.

[0113] According to the control method of the vehicle OTA software upgrade system proposed in the embodiments of this application, the current version information and current vehicle identifier of each electronic control unit are identified, the OTA software upgrade task is determined based on the current version information and current vehicle identifier, the corresponding upgrade strategy is generated based on the OTA software upgrade task, the upgrade mode and self-upgrade flashing program are determined according to the upgrade strategy, and the OTA software upgrade package is sent to each corresponding electronic control unit to perform the corresponding upgrade operation according to the upgrade mode and self-upgrade flashing program, so as to improve the software upgrade efficiency and enhance the user experience.

[0114] The following will combine Figure 7 The control method of the vehicle OTA software upgrade system of this application is described in detail below:

[0115] The sequence diagram for OTA interaction between the vehicle and the cloud, where OTA Server represents the cloud, illustrates the implementation of the ADCC domain controller self-upgrade process. The specific steps are as follows:

[0116] Step 1: Power on the vehicle and start running the UCM Master and Diagnostic Engine of the VCC domain controller, as well as the UDS Service and OTA Service of the ADCC domain controller.

[0117] Step 2: The VCC domain controller checks the prerequisites. If the OTA diagnostic self-test passes, the ECU version information of the ADCC domain controller can be obtained through the $22 service.

[0118] Step 3: The VCC domain controller obtains the VIN vehicle identification code and reports the VIN code and ADCC domain controller version information to the cloud OTA server.

[0119] Step 4: The OTA Server performs task matching and sends the matching task results to the UCMMaster of the VCC domain controller.

[0120] Step 5: UCM Master parses the upgrade task information, downloads the OTA upgrade package, and performs integrity verification;

[0121] Step 6: A prompt will appear for a new OTA update. If the user clicks "Upgrade Now", the vehicle will undergo a charging check, be remotely powered on, and enter OTA mode.

[0122] Step 7: Check the preconditions for the upgrade and determine whether the current system status of the ADCC domain controller supports OTA upgrade.

[0123] Step 8: The VCC domain controller requests an upgrade for the ADCC domain controller and sends the path to the OTA upgrade package and the first-level RSA signature file to the ADCC domain controller.

[0124] Step 9: The ADCC domain controller decompresses the OTA upgrade package and verifies the first-level RSA signature; OTA self-upgrade will only proceed after the first-level signature verification is successful.

[0125] Step 10: The VCC domain controller sends the UDS command to the ADCC domain controller via DoIP or HTTP to complete the UDS flashing process. Refer to the UDS Service module for the UDS flashing process.

[0126] Step 11: After the UDS flashing is completed, the VCC domain controller queries the ADCC domain controller for the upgrade result. If successful, it exits OTA mode and remotely powers down.

[0127] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0128] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0129] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0130] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0131] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0132] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A vehicle OTA software upgrade system, characterized by, Comprise: The ADCC domain controller is used for obtaining OTA software upgrade package and issued upgrade strategy, determining upgrade mode and self-upgrade program according to the upgrade strategy, and issuing the OTA software upgrade package to the corresponding electronic control unit according to the upgrade mode and the self-upgrade program to perform corresponding upgrade operation; The VCC domain controller in communication connection with the ADCC domain controller is used for obtaining current version information feedback of each electronic control unit to the cloud, receiving OTA software upgrade task issued by the cloud through HTTP protocol interaction, analyzing the OTA software upgrade task to generate upgrade strategy, and issuing the upgrade strategy to the ADCC domain controller to control vehicle upgrade.

2. The vehicle OTA software upgrade system of claim 1, wherein, The VCC domain controller comprises an upgrade configuration management main program module and a diagnosis engine, wherein, The upgrade configuration management main program module is used for collecting software and hardware version information of each electronic control unit in the vehicle to report to the cloud, receiving OTA upgrade task issued by the cloud, analyzing the OTA upgrade task to generate upgrade strategy, controlling OTA software upgrade package downloading, signature verification, storage and distribution functions according to the upgrade strategy, collecting download progress and upgrade result of each electronic control unit to feedback to the cloud, and realizing functions of remote diagnosis, breakpoint resume, power-off resume and OTA upgrade exception handling; The diagnosis engine is used for diagnosing control node and transmitting and receiving different instructions related to vehicle diagnosis.

3. The vehicle OTA software upgrade system of claim 1, wherein, The ADCC domain controller comprises an OTA Service module, a UDS Service module, a DoIP Transceiver module, a differential engine and a storage space, wherein, The OTA Service module is used for realizing self-brushing upgrade of internal system software of the ADCC domain controller; The UDS Service module interacts with the VCC domain controller, uses standard DoIP-UDS Service program or non-standard Http-UDS Service program to realize self-upgrade, and completes upgrade operation of corresponding electronic control unit in pre-programming, re-programming and post-programming stages according to the upgrade strategy; The DoIP Transceiver module is used for controlling OTA upgrade of each electronic control unit node hung by the ADCC domain controller through interaction with the diagnosis engine or diagnosis instrument, and realizing vehicle software upgrade; The differential engine is used for providing differential upgrade function based on open source differential restoration algorithm and cross-compilation for platform OTA, and controlling the ADCC domain controller to perform vehicle software upgrade operation; The storage space is used for storing OTA software upgrade package.

4. The vehicle OTA software upgrade system of claim 3, wherein, The OTA Service module further comprises an OTA management module, an OTA update management module and an OTA partition update module, wherein, The OTA management module is used for obtaining and reporting device information through HTTP protocol interface, performing digital signature verification, controlling self-upgrade process, and reporting upgrade progress and result to the UDS Service; The OTA update management module is used for being responsible for OTA log initialization, system state and upgrade mode checking, secondary digital signature verification, so as to ensure stability and security of upgrading. The OTA partition update module is used for performing checking sum and flashing of partition image according to an upgrade configuration file.

5. The vehicle OTA software upgrade system of claim 3, wherein, The UDS Service module further comprises: an Http-UDS Service flashing service program and a DoIP-UDS Service flashing service program, wherein, The Http-UDS Service flashing service program is used for being responsible for self-upgrading of the ADCC domain controller by interacting with the UCM Master program, downloading an OTA software package to a specified storage space through a URL link, and guiding OTA upgrading and obtaining OTA upgrading state feedback to the UCM Master through the OTA Service defined Http interactive protocol interface. The DoIP-UDS Service flashing service program is used for being responsible for self-upgrading of the ADCC domain controller by interacting with the Diagnostic Engine program, downloading an OTA software package to a specified storage space through a DoIP transmission protocol, and guiding OTA upgrading and obtaining OTA upgrading state feedback to the diagnostic engine through the OTA Service defined Http interactive protocol interface.

6. The vehicle OTA software upgrade system of claim 3, wherein, The OTA Service module is further used for interacting with the UDS Service program interactive protocol interface, guiding OTA self-upgrading function of the ADCC domain controller by the UDS Service, supporting A / B partition, single partition, backup partition flashing function, supporting OTA upgrading security protection function, supporting OTA log information recording and uploading function.

7. The vehicle OTA software upgrade system of claim 3, wherein, The DoIP Transceiver module further comprises: a DiagCommMng module, a DoIP-DoIP node module, and a DoIP-Can node module, wherein, The DiagCommMng module is used for analyzing a routing configuration table, judging whether an ECU node is a Can node or a DoIP node according to the routing configuration table, so as to be distributed to a corresponding DoIP-DoIP node protocol stack or DoIP-Can node protocol stack; The DoIP-DoIP node module is used for forwarding a DoIP diagnostic request instruction to an Ethernet ECU node, receiving a DoIP response, and forwarding the DoIP response to the Test Equipment through DiagCommMng callback; The DoIP-Can node module is used for converting the DoIP diagnostic request instruction into a Can / CanFD message, forwarding the Can / CanFD message to a Can channel ECU node, receiving a Can response, converting the Can response into a DoIP response, and forwarding the DoIP response to the Test Equipment through DiagCommMng callback.

8. A vehicle characterized by comprising: The vehicle OTA software upgrading system comprises the vehicle OTA software upgrading system according to any one of claims 1-7.

9. A control method of a vehicle OTA software upgrade system, characterized by, The method is implemented by the vehicle OTA software upgrading system in any one of claims 1-7, wherein the method comprises the following steps: identifying current version information and current vehicle identification of each electronic control unit; determining an OTA software upgrading task based on the current version information and the current vehicle identification, and generating a corresponding upgrading strategy based on the OTA software upgrading task; determining an upgrading mode and a self-upgrading flashing program according to the upgrading strategy, and downloading the OTA software upgrading package to the corresponding each electronic control unit to perform a corresponding upgrading operation according to the upgrading mode and the self-upgrading flashing program.

10. The control method of the vehicle OTA software upgrade system according to claim 9, characterized in that, The downloading of the OTA software upgrading package to the corresponding each electronic control unit to perform a corresponding upgrading operation according to the upgrading mode and the self-upgrading flashing program comprises: judging whether a current system state of an ADCC domain controller supports OTA upgrading; if the current system state supports OTA upgrading, downloading a path of the OTA software upgrading package and a primary encryption algorithm signature file to the ADCC domain controller, wherein the ADCC domain controller decompresses the OTA software upgrading package after successfully verifying the primary encryption algorithm signature file, and downloads the OTA software upgrading package to the corresponding each electronic control unit to perform self-upgrading.

Images