Vehicle OTA parallel upgrading method

Abstract

The invention provides a vehicle OTA parallel upgrading method, and belongs to the technical field of vehicle cloud interaction. The method is used for flashing and upgrading a self-upgrading part of an electronic control unit (ECU), a diagnostic communication protocol part based on an internet protocol and a controller local area network part, and comprises the following steps of: step 0, determining a parallel rule and classifying the upgrading parts of the ECU before upgrading; the method comprises the steps of 1, configuring upgrading tasks according to parallel rules; step 2, the main downloading agent verifies the preposed environment and downloads each upgrade package; step 3, flashing and upgrading three-power upgrading parts in the diagnosis communication protocol part based on the Internet protocol and the controller local area network part; 4, carrying out parallel upgrading on a non-three-power upgrading piece in the self-upgrading piece, the diagnosis communication protocol piece based on the Internet protocol and the controller local area network piece; and step 5, finishing upgrading. According to the OTA upgrading parallel flashing software, the flashing tasks of the multiple ECUs are processed in parallel, the upgrading efficiency is remarkably improved, and the vehicle downtime is shortened.

Description

Technical Field

[0001] This invention relates to the field of vehicle-cloud interaction technology, and more specifically to a method for parallel OTA upgrades of vehicles. Background Technology

[0002] With the increasing complexity of vehicle control systems and the growing number of ECUs (Electronic Control Units), the previously used sequential OTA (Over-the-Air) technology, due to its long upgrade time and low efficiency, can no longer meet the needs of vehicle OTA upgrades. In remote OTA technology, parallel flashing has become one of the directions of technological development to further improve upgrade efficiency and resource utilization. Parallel flashing upgrades multiple ECUs simultaneously, reducing upgrade time and improving the user upgrade experience. Summary of the Invention

[0003] The purpose of this invention is to solve the problems existing in the prior art and to provide a vehicle OTA parallel upgrade method. By optimizing the priority management of different ECUs, the flashing order adjustment, the fault tolerance mechanism and the network resource allocation, this invention can achieve efficient and stable multi-ECU parallel upgrade.

[0004] This invention is achieved through the following technical solution:

[0005] A vehicle OTA parallel upgrade method involves flashing and upgrading the self-upgrading component of the electronic control unit (ECU), the diagnostic communication protocol component based on the Internet protocol, and the controller area network component. The method includes:

[0006] Step 0: Before upgrading, clarify the parallel rules and the classification of electronic control unit (ECU) upgrade parts;

[0007] Step 1: Configure upgrade tasks according to parallel rules;

[0008] Step 2: The main download agent verifies the pre-installed environment and downloads each upgrade package;

[0009] Step 3: Flash and upgrade the three-electric upgrade components in the diagnostic communication protocol based on Internet Protocol and the controller area network component;

[0010] Step 4: Perform parallel upgrades on the self-upgrade components, the diagnostic communication protocol components based on Internet Protocol, and the non-electrical upgrade components in the controller area network components;

[0011] Step 5, upgrade complete.

[0012] Furthermore, the parallel rules include: For diagnostic communication protocol components based on Internet protocols and controller area network components, the three-electric upgrade components cannot be upgraded in parallel with non-three-electric upgrade components and must be upgraded first; ECU upgrade components within the same local area network channel are processed serially, while ECU upgrade components within different local area network channels are processed in parallel; if there are related components in the upgrade list, the relationship is defined through a pre-configured dependency tree, and if any related component fails to upgrade, other components that depend on it immediately stop the current upgrade and trigger a rollback.

[0013] Furthermore, step 1 includes:

[0014] Step 101: Determine the parallel upgrade strategy based on the electronic control unit (ECU) topology;

[0015] Step 102: Configure the parallel upgrade strategy and upgrade task according to the parallel rules;

[0016] Step 103: Generate an upgrade task based on the Electronic Control Unit (ECU) topology.

[0017] Furthermore, step 101 includes:

[0018] Step 1011: Identify the key components for the upgrade;

[0019] Step 1012: Analyze the connection method between the Electronic Control Unit (ECU) and the User Connection Unit, including: the self-upgrading component is connected to the User Connection Unit via USB cable or Ethernet; the diagnostic communication protocol component based on Internet Protocol is connected to the User Connection Unit via Ethernet; and the Controller Area Network (CAN) component is connected to the User Connection Unit via CAN channel.

[0020] Step 1013: Classify the upgrade components of each electronic control unit (ECU) in the topology and divide the local area network channels where each ECU is located.

[0021] Furthermore, the parallel upgrade strategy also includes setting conditions prohibiting parallel upgrades: ECU upgrades on the same local area network channel will not be performed in parallel; ECU upgrades on slave nodes and master nodes on the LIN bus cannot be performed in parallel; and ECU upgrades on slave nodes on the LIN bus cannot be performed in parallel.

[0022] Furthermore, step 3 includes three steps: pre-programming, reprogramming, and post-programming.

[0023] Step 301: Using the function addressing method, program all the three-electric upgrade components of the target electronic control unit (ECU);

[0024] Step 302: The reprogramming module manages the reprogramming process of the target electronic control unit (ECU) and sequentially initiates the reprogramming of the three-electric upgrade components in different electronic control units (ECUs).

[0025] Step 303: Using the function addressing method, perform post-programming operations on the three-electric upgrade components of the target electronic control unit (ECU).

[0026] Furthermore, step 301 includes:

[0027] Step 3011: The target electronic control unit (ECU) is brought into an extended session via function addressing;

[0028] Step 3012: In the extended session, enter secure access to unlock write permissions;

[0029] Step 3013: Disable non-diagnostic communication of all target electronic control units (ECUs) through function addressing;

[0030] Step 3014: Check programming conditions and erase memory;

[0031] Step 3015: Output the target electronic control unit (ECU) to enter the ready state;

[0032] Step 3016: Obtain the data transmission parameters returned by the target electronic control unit (ECU).

[0033] Furthermore, the reprogramming of the electronic control unit (ECU) is carried out in parallel through multi-threading, with each thread responsible for one local area network (LAN) channel; the three-electric upgrade components within one LAN channel are flashed serially, while the three-electric upgrade components in different LAN channels are flashed in parallel.

[0034] Furthermore, step 4 includes:

[0035] Step 401: Send a parallel flash command to trigger the entire upgrade process;

[0036] Step 402: After receiving the instruction, perform parallel flashing strategy detection and evaluate the current vehicle status, network load, and electronic control unit (ECU) dependencies.

[0037] Step 403: Pre-program the self-upgrade component of the target electronic control unit (ECU), as well as the non-electric upgrade components in the diagnostic communication protocol component based on Internet Protocol and the controller area network component.

[0038] Step 404: The self-upgrade component of the target electronic control unit (ECU), as well as the non-electric upgrade components in the Internet Protocol-based diagnostic communication protocol component and controller area network component, enter the ready state, receive the data transmission parameters returned by the target electronic control unit (ECU), and reprogram using the downloaded upgrade package;

[0039] Step 405: After all electronic control unit (ECU) self-upgrade components, as well as all Internet protocol-based diagnostic communication protocol components and non-electrical upgrade components in the controller area network components, have completed their reprogramming in sequence, the post-programming process is executed.

[0040] Furthermore, steps 3 and 4 employ a timeout protection mechanism, using a global timeout timer to cover the entire flashing process; the timeout protection includes:

[0041] Upon receiving the parallel write command, a global timeout timer is started;

[0042] Upon receiving a successful response to an ECU flashing operation, the global timeout timer is immediately reset;

[0043] Stop the global timeout timer, including: after all electronic control units (ECUs) are successfully flashed, stop the global timeout timer; if the global timeout timer determines that it has timed out, terminate all flashing tasks and start the rollback process.

[0044] The beneficial effects of this invention are as follows: The OTA upgrade parallel flashing software of this invention significantly improves upgrade efficiency and reduces vehicle downtime (upgrade time is reduced to 30% to 50% of non-parallel flashing time) by processing flashing tasks for multiple ECUs in parallel, thus enhancing the user experience. Based on the rational scheduling of diagnostic engine (DE) resources and network bandwidth, it optimizes system resource utilization and improves overall throughput. Simultaneously, through timeout protection mechanisms and conflict avoidance strategies, the software can effectively cope with command loss and communication failures, ensuring the safety and stability of the upgrade process. Its flexible parallel flashing strategy enables the software to adapt to vehicle systems under different architectures and resource conditions, meeting the diverse upgrade needs of complex vehicles, significantly improving the speed and reliability of OTA upgrades, and providing better remote upgrade support for intelligent connected vehicles. Attached Figure Description

[0045] Figure 1 The parallel upgrade flowchart of this invention.

[0046] Figure 2 Architecture diagram of the vehicle-side ECU in this invention.

[0047] Figure 3 Parallel brushing schedule diagram of an embodiment of the method of the present invention. Detailed Implementation

[0048] The present invention will now be described in further detail with reference to the accompanying drawings:

[0049] The vehicle ECU upgrade list includes three types: self-upgrading components, DOIP (Diagnostic Communication over Internet Protocol) components, and CAN (Controller Area Network) components. Self-upgrading components, DOIP components, and CAN components can all be upgraded in parallel. However, the three-electric system upgrade components within DOIP or CAN components—referring to ECUs that operate under high-voltage environments (e.g., Battery Management System, Motor Controller Unit, Vehicle Controller Unit)—cannot be upgraded in parallel with non-three-electric system upgrade components due to their high-voltage requirements. In parallel upgrades, the upgrade order must be determined first: the three-electric system upgrade components are upgraded first; then, the self-upgrading components, DOIP components, and CAN components are upgraded in parallel. To minimize cross-interference in the ECU upgrade chain, ECUs within the same CAN channel are upgraded serially, while ECUs in different CAN channels are upgraded in parallel. If the upgrade list includes related components, the failure of any related component upgrade will cause other related components in the upgrade list to continue upgrading out of order, thus changing the upgrade sequence.

[0050] Before the formal upgrade, it is necessary to clarify the parallel rules and ECU classification.

[0051] ECU types include:

[0052] (1) Self-upgrade component: It can be upgraded independently by connecting to the UCU (User Connection Unit) via USB or Ethernet.

[0053] (2) DOIP: A diagnostic communication protocol based on Internet Protocol, which connects to the UCU via Ethernet.

[0054] (3) CAN component: Based on the controller local area network, it is connected to the UCU through the CAN channel.

[0055] Establish parallel rules, including:

[0056] (1) Self-upgrading components, DOIP components and CAN components can be flashed in parallel; however, there are exceptions: the three-electric upgrade components in DOIP or CAN components that need to be in a high-voltage environment cannot be upgraded in parallel with non-three-electric upgrade components and must be upgraded first.

[0057] (2) Channel restriction: ECUs in the same CAN channel are upgraded serially to avoid excessive bus load; ECUs in different CAN channels are upgraded in parallel.

[0058] (3) Related component handling: If there are related components in the upgrade list, the related components are ECU groups with functional dependencies, such as ABS (Anti-lock Braking System) and ESP (Electronic Stability Program). The relationship is defined by the dependency tree pre-configured in the cloud. When any related component upgrade fails, other components in the ECU group that depend on it will immediately stop the upgrade and trigger a rollback.

[0059] Determine the upgrade order: prioritize the parallel upgrade of the three electrical components; then, within the constraints of the channel rules, upgrade the self-upgrading components, DOIP components, and CAN components in parallel.

[0060] The above steps are to ensure that the upgrade list is sorted reasonably and to reduce cross-interference.

[0061] The parallel upgrade method described in this invention is as follows: Figure 1 ,include:

[0062] Step 1: Configure tasks according to parallel rules

[0063] First, the parallel strategy is determined based on the vehicle-side ECU topology.

[0064] like Figure 2 The diagram showing the vehicle-side ECU architecture illustrates the vehicle-side topology, which forms the basis for formulating parallel strategies. It demonstrates the ECU's connection method and channel division, directly affecting parallel efficiency.

[0065] (1) As Figure 2 As shown, the key components for the upgrade include:

[0066] The UCU (User Connection Unit) is the main control unit (host module) of the OTA vehicle software of this invention. As the host software, it provides DOIP and CAN low-level interface support for the OTA software. It, together with DE and MDA, forms a central scheduling module. DE and MDA are developed OTA programs integrated in the UCU environment.

[0067] MDA (Master Download Agent) is responsible for downloading upgrade packages for each ECU and triggering the DE program to perform parallel flashing tasks;

[0068] The DE (Diagnostic Engine) receives trigger commands from the MDA and performs parallel or serial flashing on each ECU according to the UDS (Unified Diagnostic Services) commands.

[0069] (2) Analyze the ECU connection method

[0070] The self-upgrading component connects to the UCU via USB cable or Ethernet;

[0071] DOIP component 1 and DOIP component 2 are connected to the UCU via Ethernet;

[0072] CAN components: Groups connect to the UCU via CAN channels. For example, CAN component 1 and CAN component 2 are connected to the UCU via CAN channel 1, and CAN component 3 and CAN component 4 are connected to the UCU via CAN channel 2.

[0073] (3) Parallel line partitioning

[0074] Classifying the ECUs in the architecture diagram and dividing the channels where each ECU is located are the foundation for formulating a parallel flashing strategy. The quality of the parallel flashing strategy directly affects the success rate and efficiency of parallel flashing.

[0075] Figure 2 In this architecture, five parallel lines can be formed: self-upgrading component, DOIP component 1, DOIP component 2, CAN channel 1, and CAN channel 2.

[0076] CAN component 1 and CAN component 2 are on the same channel (CAN channel 1) and must be upgraded serially; while CAN component 1 and CAN component 3 are on different channels (CAN channels 1 and 2) and can be upgraded in parallel.

[0077] Subsequently, in the upgrade management module of the OTA platform, parallel upgrade strategies and upgrade tasks are configured according to the rules.

[0078] The OTA platform configures upgrade tasks according to a parallel strategy, but the number of ECUs that can be flashed in parallel is constrained by factors such as vehicle bus resources, Ethernet speed, and flashing success rate.

[0079] To ensure the stability and success rate of the upgrade, this invention establishes a prohibition on parallel upgrades. ECUs will not be upgraded in parallel under the following circumstances: ECUs on the same channel will not be upgraded in parallel because excessive CAN bus load may cause upgrade failure; because the master node needs to convert CAN messages into LIN (Local Interconnect Network) messages and send them to the slave nodes on the LIN bus, slave ECUs on the LIN bus and master ECUs cannot be upgraded in parallel; to avoid upgrade failure due to excessive bus load, slave ECUs on the LIN bus cannot be upgraded in parallel.

[0080] These cloud configuration rules ensure that parallel write tasks are executed efficiently and reliably, provided that resource and transmission conditions are met.

[0081] Ultimately, the cloud generates upgrade tasks based on the ECU architecture topology.

[0082] like Figure 2 In the architecture diagram, the upgrade task includes a self-upgrading component, a DOIP component, and a CAN component. CAN components 1 and 2 are both in CAN channel 1, therefore, they are upgraded serially; CAN components 3 and 4 are both in CAN channel 2, therefore, they are upgraded serially; while CAN components 1 and CAN components 3, being in different CAN channels, can be upgraded in parallel. The self-upgrading component, DOIP component 1, DOIP component 2, CAN channel 1, and CAN channel 2 constitute the five parallel lines for parallel upgrades in this architecture.

[0083] Step 2: Pre-installation environment verification and upgrade package download. The main download agent (MDA) performs pre-installation environment verification to ensure that all ECUs meet the upgrade requirements. (If the upgrade requirements are not met after the upgrade package is downloaded, the upgrade process ends.) After receiving the configuration task, the MDA downloads the upgrade package. Specifically, the upgrade strategy is configured in the OTA platform's upgrade task module. The upgrade task is matched based on the vehicle's information. If the task is successfully matched, the task information and download address are sent through the OTA server.

[0084] The main download agent (MDA) has completed downloading the upgrade packages for each ECU.

[0085] With steps 1 and 2 completed as prerequisites, the parallel write process begins. The process includes:

[0086] (1) Self-upgrade software: The main download agent (MDA) can trigger self-upgrade directly or through an agent;

[0087] (2) Three-electric upgrade components: can be upgraded in parallel with other three-electric upgrade components;

[0088] (3) The flashing of DOIP and CAN components must follow the general UDS flashing specifications.

[0089] Step 3: Flash and upgrade the three-electric system components.

[0090] Step 3 as follows Figure 3 As shown, the first step is to flash and upgrade the three-electric system components. These components can be upgraded in parallel with other three-electric system components because they require pre-installation actions, such as power-on, before the upgrade can be performed. Therefore, parallel upgrades of the same type of ECU are more efficient. The flashing process consists of three stages: pre-programming, reprogramming, and post-programming.

[0091] Step 301. Pre-programming: Use the function addressing method to complete the pre-programming operation for all DOIP and CAN components.

[0092] First, the main download agent (MDA) sends a parallel flashing command to the diagnostic engine (DE). Upon receiving the command, the DE immediately checks the feasibility of the parallel rules and ECU classifications configured and issued by the OTA cloud platform upgrade management module. This check includes verifying whether the number of ECUs to be flashed in parallel exceeds a limit. This limit is predefined in the vehicle software (DE) and includes rules related to resources, network communication, and vehicle status. The check includes assessments of DE resources and bus load, as well as communication status, security, and dependencies. The method involves sending a UDS command and receiving a response for confirmation. If the conditions are met, the DE sends a pre-programming command to the DE-UDS pre-programming module. The DE-UDS pre-programming module automatically sets the pre-programming timeout based on the ECU type and the scale of the parallel task.

[0093] After the pre-programming test is passed, the corresponding instructions are transmitted to each ECU for pre-programming, so that the target ECU enters the state of being ready to receive new software.

[0094] The pre-programming process is as follows: First, target ECUs are brought into an extended session in batches via function addressing; secure access is granted to unlock flashing permissions; non-diagnostic communication of all target ECUs is disabled via function addressing; programming conditions are then checked and memory is erased; after pre-programming is completed, the target ECUs enter a "ready" state, ready to download the upgrade package, and report their acceptable data block length parameters, preparing for the parallel reprogramming phase. If any ECU pre-programming fails, a failure report containing specific error codes is output, and the DE determines the subsequent process. Finally, the data transmission parameters returned by the ECU are requested and retrieved.

[0095] Specifically, there are two follow-up procedures:

[0096] (1) If it is an OTA process, if the ECU pre-programming fails, the OTA program collects the error code and reports it to the cloud, restoring the vehicle to its state before the upgrade and notifying the owner to end the process.

[0097] (2) If it is a UDS flashing process, it shall be performed in accordance with the OEM flashing specifications. For example, a reset action may be performed if the ECU pre-programming fails.

[0098] Step 302. Reprogramming: After successful pre-programming, upon receiving the target ECU entering the "ready" state, along with the pre-programmed output ECU ready list, data transmission parameters for each ECU (such as maximum data block length), and downloaded upgrade package data, reprogramming is triggered. This is processed in parallel using multi-threading, with each thread responsible for one electric drive upgrade component or one CAN channel. Electric drive upgrade components within a single CAN channel are flashed serially, while those within different CAN channels are flashed in parallel. The parallel reprogramming flashing phase is complete after all electric drive upgrade components for all ECUs within all CAN channels have completed the reprogramming stage.

[0099] Furthermore, after completing the pre-programming process, DE begins sending data packets to each ECU in parallel. The ECUs receive the data and sequentially enter the reprogramming stage. At this point, the DE-UDS reprogramming module manages the ECU reprogramming process, initiating reprogramming tasks for different ECUs at different times.

[0100] Step 303. Post-programming: After the reprogramming phase is successfully completed, DE triggers the post-programming process. Using function addressing, programming operations are performed on all DOIP and CAN components.

[0101] Specifically, this includes: initiating the ECU's internal verification routine via the UDS command to verify the integrity of the new software image, updating the software version number and other information in the ECU to the new version, revoking the communication prohibition command from the pre-programming stage to restore normal network communication for the ECU, switching back to the default diagnostic session, and exiting programming mode. The ECU software version is read via the UDS command and compared with the expected value to ensure consistency. The ECU self-test routine is then initiated to confirm its normal function. Finally, the ECU is reset and its ability to re-enter online and respond to diagnostic requests is verified.

[0102] Step 4: Perform parallel upgrades on the self-upgrading component, DOIP component, and CAN component.

[0103] After upgrading the three-electric upgrade components, the non-three-electric upgrade components such as self-upgrading components, DOIP components, and CAN components are flashed and upgraded.

[0104] like Figure 3 As shown, parallel upgrade operations include task scheduling and allocation, resource management, state management, process lifecycle control, exception handling, and degradation. Parallel processing is achieved through multi-threading, with each thread responsible for one DOIP component or one CAN channel. The DE-UDS reprogramming module manages the ECU reprogramming process, initiating reprogramming tasks for different ECUs at different times. The entire parallel flashing process is managed in terms of timing and state by DE's scheduling mechanism.

[0105] The entire parallel flushing process is managed by the DE scheduling mechanism, which oversees the timing, status, and resource management of the entire process. This includes parallel processing of the following upgrade steps:

[0106] Step 401. Instruction Issuance: The MDA first sends a parallel flash command to the DE, triggering the entire upgrade process.

[0107] Step 402. Policy Detection: After receiving the instruction, the DE first performs a policy detection for parallel flashing. This is used to evaluate the current vehicle status, network load, ECU dependencies, etc., to ensure that the conditions for parallel upgrade are met.

[0108] Step 403. Pre-programming: After the strategy detection is passed, the process enters the pre-programming stage. Corresponding instructions are transmitted to each ECU for pre-programming, preparing the target ECU to receive the new software.

[0109] Step 404. Parallel Reprogramming: After successful preprogramming, the target ECU is received as "ready" and a list of ready ECUs, including the preprogramming output, data transmission parameters for each ECU (such as maximum data block length), and downloaded upgrade package data are received. Then, reprogramming is triggered: multiple ECUs are divided into different groups and firmware data is written and updated simultaneously.

[0110] like Figure 3 As shown, DOIP component 1 and DOIP component 2 (ECUs connected via Ethernet diagnostic protocol) are flashed independently and in parallel.

[0111] Meanwhile, the ECUs on the CAN bus are also flashed in parallel by channel group. For example, CAN devices 1 and CAN devices 2 are executed serially as one group (because they share the same CAN channel), while CAN devices 3 and CAN devices 4 are executed serially as another group. These two CAN groups are executed in parallel with the previous DOIP groups.

[0112] Step 405. Post-programming: After completing the reprogramming steps for the target ECU upgrade, DOIP, and CAN non-electrical upgrade components, the post-programming process is triggered. The ECU's internal verification routine is started via the UDS command to verify the new software image is complete and error-free, update the software version number and other information in the ECU to the new version, revoke the communication prohibition command from the pre-programming stage, restore normal network communication to the ECU, switch back to the default diagnostic session, and exit programming mode. The ECU software version is read via the UDS command and compared with the expected value to ensure consistency. The ECU self-test routine is started to confirm its normal function. The ECU is reset and its ability to re-enter and respond to diagnostic requests is verified.

[0113] Step 5: End.

[0114] Furthermore, the fault tolerance mechanisms in steps 3 and 4 of this invention employ timeout protection. This mechanism reduces complexity by covering the entire process with a single timeout timer, while ensuring the reliability of the parallel flashing process. In the timeout protection mechanism for parallel flashing, this invention uses a global timeout timer to cover the entire flashing process. The main protection scenarios of this mechanism include: potential loss of subsequent instructions (such as installation instructions or instructions to query upgrade results) after the main download agent (MDA) sends the parallel flashing instruction to the diagnostic engine (DE), as well as communication failures. The timeout protection process is as follows:

[0115] Step 601: Start the timeout timer

[0116] After the diagnostic engine (DE) successfully receives the parallel flash command sent by the main download agent MDA, it starts a timeout timer. The estimated timeout duration can be determined based on actual testing (the initial value is approximately 10 minutes per component upgrade). This invention prevents a single global timeout timer from covering the entire flash cycle of pre-programming, reprogramming, and post-programming. Compared to traditional solutions that set timers separately for each stage or operation, this design greatly simplifies state management complexity and eliminates potential vulnerabilities caused by timer switching between stages, more effectively protecting against process freezes due to command loss or communication interruption. Subsequent command loss or communication interruption can also cause process freezes.

[0117] Step 602: Timer Reset

[0118] Whenever the diagnostic engine (DE) receives a successful response to an ECU flashing operation, i.e., when it receives a positive response from the ECU after ECU Reset (0x11) or a subsequent Tester Present (0x3E) response, it immediately resets the timeout timer to ensure that the flashing process proceeds in sequence. This prevents the entire upgrade process from being misjudged as timeout and terminated due to a legitimate but time-consuming operation of a single or partial ECU.

[0119] For example: The upgrade task performs OTA upgrades for four ECUs simultaneously, namely:

[0120] ECU_A (Gateway, large-capacity upgrade package, via CAN FD)

[0121] ECU_B (Infotainment Head Unit, Large Capacity Upgrade Package, via DOIP)

[0122] ECU_C (Body Controller, Medium-Capacity Upgrade Package, via CAN)

[0123] ECU_D (Radar module, small upgrade package, via CAN)

[0124] If the timeout period is set to 45 minutes, and ECU_C and ECU_D have completed their reprogramming, ECU_A has just finished its time-consuming reprogramming and sent its final TransferData response, while ECU_B is still transmitting data, then the timer is refreshed back to 45 minutes. If all ECUs have completed their programming, the upgrade is successful, and the timers for ECUs DE stop.

[0125] Step 603: Stop the timer

[0126] Normal Stop: During the flashing process, once all ECUs have completed programming and the flashing is confirmed to be successful, the timeout timer stops. Specifically, the global timeout timer stops only when all target ECUs have completed the programming phase and passed final confirmation (such as successful verification of the software version number, or the ECU responding to a diagnostic request after reset), marking the complete success of the upgrade process.

[0127] Timeout termination and handling (abnormal termination):

[0128] (1) Detection mechanism: The system detects timeout events through a timer and sets a timeout flag; the main loop of DE polls the flag to determine whether a timeout has occurred.

[0129] (2) Abort operation: Once the timeout occurs, DE will immediately abort all write tasks and start the rollback process.

[0130] (3) Rollback and recovery: For ECUs that have not been upgraded, they can be restored to their original functional state by restarting or executing the rollback routine.

[0131] (4) Status reporting and cleanup: DE generates a report containing error codes and detailed status and uploads it to the cloud. Specifically, the error codes and detailed status are uploaded to the vehicle management module of the OTA platform; and all system resources are released, and the upgrade process is finally terminated.

[0132] The above technical solution is only one embodiment of the present invention. For those skilled in the art, based on the principles disclosed in the present invention, it is easy to make various types of improvements or modifications, and not limited to the technical solutions described in the specific embodiments of the present invention. Therefore, the foregoing description is only preferred and not restrictive.

Claims

1. A vehicle OTA parallel upgrade method, which flashes and upgrades the self-upgrade component of the electronic control unit (ECU), the diagnostic communication protocol component based on the Internet protocol, and the controller area network component, characterized in that: The method includes: Step 0: Before upgrading, clarify the parallel rules and the classification of electronic control unit (ECU) upgrade parts; Step 1: Configure upgrade tasks according to parallel rules; Step 2: The main download agent verifies the pre-installed environment and downloads each upgrade package; Step 3: Flash and upgrade the three-electric upgrade components in the diagnostic communication protocol based on Internet Protocol and the controller local area network component; Step 4: Perform parallel upgrades on the self-upgrade components, the diagnostic communication protocol components based on Internet Protocol, and the non-electrical upgrade components in the controller area network components; Step 5, upgrade complete.

2. The vehicle OTA parallel upgrade method according to claim 1, characterized in that: The parallel rules include: diagnostic communication protocol components based on Internet protocols and controller area network components where the three-electric upgrade components cannot be upgraded in parallel with non-three-electric upgrade components and must be upgraded first; electronic control unit (ECU) upgrade components within the same local area network channel are processed serially, while ECU upgrade components within different local area network channels are processed in parallel; if there are related components in the upgrade list, the relationship is defined through a pre-configured dependency tree, and if any related component fails to upgrade, other components that depend on it immediately stop the current upgrade and trigger a rollback.

3. The vehicle OTA parallel upgrade method according to claim 2, characterized in that: Step 1 includes: Step 101: Determine the parallel upgrade strategy based on the electronic control unit (ECU) topology; Step 102: Configure the parallel upgrade strategy and upgrade task according to the parallel rules; Step 103: Generate an upgrade task based on the Electronic Control Unit (ECU) topology.

4. The vehicle OTA parallel upgrade method according to claim 3, characterized in that: Step 101 includes: Step 1011: Identify the key components for the upgrade; Step 1012: Analyze the connection method between the Electronic Control Unit (ECU) and the User Connection Unit, including: the self-upgrading component is connected to the User Connection Unit via USB cable or Ethernet; the diagnostic communication protocol component based on Internet Protocol is connected to the User Connection Unit via Ethernet; and the Controller Area Network (CAN) component is connected to the User Connection Unit via CAN channel. Step 1013: Classify the upgrade components of each electronic control unit (ECU) in the topology and divide the local area network channels where each ECU is located.

5. The vehicle OTA parallel upgrade method according to claim 4, characterized in that: The parallel upgrade strategy also includes setting conditions that prohibit parallel upgrades: Electronic control units (ECUs) on the same local area network channel cannot be upgraded in parallel; slave node ECUs and master node ECUs on the LIN bus cannot be upgraded in parallel; slave node ECUs on the LIN bus cannot be upgraded in parallel with each other.

6. The vehicle OTA parallel upgrade method according to claim 4 or 5, characterized in that: Step 3 includes: Step 301: Using the function addressing method, program all the three-electric upgrade components of the target electronic control unit (ECU); Step 302: The reprogramming module manages the reprogramming process of the target electronic control unit (ECU) and sequentially initiates the reprogramming of the three-electric upgrade components in different electronic control units (ECUs). Step 303: Using the function addressing method, perform post-programming operations on the three-electric upgrade components of the target electronic control unit (ECU).

7. The vehicle OTA parallel upgrade method according to claim 6, characterized in that: Step 301 includes: Step 3011: The target electronic control unit (ECU) is brought into an extended session via function addressing; Step 3012: In the extended session, enter secure access to unlock write permissions; Step 3013: Disable non-diagnostic communication of all target electronic control units (ECUs) through function addressing; Step 3014: Check programming conditions and erase memory; Step 3015: Output the target electronic control unit (ECU) to enter the ready state; Step 3016: Obtain the data transmission parameters returned by the target electronic control unit (ECU).

8. The vehicle OTA parallel upgrade method according to claim 6, characterized in that: The reprogramming of the electronic control unit (ECU) is carried out in parallel through multi-threading, with each thread responsible for one local area network channel; The three-electric upgrade components within a single local area network channel are flashed serially, while the three-electric upgrade components in different local area network channels are flashed in parallel.

9. The vehicle OTA parallel upgrade method according to claim 8, characterized in that: Step 4 includes: Step 401: Send a parallel flash command to trigger the entire upgrade process; Step 402: After receiving the instruction, perform parallel flashing strategy detection and evaluate the current vehicle status, network load, and electronic control unit (ECU) dependencies. Step 403: Pre-program the self-upgrading components of the target electronic control unit (ECU), as well as the non-electric upgrade components in the diagnostic communication protocol based on Internet Protocol and the controller area network component. Step 404: The self-upgrade component of the target electronic control unit (ECU), as well as the non-electric upgrade components in the Internet Protocol-based diagnostic communication protocol component and controller area network component, enter the ready state, receive the data transmission parameters returned by the target electronic control unit (ECU), and reprogram using the downloaded upgrade package; Step 405: After all electronic control unit (ECU) self-upgrade components, as well as all Internet protocol-based diagnostic communication protocol components and non-electrical upgrade components in the controller area network components, have completed their reprogramming in sequence, the post-programming process is executed.

10. The vehicle OTA parallel upgrade method according to claim 9, characterized in that: Steps 3 and 4 employ a timeout protection mechanism, using a global timeout timer to cover the entire flashing process; the timeout protection includes: Upon receiving the parallel write command, a global timeout timer is started; Upon receiving a successful response to an ECU flashing operation, the global timeout timer is immediately reset; Stop the global timeout timer, including: after all electronic control units (ECUs) are successfully flashed, stop the global timeout timer; if the global timeout timer determines that it has timed out, terminate all flashing tasks and start the rollback process.

Images