Firmware upgrade method, electronic device, and storage medium

Abstract

The application provides a firmware upgrading method, an electronic device and a storage medium, wherein the firmware upgrading method comprises the following steps: obtaining verification metadata of a firmware to be upgraded; obtaining a signature verification result based on the verification metadata of the firmware to be upgraded; obtaining upgrading data of the firmware to be upgraded when a firmware to be upgraded upgrading data downloading condition is met, wherein the firmware to be upgraded upgrading data downloading condition at least comprises that the signature verification result indicates that the verification metadata passes verification; and upgrading the firmware to be upgraded based on the upgrading data of the firmware to be upgraded. The application can improve the safety of a vehicle-mounted controller during the upgrading process and reduce the upgrading time of the vehicle-mounted controller.

Description

Technical Field

[0001] This application relates to the field of intelligent driving controller upgrades, and more specifically, to a firmware upgrade method, electronic device, and storage medium. Background Technology

[0002] As intelligent driving controllers evolve towards heterogeneous architectures, the industry commonly adopts a combination architecture of high-performance SoCs and high-security MCUs. However, existing OTA upgrade technologies suffer from the following significant drawbacks under this heterogeneous architecture: Existing technologies only perform signature verification after the complete upgrade package is downloaded. If the verification fails, a large amount of network bandwidth and vehicle storage resources have already been consumed, resulting in wasted resources. At the same time, they cannot prevent illegal firmware upgrades from the source, posing a serious security risk. Summary of the Invention

[0003] The purpose of this application is to provide a firmware upgrade method, electronic device, and storage medium to overcome at least one of the technical defects of the prior art.

[0004] In a first aspect, the present invention provides a firmware upgrade method, the method being applied to a first vehicle-mounted controller, the method comprising: Obtain the verification metadata of the firmware to be upgraded; Based on the verification metadata of the firmware to be upgraded, the signature verification result is obtained; Under the condition that the upgrade data of the firmware to be upgraded is downloaded, the upgrade data of the firmware to be upgraded is obtained; wherein, the condition for downloading the upgrade data of the firmware to be upgraded includes at least the signature verification result indicating that the verification metadata verification is successful; The firmware to be upgraded is upgraded based on the upgrade data of the firmware to be upgraded.

[0005] In the above implementation process, by signing and verifying the verification metadata, the integrity and legality of the upgrade data can be verified, preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. At the same time, since upgrade data is only downloaded after the verification metadata has passed, invalid downloads of upgrade data can be avoided, thus preventing invalid upgrade data downloads from consuming download bandwidth.

[0006] In an optional implementation, the upgrade data of the firmware to be upgraded includes first firmware upgrade data and second firmware upgrade data; The step of obtaining the upgrade data for the firmware to be upgraded includes: Obtain the first firmware upgrade data; A download license message is sent to a second vehicle controller, which is configured to obtain the second firmware upgrade data based on the download license message; wherein the second vehicle controller and the first vehicle controller download the firmware upgrade data in parallel.

[0007] In the above implementation process, by enabling the second vehicle controller to download firmware upgrade data in parallel with the first vehicle controller, the bandwidth pressure on the first vehicle controller can be reduced. Simultaneously, the download speed of the upgrade data can be increased, shortening the time required for OTA upgrades.

[0008] In an optional implementation, the method further includes: Obtain the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network; Based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network, the bandwidth allocation priority of the first vehicle controller relative to the second vehicle controller is determined. The download bandwidth for the first vehicle controller and the download bandwidth for the second vehicle controller are allocated based on the bandwidth allocation priority; wherein, the download progress of the first firmware upgrade data is synchronized with the download progress of the second firmware upgrade data.

[0009] During the above implementation process, based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network, the bandwidth allocation priority can be adjusted to better utilize the total data bandwidth, so that the download progress of the first firmware upgrade data tends to be synchronized with the download progress of the second firmware upgrade data, and ultimately avoids the overall upgrade delay caused by the download lag of a single chip.

[0010] In an optional implementation, the method further includes: Obtain the context recovery status and resume status of the first vehicle controller, and the context recovery status and resume status of the second vehicle controller; If the context recovery status of any vehicle controller indicates context recovery failure, or the resume status of any vehicle controller indicates resume abnormality, the first firmware upgrade data is deleted, and a deletion command is sent to the second vehicle controller; wherein, the second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

[0011] In the above implementation process, a rollback operation can be performed when the context recovery and continuation of any controller fails, thus avoiding vehicle safety issues caused by abnormal upgrades.

[0012] In an optional implementation, upgrading the firmware based on the upgrade data of the firmware to be upgraded includes: The first firmware upgrade data and the second firmware upgrade data are validated to obtain a validation result; wherein, the data validation includes at least legality validation, integrity validation and version compatibility validation. Under the condition that the verification result indicates that the verification is passed, the first firmware upgrade data is written into the spare execution partition of the first vehicle controller, and a data flashing command is sent to the second vehicle controller. The second vehicle controller is configured to flash the second firmware upgrade data to the spare execution partition of the second vehicle controller based on the data flashing command. Obtain the flashing result of the first firmware upgrade data and the flashing result of the second firmware upgrade data; The firmware to be upgraded is upgraded based on the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data.

[0013] In the above implementation process, the firmware upgrade data can be verified before data is flashed, thereby ensuring that the flashed data is complete and undamaged.

[0014] In an optional implementation, upgrading the firmware based on the upgrade data of the firmware to be upgraded further includes: If the verification result indicates that the verification fails, then the flashing of the first firmware upgrade data and the second firmware upgrade data shall be stopped.

[0015] In the above implementation process, if the verification result indicates that the verification fails, the writing process is stopped, thereby avoiding system upgrades based on incomplete or damaged illegal data.

[0016] In an optional implementation, the first firmware upgrade data and the second firmware upgrade data are flashed in parallel.

[0017] In the above implementation process, the parallel flashing of the second firmware upgrade data and the first firmware upgrade data can shorten the flashing time, further improve the upgrade speed, and shorten the upgrade time required.

[0018] In an optional implementation, upgrading the firmware based on the upgrade data of the firmware to be upgraded further includes: If the flashing result of the first firmware upgrade data is a flashing failure, and / or the flashing result of the second firmware upgrade data is a flashing failure, the first firmware upgrade data is deleted, and a deletion command is sent to the second vehicle controller; wherein, the second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

[0019] In the above implementation process, if any controller fails to be written, all controllers will be rolled back to avoid the risk of controller malfunction due to the semi-upgrade state.

[0020] In an optional implementation, upgrading the firmware based on the upgrade data of the firmware to be upgraded further includes: Under the condition that the flashing result of the first firmware upgrade data is successful and the flashing result of the second firmware upgrade data is successful, the firmware boot partition of the first vehicle controller is switched to the storage partition where the first firmware upgrade data is located, and a partition switching command is sent to the second vehicle controller. The second vehicle controller is configured to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching command.

[0021] In the above implementation process, if both the first vehicle controller and the second vehicle controller are successfully flashed, a partition switching operation is performed to enable the first vehicle controller and the second vehicle controller to execute the new version of firmware, thereby completing the firmware upgrade.

[0022] Secondly, the present invention provides a firmware upgrade device, the device being applied to a first vehicle controller, the device comprising: The first acquisition module is used to acquire the verification metadata of the firmware to be upgraded; The signature verification module is used to obtain the signature verification result based on the verification metadata of the firmware to be upgraded; The second acquisition module is used to acquire the upgrade data of the firmware to be upgraded when the conditions for downloading the upgrade data of the firmware to be upgraded are met; wherein, the conditions for downloading the upgrade data of the firmware to be upgraded include at least the signature verification result indicating that the verification metadata verification is successful; The upgrade execution module is used to upgrade the firmware to be upgraded based on the upgrade data of the firmware to be upgraded.

[0023] Thirdly, the present invention provides an electronic device, comprising: Processor; and The memory is configured to store machine-readable instructions that, when executed by the processor, perform the method as described in any of the foregoing embodiments.

[0024] In the aforementioned implementation process, the electronic device verifies the integrity and legality of the upgrade data by signing and verifying the verification metadata, thus preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. Simultaneously, since upgrade data is only downloaded after the verification metadata has been verified, invalid downloads of upgrade data are avoided, thereby preventing invalid upgrade data downloads from consuming download bandwidth.

[0025] Fourthly, the present invention provides a storage medium storing a computer program, the computer program being executed by a processor as described in any of the foregoing embodiments.

[0026] In the above implementation process, the storage medium verifies the integrity and legality of the upgrade data by signing and verifying the verification metadata, thus preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. Simultaneously, since upgrade data is only downloaded after the verification metadata has passed, invalid downloads of upgrade data are avoided, thereby preventing invalid upgrade data downloads from consuming download bandwidth. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart illustrating a firmware upgrade method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram of an OTA upgrade system with a heterogeneous architecture for an intelligent driving controller provided in an embodiment of this application; Figure 5 This is a schematic diagram of an OTA upgrade process provided in an embodiment of this application; Figure 6 This is a schematic diagram of an atomic upgrade process provided in an embodiment of this application; Figure 7a This is a first schematic diagram of a breakpoint resume process provided in an embodiment of this application; Figure 7b This is a second schematic diagram of a breakpoint resume download process provided in an embodiment of this application; Figure 7c This is a third schematic diagram of a breakpoint resume process provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] Please see Figure 1 , Figure 1 This is a flowchart illustrating a firmware upgrade method provided in an embodiment of this application, wherein the method is applied to a first vehicle controller. Figure 1 As shown, the method includes the following steps: 101. Obtain the verification metadata of the firmware to be upgraded; 102. Based on the verification metadata of the firmware to be upgraded, obtain the signature verification result; 103. Under the condition that the upgrade data of the firmware to be upgraded can be downloaded, the upgrade data of the firmware to be upgraded can be obtained; wherein, the conditions for downloading the upgrade data of the firmware to be upgraded shall include at least the signature verification result indicating that the verification metadata verification is passed; 104. Upgrade the firmware based on the upgrade data of the firmware to be upgraded.

[0031] In this embodiment, the first vehicle controller refers to the system-on-chip (SOC) in the intelligent driving domain controller, which can be a high-performance automotive-grade SOC or a main control chip with OTA-Slave functionality.

[0032] In this embodiment, the firmware to be upgraded refers to the set of firmware programs in the intelligent driving domain controller that need to be updated via OTA (Over-The-Air). These programs can be the firmware programs of the SOC system-on-a-chip and the firmware programs of the MCU (Microcontroller Unit).

[0033] In this embodiment, verification metadata refers to a data set containing firmware signature, version information, hash value, etc., used to verify the legitimacy of firmware. It can be an ECDSA-256 digital signature file or a metadata data set containing firmware version number and checksum.

[0034] In this embodiment, the signature verification result refers to the verification conclusion obtained after verifying the verification metadata through a cryptographic algorithm. It can be a signature verification pass status indicator or a signature verification failure error code.

[0035] In this embodiment, the upgrade data download condition refers to the pre-verification requirements that must be met before starting the firmware data download. These conditions can be Boolean values ​​indicating that metadata signature verification has passed, or composite conditions that include signature verification results and permission verification.

[0036] In this embodiment, one specific way to obtain the verification metadata of the firmware to be upgraded is as follows: the SOC requests the metadata download address from the cockpit domain controller through the DoIP protocol, and after establishing a TLS secure connection, downloads the metadata from the cloud server. The metadata contains information such as firmware hash value, digital signature, and version number.

[0037] In this embodiment, one specific way to obtain the verification metadata of the firmware to be upgraded is as follows: the SOC reads the metadata index of the firmware to be upgraded from the locally stored upgrade task queue, and initiates a metadata query request to the cloud authentication server through the SOME / IP protocol to obtain the encrypted verification metadata.

[0038] In this embodiment, a specific way to obtain the signature verification result based on the verification metadata of the firmware to be upgraded is as follows: the SOC calls the ECDSA-256 signature verification algorithm of the Hardware Security Module (HSM), uses a preset public key to verify the metadata signature, generates a verification result, and records the verification log.

[0039] In this embodiment, a specific way to obtain the signature verification result based on the verification metadata of the firmware to be upgraded is as follows: the SOC sends the verification metadata to the security coprocessor, the coprocessor performs signature verification and returns a verification status code, and the SOC determines whether the verification is successful based on the status code.

[0040] In this embodiment, under the condition that the upgrade data of the firmware to be upgraded is downloaded, a specific way to obtain the upgrade data of the firmware to be upgraded is as follows: the SOC generates a global transaction ID and checks whether the local storage space is sufficient. After confirming that the condition is met, it initiates a firmware package download request to the cloud and establishes a parallel download channel.

[0041] In this embodiment, under the condition that the upgrade data of the firmware to be upgraded is to be downloaded, a specific way to obtain the upgrade data of the firmware to be upgraded is as follows: after the SOC verifies the user authorization status and network connection quality and confirms that the upgrade data download conditions are met, a multi-threaded download connection is established through the automotive-grade APN private network to start downloading the firmware upgrade data.

[0042] In this embodiment, a specific way to upgrade the firmware based on the upgrade data of the firmware to be upgraded can be as follows: after the firmware is downloaded, the SOC writes the upgrade data to the backup execution partition, performs version verification, switches the boot partition pointer, and restarts the controller to complete the upgrade.

[0043] In this embodiment, a specific way to upgrade the firmware based on the upgrade data of the firmware to be upgraded can be: after the SOC performs integrity verification on the upgrade data, it calls the flash interface to write the data to the Flash memory, updates the version information, and triggers a soft reset of the controller.

[0044] In the above implementation process, by signing and verifying the verification metadata, the integrity and legality of the upgrade data can be verified, preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. At the same time, since upgrade data is only downloaded after the verification metadata has passed, invalid downloads of upgrade data can be avoided, thus preventing invalid upgrade data downloads from consuming download bandwidth.

[0045] For example, in the scenario of upgrading intelligent driving controllers, when a vehicle undergoes an OTA upgrade in a parking lot, the system first downloads a small amount of verification metadata (only a few hundred KB) for ECDSA-256 signature verification. If the firmware package has been tampered with by malicious attackers in the cloud, the signature verification process will immediately identify the signature mismatch, the system will directly terminate the upgrade process and report a security alert, preventing several gigabytes of malicious firmware from being downloaded to the vehicle controller. This pre-verification mechanism not only protects the vehicle's network security but also saves the driver's mobile network traffic, especially in scenarios with poor network environments such as underground parking lots, avoiding prolonged network occupation and storage space waste caused by downloading large amounts of illegal firmware.

[0046] In an optional implementation, the upgrade data of the firmware to be upgraded includes first firmware upgrade data and second firmware upgrade data. Accordingly, obtaining the upgrade data of the firmware to be upgraded includes: Obtain the first firmware upgrade data; A download license message is sent to the second vehicle controller, which is configured to obtain the second firmware upgrade data based on the download license message; wherein the second vehicle controller and the first vehicle controller download the firmware upgrade data in parallel.

[0047] In this embodiment, the first firmware upgrade data refers to the firmware update data package for the first onboard controller (SOC), which may be the SOC operating system image file or the SOC application layer software package.

[0048] In this embodiment, the second firmware upgrade data refers to the firmware update data package for the second vehicle controller (MCU), which may be the MCU low-level driver or the MCU security monitoring firmware.

[0049] In this embodiment, the download license message refers to the authorized download instruction sent by the master controller to the slave controller. It can be a SOME / IP service call with a transaction ID or an encrypted DoIP diagnostic instruction.

[0050] In this embodiment, parallel download refers to a collaborative mechanism in which multiple controllers simultaneously and independently download data. This can be either dual-channel independent download or multi-threaded concurrent download.

[0051] In this embodiment, one specific way to obtain the first firmware upgrade data is as follows: the SOC directly connects to the cloud server via an Ethernet interface, establishes an HTTPS download connection, downloads its own firmware package according to the chunked transfer encoding method, and records the download progress and verification code at the same time.

[0052] In this embodiment, one specific way to obtain the first firmware upgrade data is as follows: the SOC obtains the CDN distribution address of the firmware package from the cloud, downloads multiple data blocks concurrently using multi-threaded download technology, and calculates the MD5 checksum in real time to ensure data integrity.

[0053] In this embodiment, one specific way to send a download license message to the second vehicle controller is as follows: the SOC sends a license message containing a global transaction ID and a download address to the MCU via the SOME / IP protocol. After receiving the message, the MCU verifies the validity of the transaction ID and prepares to download.

[0054] In this embodiment, one specific way to send a download license message to the second vehicle controller is as follows: the SOC generates a download license token with a timestamp, broadcasts the download license message via the vehicle Ethernet, and the MCU listens to the message, parses the token, and establishes a download connection.

[0055] In this embodiment, a specific method for the second vehicle controller and the first vehicle controller to download firmware upgrade data in parallel can be: the MCU connects directly to the cloud through an independent Ethernet PHY chip and downloads its respective firmware package simultaneously with the SOC, with both parties synchronizing the download progress in real time through heartbeat packets.

[0056] In this embodiment, a specific method for the second vehicle controller and the first vehicle controller to download firmware upgrade data in parallel can be as follows: the SOC and MCU establish independent TCP connections to download the firmware, the MCU periodically reports the download percentage to the SOC, and the SOC dynamically adjusts the bandwidth allocation according to the progress difference.

[0057] In the above implementation process, by enabling the second vehicle controller and the first vehicle controller to download firmware upgrade data in parallel, the bandwidth pressure on the first vehicle controller can be reduced. Simultaneously, the download speed of the upgrade data can be increased, shortening the time required for OTA upgrades.

[0058] For example, when a vehicle owner initiates an OTA (Over-The-Air) upgrade, the traditional solution requires the SOC (System-on-a-Chip) to download the complete MCU firmware package before forwarding it to the MCU, a process that takes 40 minutes. However, with the parallel download mechanism in this embodiment, the SOC and MCU each download firmware simultaneously from the cloud via independent Ethernet channels. The SOC downloads its own 3GB system image, while the MCU synchronously downloads a 1.5GB control program. Since the downloads of the two controllers do not interfere with each other, the total upgrade time is reduced to 25 minutes. Simultaneously, the SOC's CPU load decreases from 85% to 50%, avoiding system lag caused by data forwarding and ensuring the normal operation of other vehicle functions during the upgrade process.

[0059] In an optional implementation, the firmware upgrade method of this application embodiment further includes the following steps: Obtain the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network; Based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network, the bandwidth allocation priority of the first vehicle controller relative to the second vehicle controller is determined. Download bandwidth for the first vehicle controller and download bandwidth for the second vehicle controller are allocated based on bandwidth allocation priority; wherein, the download progress of the first firmware upgrade data is synchronized with the download progress of the second firmware upgrade data.

[0060] In this embodiment, download progress refers to a quantitative indicator of the degree to which firmware data download is complete. It can be a percentage progress value or the number of bytes downloaded.

[0061] In this embodiment, network status data refers to a set of real-time parameters that reflect the current network connection quality. These parameters may include bandwidth utilization and packet loss rate, or RTT latency and signal strength.

[0062] In this embodiment, bandwidth allocation priority refers to the weight coefficient of network resource allocation for each controller dynamically adjusted according to the download status. It can be a priority value of 0-100, or a three-level priority of high / medium / low.

[0063] In this embodiment, progress synchronization refers to maintaining a coordinated state of download progress among multiple controllers through bandwidth scheduling. This can be achieved by the progress difference being less than a threshold or by a synchronization completion time window.

[0064] In this embodiment, a specific implementation method for obtaining the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network is as follows: the SOC collects its own download progress (e.g., 65%) and the download progress reported by the MCU (e.g., 45%) every 5 seconds, and at the same time obtains the current bandwidth utilization (70%) and packet loss rate (2%) through the network monitoring module.

[0065] In this embodiment, a specific way to obtain the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network is as follows: the SOC calls the system API to obtain the real-time network status, including parameters such as TCP connection speed and buffer occupancy rate, and calculates the progress difference in combination with the download speed of the two chips.

[0066] In this embodiment, a specific implementation of determining the bandwidth allocation priority of the first vehicle controller relative to the second vehicle controller based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network is as follows: when it is detected that the MCU download progress lags behind the SOC by more than 15%, the SOC will raise the bandwidth priority of the MCU to 80 and lower its own to 60, ensuring that the lagging party obtains more network resources.

[0067] In this embodiment, a specific implementation method for determining the bandwidth allocation priority of the first vehicle controller relative to the second vehicle controller based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network is as follows: the SOC dynamically calculates the priority according to the network congestion situation. For example, when the network quality is poor, the controller with slower progress is given priority, and the weighted fair queue algorithm is used to allocate bandwidth.

[0068] In this embodiment, a specific method for allocating the download bandwidth of the first vehicle controller and the second vehicle controller based on bandwidth allocation priority is as follows: the SOC allocates network bandwidth according to priority ratio using traffic shaping technology, such as the MCU receiving 60% bandwidth and the SOC receiving 40%, and the allocation effect is guaranteed through QoS policies.

[0069] In this embodiment, a specific way to allocate the download bandwidth of the first vehicle controller and the second vehicle controller based on bandwidth allocation priority is as follows: the SOC adjusts the TCP window size and congestion control parameters to allocate a larger sending window to the high-priority controller, while limiting the burst traffic of the low-priority controller.

[0070] During the above implementation process, based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network, the bandwidth allocation priority can be adjusted to better utilize the total data bandwidth, so that the download progress of the first firmware upgrade data tends to be synchronized with the download progress of the second firmware upgrade data, and ultimately avoids the overall upgrade delay caused by the download lag of a single chip.

[0071] For example, during a backend upgrade while the vehicle is traveling on city roads, network signal fluctuations occur when the vehicle passes through a tunnel. The SOC detects that the MCU's download progress drops from 50% to 45%, while its own progress remains at 60%, and the network packet loss rate rises to 8%. The system immediately initiates dynamic bandwidth scheduling, raising the MCU's priority from 50 to 85 and lowering the SOC's priority to 40. After 2 minutes of adjustment, the MCU's download speed increases from 2MB / s to 5MB / s, catching up to 55%, and narrowing the gap with the SOC to within 5%. Once the vehicle exits the tunnel and the network recovers, the system automatically balances the bandwidth of both devices, ensuring that both controllers complete the download simultaneously within 3 minutes. This intelligent scheduling avoids overall upgrade delays caused by download lag in a single chip.

[0072] In an optional implementation, the firmware upgrade method of this application embodiment further includes the following steps: Obtain the context recovery status and resume status of the first vehicle controller, and the context recovery status and resume status of the second vehicle controller; If the context recovery status of any vehicle controller indicates context recovery failure, or the resume status of any vehicle controller indicates resume abnormality, the first firmware upgrade data is deleted, and a deletion command is sent to the second vehicle controller; wherein, the second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

[0073] In this embodiment, the context recovery status refers to the execution environment reconstruction status when the controller resumes the upgrade process from the interruption point. It can be a recovery success / failure indicator or a recovery progress percentage.

[0074] In this embodiment, the resume status refers to the execution status identifier of each stage during the resume process. It can be resumed / completed / abnormal, or it can be a status code with an error code. In this embodiment, the deletion command refers to the control command sent by the master controller to the slave controller to clear the upgrade data. It can be a SOME / IP service call or a DoIP diagnostic deletion request.

[0075] In this embodiment, rollback operation refers to a security mechanism that undoes executed operations and restores the system to its pre-upgrade state in the event of an upgrade anomaly. Rollback can be data deletion and state reset, or partition rollback and version recovery.

[0076] In this embodiment, a specific method for obtaining the context recovery status and resume status of the first vehicle controller and the second vehicle controller can be as follows: the SOC reads the context information saved during the interrupt from local persistent storage, and simultaneously queries the MCU for its recovery status and resume progress via the SOME / IP protocol, summarizing the dual-chip status. In this embodiment, a specific way to obtain the context recovery status and resume status of the first vehicle controller, as well as the context recovery status and resume status of the second vehicle controller, may be: the SOC starts a status detection thread, checks its own and the MCU's resume log files respectively, parses the latest status identifiers and error information, and generates a status report.

[0077] In this embodiment, a specific way to delete the first firmware upgrade data and send a deletion command to the second vehicle controller when either vehicle controller's context recovery status indicates context recovery failure or either vehicle controller's resume status indicates resume abnormality can be: When the MCU reports a "context verification failed" error, the SOC immediately terminates the resume transmission process, calls the secure erase interface to delete the local firmware package, and sends a digitally signed deletion command to the MCU.

[0078] In this embodiment, a specific way to delete the first firmware upgrade data and send a deletion command to the second vehicle controller when the context recovery status of any vehicle controller indicates context recovery failure or the resume status of any vehicle controller indicates resume abnormality can be as follows: After the SOC determines that the status of any controller is abnormal, it starts a rollback transaction, first deletes the firmware data downloaded by itself, and then sends a deletion request to the MCU through an encrypted channel, and waits for a confirmation response.

[0079] In this embodiment, a specific way for the second vehicle controller to delete the second firmware upgrade data based on the deletion command is as follows: after receiving the deletion command, the MCU verifies the legality of the command signature and transaction ID, calls the Flash erase function to clear the upgrade data partition, and updates the status to "rollback".

[0080] In this embodiment, a specific method for the second vehicle controller to delete the second firmware upgrade data based on the deletion command is as follows: the MCU executes a secure deletion process, first marking the data as invalid, then physically erasing the storage block, and finally sending a deletion completion confirmation message to the SOC.

[0081] In the above implementation process, a rollback operation can be performed when the context recovery and continuation of any controller fails, thus avoiding vehicle safety issues caused by abnormal upgrades.

[0082] For example, when the vehicle owner restarts the vehicle, the system attempts to resume the upgrade from a breakpoint. The SOC detects a "context verification failure" report from the MCU, caused by corruption of the MCU's resume log file. The system immediately triggers a global rollback mechanism. The SOC first deletes its own downloaded 2.8GB firmware data and simultaneously sends an encrypted deletion command to the MCU. Upon receiving the command, the MCU securely erases 1.2GB of upgrade data, and both systems are synchronously rolled back to their state before the upgrade. The entire rollback process is completed within 10 seconds, and the vehicle's intelligent driving functions immediately return to normal, avoiding system instability caused by residual abnormal upgrade data. This rapid rollback mechanism is particularly suitable for urban driving scenarios with frequent starts and stops, ensuring the safety and reliability of the upgrade process.

[0083] In an optional implementation, the firmware to be upgraded is upgraded based on the upgrade data of the firmware to be upgraded, including the following sub-steps: The first firmware upgrade data and the second firmware upgrade data are verified to obtain the verification results; the data verification includes at least legality verification, integrity verification and version compatibility verification. Under the condition that the verification result indicates that the verification is passed, the first firmware upgrade data is written to the spare execution partition of the first vehicle controller, and a data flashing command is sent to the second vehicle controller. The second vehicle controller is configured to flash the second firmware upgrade data to the spare execution partition of the second vehicle controller based on the data flashing command. Obtain the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data; The firmware to be upgraded is upgraded based on the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data.

[0084] In this embodiment, data verification refers to the process of checking firmware upgrade data in multiple dimensions to ensure its availability. This can be hash verification and signature verification, or CRC verification and version comparison.

[0085] In this embodiment, legitimacy verification refers to a security check that verifies the trustworthiness of the firmware data source and its authorization status. This can be either digital signature verification or certificate chain verification.

[0086] In this embodiment, integrity verification refers to the verification process of checking whether firmware data has been tampered with or damaged during transmission. This process can be either SHA-256 hash comparison or MD5 checksum verification.

[0087] In this embodiment, version compatibility verification refers to the check that confirms the compatibility of the new firmware with the existing system and other controller versions. This can be an API interface compatibility check or a dependency library version matching check.

[0088] In this embodiment, the spare execution partition refers to an independent storage area used to store the new firmware version. It can be an inactive partition in an A / B partition architecture or a shadow partition. In this embodiment, the data flashing command refers to the firmware writing control command sent by the master controller to the slave controller. It can be a SOME / IP flashing service call or a UDS flashing diagnostic command.

[0089] In this embodiment, a specific way to verify the first firmware upgrade data and the second firmware upgrade data and obtain the verification result is as follows: the SOC calls the hardware security module to perform ECDSA signature verification, SHA-256 hash comparison and version number parsing on the firmware package, and generates a verification report containing the three check results.

[0090] In this embodiment, a specific way to verify the first firmware upgrade data and the second firmware upgrade data and obtain the verification result is as follows: the SOC executes a multi-level verification process, first verifying the integrity of the firmware package, then checking the legality of the digital signature, and finally comparing the version dependency relationship. If any check fails, the verification is marked as unsuccessful.

[0091] In this embodiment, under the condition that the verification result indicates that the verification is passed, a specific way to write the first firmware upgrade data into the spare execution partition of the first vehicle controller and send a data flashing command to the second vehicle controller can be: after the verification is passed, the SOC writes the firmware data into the spare partition in blocks, performs a CRC check every 1MB written, and sends a flashing command with a check code to the MCU after all writing is completed.

[0092] In this embodiment, under the condition that the verification result indicates that the verification is passed, a specific way to write the first firmware upgrade data into the spare execution partition of the first vehicle controller and send a data flashing instruction to the second vehicle controller can be: the SOC calls the Flash driver interface to program the firmware data into the spare partition in units of pages, while recording the write log. After completion, the MCU is notified to start flashing via the SOME / IP protocol.

[0093] In this embodiment, a specific way to obtain the flashing results of the first firmware upgrade data and the second firmware upgrade data can be: the SOC monitors its own flashing progress and receives the flashing status reported by the MCU, including success / failure indicators, number of bytes written, verification results, and other information.

[0094] In this embodiment, a specific method for obtaining the flashing results of the first firmware upgrade data and the second firmware upgrade data can be: the SOC sets a timeout timer to wait for the MCU to confirm the completion of the flashing process; if no response is received after the timeout, the flashing status is actively queried, and the flashing results of both chips are summarized. In this embodiment, a specific way to upgrade the firmware to be upgraded based on the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data can be as follows: when both chips are successfully flashed, the SOC prepares to perform partition switching; if either fails, a rollback process is triggered to ensure system consistency.

[0095] In this embodiment, a specific way to upgrade the firmware to be upgraded based on the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data is as follows: the SOC decides on subsequent actions based on the flashing results; if successful, it enters the submission stage; if it fails, it performs data cleanup and state recovery.

[0096] In the above implementation process, the firmware upgrade data can be verified before data is flashed, thereby ensuring that the flashed data is complete and undamaged.

[0097] For example, after the firmware download is complete, the system first performs triple verification on the 3GB SOC firmware and the 1.5GB MCU firmware: verifying the digital signature to confirm the firmware's legitimate origin, comparing the SHA-256 hash value to ensure data integrity, and checking the version number to confirm compatibility with the vehicle's current configuration. After successful verification, the SOC securely writes the firmware to the backup partition, and simultaneously instructs the MCU to begin flashing. The entire verification process is completed within 30 seconds, avoiding flashing failures due to firmware corruption or version incompatibility.

[0098] In an optional implementation, upgrading the firmware based on its upgrade data further includes the following sub-steps: If the verification result indicates that the verification fails, the flashing of the first firmware upgrade data and the second firmware upgrade data will be stopped.

[0099] In this embodiment, "verification failure" refers to the determination result that the firmware data has legality, integrity or compatibility issues during the data verification process. This could be a signature verification failure or a hash value mismatch.

[0100] In this embodiment, stopping the flashing process refers to a security control action that immediately stops the firmware data writing operation when an anomaly is detected. This can be either immediately terminating the writing process or rolling back the data that has already been written.

[0101] In this embodiment, illegal data refers to firmware upgrade data that does not meet security specifications or integrity requirements. This data can be malicious firmware that has been tampered with, or data packets that have been transmitted corrupted.

[0102] In this embodiment, a specific way to stop writing the first firmware upgrade data and the second firmware upgrade data when the verification result indicates that the verification fails can be as follows: when the verification finds that the firmware signature is invalid, the SOC immediately terminates the Flash write operation, releases the allocated buffer, records the security log and reports the error code.

[0103] In this embodiment, a specific way to stop flashing the first firmware upgrade data and the second firmware upgrade data when the verification result indicates that the verification failed can be as follows: after the SOC detects the hash verification failure, it calls the emergency stop interface, interrupts all flashing threads, clears temporary files, and sends a verification failure alarm to the cockpit controller.

[0104] In the above implementation process, if the verification result indicates that the verification fails, the writing process is stopped, thereby avoiding system upgrades based on incomplete or damaged illegal data.

[0105] For example, the OTA update system of a vehicle detected that the hash value of the firmware package downloaded from the test server did not match the expected value. The system immediately stopped the flashing operation to prevent the corrupted firmware from being written to the controller. Investigation revealed that data packet loss occurred during transmission on the test server, resulting in an incomplete firmware package.

[0106] In an optional implementation, the first firmware upgrade data and the second firmware upgrade data are flashed in parallel.

[0107] In this embodiment, parallel flashing refers to a collaborative mechanism in which multiple controllers simultaneously perform firmware data writing operations. This can be either dual-thread synchronous flashing or asynchronous concurrent flashing.

[0108] In this embodiment, the flashing time refers to the total time required to complete the firmware data writing operation, which can be the Flash programming time or the total time including verification.

[0109] In this embodiment, a specific implementation method for parallel flashing of the first firmware upgrade data and the second firmware upgrade data is as follows: the SOC starts two independent flashing threads, the main thread is responsible for its own Flash programming, and the secondary thread coordinates the MCU to start flashing synchronously through the SOME / IP protocol. The two threads execute in parallel according to a preset rhythm.

[0110] In this embodiment, a specific way to implement the parallel flashing of the first firmware upgrade data and the second firmware upgrade data is as follows: the SOC and the MCU each call their local Flash drivers and perform data writing operations simultaneously. The SOC periodically exchanges flashing progress with the MCU to ensure that both are in sync.

[0111] In the above implementation process, the parallel flashing of the second firmware upgrade data and the first firmware upgrade data can shorten the flashing time, further improve the upgrade speed, and shorten the upgrade time required.

[0112] For example, in vehicle software iteration and upgrade scenarios, traditional serial flashing requires first writing 3GB of firmware to the SOC (approximately 8 minutes), and then writing 1.5GB of firmware to the MCU (approximately 4 minutes), for a total time of 12 minutes. With the parallel flashing mechanism of this embodiment, the SOC and MCU begin flashing operations simultaneously. The SOC completes its firmware writing in 8 minutes, and the MCU completes its flashing in 4 minutes before entering a waiting state, reducing the total time to 8 minutes.

[0113] In an optional implementation, upgrading the firmware based on its upgrade data further includes the following sub-steps: If the flashing result of the first firmware upgrade data is a flashing failure, and / or the flashing result of the second firmware upgrade data is a flashing failure, the first firmware upgrade data is deleted, and a deletion command is sent to the second vehicle controller; wherein, the second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

[0114] In this embodiment, flashing failure refers to a state in which an error occurs during the firmware data writing process, resulting in the operation not being completed. This could be a Flash programming error or a verification failure rollback.

[0115] In this embodiment, the semi-upgrade state refers to an inconsistent state in which some controllers have completed the upgrade while others have not. This state can be either a complete upgrade of the SOC but not the MCU, or an intermediate state of version mismatch.

[0116] In this embodiment, the risk of functional abnormality refers to the controller malfunction or safety issues that may result from inconsistent system states. These issues may include communication protocol incompatibility or functional logic conflicts.

[0117] In this embodiment, under the condition that the flashing result of the first firmware upgrade data is a flashing failure, and / or the flashing result of the second firmware upgrade data is a flashing failure, a specific implementation of deleting the first firmware upgrade data and sending a deletion command to the second vehicle controller is as follows: when the SOC detects that the MCU reports a flashing failure, it immediately calls the secure erase function to delete the firmware data it has already written, and at the same time sends a deletion command with a transaction ID to the MCU.

[0118] In this embodiment, under the condition that the flashing result of the first firmware upgrade data is a flashing failure, and / or the flashing result of the second firmware upgrade data is a flashing failure, a specific implementation of deleting the first firmware upgrade data and sending a deletion command to the second vehicle controller is as follows: the SOC monitors the flashing status of the two chips, and if either fails, it initiates an atomic rollback transaction, first rolls back its own status, and then instructs the MCU to delete the data, ensuring that the status of both chips is consistent.

[0119] In this embodiment, a specific way for the second vehicle controller to delete the second firmware upgrade data based on the deletion command is as follows: after receiving the deletion command, the MCU verifies the validity of the command, calls the Flash Erasure API to clear the upgrade partition, and updates the status register to "rollback complete".

[0120] In this embodiment, a specific method for the second vehicle controller to delete the second firmware upgrade data based on the deletion command is as follows: the MCU executes a secure deletion process, first marking the data as invalid, then physically erasing it, and finally sending a confirmation response to the SOC to complete the rollback operation.

[0121] In the above implementation process, if any controller fails to be written, all controllers will be rolled back to avoid the risk of controller malfunction due to the semi-upgrade state.

[0122] For example, upon detecting an anomaly, the system immediately triggers a global rollback: the SOC deletes its own 2.5GB of written firmware data, while simultaneously instructing the MCU to erase 1.2GB of corrupted data. The entire rollback process is completed within 15 seconds, restoring the vehicle's intelligent driving system to its stable state before the upgrade. This atomic rollback mechanism avoids the communication protocol incompatibility issues caused by a "semi-upgrade" state, where the SOC runs the new version while the MCU remains on the old version.

[0123] In an optional implementation, upgrading the firmware based on its upgrade data further includes the following sub-steps: Under the conditions that the flashing result of the first firmware upgrade data is successful and the flashing result of the second firmware upgrade data is successful, the firmware boot partition of the first vehicle controller is switched to the storage partition where the first firmware upgrade data is located, and a partition switching command is sent to the second vehicle controller. The second vehicle controller is configured to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching command.

[0124] In this embodiment, successful flashing means that the firmware data has been written completely and without error to the controller's storage area and has passed the verification. This can be either a successful write verification or a successful integrity verification.

[0125] In this embodiment, the firmware boot partition refers to the firmware storage area that is loaded and executed when the controller starts up. It can be the active A partition or the master boot partition.

[0126] In this embodiment, a storage partition refers to an independent logical storage area divided in the controller's Flash memory, which can be a spare B partition or a shadow update partition.

[0127] In this embodiment, the partition switching command refers to the partition switching control command sent by the master controller to the slave controller. It can be the SOME / IP partition switching service or a boot configuration update command.

[0128] In this embodiment, under the condition that the flashing result of the first firmware upgrade data is successful and the flashing result of the second firmware upgrade data is successful, a specific way to switch the firmware boot partition of the first vehicle controller to the storage partition where the first firmware upgrade data is located is as follows: after both chips are successfully flashed, the SOC updates the boot configuration register, switches the boot partition pointer from the current partition A to partition B containing the new firmware, and updates the version information at the same time.

[0129] In this embodiment, under the condition that the flashing result of the first firmware upgrade data is successful and the flashing result of the second firmware upgrade data is successful, a specific way to switch the firmware boot partition of the first vehicle controller to the storage partition where the first firmware upgrade data is located is as follows: the SOC calls the boot management interface, atomically updates the partition mapping table, sets the new partition as the active partition for the next boot, records the switching log, and prepares for restart.

[0130] In this embodiment, a specific way to send a partition switching command to the second vehicle controller, and configure the second vehicle controller to switch its boot partition to the storage partition where the second firmware upgrade data is located based on the partition switching command, is as follows: the SOC sends a digitally signed partition switching command to the MCU through the SOME / IP protocol. After verification, the MCU updates its own boot configuration and switches the boot partition to the area where the new firmware is located.

[0131] In this embodiment, a specific way to send a partition switching command to the second vehicle controller and configure the second vehicle controller to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching command can be as follows: after the MCU receives the command, it executes a safe switching process, first backs up the current configuration, then updates the partition pointer, and finally confirms the switching is complete to the SOC.

[0132] In this embodiment, a specific way to configure the second vehicle controller to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching instruction can be as follows: the MCU parses the partition switching instruction, calls the underlying Flash driver to update the partition mapping information of the boot sector, and sets the new firmware partition as the active boot partition.

[0133] In this embodiment, a specific way in which the second vehicle controller is configured to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching command can be: the MCU performs an atomic switching operation to ensure that no intermediate state occurs during the switching process, and sends a successful switching confirmation to the SOC after the update is completed.

[0134] In the above implementation process, if both the first vehicle controller and the second vehicle controller are successfully flashed, a partition switching operation is performed to enable the first vehicle controller and the second vehicle controller to execute the new version of firmware, thereby completing the firmware upgrade.

[0135] For example, a certain vehicle model needs to upgrade both the SOC and MCU of its intelligent driving system from V1.2 to V2.0 simultaneously. After both chips are successfully flashed with firmware, the system performs an atomic partition switch: the SOC switches its boot partition from region A to region B, and the MCU simultaneously switches its boot partition to the new firmware region. After the switch is complete, both controllers load the V2.0 firmware simultaneously when the vehicle restarts, ensuring system version consistency. This collaborative switching mechanism avoids version fragmentation issues, i.e., functional abnormalities caused by different controllers running different versions.

[0136] Please see Figure 2 , Figure 2This is a schematic diagram of a firmware upgrade device provided in an embodiment of this application. The firmware upgrade device is applied to a first vehicle controller. Figure 2 As shown, the firmware upgrade device includes the following functional modules: The first acquisition module 201 is used to acquire the verification metadata of the firmware to be upgraded; The signature verification module 202 is used to obtain the signature verification result based on the verification metadata of the firmware to be upgraded; The second acquisition module 203 is used to acquire the upgrade data of the firmware to be upgraded when the conditions for downloading the upgrade data of the firmware to be upgraded are met; wherein, the conditions for downloading the upgrade data of the firmware to be upgraded include at least the signature verification result indicating that the verification metadata verification has passed; The upgrade execution module 204 is used to upgrade the firmware to be upgraded based on the upgrade data of the firmware to be upgraded.

[0137] In the above implementation process, by signing and verifying the verification metadata, the integrity and legality of the upgrade data can be verified, preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. At the same time, since upgrade data is only downloaded after the verification metadata has passed, invalid downloads of upgrade data can be avoided, thus preventing invalid upgrade data downloads from consuming download bandwidth.

[0138] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 3 As shown, the electronic device includes: Processor 301; and The memory 302 is configured to store machine-readable instructions that, when executed by the processor 301, perform the method as described in any of the foregoing embodiments.

[0139] In the aforementioned implementation process, the electronic device, by executing a firmware upgrade method, can perform signature verification on the verification metadata, thereby verifying the integrity and legality of the upgrade data and preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. Simultaneously, since upgrade data is only downloaded after the verification metadata has been verified, invalid downloads of upgrade data are avoided, thus preventing invalid upgrade data downloads from consuming download bandwidth.

[0140] Furthermore, embodiments of this application also provide a storage medium storing a computer program, which is executed by a processor using the method described in any of the foregoing embodiments.

[0141] In the aforementioned implementation process, the storage medium, by executing the firmware upgrade method, can perform signature verification on the verification metadata, thereby verifying the integrity and legality of the upgrade data and preventing unauthorized or incomplete upgrade data from causing vehicle system security issues. Simultaneously, since upgrade data is only downloaded after the verification metadata has been verified, invalid downloads of upgrade data are avoided, thus preventing invalid upgrade data downloads from consuming download bandwidth.

[0142] To facilitate a further understanding of the embodiments of this application, a specific example is provided. (Refer to...) Figure 4 , Figure 4 This is a schematic diagram of an OTA upgrade system for a heterogeneous architecture of an intelligent driving controller provided in an embodiment of this application, which is applied to OTA upgrade scenarios for intelligent driving controllers. Figure 4 The main hardware components involved in this system include: Cloud server: As the sole legal source of issuance for the vehicle OTA upgrade package, it is responsible for the generation of upgrade packages and metadata, ECDSA-256 encrypted signature and distribution, provides a secure communication channel between the vehicle and the cloud, does not participate in the vehicle-side upgrade process scheduling, and is compatible with automotive-grade APN private network and TLS secure communication.

[0143] Cockpit Domain Controller: As the sole master control unit for vehicle OTA upgrades, it is only responsible for confirming upgrade intentions, obtaining user authorization, issuing upgrade commands, displaying upgrade status and summarizing results. It does not participate in the relaying of any upgrade packages / metadata, completely isolating the control link and data link, and interacting with the SOC through the automotive-grade DoIP protocol.

[0144] Intelligent Driving Domain Controller: It has a built-in SOC and MCU. The SOC is a high-performance automotive-grade SOC, which serves as the unified OTA scheduling center inside the intelligent driving controller. The OTA-Slave function module is deployed in this unit and is responsible for metadata download and signature verification, unified scheduling of domain upgrades, firmware download and flashing, security control of the entire upgrade process, and main control responsibilities for abnormal rollback. It communicates with the MCU through the SOME / IP protocol.

[0145] The MCU adopts a high-safety automotive-grade MCU that meets the ASIL-D functional safety level. As a safety control unit for the execution layer of the intelligent driving domain, it has independent Ethernet access capability and is responsible for its own firmware to be independently downloaded directly to the cloud, verified locally and flashed. It works with the SOC to complete cross-chip collaborative upgrades and global synchronous rollback.

[0146] Furthermore, the DoIP protocol is used to realize command interaction between the cockpit domain controller and the SOC; the SOME / IP protocol is used to realize inter-chip communication between the SOC and the MCU; and the ECDSA-256 algorithm is used to realize security signature verification, which meets the mandatory requirements of UNECE R156 regulations.

[0147] Furthermore, the OTA upgrade process in this embodiment includes the following four stages: Upgrade preparation and pre-approval phase: After the cockpit domain controller and cloud server confirm the upgradable version, an OTA upgrade request is sent to the SOC. Please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of an OTA upgrade process provided in an embodiment of this application, such as... Figure 5 As shown, after the SOC completes the request's legitimacy verification, it directly connects to the cloud to download the metadata data package and completes ECDSA-256 signature verification. Upon successful signature verification, the status is reported to the cockpit domain controller; if signature verification fails, the process is terminated and an error is reported. Specifically, the metadata pre-verification mechanism completes metadata signature verification for only one-thousandth the size of the full firmware package before downloading. Only after successful signature verification does the full download begin, blocking the risk of unauthorized firmware downloads and flashing at the source. Furthermore, for large firmware packages (GB-level), this saves over 90% of wasted public network bandwidth and in-vehicle storage resources.

[0148] Parallel Download and Collaborative Preparation Phase: After obtaining formal upgrade authorization from the user, the cockpit domain controller issues formal upgrade control commands to the SOC. The SOC generates a globally unique transaction ID and issues download permission to the MCU. The SOC and MCU synchronously connect directly to the cloud to download their own firmware packages, synchronizing download progress in real time. After completing the download and local verification, the upgrade is confirmed to be ready. This approach employs SOC master control scheduling and MCU direct-connection parallel download technology, allowing the MCU to independently download firmware without SOC relay, executing the upgrade process completely in parallel with the SOC's own upgrade process. Compared to traditional serial solutions, this reduces the total upgrade time by more than 40%. Simultaneously, it fully utilizes the MCU's built-in Ethernet hardware capabilities, eliminating the bandwidth bottleneck of SOC relay and reducing the SOC's data forwarding load by more than 30%.

[0149] Atomic Upgrade and Closed-Loop Stages: Reference Figure 6 , Figure 6 This is a schematic diagram of an atomic upgrade process provided in an embodiment of this application. Figure 6 As shown, the SOC and MCU synchronously execute a three-stage atomic upgrade process, completing the entire process of pre-verification, parallel flashing, and atomic commit / global rollback. After the upgrade is completed, the SOC reports the final upgrade result to the cockpit domain controller, completing the entire OTA process loop. The "pre-verification-parallel flashing-atomic commit / global rollback" closed-loop process ensures firmware version consistency between the SOC and MCU, meets ASIL-D functional safety requirements, and completely eliminates the risk of controller malfunctions caused by a "semi-upgrade" state.

[0150] Anomaly Handling Phase: During the upgrade process, if issues such as signature verification failure, download verification anomaly, or flashing failure occur, the corresponding process branch will be executed to terminate or perform a global rollback operation. The SOC will report the error information to the cockpit domain controller to ensure that the intelligent driving controller functions normally and meets automotive safety requirements.

[0151] Furthermore, referring to Table 1, this implementation method also achieves the following core functions by binding the entire upgrade process with a globally unique transaction ID: Table 1

[0152] Furthermore, referring to Figure 7a , Figure 7b and Figure 7c , Figure 7a This is a first schematic diagram of a breakpoint resume process provided in an embodiment of this application. Figure 7b This is a second schematic diagram of a breakpoint resume process provided in an embodiment of this application. Figure 7c This is a third schematic diagram of a breakpoint resume process provided in an embodiment of this application, wherein, Figure 7a , Figure 7b and Figure 7c The breakpoint resume process shown constitutes a complete breakpoint resume process. For example... Figure 7a , Figure 7b and Figure 7c As shown, the breakpoint resume process in this implementation is independent of the original four-stage vehicle OTA, forming a self-closing logic of "interruption trigger → state persistence → recovery trigger → context recovery → resume execution → process regression / closure". The entire process is uniformly scheduled by the SOC, without cloud-based involvement in core resume operations. The global transaction ID plays the following role in breakpoint resume: Unique index for breakpoint status: Binds to core interrupt information, persistently stores it, and realizes a unified index for interrupt status across all stages; Dual-chip resume transmission synchronous scheduling: As a synchronization credential, it ensures that the resume transmission rhythm of the two chips is consistent and adapts to heterogeneous dual-chip architecture. Resumption permission verification: As a credential for resuming the download, it rejects illegal TIDs, ensures the security of resuming the download, and meets automotive-grade requirements; Multi-round interruption resume: Update and bind the progress of multiple interruptions, and resume the transmission from the most recent breakpoint to improve efficiency; Resumption process closed loop: Mark the resumption status, trigger rollback / return to the original process, reclaim TID according to rules, and realize full process control.

[0153] Among them, a cross-chip collaboration mechanism based on a globally unique transaction ID is designed, and the entire upgrade process is bound to a unified transaction ID. This enables real-time synchronization of SOC and MCU upgrade progress, collaborative breakpoint resume after network interruption, and dynamic bandwidth priority scheduling based on real-time status, which increases the upgrade success rate to over 99.9% and significantly improves upgrade stability in complex environments such as weak networks.

[0154] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0155] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0157] It should be noted that if a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0158] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0159] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A firmware upgrade method, characterized in that, The method is applied to a first vehicle-mounted controller, and the method includes: Obtain the verification metadata of the firmware to be upgraded; Based on the verification metadata of the firmware to be upgraded, the signature verification result is obtained; Under the condition that the upgrade data of the firmware to be upgraded is downloaded, the upgrade data of the firmware to be upgraded is obtained; wherein, the condition for downloading the upgrade data of the firmware to be upgraded includes at least the signature verification result indicating that the verification metadata verification is passed, and the upgrade data of the firmware to be upgraded includes first firmware upgrade data and second firmware upgrade data. The firmware to be upgraded is upgraded based on the upgrade data of the firmware to be upgraded; Obtain the context recovery status and resume status of the first vehicle controller, and the context recovery status and resume status of the second vehicle controller; If the context recovery status of any vehicle controller indicates context recovery failure, or the resume status of any vehicle controller indicates resume abnormality, the first firmware upgrade data is deleted, and a deletion command is sent to the second vehicle controller; wherein, the second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

2. The method according to claim 1, characterized in that, The step of obtaining the upgrade data for the firmware to be upgraded includes: Obtain the first firmware upgrade data; A download license message is sent to a second vehicle controller, which is configured to obtain the second firmware upgrade data based on the download license message; wherein the second vehicle controller and the first vehicle controller download the firmware upgrade data in parallel.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network; Based on the download progress of the first firmware upgrade data, the download progress of the second firmware upgrade data, and the status data of the download network, the bandwidth allocation priority of the first vehicle controller relative to the second vehicle controller is determined. The download bandwidth for the first vehicle controller and the download bandwidth for the second vehicle controller are allocated based on the bandwidth allocation priority; wherein, the download progress of the first firmware upgrade data is synchronized with the download progress of the second firmware upgrade data.

4. The method according to claim 2, characterized in that, The upgrade of the firmware to be upgraded based on the upgrade data of the firmware to be upgraded includes: The first firmware upgrade data and the second firmware upgrade data are validated to obtain a validation result; wherein, the data validation includes at least legality validation, integrity validation and version compatibility validation. Under the condition that the verification result indicates that the verification is passed, the first firmware upgrade data is written into the spare execution partition of the first vehicle controller, and a data flashing command is sent to the second vehicle controller. The second vehicle controller is configured to flash the second firmware upgrade data to the spare execution partition of the second vehicle controller based on the data flashing command. Obtain the flashing result of the first firmware upgrade data and the flashing result of the second firmware upgrade data; The firmware to be upgraded is upgraded based on the flashing results of the first firmware upgrade data and the flashing results of the second firmware upgrade data.

5. The method according to claim 4, characterized in that, in, The first firmware upgrade data and the second firmware upgrade data are flashed in parallel.

6. The method according to claim 4, characterized in that, The upgrade of the firmware to be upgraded based on the upgrade data of the firmware to be upgraded also includes: If the flashing result of the first firmware upgrade data is a flashing failure, and / or the flashing result of the second firmware upgrade data is a flashing failure, delete the first firmware upgrade data and send a deletion command to the second vehicle controller. The second vehicle controller is configured to delete the second firmware upgrade data based on the deletion command.

7. The method according to claim 4, characterized in that, The upgrade of the firmware to be upgraded based on the upgrade data of the firmware to be upgraded also includes: Under the condition that the flashing result of the first firmware upgrade data is successful and the flashing result of the second firmware upgrade data is successful, the firmware boot partition of the first vehicle controller is switched to the storage partition where the first firmware upgrade data is located, and a partition switching command is sent to the second vehicle controller. The second vehicle controller is configured to switch the boot partition of the second vehicle controller to the storage partition where the second firmware upgrade data is located based on the partition switching command.

8. An electronic device, characterized in that, include: processor; as well as A memory configured to store machine-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-7.

9. A storage medium, characterized in that, The storage medium stores a computer program, which is executed by a processor according to any one of claims 1-7.

Images