A method for atomic update and automatic rollback of vehicle software based on SOVD protocol

Abstract

This invention relates to the field of intelligent driving technology, providing a method for atomic update and automatic rollback of vehicle software based on the SOVD protocol. This method adds extended fields to the standard SOVD update package to describe atomicity requirements, dependencies, and rollback information, and parses dependencies to generate a cross-ECU sub-update execution sequence. Then, based on this sub-update execution sequence and atomicity requirements, it coordinates multiple ECUs to execute sub-updates in a transactional manner. If any sub-update fails, a rollback process is automatically triggered, and the affected ECUs are restored to their pre-update state based on the rollback information. Simultaneously, an enhanced SOVD status query interface provides update information including the overall status of the atomic update transaction, failed steps, and rollback progress. This invention solves the problem of lacking reliable transaction guarantees and automatic rollback capabilities in multi-ECU atomic updates under the standard SOVD protocol, ensuring the consistency and security of software version changes, and improving the observability of the update process.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and more specifically, to a method for atomic update and automatic rollback of vehicle software based on the SOVD protocol. Background Technology

[0002] In the field of intelligent connected vehicles, over-the-air (OTA) software updates are a key means of achieving functional iteration, security fixes, and performance optimization. With the surge in the number of electronic control units (ECUs) and high-performance computing (HPCs), software complexity has increased, and a single update package often involves the coordinated updates of multiple ECUs. To address this need, the AUTOSAR organization introduced the Service-Oriented Vehicle Diagnostics (SOVD) standard, which is based on modern technologies such as HTTPS and RESTful APIs and defines a standardized interface for software updates. The SOVD standard allows updates to multiple ECUs to be packaged into an atomic update package, meaning that all sub-updates within the package either all succeed or all fail. However, this standard only introduces the concept of atomic updates and does not define specific transaction guarantee mechanisms, failure rollback protocols, or methods for describing cross-ECU dependencies.

[0003] Currently, some existing technologies have attempted to address the dependency and rollback issues in multi-ECU collaborative upgrades. For example, some solutions acquire ECU dependencies, group them, and flash them sequentially, enabling a rollback of the entire group if a failure occurs within a group; others use directed acyclic graphs to depict dependencies and combine them with distributed consensus protocols to achieve atomic switching; still others use a dual-partition architecture to achieve single-ECU rollback. All these solutions have explored dependency handling or rollback mechanisms.

[0004] However, existing solutions are not deeply integrated with the SOVD standard, resulting in a lack of true transactional guarantees for atomic updates, reliance on manual intervention for rollbacks, and complex and non-standardized dependency management. These problems hinder the evolution of OTA systems towards more reliable transactional upgrades. Summary of the Invention

[0005] This invention addresses the technical problem of the lack of practical transaction guarantees and automatic recovery capabilities in atomic updates of multi-ECU software under the existing SOVD standard. It provides a method for atomic updates and automatic rollback of vehicle software based on the SOVD protocol, ensuring the atomicity and consistency of cross-ECU update operations, effectively avoiding the risk of the system entering a hybrid software version, and improving the reliability and maintainability of the update process through enhanced status feedback.

[0006] According to a first aspect of the present invention, a method for atomic update and automatic rollback of vehicle software based on the SOVD protocol is provided, comprising: The update package resources defined in the SOVD standard are supplemented with extended fields to describe atomicity requirements, dependencies, and rollback information. The dependencies in the extended fields are parsed to generate a sub-update execution sequence across ECUs. Based on the sub-update execution sequence and the atomicity requirement, multiple ECUs are coordinated to perform sub-updates in a transactional manner, and a rollback process is triggered when any sub-update fails, and the affected ECUs are restored to their pre-update state according to the rollback information; Update information is fed back through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0007] Based on the above technical solution, the present invention can also be improved as follows.

[0008] Optionally, the extended fields include: transaction identifier, atomicity flag, rollback packet identifier pointing to a predefined rollback packet, a list of dependencies describing the execution order constraints between update units, a list of checkpoints defining key stages of the update process, and transaction timeout.

[0009] Optionally, parsing the dependencies in the extended fields to generate a sub-update execution sequence across ECUs includes: The dependencies in the extended fields that describe the execution order constraints between the various sub-updates are parsed. A directed acyclic graph is constructed based on the dependency list, and the directed acyclic graph is topologically sorted to generate a valid cross-ECU sub-update execution sequence.

[0010] Optionally, the transactional coordination of multiple ECUs executing sub-updates includes employing a parallel execution mode or a sequential execution mode, wherein: The parallel execution mode includes: sending a preparation command to all ECUs involved in this update, and sending a submission command after all ECUs involved in this update are ready; if any ECU fails during the preparation or submission phase, the rollback process is triggered. The sequential execution mode includes: executing the sub-transactions corresponding to each sub-update unit in the order of execution of each sub-update constrained in the sub-update execution sequence; if any sub-transaction fails, the compensation operation of the successful sub-transactions is executed in reverse order.

[0011] Optionally, the selection between the parallel execution mode and the sequential execution mode is determined based on at least one of the atomicity requirements, the security level of the functions involved in the update package, or client instructions.

[0012] Optionally, the triggering of the rollback process, which restores the affected ECU to its pre-update state based on the rollback information, includes: Stop all currently pending child update tasks; Perform rollback operations on successfully updated ECUs in the reverse order of the current execution sequence; The rollback operation includes at least one of the following methods: calling the rollback routine built into the ECU, flashing using the complete rollback package pointed to by the rollback package identifier, or restoring using the recovery point generated for the ECU during the update preparation phase.

[0013] Optionally, the recovery point can be a full backup or a differential backup.

[0014] Optionally, the triggering condition for any sub-update failure includes at least one of the following: The system receives an error response from the ECU, the sub-update operation times out, or communication with the ECU is interrupted.

[0015] Optionally, the update information may also include a recoverability identifier; the recoverability identifier is used to indicate whether to re-initiate the update operation based on the same update package after the update fails.

[0016] According to a second aspect of the present invention, a vehicle software atomic update and automatic rollback system based on the SOVD protocol is provided, comprising: The metadata processing module is used to add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs; The execution and rollback module is used to coordinate the execution of sub-updates by multiple ECUs in a transactional manner based on the sub-update execution sequence and the atomicity requirement, and to trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information; The status feedback module is used to provide update information through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0017] According to a third aspect of the present invention, an electronic device is provided, including a memory and a processor, wherein the processor is configured to implement the steps of the above-described vehicle software atomic update and automatic rollback method based on the SOVD protocol when executing a computer management program stored in the memory.

[0018] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, on which a computer management class program is stored, wherein when the computer management class program is executed by a processor, the steps of the above-described method for atomic update and automatic rollback of vehicle software based on the SOVD protocol are implemented.

[0019] This invention provides a method, system, electronic device, and storage medium for atomic updates and automatic rollback of vehicle software based on the SOVD protocol. By extending the metadata of the SOVD standard update package, it uses structured extended fields to describe atomicity requirements, dependencies between sub-updates, and rollback information, and generates a cross-ECU execution sequence accordingly. Based on this sequence and atomicity requirements, it coordinates updates across multiple ECUs using a transactional approach, ensuring that a rollback process is automatically triggered if any sub-update fails, restoring the system state to consistency based on preset rollback information. Simultaneously, an enhanced status query interface provides real-time feedback on key information such as transaction status, failure steps, and rollback progress. This invention achieves reliable update scheduling through standardized dependency descriptions and execution sequence generation, and ensures the atomicity and consistency of software version changes across multiple ECUs using transactional execution and automatic rollback mechanisms. This significantly reduces the risk of the system entering a mixed-version state due to partial update failures, and improves the observability and maintainability of the entire update process through transparent status feedback. Attached Figure Description

[0020] Figure 1 A flowchart of a vehicle software atomic update and automatic rollback method based on the SOVD protocol provided by the present invention; Figure 2 A schematic diagram of a vehicle software atomic update and automatic rollback system architecture based on the SOVD protocol is provided for one embodiment. Figure 3 A flowchart of a vehicle software atomic update and automatic rollback method based on the SOVD protocol provided for one embodiment; Figure 4 A schematic diagram illustrating the two-phase commit and rollback signaling interaction for a particular embodiment; Figure 5 A functional block diagram of a vehicle software atomic update and automatic rollback system based on the SOVD protocol provided by the present invention; Figure 6 A schematic diagram of the hardware structure of a possible electronic device provided by the present invention; Figure 7 This is a schematic diagram of the hardware structure of a possible computer-readable storage medium provided by the present invention. Detailed Implementation

[0021] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0022] In this embodiment of the invention, when collecting, processing, and storing user personal information (such as images, behavioral characteristics, etc.), the implementation of the technical solution strictly adheres to the principles of legality, legitimacy, and necessity, as well as the core rule of "notification-consent." Specifically, before information collection, the system clearly informs the user of the purpose, method, scope, and usage rules of information collection through an interactive interface, and requires the user's active authorization and consent. The entire information processing process employs data encryption, access control, and other technical measures to ensure information security, and establishes mechanisms to facilitate users' exercise of their rights (such as querying, correcting, withdrawing consent, and deleting information). For exceptions stipulated by law (such as those necessary for fulfilling statutory duties or responding to public health emergencies), their application is strictly limited to the scope and limits authorized by law, ensuring that the technical solution does not contain any content that violates the law, social morality, or harms the public interest.

[0023] Figure 1 A flowchart of a vehicle software atomic update and automatic rollback method based on the SOVD protocol provided by this invention is shown below. Figure 1 As shown, the method includes steps S1 to S3: S1, add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs.

[0024] This step extends the metadata of the SOVD standard software update package in a structured way. The added extended fields include transaction identifiers, atomicity flags, dependency lists, and rollback package identifiers. Upon receiving an update request, the system parses these extended fields, particularly the dependency list, which describes the execution order constraints between the various sub-update units. Based on these dependencies, a directed acyclic graph is constructed and topologically sorted to generate a valid, circularly independent sub-update execution sequence across multiple electronic control units (ECUs), providing a clear path planning for subsequent transactional execution.

[0025] S2, based on the sub-update execution sequence and the atomicity requirement, coordinate multiple ECUs to execute sub-updates in a transactional manner, and trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information.

[0026] This step, based on the execution sequence generated in the first step and the requirements indicated by the atomicity flag, coordinates the update operations of multiple ECUs using a specific transactional approach. Specifically, this includes parallel execution mode and sequential execution mode. Regardless of the mode used, the goal is to ensure that all sub-updates either succeed completely or fail completely. If any stage fails during execution, the system automatically triggers a rollback process. The rollback operation, based on predefined rollback information in the extended fields, such as the rollback package identifier or the recovery point generated during the preparation phase, restores the updated ECU software state to its state before the start of this update, in the reverse direction of the execution order, thereby ensuring the consistency of the entire vehicle software system.

[0027] S3, update information is fed back through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0028] This step provides observability for the entire atomic update process. During update execution or rollback, the standard SOVD status query interface is enhanced to provide richer and more detailed status information. This information includes not only the overall transaction status (preparing, executing, rolling back, or completed), but also precise indication of the specific failure steps in the event of a failure. Furthermore, during rollback, the interface provides real-time feedback on the rollback progress. These enhanced update information enable cloud management platforms or in-vehicle clients to clearly and in real-time monitor the execution status and health of the entire complex update transaction.

[0029] Understandably, given the deficiencies in the background technology, this invention proposes a method for atomic update and automatic rollback of vehicle software based on the SOVD protocol. This method extends the metadata of the SOVD standard update package, injecting structured fields describing atomicity, dependencies, and rollback information, and uses this to parse and generate a cross-ECU execution sequence. Then, based on this sequence and atomicity requirements, it coordinates the execution of multiple ECUs in a transactional manner, ensuring that if any sub-update fails, a rollback is automatically triggered based on preset rollback information, restoring the affected units to a consistent state. Simultaneously, it provides transparent information including the overall transaction status, failure steps, and rollback progress through an enhanced status query interface.

[0030] Based on the standard SOVD protocol, this invention achieves transaction atomicity and automatic rollback capability for multi-ECU software updates. It ensures the reliability of update scheduling through dependency resolution and sequence planning, and eliminates the risk of the system getting stuck in mixed software versions through transaction execution and automatic rollback mechanisms. This effectively improves the robustness and security of online vehicle software upgrades. At the same time, it enhances the observability of the operation and maintenance process and the efficiency of fault location by leveraging enhanced status feedback.

[0031] Based on the above technical solutions, the embodiments of the present invention can be further improved as follows.

[0032] Example 1: Due to the shallow application of the SOVD standard in existing technologies, the lack of transaction guarantees for atomic updates, and the imperfect dependency and rollback mechanisms, this embodiment extends the update package metadata, introduces transaction identifiers, two-phase commit (parallel execution) / Saga execution (sequential execution) modes, a dual rollback mechanism based on recovery points and rollback packages, and a dependency-driven DAG scheduling algorithm to achieve reliable atomic updates across multiple ECUs / HPCs.

[0033] This embodiment is set up as follows: Figure 2 The illustrated system architecture for atomic updates and automatic rollback of vehicle software based on the SOVD protocol is used to perform... Figure 1 The method shown is based on an embedded C language environment (ECU side) and a cloud microservice architecture, which is in line with actual development.

[0034] In one possible embodiment, combining Figure 3 As shown, step S1 includes sub-steps S101 to S102.

[0035] S101, Extended Update Package Metadata Metadata for software update package resources conforming to the SOVD standard is extended by adding structured extended fields. These extended fields describe the transactional requirements, dependencies, and rollback information of this update, specifically including a globally unique transaction identifier, an atomicity flag declaring atomicity requirements, a list of dependencies describing the execution order constraints between various sub-update units, a rollback package identifier pointing to a predefined rollback package, a list of checkpoints defining key stages of the update process, and the transaction timeout period, etc.

[0036] Specifically, this embodiment adds the following metadata fields to the update package: (1) Transaction ID: Assign a globally unique transaction ID to each atomic update operation to track the entire update process; (2) Atomicity flag: indicates whether the update package requires atomicity (i.e., all sub-updates must either succeed or all be rolled back); (3) Rollback package identifier: Optional field, pointing to a predefined rollback package (i.e., a complete firmware package that restores to the version before the update); (4) Dependency list: describes the execution order constraints between each sub-update. Each dependency record contains the ID of the update package it depends on and the dependency type (sequential execution or parallel execution). (5) Checkpoint list: Defines key stages in the update process (such as download completion, verification completion, flashing completion, activation completion) for fine-grained progress tracking and partial rollback; (6) Timeout: The maximum execution time allowed for the entire update transaction. A rollback will be automatically triggered after the timeout.

[0037] These extended fields are all prefixed with x- and do not affect the use of the standard SOVD API.

[0038] S102, respond to update instructions, resolve dependencies and generate execution sequences. During the update preparation phase, the system parses the dependency list in the extended fields. This dependency list clarifies the sequential execution constraints between multiple sub-update units. Based on this list, a directed acyclic graph model is constructed, and by topologically sorting this directed acyclic graph, a valid, non-cyclically dependent sub-update execution sequence spanning multiple electronic control units (ECUs) is generated. This sequence provides a definite order of operations for subsequent atomic execution.

[0039] For example, in a practical implementation, when an SOVD client calls the PUT / updates / {update-package-id} / prepare update interface, the SOVD server performs the following sub-steps: (1) Transaction initialization: The server parses the transaction ID in the request, and automatically generates it if the client does not provide it. At the same time, a transaction record is created in non-volatile memory, with the initial state being "initialized"; (2) Dependency resolution and topological sorting: The server reads the dependency list and constructs a directed acyclic graph (DAG). Each sub-update unit is a node in the DAG, and dependencies are directed edges between nodes. The server performs a topological sort on the DAG to generate a valid execution order. If a circular dependency exists in the DAG (e.g., A depends on B, and B depends on A), an error is returned and the process aborts. (3) Prerequisite checks: Following the topology sorting, each affected ECU is checked sequentially to see if it meets the update conditions, including: whether the vehicle has sufficient battery power, whether the target ECU has sufficient storage space, and whether the current software version is compatible with the update package. If any condition is not met, the preparation is aborted and an error is returned. (4) Generate recovery points: Recovery point information is generated for each sub-update unit, recording the current version's identifier (such as version number and checksum) and its storage location. There are two types of recovery points: full backup (saving the entire firmware image) or differential backup (saving only the differences from the old version), which is automatically selected based on the ECU's capabilities. (5) Transaction status update: Once all sub-units are ready, the transaction status is updated to "Ready" and awaits execution instructions.

[0040] In one possible embodiment, combining Figure 3 As shown, step S2 includes sub-steps S201 to S203.

[0041] S201, Select and execute transactional update mode. The system coordinates multiple ECUs by selecting either parallel or sequential execution mode based on at least one of the following: atomicity requirements (e.g., business consistency requirements), ECU rollback capabilities, the security level of the functions involved in the update package (security-related vs. non-security-related), or client instructions. The server can preset recommended modes in the metadata, and the client can also dynamically specify specific execution modes.

[0042] (1) Parallel execution mode, suitable for strong consistency requirements, such as power systems and ADAS. In this embodiment, it is submitted in two stages as follows: Preparation Phase: The server sends a "Prepare for Update" command to all ECUs involved in this update. Upon receiving the command, each ECU involved in this update performs the following operations: backs up the current firmware (or records a restore point), locks relevant resources to prevent interference from other operations, and self-checks the integrity and compatibility of the update package. Once all ECUs have completed the above preparations, they return to the "Ready" state. If any ECU fails to prepare or times out, the server immediately initiates the rollback process.

[0043] Submission Phase: After confirming that all ECUs are ready, the server sends a "Submit" command to all ECUs involved in this update. Each ECU performs the actual firmware flashing and activation operations. If all ECUs submit successfully, the transaction status is updated to "Submitted". If any ECU submission fails, the server immediately performs a rollback operation on the successfully submitted ECUs in reverse order.

[0044] (2) The sequential execution mode, also known as the Saga mode, is suitable for non-critical updates where eventual consistency is acceptable, such as infotainment systems. This sequential execution mode decomposes the entire atomic update into multiple sequentially executed sub-transactions. Each sub-transaction corresponds to the update of an ECU, and predefines the corresponding compensation operation (i.e., rollback step). The server executes the sub-transactions in topological order: after the current sub-transaction is successfully completed, the next one continues; if a sub-transaction fails, the compensation operations of all successful sub-transactions are executed in reverse order to restore the system to the state before the update.

[0045] S202, Monitor execution status and trigger rollback. During transaction execution, the system continuously monitors the execution status of each sub-update. When any sub-update failure is detected, such as receiving an error response from the ECU, operation timeout, or communication interruption with the ECU, the system immediately terminates subsequent update tasks and automatically triggers the rollback process.

[0046] refer to Figure 4 The diagram shown illustrates the interaction between the two-phase commit and rollback signaling, combined with... Figure 3 As shown, in this embodiment, the process of monitoring the execution status and triggering rollback specifically includes: 1. During the update process, the SOVD server continuously monitors the following events. A rollback will be automatically triggered if any of the following occurs: (1) Response monitoring: Each ECU must return a response after performing a preparation, submission, or compensation operation. If a negative response (such as 0x7F in the UDS protocol) or an error code defined by SOVD is returned, it is considered a failure.

[0047] (2) Timeout monitoring: Each operation has a preset timeout period (specified through the timeout field in the metadata). If no response is received after this time, it is judged as a timeout failure.

[0048] (3) Communication monitoring: If the vehicle is interrupted from the cloud network or the CAN / Ethernet communication inside the vehicle is abnormal, it is determined as a communication failure.

[0049] 2. When the server automatically triggers the rollback process, perform the following operations: (1) Stop all update tasks that have not yet started; (2) Update the transaction status to "rollback in progress"; (3) Traverse the list of successfully updated ECUs in reverse order (in reverse order of execution), and perform a rollback operation for each ECU: ① Prioritize calling the ECU's built-in rollback routine (such as the dedicated rollback command in the UDS service). ②If the ECU does not support rollback routines, but a rollback package ID is defined in the metadata, then the rollback package is called to perform a complete recovery; ③Otherwise, read the backup firmware from the previously saved restore point and re-flash it.

[0050] 3. Update the rollback progress percentage after each ECU rollback is completed.

[0051] 4. After all rollbacks are completed, the transaction status is updated to "rollback completed", and the reason for failure and the rollback completion time are recorded.

[0052] S203, Perform automated rollback recovery refer to Figure 4As shown, the system performs rollback operations on successfully updated ECUs in the reverse order of the sub-update execution. The rollback operation is specifically executed based on the rollback information obtained during the update preparation phase. The methods include calling the ECU's built-in rollback routine, flashing using the complete rollback package pointed to by the rollback package identifier, or restoring using the recovery point generated for the ECU, thereby restoring the software state of all affected ECUs to a consistent state before the start of this update.

[0053] Understandably, this embodiment enhances the system's flexibility in handling complex update requirements by providing transactional execution mode selection adaptable to different scenarios, ensuring strong consistency of core function updates and eventual consistency of ordinary updates; through real-time monitoring and automatic rollback triggering, it achieves immediate response and rapid isolation of faults during the update process, effectively preventing the spread of erroneous states in the vehicle software system and improving the system's robustness and security; through standardized automated rollback recovery operations, it ensures that the state of each ECU can be reliably and consistently restored after an update failure, significantly reducing reliance on manual intervention and effectively improving the automation level, reliability, and operational efficiency of the software upgrade process.

[0054] In one possible embodiment, step S3 includes sub-steps S301 to S303.

[0055] S301, Collect and generate enhanced state information: During the execution and rollback of atomic update transactions, the system collects and generates status information in real time that far exceeds the specifications of the standard SOVD protocol. The collected status information includes at least the overall progress status of the transaction, the specific failure step or faulty ECU identifier if a failure occurs, and the rollback completion progress of each ECU during the rollback process.

[0056] S302, Assess and label recoverability After a transaction fails or rolls back, the system assesses whether the update is retryable based on the reason for failure, the current state of the ECU, and the rollback result. The system generates a recoverability flag to explicitly indicate whether the entire update operation can be re-initiated and completed based on the same original update package after the update fails.

[0057] S303, Response to status query request When the cloud management platform or vehicle client initiates a query through the enhanced SOVD status query interface, the system will encapsulate the integrated enhanced status information, including the overall transaction status, failed steps, rollback progress collected in step S301, and the recoverability identifier generated in step S302, according to a predefined format, and feed it back to the requester through this interface.

[0058] For example, in a specific implementation scenario, extending the existing SOVD standard's status query interface GET / updates / {update-package-id} / status returns the following extended information: (1) Transaction status: enumeration values ​​such as initialization, preparation, prepared, execution, committed, rollback, and rollback; (2) Failure steps: Identify which specific sub-update unit failed and at which stage (preparation / commit / rollback); (3) Rollback progress: an integer from 0 to 100, representing the percentage of rollback completion; (4) Recoverability indicator: indicates whether recovery is possible after failure through manual operation (such as re-providing the update package); If the transaction status is "rolled back" and the recoverability flag is true (e.g., the failure was caused only by network fluctuations and the firmware was not damaged), the client can re-initiate the update request.

[0059] In this embodiment, by collecting and generating enhanced information in real time, including the overall transaction status, specific failure steps, and rollback progress, the system provides the operations and maintenance team with transparency in the update process and precise fault location capabilities, overcoming the problems of ambiguous status and difficulty in tracing issues in traditional solutions. By evaluating and marking recoverability indicators, a clear decision-making basis is provided for subsequent operations after update failures, avoiding secondary failures that may be caused by blind retries, and effectively improving the accuracy of operations and maintenance decisions and system recovery efficiency. Through standardized enhanced interface response queries, the system ensures that the aforementioned key information can be obtained stably and reliably, thereby constructing a closed-loop system from status awareness and intelligent assessment to decision support, significantly improving the maintainability, observability, and automation and intelligence level of the entire software update system.

[0060] Example 2: Figure 5 A structural diagram of a vehicle software atomic update and automatic rollback system based on the SOVD protocol is provided for an embodiment of the present invention, as shown below. Figure 5 As shown, a vehicle software atomic update and automatic rollback system based on the SOVD protocol includes a metadata processing module, an execution and rollback module, and a status feedback module, wherein: The metadata processing module is used to add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs; The execution and rollback module is used to coordinate the execution of sub-updates by multiple ECUs in a transactional manner based on the sub-update execution sequence and the atomicity requirement, and to trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information; The status feedback module is used to provide update information through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0061] It is understood that the vehicle software atomic update and automatic rollback system based on the SOVD protocol provided by this invention corresponds to the vehicle software atomic update and automatic rollback method based on the SOVD protocol provided in the foregoing embodiments. The relevant technical features of the vehicle software atomic update and automatic rollback system based on the SOVD protocol can be referred to the relevant technical features of the vehicle software atomic update and automatic rollback method based on the SOVD protocol, and will not be repeated here.

[0062] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating an embodiment of the electronic device provided in this invention. For example... Figure 6 As shown, this embodiment of the invention provides an electronic device 600, including a memory 610, a processor 620, and a computer program 611 stored in the memory 610 and executable on the processor 620. When the processor 620 executes the computer program 611, it performs the following steps: S1, add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs; S2, based on the sub-update execution sequence and the atomicity requirement, coordinate multiple ECUs to execute sub-updates in a transactional manner, and trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information; S3, update information is fed back through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0063] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating an embodiment of a computer-readable storage medium provided by the present invention. (See diagram below.) Figure 7 As shown, this embodiment provides a computer-readable storage medium 700, on which a computer program 611 is stored. When the computer program 611 is executed by a processor, it performs the following steps: S1, add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs; S2, based on the sub-update execution sequence and the atomicity requirement, coordinate multiple ECUs to execute sub-updates in a transactional manner, and trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information; S3, update information is fed back through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

[0064] This invention provides a method, system, electronic device, and storage medium for atomic update and automatic rollback of vehicle software based on the SOVD protocol. By injecting structured metadata describing atomicity requirements, dependencies, and rollback information into the update package, and parsing the dependencies to generate a deterministic cross-ECU execution sequence, it achieves transactional coordination of update operations for multiple ECUs on the vehicle side. This ensures that if any unit update fails, a rollback process is automatically triggered based on preset rollback information, restoring the affected unit to a consistent state. Simultaneously, an enhanced status query interface provides transparent information including transaction status, failure steps, and rollback progress. This invention solves the collaborative scheduling problem of multi-ECU updates through standardized dependency descriptions and execution sequence generation. By utilizing transactional execution and automatic rollback mechanisms, it ensures the atomicity and consistency of software version changes across multiple ECUs, greatly reducing the risk of the system entering a mixed version state due to partial update failures. Furthermore, the observable status feedback throughout the entire process significantly improves the efficiency of system operation and maintenance and fault diagnosis.

[0065] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0066] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0067] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0068] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0069] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0070] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0071] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for atomic update and automatic rollback of vehicle software based on the SOVD protocol, characterized in that, include: The update package resources defined in the SOVD standard are supplemented with extended fields to describe atomicity requirements, dependencies, and rollback information. The dependencies in the extended fields are parsed to generate a sub-update execution sequence across ECUs. Based on the sub-update execution sequence and the atomicity requirement, multiple ECUs are coordinated to perform sub-updates in a transactional manner, and a rollback process is triggered when any sub-update fails, and the affected ECUs are restored to their pre-update state according to the rollback information; Update information is fed back through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

2. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 1, characterized in that, The extended fields include: transaction identifier, atomicity flag, rollback packet identifier pointing to a predefined rollback packet, a list of dependencies describing the execution order constraints between sub-update units, a list of checkpoints defining the key stages of the update process, and transaction timeout.

3. A method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 1 or 2, characterized in that, The process of parsing dependencies in extended fields to generate a sub-update execution sequence across ECUs includes: The dependencies in the extended fields that describe the execution order constraints between the various sub-updates are parsed. A directed acyclic graph is constructed based on the dependency list, and the directed acyclic graph is topologically sorted to generate a valid cross-ECU sub-update execution sequence.

4. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 1, characterized in that, The method of coordinating multiple ECUs to execute sub-updates in a transactional manner includes using either a parallel execution mode or a sequential execution mode, wherein: The parallel execution mode includes: sending a preparation command to all ECUs involved in this update, and sending a submission command after all ECUs involved in this update are ready; if any ECU fails during the preparation or submission phase, the rollback process is triggered. The sequential execution mode includes: executing the sub-transactions corresponding to each sub-update unit in the order of execution of each sub-update constrained in the sub-update execution sequence; if any sub-transaction fails, the compensation operation of the successful sub-transactions is executed in reverse order.

5. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 4, characterized in that, The selection between the parallel execution mode and the sequential execution mode is determined based on at least one of the atomicity requirements, the security level of the functions involved in the update package, or client instructions.

6. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 2, characterized in that, The trigger rollback process, based on the rollback information, restores the affected ECUs to their pre-update state, including: Stop all currently pending child update tasks; Perform rollback operations on successfully updated ECUs in the reverse order of the current execution sequence; The rollback operation includes at least one of the following methods: calling the rollback routine built into the ECU, flashing using the complete rollback package pointed to by the rollback package identifier, or restoring using the recovery point generated for the ECU during the update preparation phase.

7. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 6, characterized in that, The recovery point is either a full backup or a differential backup.

8. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 1, characterized in that, The triggering conditions for any sub-update failure include at least one of the following: The system receives an error response from the ECU, the sub-update operation times out, or communication with the ECU is interrupted.

9. The method for atomic update and automatic rollback of vehicle software based on the SOVD protocol according to claim 1, characterized in that, The update information also includes a recoverability identifier; the recoverability identifier is used to indicate whether to re-initiate the update operation based on the same update package after the update fails.

10. A vehicle software atomic update and automatic rollback system based on the SOVD protocol, characterized in that, include: The metadata processing module is used to add extended fields to the update package resources defined by the SOVD standard to describe atomicity requirements, dependencies and rollback information, and parse the dependencies in the extended fields to generate a sub-update execution sequence across ECUs; The execution and rollback module is used to coordinate the execution of sub-updates by multiple ECUs in a transactional manner based on the sub-update execution sequence and the atomicity requirement, and to trigger a rollback process when any sub-update fails, and restore the affected ECUs to their pre-update state according to the rollback information; The status feedback module is used to provide update information through the enhanced SOVD status query interface. The update information includes at least the overall status of the atomic update transaction, the failed steps, and the rollback progress.

Images