Atomization collaborative upgrading method, vehicle and system

Abstract

The invention provides an atomization collaborative upgrading method, a vehicle and a system, and belongs to the technical field of automotive electronics, and the method comprises the following steps: obtaining upgrading task metadata; the upgrade task metadata comprises a target electronic control unit list and a dependency relationship among the electronic control units defined in the list; generating snapshot data of each target electronic control unit based on the upgrade task metadata; based on the upgrade task metadata, executing an upgrade task composed of a plurality of upgrade sub-processes, and when each upgrade sub-process is executed, synchronously generating and storing log entries recording operation contents corresponding to the upgrade sub-processes; and if the execution of the upgrade task is stopped due to interruption, determining an execution interruption point based on the log entry after the vehicle end management unit resumes operation, and executing a recovery upgrade task based on the execution interruption point and the snapshot data. According to the invention, the security, reliability and traceability of the multi-ECU collaborative upgrading process are realized.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, and more specifically to an atomized collaborative upgrade method, vehicle, and system. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity technologies, the number and functional complexity of onboard electronic control units (ECUs) have increased dramatically, making over-the-air (OTA) updates a core means of achieving vehicle function iteration, performance optimization, and security vulnerability patching. Against this backdrop, ensuring coordinated, reliable, and secure upgrades to dozens or even hundreds of ECUs with complex dependencies within a vehicle has become a key technological challenge in the field of intelligent vehicles.

[0003] To address the aforementioned challenges, a common upgrade architecture is the "server-vehicle agent-ECU" approach. The vehicle's OTA management unit is typically responsible for downloading upgrade packages from the cloud server and flashing them sequentially or in parallel to each target ECU. During this process, existing technologies incorporate basic transaction management, logging, and simple rollback mechanisms, such as recording upgrade steps and attempting to revert to a previous version in case of upgrade failure, to ensure basic controllability and recoverability of the upgrade process.

[0004] However, existing technical solutions still have significant shortcomings when dealing with complex multi-ECU upgrade scenarios requiring high reliability and strong consistency: First, transaction management is weak, the modules in the upgrade process are coupled, atomicity guarantees are lacking, and the upgrade context is easily lost, making it difficult to accurately restore to a consistent state during rollback; second, the logging system is inadequate, with fragmented records and a lack of multiple backups and integrity checks, making it difficult to effectively trace the root cause after a failure; third, the execution scheduling and exception handling mechanisms are crude, failing to effectively distinguish the functional safety priorities of ECUs, lacking global consistency checks, and having insufficient fault tolerance and recovery capabilities in abnormal scenarios such as power outages and network interruptions. These technical shortcomings make existing solutions unable to meet the upgrade requirements of intelligent vehicles for multiple ECUs, high dependence, strong security, and high reliability in terms of security, reliability, and traceability. Therefore, there is an urgent need for a clear, collaborative, efficient, and secure OTA upgrade end-to-end implementation solution. Summary of the Invention

[0005] In view of this, it is necessary to provide an atomic collaborative upgrade method, vehicle, and system to address the technical problems of insufficient security, reliability, and traceability in multi-ECU collaborative upgrade scenarios in the existing technology.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides an atomized collaborative upgrade method, executed by a vehicle, the method comprising:

[0007] Obtain upgrade task metadata; the upgrade task metadata includes a list of target electronic control units and the dependencies between the electronic control units defined in the list; Snapshot data of each target electronic control unit is generated based on the upgrade task metadata; Based on the upgrade task metadata, an upgrade task consisting of multiple upgrade sub-processes is executed, and log entries corresponding to each upgrade sub-process are generated and stored synchronously during the execution of each upgrade sub-process. If the execution of the upgrade task is interrupted, after the vehicle-side management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

[0008] In one possible implementation, generating snapshot data for each target electronic control unit based on the upgrade task metadata includes: Verify the metadata of the upgrade task; The verified upgrade task metadata is parsed to obtain a list of target electronic control units and the dependencies between the target electronic control units in the list; Based on the dependency relationship, the current state information generated by the interaction with the target electronic control unit is obtained, and the corresponding snapshot data is generated according to the current state information.

[0009] In one possible implementation, verifying the upgrade task metadata includes: Based on the pre-set server public key, the digital signature of the upgrade task metadata is verified. If the digital signature verification is successful, it is determined that the upgrade task metadata has passed the legality and integrity verification. Based on preset field format rules, the preset fields in the upgrade task metadata are verified. If each preset field exists and its format conforms to the field format rules, the upgrade task metadata is determined to have passed the data format verification. Based on the target electronic control unit list and the dependencies, it is detected whether there is a circular dependency path with a length not exceeding a preset threshold. If no circular dependency path is detected, it is determined that the upgrade task metadata has passed the logical verification.

[0010] In one possible implementation, obtaining the upgrade task metadata includes: Receive the request header sent by the upgrade server, and parse the request header to determine the content length; If the length of the content exceeds a preset threshold, the network connection with the server will be terminated. If the length of the content does not exceed a preset threshold, the upgrade task metadata is obtained by concatenating the request header and stored in a pre-allocated buffer.

[0011] In one possible implementation, the execution of an upgrade task consisting of multiple upgrade sub-processes based on the upgrade task metadata includes: Based on the upgrade task metadata, obtain the upgrade image data corresponding to the target electronic control unit; Based on the aforementioned dependencies, the upgrade execution order for each of the target electronic control units is determined; For each target electronic control unit, the upgrade sub-processes are executed sequentially according to the upgrade execution order to complete the upgrade task: downloading the corresponding upgrade image data, erasing the target storage partition, writing the upgrade image data, and verifying the written data.

[0012] In one possible implementation, downloading the corresponding upgrade image data includes: Send a download request for a specific data block to the upgrade server; Receive response information from the upgrade server corresponding to the download request, the response information including the specific data block, the hash value of the specific data block and its digital signature; Perform hash verification and signature verification on the received specific data block; If both the hash verification and signature verification pass, the download of the specific data block is confirmed to be successful. The download of the upgrade image data is completed when all data blocks corresponding to the upgrade image data are confirmed to have been successfully downloaded.

[0013] In one possible implementation, the synchronous generation and storage of log entries corresponding to the upgrade sub-process includes: After completing an upgrade sub-process, a log entry conforming to the corresponding predefined format is generated based on the operation type of the upgrade sub-process, the identifier of the target electronic control unit, and the execution result. Write the log entries and their integrity check codes into the non-volatile storage area.

[0014] Secondly, the present invention also provides an atomic collaborative upgrade method, executed by a server, the method comprising: Generate upgrade task metadata, which includes a list of target electronic control units and the dependencies between the electronic control units in the list; The upgrade task metadata is sent to the vehicle management unit of the target vehicle, so that the vehicle management unit generates snapshot data of each target electronic control unit based on the upgrade task metadata, executes an upgrade task consisting of multiple upgrade sub-processes based on the upgrade task metadata, and synchronously generates and stores log entries corresponding to each upgrade sub-process during execution; if the execution of the upgrade task is interrupted, after the vehicle management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

[0015] Thirdly, the present invention also provides a vehicle, the vehicle including an electronic control unit and a vehicle-side management unit, the vehicle-side management unit being used to implement the steps in the atomic collaborative upgrade method described in the first aspect.

[0016] Fourthly, the present invention also provides an atomized collaborative upgrade system, including a server and the vehicle described in the third aspect.

[0017] The beneficial effects of this invention are as follows: The atomic collaborative upgrade method provided by this invention first decomposes the upgrade task into a series of sequentially executed upgrade sub-processes, breaking down the complex upgrade task into the smallest unit that can independently succeed or fail. During the execution of each upgrade sub-process, log entries recording the corresponding operation content of the upgrade sub-process are generated and stored synchronously. Thus, when any upgrade sub-process fails (e.g., due to power failure), the system can accurately locate the last successful upgrade sub-process through the logs, thereby determining the execution interruption point. Only for the incomplete or failed ECU, the upgrade task is rolled back and restored based on the execution interruption point and snapshot data, achieving atomic upgrades and precise rollback, improving the success rate of vehicle upgrades and system reliability. Furthermore, through dependency-driven collaborative scheduling, efficiency is optimized and functional safety is ensured: the upgrade task metadata includes the dependencies between ECUs (including the dependent ECU and the dependent ECU). The TMU can process ECU download tasks without dependencies in parallel, while simultaneously performing serial scheduling for ECUs with dependencies, making reasonable use of network and bus resources, avoiding system functional disorders or security risks caused by missing dependencies during the upgrade process, and transforming multi-ECU upgrades from chaotic concurrency to orderly collaboration. In this way, when an anomaly occurs during the upgrade process or a replay is needed, operations and maintenance personnel can accurately reconstruct the actual operation content and context of each upgrade sub-process based on log entries and dependencies, and quickly locate the cause of the upgrade anomaly. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A schematic flowchart of an embodiment of the atomized collaborative upgrade method provided by the present invention; Figure 2 For the present invention Figure 1 A schematic diagram of an embodiment of S102; Figure 3 For the present invention Figure 2 A schematic diagram of an embodiment of S201; Figure 4 For the present invention Figure 1 A schematic diagram of an embodiment of S101; Figure 5 This is a schematic diagram of a process for performing an upgrade task according to an embodiment of the present invention; Figure 6 This is a schematic diagram of an embodiment of the process of downloading and upgrading image data according to the present invention; Figure 7 This is a schematic diagram of an embodiment of the present invention that synchronously generates and stores log entries corresponding to the upgrade sub-process; Figure 8 A schematic diagram of an embodiment of the electronic device provided by the present invention; Figure 9 A schematic flowchart of an embodiment of the transaction initialization module provided by the present invention; Figure 10 A schematic flowchart of an embodiment of the log management module provided by the present invention; Figure 11 This is a schematic flowchart of an embodiment of the upgrade execution module provided by the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0022] The terms "first," "second," etc., used in the embodiments of this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a technical feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] Before demonstrating the embodiments, the following terms will be explained.

[0025] OTA (Over-The-Air) refers to sending data packets from a remote server to a terminal device (such as a car or mobile phone) via a mobile communication network (such as 4G / 5G) or wireless connection such as Wi-Fi to update or repair software, firmware, configuration, or even autonomous driving maps.

[0026] The TMU (Telematics Management Unit) is located inside the vehicle and is the central in-vehicle coordination and safety controller responsible for managing and executing the entire OTA upgrade process.

[0027] An ECU (Electronic Control Unit) is an embedded system, a microcomputer in a vehicle that controls one or more electrical systems or subsystems.

[0028] This invention provides an atomized collaborative upgrade method, vehicle, and system, which are described below.

[0029] Figure 1 This is a schematic flowchart of an embodiment of the atomized collaborative upgrade method provided by the present invention, executed by a vehicle, such as... Figure 1 As shown, the atomized collaborative upgrade method includes: S101. Obtain upgrade task metadata; the upgrade task metadata includes a list of target electronic control units and the dependencies between the electronic control units defined in the list.

[0030] It should be noted that the TMU, as the core coordinator of the upgrade transaction, initiates the upgrade initialization process. The TMU includes the Transaction Initialization Module (TIM), the Log Management Module (LMM), and the Upgrade Execution Module (UEM). The TIM establishes a connection with the cloud OTA server via the vehicle Ethernet, receives and stores the upgrade task metadata issued by the server. The upgrade task metadata is a JSON format string, which includes a list of target electronic control units (ECUs) (ecu_list) and dependencies. The upgrade task metadata may also include other fields, such as the target version of each ECU and the download address of the upgrade image.

[0031] S102. Generate snapshot data for each target electronic control unit based on the upgrade task metadata.

[0032] It should be noted that before the upgrade process is started, TIM generates a complete snapshot of the pre-upgrade state for each target ECU in the vehicle as snapshot data. The snapshot data includes the current state of the ECU or the pre-upgrade state, such as the current version, hardware version, and currently active partition.

[0033] S103. Based on the upgrade task metadata, execute the upgrade task consisting of multiple upgrade sub-processes, and synchronously generate and store log entries corresponding to each upgrade sub-process when executing each upgrade sub-process.

[0034] It should be noted that the upgrade task is broken down into a series of sequentially executed upgrade sub-processes. During the execution of each upgrade sub-process, LMM creates detailed log entries in real time and stores them in a log file. These log entries typically include fields such as timestamp, upgrade sub-process ID, upgrade sub-process name, operation object, execution result (including success or failure), and detailed message.

[0035] S104. If the execution of the upgrade task is interrupted, after the vehicle management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

[0036] It should be noted that: Assume that the vehicle experiences an unexpected power outage during the upgrade task. When the vehicle is powered back on and the TMU restarts, the recovery process is automatically triggered. The LMM reads the log file in the eMMC storage and verifies the integrity of all log entries using a CRC checksum. It then sequentially parses the log entries to pinpoint the point of interruption in the upgrade task. Using this interruption point as a new starting point, the upgrade task is re-enabling itself based on snapshot data to re-download the upgrade.

[0037] In summary, the atomic collaborative upgrade method provided by this invention first decomposes the upgrade task into a series of sequentially executed upgrade sub-processes, breaking down the complex upgrade task into the smallest unit that can independently succeed or fail. During the execution of each upgrade sub-process, log entries recording the corresponding operation content are generated and stored synchronously. Thus, when any upgrade sub-process fails (e.g., due to power failure), the system can accurately locate the last successful upgrade sub-process through the logs, thereby determining the execution interruption point. Only for incomplete or failed ECUs, the upgrade task is rolled back and restored based on the execution interruption point and snapshot data, achieving atomic upgrades and precise rollback, improving the success rate of vehicle upgrades and system reliability. Furthermore, by using dependency-driven collaborative scheduling, efficiency is optimized and functional safety is ensured: the upgrade task metadata includes dependencies between ECUs (including dependent ECUs and dependent ECUs). The TMU can process ECU download tasks without dependencies in parallel, while simultaneously performing serial scheduling for ECUs with dependencies, making reasonable use of network and bus resources, avoiding system functional disorders or security risks caused by missing dependencies during the upgrade process, and transforming multi-ECU upgrades from chaotic concurrency to orderly collaboration. In this way, when an anomaly occurs during the upgrade process or a replay is needed, operations and maintenance personnel can accurately reconstruct the actual operation content and context of each upgrade sub-process based on log entries and dependencies, and quickly locate the cause of the upgrade anomaly.

[0038] In some embodiments of the present invention, such as Figure 2 As shown, Figure 2 As shown, step 102 includes: S201. Verify the metadata of the upgrade task; S202. Parse the verified upgrade task metadata to obtain a list of target electronic control units and the dependencies between the target electronic control units in the list; S203. Based on the dependency relationship, obtain the current state information generated by interacting with the target electronic control unit, and generate the corresponding snapshot data according to the current state information.

[0039] It should be noted that: TIM verifies the acquired upgrade task metadata according to S301 to S303 of the following embodiments. TIM parses the verified upgrade task metadata to obtain the target electronic control unit list (ecu_list) and the dependencies between the various target electronic control units contained in the ecu_list. Then, TIM obtains the status acquisition order based on the dependencies and communicates with each target ECU sequentially according to the status acquisition order through the vehicle SOME / IP protocol, thereby collecting the current status information generated by the interaction with the target ECU (such as ECU ID, timestamp, version information, hash value, partition information, etc.). Based on the current status information, TIM generates unique and tamper-proof snapshot data of the ECU's state before the upgrade.

[0040] In this embodiment, the acquired upgrade task metadata needs to be verified before the upgrade is executed, ensuring the credibility of the entire upgrade process and improving the overall security of OTA upgrades. Furthermore, by systematically collecting and storing the current state information of each ECU according to its dependencies before the upgrade is executed, generating corresponding snapshot data, when some ECUs fail during the upgrade process, the problematic ECUs can be accurately and quickly restored to the historical state (same version and configuration) recorded in the snapshot data, without affecting other successfully upgraded ECUs, greatly improving the reliability and availability of vehicle upgrades.

[0041] In some embodiments of the present invention, such as Figure 3 As shown, step S201 includes: S301. Based on the preset server public key, verify the digital signature of the upgrade task metadata. If the digital signature verification is successful, determine that the upgrade task metadata has passed the legality and integrity verification.

[0042] It should be noted that after completing the TLS 1.3 secure handshake with the OTA server, TIM receives upgrade task metadata in JSON format. TIM first calls the cJSON library to parse this string, locating and extracting the signature field. The signature field is a Base64 encoded string, which TIM decodes using the Base64 decoding function (mbedtls_base64_decode) into 256 bytes of raw binary data—the digital signature generated by the server using its private key. To ensure consistent verification, TIM sorts all key-value pairs in the metadata, except for the signature field, in ascending ASCII order by key name. These are then concatenated into a continuous string. Next, the SHA256 hash value of this string is calculated using the hash calculation function (mbedtls_sha256_update), resulting in a 32-byte first hash value, Hash_local. TIM then reads the pre-configured RSA public key corresponding to the OTA server from its own NOR Flash non-erasable secure storage area. The digital signature is decrypted using the public key verification function (mbedtls_pk_verify). Theoretically, the result of the RSA decryption operation should be the hash value of the data used to generate the signature on the server side, resulting in a second hash value, Hash_decrypted. TIM compares the second hash value, Hash_decrypted, byte-by-byte with the first hash value, Hash_local. If they match exactly, the digital signature verification passes, indicating that the validity and integrity verification has been successful. If they do not match, the digital signature verification fails.

[0043] S302. Based on preset field format rules, verify the preset fields in the upgrade task metadata. If each preset field exists and its format conforms to the field format rules, determine that the upgrade task metadata has passed the data format verification.

[0044] It's important to note that TMU has a pre-built validation rule base, which includes multiple field format rules. TIM then iterates through the parsed JSON object, performing existence and format matching checks on each preset field in the upgrade task metadata. For example, it uses regular expressions to validate the version number format and queries the whitelist to validate the domain name. It also checks if the field data type is correct (e.g., whether package_size is an integer). Only when all preset fields exist and their values ​​fully conform to the preset format rules is the data format validation considered successful. If any preset field is missing or has an invalid format, the data format validation fails, and a specific error code, such as a metadata format error, is returned.

[0045] S303. Based on the target electronic control unit list and the dependency relationship, detect whether there is a circular dependency path with a length not exceeding a preset threshold. If no circular dependency path is detected, determine that the upgrade task metadata has passed the logical verification.

[0046] It's important to note that TIM initializes a data structure (such as an adjacency list) in memory, creating a dependency graph with all ECU IDs in `ecu_list` as nodes. A directed edge is established between node B and node A in the dependency graph, indicating that B is dependent on A or A depends on B. Each dependency entry in the dependency graph is traversed, searching for cyclic dependency paths whose length does not exceed a preset threshold (e.g., length 3). For example, it checks for the existence of an edge A→B and B→A (a cycle of length 2), or A→B→C→A (a cycle of length 3). During the traversal and detection, if no cyclic path of length not exceeding the preset threshold is found, the logical verification is passed, indicating that the dependency graph is acyclic within a foreseeable path depth and can be topologically sorted, thus deriving a feasible linear upgrade order. Once a cyclic dependency path is detected, a specific error code is returned to indicate the existence of a cyclic dependency, and the upgrade task is terminated.

[0047] In this embodiment, digital signature verification in S301 ensures that every upgrade command received by the vehicle is non-repudiable and complete, reducing the risk of man-in-the-middle attacks, malicious servers issuing illegal commands, or data tampering during network transmission, thus improving upgrade security. Furthermore, field format verification in S302 prevents system crashes caused by format errors, improving robustness. Furthermore, circular dependency detection in S303 detects and rejects circular dependencies, avoiding logical deadlocks during upgrade execution due to unresolved ordering issues, thereby improving the success rate of complex multi-ECU upgrade tasks.

[0048] In some embodiments of the present invention, such as Figure 4 As shown, step S101 includes: S401. Receive the request header sent by the upgrade server and parse the request header to determine the content length.

[0049] It's important to note that TIM continuously listens on port 443 of the OTA server via the vehicle's Ethernet controller. When a TCP connection request from a whitelisted server IP is detected, a lightweight TCP / IP stack (such as LWIP) is used to complete a three-way handshake and establish a connection. After the connection is established, TIM begins receiving HTTP POST request header data pushed by the server. TIM reads the socket data in a loop until it detects the HTTP header end-of-line character (\r\n\r\n). The received request header data is temporarily stored in memory, with its maximum length limited to 16KB to prevent malicious long header attacks. TIM parses the request header to extract the value of the Content-Length field. This field represents the size of the request body (i.e., the part carrying JSON-formatted metadata) in bytes, in ASCII string form. TIM converts the Content-Length string value to an integer value to obtain the content length of the request data (Expected_Size).

[0050] S402. If the length of the content exceeds a preset threshold, terminate the network connection with the server. S403. If the length of the content does not exceed a preset threshold, the upgrade task metadata is obtained by concatenating the request header and stored in a pre-allocated buffer.

[0051] It's important to note that TIM compares the content length to a hard-coded preset threshold (e.g., 1 MB). If the content length exceeds this threshold, TIM immediately identifies it as an anomaly or a potential attack (such as an attempt to exhaust the vehicle's memory with an excessively large request body). As a defense, TIM does not receive any request body data but instead sends a TCP RST (reset) packet directly to the server via the socket, forcibly disconnecting the network connection. Simultaneously, TIM records an error code in its internal error log indicating that the request body is too large and reports this event. If the content length is less than or equal to the preset threshold, TIM enters the secure reception process. Because TCP is a streaming protocol, the request body data may arrive in multiple packets. TIM starts a loop, continuously reading data blocks (TCP segments) from the socket and concatenating them in the order they arrive until the cumulative number of bytes received equals the content length. TIM copies the concatenated upgrade task metadata to a pre-allocated, fixed-size memory buffer on the function stack. Subsequently, TIM uses this buffer as a data source for the S201 verification and parsing process.

[0052] In this embodiment, S401 to S402 identify and block any malicious attacks or abnormal server behaviors that attempt to exhaust the stack memory or processing resources by sending excessively large request bodies, ensuring the baseline stability and availability of the vehicle-side management unit under worst-case conditions. Furthermore, through S403's cyclic reception and splicing, TIM can reliably reconstruct the complete upgrade task metadata sent by the server from the streaming TCP connection. If the data is incomplete during transmission due to network anomalies, the reception logic will time out due to insufficient content length, preventing the incomplete data from being delivered to subsequent stages. This atomic reception prevents a chain reaction of parsing errors or security check bypasses that may be caused by processing incomplete or misaligned data, ensuring the first line of defense for data integrity in the entire upgrade transaction, guaranteeing data consistency and correct processing.

[0053] In some embodiments of the present invention, such as Figure 5 As shown, the upgrade task, which consists of multiple upgrade sub-processes, is executed based on the upgrade task metadata, including: S501. Based on the upgrade task metadata, obtain the upgrade image data corresponding to the target electronic control unit.

[0054] It should be noted that: UEM parses the metadata of the verified upgrade task and extracts the Uniform Resource Locator (package_url) field corresponding to each ECU. UEM calculates the total number of blocks based on the upgrade package size (package_size) and data block size in the metadata. UEM maintains a block status table in memory and eMMC for each ECU, recording the status of each data block, including not downloaded, downloading, download completed, and verification failed. UEM first reads the block status table, filters out all data blocks with the status of verification failed or not downloaded, and adds them to the download queue according to their sequence number. A multi-threaded mechanism is used, with each thread responsible for the download task of one ECU. An incomplete data block is taken from the download queue, and an HTTP GET request is sent to the server address pointed to by the Uniform Resource Locator. The request parameters include the transaction ID, ECU ID, and block sequence number. The server response contains the data block and its SHA256 hash value. After receiving the complete data block, UEM immediately calculates its hash value in memory and compares it with the hash in the response. If they match, the data block is written to the ECU's dedicated cache file in the eMMC, and the status of the data block in the block status table is updated to "completed." Simultaneously, the LMM records a log entry indicating successful data block download. If they do not match, the block status is marked as "verification failed," and it is added to the retry queue. After network interruption recovery, the UEM only needs to re-download data blocks that are not currently being downloaded, achieving efficient resuming of downloads.

[0055] S502. Determine the upgrade execution order of each target electronic control unit according to the dependency relationship.

[0056] It should be noted that: the topology sorting algorithm based on dependencies yields a linear ECU sequence, where all dependent ECUs of any ECU in the sequence appear before that ECU. The upgrade execution order of each target electronic control unit is determined based on the ECU sequence.

[0057] For example, if the dependency is that ECU_ADAS depends on ECU_POWER, then the generation order is ECU_POWER → ECU_ADAS.

[0058] S503. For each target electronic control unit, the upgrade sub-processes are executed sequentially according to the upgrade execution order to complete the upgrade task: downloading the corresponding upgrade image data, erasing the target storage partition, writing the upgrade image data, and verifying the written data.

[0059] It should be noted that: UEM executes a standardized four-step upgrade sub-process serially for each ECU in the ECU sequence according to the upgrade execution order determined in S502. This includes downloading the corresponding upgrade image data, erasing the target storage partition (using the currently active partition of the snapshot data to find the inactive partition as the target storage partition, usually the ECU's Flash memory partition, and erasing the data in the target storage partition to prepare a clean and defined state space for writing new upgrade image data later), writing the upgrade image data, and verifying the written data (verifying the upgrade image data written to the target storage partition to confirm that the writing process is completely correct and that the written data is completely consistent with the source image on the storage medium). Furthermore, LMM and UEM work together deeply throughout the entire S503 process. Before any of the above four upgrade sub-processes begins, log entries are pre-allocated. After the upgrade sub-process is completed successfully or unsuccessfully, the results (operation type, ECU ID, key parameters, status code) are atomically written to the log file, ensuring that the operation history is saved instantly and immutably.

[0060] In this embodiment, the dependency relationship is transformed into a definite upgrade execution order, realizing intelligent and automated orchestration of the upgrade process. This ensures that the dependent ECU (such as the powertrain) completes the upgrade before the dependent ECU (such as the autonomous driving module), eliminating the risk of functional chain breakage caused by human error in the upgrade order or concurrent execution. It ensures that at the moment the vehicle completes the upgrade, the functional interaction logic between all ECUs is in a coordinated and consistent new state, achieving a seamless and safe upgrade of the vehicle.

[0061] In some embodiments of the present invention, such as Figure 6 As shown, the download of the corresponding upgrade image data includes: S601, Send a download request for a specific data block to the upgrade server; S602. Receive response information returned by the upgrade server corresponding to the download request, the response information including the specific data block, the hash value of the specific data block and its digital signature; It should be noted that: The UEM constructs a download request for the specific data block to be downloaded, and sends this download request through an established TLS secure channel. The UEM receives the server's response to the download request, and after parsing the response, the UEM obtains at least three core fields, including: the specific data block, the hash value of the specific data block (i.e., the third hash value), and its digital signature. The UEM temporarily stores the specific data block in a receive buffer in memory.

[0062] S603. Perform hash verification and signature verification on the received specific data block; S604. If both the hash verification and signature verification pass, the specific data block is confirmed to have been successfully downloaded. The download of the upgrade image data is completed when all data blocks corresponding to the upgrade image data are confirmed to have been successfully downloaded.

[0063] It should be noted that: The UEM performs a hash calculation on the data block in the receive buffer to obtain a fourth hash value, and compares this fourth hash value with the third hash value parsed from the response information. If they do not match, it is determined that the data block has experienced a bit error or has been tampered with during transmission, and the hash verification fails. Conversely, if they match, the hash verification of this data block is considered successful. The UEM decodes the digital signature corresponding to the specific data block in the signature field of the response information to obtain the original digital signature data. Using the OTA server public key pre-installed in the vehicle's secure storage (such as HSM or security chip), it decrypts (or performs a signature verification operation) the digital signature data to obtain a decrypted fifth hash value. This fifth hash value is compared with the third hash value parsed from the response information (or the fourth hash value obtained by directly calculating the hash of the specific data block). If they do not match, it is determined that the response information does not come from a legitimate server and may be forged or subjected to a replay attack, and the signature verification fails. Conversely, if they match, the signature verification of this data block is considered successful. The UEM marks the status of the specific data block as "complete" in the block status table only if both hash verification and signature verification pass, and the UEM internally confirms that the data block was downloaded successfully. If either signature verification or hash verification fails, the UEM discards the copy of the specific data block in memory, records a failure log containing the specific error code, adds the specific data block to the retry queue, and attempts to download it again in a subsequent retry cycle. For each data block corresponding to the upgrade image data, the UEM repeats steps S601 to S604. The UEM determines that the upgrade image data for the ECU has been completely downloaded only if the status of all data blocks in the block status table corresponding to the ECU is "complete," thereby triggering the subsequent erase-write-verify upgrade sub-process for the ECU.

[0064] In this embodiment, dual verification through hash verification and signature verification in S603 establishes independent security verification for each data block, significantly improving the security of vehicle ECU upgrades. Furthermore, the upgrade image data download is completed only when all data blocks corresponding to the upgrade image data are confirmed to have been successfully downloaded, achieving atomic download status management. After a system restart, there is no need to re-verify successfully downloaded data blocks; only data blocks in the incomplete or failed state need to be downloaded. This greatly saves bandwidth and time, making the upgrade image data download process flexible and self-healing, automatically adapting to the unstable vehicle network environment, and significantly improving the overall success rate and efficiency of upgrade image data downloads.

[0065] In some embodiments of the present invention, such as Figure 7 As shown, the synchronous generation and storage of log entries corresponding to the upgrade sub-process includes: S701. After completing an upgrade sub-process, generate a log entry that conforms to the corresponding predefined format according to the operation type of the upgrade sub-process, the identifier of the target electronic control unit, and the execution result. S702. Write the log entry and its integrity check code into the non-volatile storage area.

[0066] It should be noted that after completing a specific upgrade sub-process, the UEM automatically constructs a log entry conforming to a predetermined data structure based on the operation category of the upgrade sub-process, the identifier of the specific electronic control unit (ECU ID) targeted, and the final execution result (including execution failure or success). When generating this log entry, the UEM calculates an integrity checksum based on the entire content of this log entry (including operation type, ECU ID, timestamp, execution result, etc.) using an algorithm. Subsequently, the UEM binds this log entry with its corresponding integrity checksum and persistently saves it to a non-volatile storage device through an indivisible write operation. That is, the write operation of a single log entry and its integrity checksum is an indivisible atomic operation.

[0067] In this embodiment, by breaking down the complex upgrade task into standard upgrade sub-processes and generating structured snapshot data for each sub-process, the upgrade process can be recorded completely and systematically. If the upgrade stops for any reason (such as power outage or network interruption), the TMU can accurately locate the last successfully verified and persistently recorded upgrade sub-process by parsing these log entries upon restarting. This ensures that the recovery process is no longer a vague restart or a complete rollback, but rather a precise continuation from the breakpoint, greatly improving upgrade efficiency and success rate. Furthermore, each log entry is accompanied by an integrity checksum calculated based on its content. During the recovery phase, the integrity of each log entry is first verified, effectively preventing incorrect recovery decisions based on erroneous or tampered log entry information and ensuring the reliability of the recovery process. Moreover, the binding and writing of individual log entries and their integrity checksums provides reliable breakpoint location and recovery capabilities for multi-ECU atomic upgrades, significantly improving the security and maintainability of the entire vehicle's OTA upgrade.

[0068] In summary, the above embodiments, Figure 8 A flowchart illustrating the OTA upgrade linkage between the transaction initialization module, log management module, and upgrade execution module, as follows: Figure 8As shown, the entire atomic collaborative upgrade process is broken down into a transaction initialization module (TIM), a log management module (LMM), and an upgrade execution module (UEM). Through close collaboration and data closure between modules, the transaction initialization module provides a global upgrade context and a snapshot of the original data, the log management module records key nodes and abnormal information throughout the process, and the upgrade execution module completes precise scheduling and full-process verification based on the context. This forms a collaborative mechanism that sets the baseline for initialization, traces the logs, and ensures the implementation of the upgrade, significantly improving the security, traceability, and fault tolerance of OTA upgrades, and adapting to the upgrade requirements of intelligent vehicles with multiple ECUs, high dependence, and strong security.

[0069] The Transaction Initialization (TIM) module includes a metadata parsing submodule and a snapshot management submodule. For example... Figure 9As shown, the metadata parsing submodule's parsing process includes receive preprocessing, encryption verification, field verification, and preliminary dependency verification. Specifically, receive preprocessing involves the TMU listening to the OTA server's port 443 via the vehicle's Ethernet (1000Mbps) and establishing a connection using a TCP / IP protocol stack (LWIP, adapted for embedded scenarios). After a three-way handshake confirmation, a TCP sliding window (window size = 65535 bytes) is opened to receive the HTTP POST request header (maximum 16KB) pushed by the server. The Content-Length field is parsed; if its value exceeds 1MB, an RST packet is sent to disconnect the connection, and error code 0x0007 (request body too large) is recorded. The TIM receives the request body data, concatenates it into a complete JSON string according to TCP segments, and stores it in a stack buffer (1MB in size to avoid heap memory fragmentation). Encryption verification involves first performing a TLS 1.3 handshake, then certificate verification, and finally signature verification. The TLS 1.3 handshake process includes the client (TMU) sending a ClientHello message (supporting cipher suites: TLS_AES_256_GCM_SHA384), receiving a ServerHello message, certificate chain, and a Finished message from the server. The certificate verification process includes reading the pre-installed server root certificate (X.509 format, PEM encoding) from NOR Flash (addresses 0x08000000-0x0800FFFF), verifying the integrity of the certificate chain (root certificate → intermediate certificates → server certificate), and checking the certificate validity period (system time obtained via onboard RTC, allowing ±30 days deviation), rejecting expired or revoked certificates. The signature verification process includes extracting the signature field (Base64 encoded) from the metadata and decoding it into a 256-byte RSA signature; sorting other metadata fields in ascending order by JSON key name and concatenating them into a string (e.g., chunk_size=102400&ecu_list=xxx&package_size=52428800...), calculating the SHA256 hash value (32 bytes); performing RSA decryption using the server's public key (2048 bits) stored in the non-erasable area of ​​NOR Flash, comparing the decryption result with the calculated SHA256 hash value, and returning an error code 0x0008 (indicating signature verification failure) if they do not match.

[0070] Field validation includes validating required fields and validating field formats. Specifically, the electronic control unit list (ecu_list) requires an array length of 1-100, where each element's electronic control unit identifier (ecu_id) must be a combination of letters, numbers, and underscores, with a length of 1-15, and the first character must be a letter (e.g., "ECU_POWER_001" is valid, "1_ECU" is invalid). The target version (target_version) must strictly adhere to the semantic versioning specification xyz, where x∈[0,9], y∈[0,99], z∈[0,999], and contain only numbers and decimal points (e.g., "v1.10.25" is valid, "v1.2.3.4" is invalid). In dependencies, each entry's dependent ECU (dependent_ecu) and base ECU (base_ecu) must exist in the ecu_list. Their minimum version format (min_version) must match the target version format (target_version), and min_version ≤ max_version (if max_version exists). The upgrade package Uniform Resource Locator (package_url) must begin with "https: / / ", have a domain name length ≤ 63 bytes, conform to DNS specifications (containing only letters, numbers, and hyphens, with first and last characters being letters or numbers), and the domain name must match the server whitelist stored in the TMU configuration file (e.g., "ota-server.com"). Format validation uses the cJSON library to parse the JSON string, checking field types (e.g., upgrade package size package_size should be an integer, data block size chunk_size should be an integer). If parsing fails or the types do not match, error code 0x0003 (metadata format error) is returned.

[0071] The initial dependency check specifically involves first checking the existence of dependent ECUs, followed by direct circular dependency detection. Dependency ECU existence check involves traversing the dependency array (dependencies array) and performing a hash lookup for each base_ecu in the hash table (key=ecu_id, value=index) constructed from ecu_list. If the lookup fails, error code 0x0004 (dependent ECU does not exist) is returned. Direct circular dependency detection involves constructing a temporary dependency table and checking for circular dependencies of length ≤3, such as A→B and B→A, or A→B→C and C→A. If such a circular dependency exists, error code 0x0201 (circular dependency) is returned.

[0072] In terms of hardware adaptation, for the AUTOSAR OS environment, the cJSON library is compiled as a static library and integrated into the AUTOSAR application layer software component (SWC). Memory allocation is implemented through the AUTOSAR memory management module (MemIf) to avoid directly calling malloc / free. For the Linux environment, dynamic memory allocation (malloc) is adopted, but memory is released immediately after each JSON object is parsed (cJSON_Delete) to avoid memory leaks. The memory allocation limit is set to 8KB, and an out-of-memory error is returned if the limit is exceeded.

[0073] The snapshot generation logic of the snapshot management submodule includes communication preparation, data reading, data processing, and storage writing. Specifically, the communication preparation involves the TMU creating a client using the SOME / IP protocol stack (using the vsomeip library), with the service name ECUInfoService (0x1234), instance ID 0x0001, and port 30500 (TCP). A service discovery request (SDRequest) is sent to the target ECU, with a timeout of 1 second. If no response is received, it retryes 3 times (500 milliseconds apart). If all retryes fail, error code 0x0701 (ECU not responding) is returned. After establishing the TCP connection, the TMU periodically (e.g., every 500 milliseconds) sends a heartbeat packet to maintain the connection. If no heartbeat response is received for 3 consecutive times, the connection is closed and reconnection is attempted. Data reading specifically involves a version query, which sends a SOME / IP request message (method ID 0x0001, no parameters). The response message returned by the ECU (status code 0x0000 indicates success) should carry the current version (current_version, string, 32 bytes), the hardware version (hw_version, string, 16 bytes), and the active partition (active_partition, string, 8 bytes). Then, a configuration query is performed, which sends a SOME / IP request message (method ID 0x0002) with a list of configuration item filters as parameters (e.g., filters for the power domain ECU: "control_threshold", "power_limit"). The configuration item key-value pairs returned by the ECU must have a key ≤ 32 bytes, a value ≤ 64 bytes, and a total number of configuration items ≤ 32 (to avoid excessive data volume). If the ECU returns a response status code other than 0x0000 (e.g., 0x0001 = parameter error, 0x0002 = insufficient permissions), the error code is recorded, and the system retryes twice. If it still fails, it returns 0x0702 (ECU data reading failed). Data processing involves first sorting the configuration parameters, followed by SHA256 calculation. Sorting the configuration parameters involves ranking the ASCII codes of the configuration item keys returned by the ECU in ascending order (e.g., "brake_response" → "control_threshold" → "power_limit") to ensure consistent hash results even when different ECUs return them in different orders. SHA256 calculation uses the SHA256 module of the mbedTLS library, initializes the context (mbedtls_sha256_init), updates the "key+value" string for each configuration item sequentially (e.g., "control_threshold=12.5"), and finally obtains a 64-byte hexadecimal string hash value.If it is an A / B partition ECU, the SOME / IP command (method ID 0x0003) is used to query the image information of the currently active partition, receiving the starting address (32-bit integer, such as 0x80000000) and size (32-bit integer, such as 0x00400000, which is 4MB), and storing it as a string format of "starting address_size" (such as "0x80000000_0x00400000"). If it is a single partition ECU, the TMU first checks whether a backup image of the ECU exists in the eMMC backup directory ( / ota_storage / backup / ); if it does not exist, the SOME / IP command (method ID 0x0004) is sent to instruct the ECU to upload the backup image via the TFTP protocol (port 69), with the storage path format " / ota_storage / backup / ECU_POWER_001_v1.0.0.bin" (containing the ECU_ID and version number).

[0074] The specific storage write process is as follows: first, serialization is performed; then, sector alignment is performed; and finally, file writing is performed. Specifically, the SnapshotInfo structure is first serialized in little-endian byte order, with the fields in the following order: snapshot_id → create_timestamp → config_hash → backup_image_ptr → backup_image_size → crc32. After serialization, the data length is fixed at 181 bytes. Since the eMMC sector size is 512 bytes, the 181 bytes of data are then padded to 512 bytes (ending with 0x00) to avoid cross-sector writes. Finally, the file is created using the open system call (example path: / ota_storage / snapshot / Snapshot_ECU_POWER_001_550e8400.info), permissions are set to 0600, the padded data is written, fsync is called to force a flush to ensure data persistence, and then the file is closed. When reading a snapshot, the first 512 bytes are read, the CRC32 field is extracted (offset 177-180 bytes), and the CRC32 value of the first 177 bytes is calculated and compared. If they do not match, the snapshot is considered corrupted. At this point, the system attempts to read the last backup snapshot (filename with "_bak" appended). If it exists and the verification passes, the backup is used; if it does not exist or is still corrupt, error code 0x0002 (snapshot corrupted) is returned, and an emergency rollback (using factory default configuration) is triggered.

[0075] like Figure 10As shown, the log management module includes a log writing submodule, a log parsing and breakpoint location submodule, and a log storage submodule. The upgrade process of the log writing submodule includes log entry construction, CRC32 calculation, file operations, writing, and disk flushing. Specifically, log entry construction involves defining a `LogEntry` structure, whose internal data unions are subdivided according to operation type to ensure compact memory layout. The data structure definitions for each operation type can be customized (e.g., including operation type, field definitions, and byte length). Field padding strictly follows 32-bit memory alignment rules and uses the compiler attribute directive `__attribute__((packed))` to prevent automatic compiler padding, thus ensuring the entire `LogEntry` structure is fixed at 256 bytes. CRC32 calculation explicitly excludes the `crc32` field itself (offset 227-242 bytes) from the structure, covering only the first 227 bytes (offset 0-226 bytes) to avoid circular dependencies. When converting the hash result to a hexadecimal string, use uppercase letters consistently (e.g., "1A2B3C4D") to avoid verification failures due to inconsistent capitalization. For file operations, i.e., log file creation, use the `chmod(fd, 0600)` command to set file permissions, ensuring only the TMU process (UID=1000) has read and write access, while other processes (such as the entertainment domain ECU process) have no access, thus preventing malicious tampering. To disable eMMC write caching, confirm the configuration using the `ioctl` command. Specifically, after sending the write mask setting command (MMC_CMD28), read the eMMC's OCR register (Operation Condition Register) to ensure the Write Cache Enable bit (WCE) is 0. If the eMMC hardware does not support the O_DIRECT flag (direct I / O flag, commonly found in older chips), it will be downgraded to using the O_SYNC flag (synchronous write), employing a strategy of calling `fsync` once every 10 log entries written to balance write performance and data reliability. Writing and flushing to disk must adhere to the write call timeout mechanism. The file descriptor is set to non-blocking mode using `fcntl(fd, F_SETFL, O_NONBLOCK)`, and the `select` function waits for a writable event with a timeout of 500 milliseconds to avoid indefinite blocking. After flushing to disk using `fsync`, the file size is read using the `stat` function to verify that the file size has increased by exactly 256 bytes after the write, ensuring that each log entry is written completely. The flushing status is queried by sending a status retrieval command (MMC_CMD13), with a 100-millisecond timeout for the eMMC response. If no response is received, a bus failure is considered, and after two retries, a write failure is returned.The exception handling during write and flush operations (refined error branches and fault recovery) includes: When write returns -1, different error codes are handled. If the error code is EINTR (interrupt), the signal is ignored and the write operation is re-executed to ensure atomicity. If the error code is EAGAIN (resource temporarily unavailable), it waits 100 milliseconds and retryes, up to 5 times. If it still fails, it switches to synchronous write mode (O_SYNC). If the error code is ENODEV (device not found), it is determined that the eMMC has fallen off or the bus is disconnected. An emergency log is recorded to the NOR Flash and a system restart is triggered. When fsync returns -1, fault classification is performed. If it is a level 1 fault (such as EIO), the current upgrade task is stopped immediately, and an emergency rollback is performed (prioritizing the recovery of the power domain and chassis domain ECUs). If it is a level 2 fault (such as ENOSPC), the archived logs are cleaned up to free up space, and then the flush is re-attempted. If successful, the upgrade continues; if it fails, a rollback is performed. If the current log file fails to write, an alternative log file is automatically created (with "_backup" appended to the filename), and writing continues in the alternative file. At the same time, the original file corruption event is recorded. After the upgrade is completed, this event log is uploaded to the OTA server for analysis.

[0076] The parsing process of the log parsing and breakpoint location submodule is as follows: Before opening the log file, read permissions are checked using the `access(log_file_path, R_OK)` command. If permissions are not granted, error code 0x0010 (log file read permission not available) is returned, and the permissions are attempted to be corrected using the `chmod` command (this operation only takes effect with root privileges). Then, the first 16 bytes of the file are read and checked against the predefined log file identifier "OTA_TMU_LOG_V1". If they do not match, the file is considered an invalid log file, and error code 0x0011 (invalid log file format) is returned. A batch read optimization strategy is adopted, that is, 16 log entries are read at a time (16 × 256 = 4096 bytes, adapted to eMMC page size) and stored in a memory buffer to reduce the number of I / O operations and improve parsing efficiency. The buffer uses a circular queue structure with a size of 64 log entries to avoid frequent memory allocation and release. The buffer is released immediately after parsing is completed. If a single log entry's CRC32 check fails, recovery is attempted using log redundancy information. This involves extracting key fields such as the transaction identifier (transaction_id) and electronic control unit identifier (ecu_id) from adjacent log entries and verifying their consistency with the failed entry. If they match, an attempt is made to repair the status field of the failed entry (this method only applies to scenarios where the status field is corrupted). When the cumulative number of invalid entries reaches 5, a log repair process is triggered. This involves creating a new log file, copying all valid entries to the new file, and then deleting the original corrupted file to ensure subsequent parsing proceeds normally. If the TMU restarts during the upgrade process and the log file is not properly closed (no end marker at the end of the file), it is considered a power outage interruption. In this case, the interruption point is determined as the operation step ID of the last successful log record incremented by 1. When recovering from the upgrade, all possible residual states from steps before the interruption point must be cleared first. If multiple log files exist (generated by log rotation), they are parsed sequentially in ascending order of file number. After merging all valid entries, the globally largest successful step ID is taken as the baseline for the interruption point. Once the breakpoint is confirmed, the global status variable of the TMU (current_step_id = breakpoint) is updated immediately, and this status is written to the temporary storage area of ​​the NOR Flash to avoid repeated log parsing after the TMU restarts.

[0077] The journal storage submodule formats the dedicated journal storage partition as an EXT4 file system, setting the block size to 4KB and the number of inodes to 1024 (to accommodate the maximum number of journal files), and reserving approximately 5% space (about 25.6MB) for bad block replacement. During formatting, the file system journaling function (journal=ordered) is enabled to ensure the consistency of file system metadata and prevent partition corruption due to power outages. The journal storage submodule periodically (at 2 AM daily) performs an eMMC bad block scan, which involves sending the card-specific data read command MMC_CMD19 (SEND_CSD) and the card identifier read command MMC_CMD20 (SEND_CID) via the multimedia card tool (mmcutils) to read the bad block list. When a new bad block is found and it is located in the data area of ​​a journal file, a file migration is triggered. This involves creating a new file, copying the valid data from the original file (excluding the location of the bad block) to the new file, deleting the original file, and updating the file path index. When the number of bad blocks exceeds 1% of the total number of blocks (approximately 5MB of storage space), an alarm message is sent to the OTA server, indicating that the eMMC needs to be replaced. The log storage submodule's cleanup strategy follows a priority order: first, expired archived logs are cleaned up (retained for 7 or 14 days depending on the policy); second, unused backup logs are cleaned up; and finally, the oldest normal logs are cleaned up when space is still insufficient. The cleanup operation can be triggered by two conditions: one is active triggering, which is to execute the cleanup task at 2:00 AM every day; the other is passive triggering, which is to trigger when the remaining space of the storage partition is ≤10% (approximately 51.2MB) during the log writing process. The cleanup process must ensure atomicity, that is, first mark the files to be deleted, delete them in batches, and then update the file system index to avoid file residue caused by interruption during the cleanup process. The backup mechanism is to back up critical logs (such as transaction start, commit, rollback, abnormal events, etc.) to the emergency log area (64KB) of NOR Flash in real time. Backup entries use a simplified format, retaining only core fields such as transaction_id, timestamp, event_type, and status to ensure that the cause of failure can still be traced in extreme cases (such as complete eMMC failure). When the NOR Flash backup log area is full, the oldest entries are overwritten in timestamp order to ensure that the latest critical events are not lost.

[0078] The log upload mechanism is triggered as follows: After a vehicle successfully completes an upgrade or rollback operation, the Vehicle Management Unit (TMU) proactively sends a log upload request to the OTA server for active reporting, using the HTTP POST method and setting the Content-Type to multipart / form-data to package and transmit the log file. When the system detects a serious anomaly, such as a corrupted log file or a threshold number of bad blocks in the eMMC storage, the TMU immediately uploads the relevant log fragments to the server for immediate analysis. The log transmission optimization strategy is as follows: To reduce bandwidth consumption on the vehicle network, the log file is compressed into gzip format before upload, with a compression ratio of approximately 3:1. For example, a 100MB original log file is compressed to approximately 33MB. To improve upload reliability and avoid resource waste, a resume function is supported. Before uploading, the TMU sends the hash value of the log file and the length of successfully uploaded data to the server; after verification, the server returns a starting position for resuming the upload, and the TMU will continue uploading the remaining portion from that position. The upload timeout is set to 30 seconds. If an upload times out or fails, the system will automatically retry, up to 3 times, with a 10-second interval between each retry. If all retries fail, the upload failure status will be recorded, and the system will attempt to upload again the next time the TMU starts.

[0079] like Figure 11As shown, the Upgrade Execution Module (UEM) includes a step decomposition submodule, a download management submodule, a flash control submodule, and a verification submodule. The step decomposition submodule standardizes the entire upgrade process into a series of finely manageable micro-steps (i.e., upgrade sub-processes). Each micro-step strictly defines the instruction interaction protocol, response verification standards, and exception handling procedures. Micro-steps include: downloading the corresponding upgrade image data, erasing the target storage partition, writing the upgrade image data and verifying the written data, as well as switching partitions and rolling back. The download management submodule is responsible for the secure and efficient download and cache management of the upgrade package data. Its core implementation logic is as follows: Based on the total upgrade package size (package_size) and fixed chunk size (chunk_size, typically 102400 bytes) provided in the upgrade metadata, the total number of data chunks is calculated using the formula: total_chunks = (package_size + chunk_size - 1) / chunk_size (rounded up). The system maintains a segmented status table in memory for each ECU and persists it to the eMMC, recording the status of each data block: 0 (not downloaded), 1 (downloading), 2 (downloading complete), 3 (verification failed). A dedicated cache directory (e.g., / ota_storage / package / ) is created for each ECU on the vehicle's eMMC.<ecu_id> Each downloaded data block is named in a fixed format (e.g., chunk_00000001.bin) and stored in this directory. The cache file permissions are strictly set to 0600 to ensure that only the TMU process can read and write, preventing tampering. Before downloading begins, the fallocate function pre-allocates all the necessary disk space for each ECU's cache file, effectively preventing download failures due to insufficient space. Before starting the download task, the system reads the persistent block status table and adds data blocks with statuses of 0 (not downloaded) or 3 (verification failed) to the download queue according to their sequence number. A multi-threaded parallel download strategy is adopted (e.g., up to 4 threads, corresponding to downloading data from 4 ECUs simultaneously). Each data block is immediately hash-verified after downloading. If the verification passes, its status is updated to 2 (download complete) and logged; if the verification fails, its status is updated to 3 and added to the retry queue. When the network connection is restored after an interruption, the system rereads the status table, only downloading data blocks with statuses of 0 or 3, skipping completed blocks with status 2, thus achieving breakpoint resumption. The system monitors the download speed in real time (calculated every 500 milliseconds). If the download speed remains below 10KB / s for 3 consecutive seconds, automatic countermeasures will be taken, such as switching to other download nodes provided by the server or reducing the number of concurrent download threads (down to a minimum of 1 thread).The system supports users pausing downloads; upon receiving a pause command, it will stop requesting new data blocks, wait for the currently downloading block to complete, update the status table, and record the pause log so that it can resume downloading from the exact breakpoint the next time it starts.

[0080] The flashing control submodule manages the bus interaction details with the ECU, ensuring the stability and reliability of the flashing process. Specifically, the service discovery phase uses UDP multicast (address 224.0.0.180, port 30490) with a 1-second discovery period and a 3-second timeout. To improve transmission efficiency, request and response parameters are serialized using Protobuf format, reducing bandwidth usage by more than 30% compared to JSON. To maintain connection activity, after the TCP connection is established, the TMU sends a heartbeat message (empty message, method ID 0xFFFF) to the ECU every 500 milliseconds. The ECU returns a response every 3 heartbeats received; if the TMU does not receive a response, the connection is considered broken. To prevent bus overload, only a maximum of two ECUs are allowed to be flashed simultaneously on the same physical bus (e.g., CAN FD), ensuring the bus load does not exceed 70%. Simultaneously, the interval for sending flashing commands is controlled: no less than 10 milliseconds on the CAN FD bus and no less than 1 millisecond on the Ethernet bus, to ensure the ECU has sufficient time to process each command. If a bus error (such as a CRC check error or data frame loss) is detected during the flashing process, the flashing is immediately paused, a bus reset command is sent, and a retry is attempted after 100 milliseconds, with a maximum of 3 retries. If the flashing still fails, a rollback is triggered. If the ECU unexpectedly goes offline during flashing (no response for 3 consecutive seconds), the TMU will attempt to wake the ECU via a wake-up line or network wake-up command. Once the ECU is back online, the connection is re-established, and execution resumes from the interrupted steps to support ECU offline recovery.

[0081] The verification submodule implements multi-layered data verification to ensure the integrity and security of the upgrade content. Specifically, after each 100KB data block is downloaded, its hash value is immediately calculated using the `mbedtls_sha256_update` function of the `mbedTLS` library, avoiding excessive memory consumption caused by loading the entire large file at once. After all data blocks have been downloaded, the hash calculation results of each block are merged in sequence according to their block numbers, ultimately obtaining the full hash value of the entire image file. This value is compared with the `ecu_image_hash` field provided in the upgrade package metadata to verify the integrity of the downloaded data.

[0082] The `mbedtls_base64_decode` function from the `mbedTLS` library decodes the Base64 encoded signature returned by the ECU into 256 bytes of raw signature data. A pre-configured server public key (PEM format) is read from NOR Flash, loaded using the `mbedtls_pk_parse_public_key` function, and then the signature is verified using the `mbedtls_pk_verify` function (specifying the SHA256 hash algorithm). The signature data embeds a mirror hash and a generation timestamp. During signature verification, the timestamp is also checked, requiring its deviation from the current system time to be within 24 hours, effectively preventing attackers from reusing old, legitimate signatures for replay attacks. The system traverses the dependency graph defined in the upgrade metadata. For each dependency entry (dependent_ecu -> base_ecu), it checks whether the target version of the dependent ECU (dependent_ecu) meets the version constraints of the dependent ECU (base_ecu), meaning the actual version of base_ecu must be within the range defined by `min_version` and `max_version` to achieve dependency verification. After the upgrade is complete, pre-set cross-ECU functional test cases are executed (for example, the power domain ECU sends a simulated acceleration command to verify whether the chassis domain ECU can correctly return the braking response). The execution results of the test cases are fed back to the TMU via the SOME / IP protocol. If any test fails, a compatibility issue is identified, and a system rollback is triggered to achieve functional interaction verification.

[0083] This invention divides the OTA upgrade system into three independent modules: transaction initialization, log management, and upgrade execution, clearly defining the responsibilities of each module and their inter-module linkage logic. A full-link collaborative working mechanism is constructed, centered on initialization as a baseline, log traceability, and execution implementation. A triple security system is designed, including ECU snapshots, full-process log backup, and global consistency verification. Task scheduling based on ECU priority and a precise anomaly rollback mechanism are implemented, forming a closed-loop control. By introducing multiple verifications and a precise rollback mechanism, the security of the upgrade process is significantly improved, effectively mitigating the risk of vehicle malfunctions. Full-process log recording and backup greatly enhance system traceability, making fault paths clearly traceable. Priority scheduling and breakpoint resume technology optimize execution efficiency in scenarios with high multi-ECU dependency. Through module decoupling and data closed-loop design, the reliability of the system architecture is improved, and subsequent maintenance costs and compatibility risks are reduced.

[0084] The present invention also provides an atomic collaborative upgrade method, executed by a server, the method comprising: Generate upgrade task metadata, which includes a list of target electronic control units and the dependencies between the electronic control units in the list; The upgrade task metadata is sent to the vehicle management unit of the target vehicle, so that the vehicle management unit generates snapshot data of each target electronic control unit based on the upgrade task metadata, executes an upgrade task consisting of multiple upgrade sub-processes based on the upgrade task metadata, and synchronously generates and stores log entries corresponding to each upgrade sub-process during execution; if the execution of the upgrade task is interrupted, after the vehicle management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

[0085] To better implement the atomized collaborative upgrade method in this embodiment of the invention, based on the atomized collaborative upgrade method, this embodiment of the invention also provides a vehicle, which includes an electronic control unit and a vehicle-side management unit, the vehicle-side management unit being used to implement the above... Figures 1 to 7 The steps in the described atomized collaborative upgrade method.

[0086] This invention also provides an atomized collaborative upgrade system, including a server and the aforementioned vehicle.

[0087] The atomized collaborative upgrade system provided in the above embodiments can realize the technical solutions described in the above atomized collaborative upgrade method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above atomized collaborative upgrade method embodiments, and will not be repeated here.

[0088] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0089] The atomized collaborative upgrade method, vehicle, and system provided by this invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. An atomized collaborative upgrading method, characterized in that, Performed by the vehicle, the method includes: Obtain upgrade task metadata; the upgrade task metadata includes a list of target electronic control units and the dependencies between the electronic control units defined in the list; Snapshot data of each target electronic control unit is generated based on the upgrade task metadata; Based on the upgrade task metadata, an upgrade task consisting of multiple upgrade sub-processes is executed, and log entries corresponding to each upgrade sub-process are generated and stored synchronously during the execution of each upgrade sub-process. If the execution of the upgrade task is interrupted, after the vehicle-side management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

2. The atomized collaborative upgrade method according to claim 1, characterized in that, The step of generating snapshot data for each target electronic control unit based on the upgrade task metadata includes: Verify the metadata of the upgrade task; The verified upgrade task metadata is parsed to obtain a list of target electronic control units and the dependencies between the target electronic control units in the list; Based on the dependency relationship, the current state information generated by the interaction with the target electronic control unit is obtained, and the corresponding snapshot data is generated according to the current state information.

3. The atomized collaborative upgrade method according to claim 2, characterized in that, The verification of the upgrade task metadata includes: Based on the pre-set server public key, the digital signature of the upgrade task metadata is verified. If the digital signature verification is successful, it is determined that the upgrade task metadata has passed the legality and integrity verification. Based on preset field format rules, the preset fields in the upgrade task metadata are verified. If each preset field exists and its format conforms to the field format rules, the upgrade task metadata is determined to have passed the data format verification. Based on the target electronic control unit list and the dependencies, it is detected whether there is a circular dependency path with a length not exceeding a preset threshold. If no circular dependency path is detected, it is determined that the upgrade task metadata has passed the logical verification.

4. The atomized collaborative upgrade method according to claim 1, characterized in that, The acquisition of upgrade task metadata includes: Receive the request header sent by the upgrade server, and parse the request header to determine the content length; If the length of the content exceeds a preset threshold, the network connection with the server will be terminated. If the length of the content does not exceed a preset threshold, the upgrade task metadata is obtained by concatenating the request header and stored in a pre-allocated buffer.

5. The atomized collaborative upgrade method according to claim 1, characterized in that, The process of executing an upgrade task consisting of multiple upgrade sub-processes based on the upgrade task metadata includes: Based on the upgrade task metadata, obtain the upgrade image data corresponding to the target electronic control unit; Based on the aforementioned dependencies, the upgrade execution order for each of the target electronic control units is determined; For each target electronic control unit, the upgrade sub-processes are executed sequentially according to the upgrade execution order to complete the upgrade task: downloading the corresponding upgrade image data, erasing the target storage partition, writing the upgrade image data, and verifying the written data.

6. The atomized collaborative upgrade method according to claim 1, characterized in that, The downloaded upgrade image data includes: Send a download request for a specific data block to the upgrade server; The system receives response information from the upgrade server corresponding to the download request, the response information including the specific data block, the hash value of the specific data block, and its digital signature; Perform hash verification and signature verification on the received specific data block; If both the hash verification and signature verification pass, the specific data block is confirmed to have been successfully downloaded. The download of the upgrade image data is completed when all data blocks corresponding to the upgrade image data are confirmed to have been successfully downloaded.

7. The atomized collaborative upgrade method according to claim 1, characterized in that, The synchronous generation and storage of log entries corresponding to the upgrade sub-process includes: After completing an upgrade sub-process, a log entry conforming to the corresponding predefined format is generated based on the operation type of the upgrade sub-process, the identifier of the target electronic control unit, and the execution result. Write the log entries and their integrity check codes into the non-volatile storage area.

8. An atomized collaborative upgrading method, characterized in that, Executed by the server, the methods include: Generate upgrade task metadata, which includes a list of target electronic control units and the dependencies between the electronic control units in the list; The upgrade task metadata is sent to the vehicle management unit of the target vehicle, so that the vehicle management unit generates snapshot data of each target electronic control unit based on the upgrade task metadata, executes an upgrade task consisting of multiple upgrade sub-processes based on the upgrade task metadata, and synchronously generates and stores log entries corresponding to each upgrade sub-process during execution; if the execution of the upgrade task is interrupted, after the vehicle management unit resumes operation, the execution interruption point is determined based on the log entries, and the upgrade task is restored based on the execution interruption point and the snapshot data.

9. A vehicle, characterized in that, The vehicle includes an electronic control unit and a vehicle management unit, wherein the vehicle management unit is used to implement the steps in the atomic collaborative upgrade method according to any one of claims 1 to 7.

10. An atomized collaborative upgrade system, characterized in that, Includes the server and the vehicle as described in claim 9.

Images