Vehicle-mounted controller non-inductive silent flashing method, system and device based on double-partition architecture and medium

Abstract

The invention relates to the technical field of vehicle-mounted controller flashing, in particular to a vehicle-mounted controller non-inductive silent flashing method, system and device based on a double-partition architecture and a medium, and the method comprises the steps: pre-downloading a to-be-upgraded firmware package, a digital signature and a signature verification public key to the local in a vehicle networking state; automatically triggering a process based on a vehicle state or a cycle time; after triggering, performing primary asymmetric signature verification on the firmware package; after passing, writing the differential data block into a backup partition of the controller by adopting a block differential transmission and verification mechanism; after writing is completed, secondary asymmetric signature verification is carried out on the complete firmware image in the backup partition; and after the starting configuration is updated, the controller is automatically switched to the backup partition for operation when the controller is powered on next time. According to the method, a user does not perceive the upgrading process, and the safety and the efficiency are improved through double signature verification and differential writing.

Description

Technical Field

[0001] This application relates to the field of vehicle controller flashing technology, specifically to a method, system, device, and medium for sensorless silent flashing of vehicle controllers based on a dual-partition architecture. Background Technology

[0002] As the new energy vehicle industry evolves towards greater intelligence and connectivity, the functions of on-board electronic controllers are becoming increasingly complex, leading to frequent software iteration requirements. Over-the-air (OTA) firmware upgrades for controllers—to fix vulnerabilities, improve performance, or add functionality—have become a crucial means of ensuring the continuous evolution and safe operation of vehicles.

[0003] Existing vehicle controller firmware upgrade solutions typically focus on addressing the issues of remote and automated software updates. Common solutions include the following basic process: a signed firmware package is released from a cloud server and distributed to the vehicle's connected devices via a wireless network; the vehicle verifies the integrity of the firmware package after certain conditions are met (e.g., the vehicle is stationary); upon successful verification, the new firmware data is written to the controller's storage area, and finally, the version switch is completed by restarting the controller. To improve the reliability of the upgrade process, some solutions introduce the concept of a backup partition, where the new firmware is written to a separate partition, and then the boot parameters are modified to boot into the new partition.

[0004] However, existing onboard controller firmware upgrade methods still have significant limitations in practical applications, especially in new energy commercial vehicle scenarios that emphasize continuous operation: the upgrade process triggering mechanism is often relatively simple or relies on fixed timing, making it difficult to intelligently adapt to the diverse and dynamic actual operating conditions of vehicles. Upgrades may be initiated when the vehicle is about to be put into operation or is undergoing critical operations, causing unexpected interference to the operation plan; when writing new firmware data to the controller, a full transmission and overwrite method is usually adopted. Even if there are only minor changes between the old and new firmware, the entire firmware package needs to be transmitted and written. When network bandwidth is limited or the controller's writing speed is limited, it will consume a long upgrade time; at the security verification level, most solutions only verify the firmware package once before writing the data. After the data is completely written to the storage medium and before the formal switchover, there is a lack of a final verification step, which cannot completely eliminate the risk of data being damaged or tampered with during the writing process; in order to make the new firmware effective, the common practice is to immediately or arrange for the controller to be restarted after the writing is completed. This restart process will cause the controller function to be temporarily interrupted, making the vehicle unusable during the upgrade period and affecting the operational continuity of commercial vehicles. Summary of the Invention

[0005] To address the technical problems of existing vehicle controller firmware upgrade methods, such as unintelligent upgrade triggering mechanisms that easily interfere with operations, low efficiency of full data transmission, inability to ensure data integrity after writing due to single security verification, and the need for immediate restart during upgrades that cause vehicle function interruption, this application provides a method, system, device, and medium for seamless silent flashing of vehicle controllers based on a dual-partition architecture. Through intelligent state or periodic triggering, block differential transmission writing, dual asymmetric signature verification, and startup configuration update combined with the next power-on switch, it achieves secure, efficient, and user-unnoticed silent flashing of vehicle controllers.

[0006] Firstly, this application provides a method for seamless silent flashing of an in-vehicle controller based on a dual-partition architecture, applicable to an in-vehicle controller configured with two partitions, wherein the partition currently running the in-vehicle controller firmware package is defined as the currently running partition, and the other partition is defined as the backup partition. The method includes the following steps: S1. When the vehicle is connected to the network, obtain the firmware package of the on-board controller to be upgraded, the corresponding digital signature and verification public key from the cloud server, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The digital signature is generated by the cloud server using a private key pair paired with the signature verification public key in the firmware package; S2. Trigger the flashing process when the preset vehicle status conditions are met or the preset periodic time point is reached; S3. In response to the flashing process, use the signature verification public key and digital signature to perform a first-level asymmetric signature verification on the firmware package; S4. After the first-level asymmetric signature verification is passed, the firmware data to be upgraded in the firmware package is written to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and writes the data block that is inconsistent with the data in the corresponding position in the backup partition as the firmware data to be upgraded. S5. After writing is complete, the data in the current backup partition is used as the firmware image to be upgraded. The signature verification public key and digital signature are used to perform secondary asymmetric signature verification on the firmware image to be upgraded. S6. After the secondary asymmetric signature verification is successful, update the boot configuration of the vehicle controller and designate the current backup partition as the primary boot partition for the next power-on. S7. When the vehicle controller is powered on again, switch the partition in which the vehicle controller is running to the current backup partition and set that partition as the new current running partition.

[0007] It should be further noted that the core processor of the vehicle controller is the Infineon TC275 chip; the configuration of the two partitions is achieved by the dual PFLASH storage partitions of the TC275 chip.

[0008] It should be further noted that in step S1, the digital signature is generated by the cloud server using its private key to sign the firmware package; The verification public key is a public key paired with the private key of the cloud server, and is synchronously distributed to the vehicle by the cloud server.

[0009] It should be further noted that the signature verification public key is updated according to the dynamic key management strategy; Dynamic key management strategies include: The cloud server generates new asymmetric key pairs according to a preset number of times or a preset period, and distributes the new public key to the vehicle through a secure channel.

[0010] It should be further noted that in step S2, the preset vehicle status conditions include: the vehicle is in a non-charging state, a stationary state, and the ignition switch is on and has not been set by the user to a mode that prohibits flashing.

[0011] It should be further noted that in step S2, the vehicle CAN bus signal is monitored in real time to determine whether the preset vehicle state conditions are met.

[0012] It should be further explained that step S3, which involves using the verification public key and digital signature to perform a first-level asymmetric signature verification on the firmware package, specifically includes: S301. Read the firmware package and calculate its firmware package hash value; S302. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S303. Compare the firmware package hash value with the original hash value; if they match, the first-level asymmetric signature verification passes.

[0013] It should be further noted that in step S3, the hardware security module in the TBOX on the vehicle side performs the first-level asymmetric signature verification of the firmware package.

[0014] It should be further explained that in step S4, the block differential transmission and verification mechanism specifically includes: S401. Divide the data in the firmware package into multiple fixed-size data blocks; S402. For each data block, calculate its first hash value; S403. Obtain the second hash value of the existing data at the corresponding location in the backup partition; S404. Compare the first hash value with the second hash value; if they match, skip the transmission and writing of the current data block; otherwise, transmit the current data block as the firmware to be upgraded and write it to the backup partition of the vehicle controller.

[0015] It should be further noted that in step S401, the data block size is 4KB.

[0016] It should be further noted that the SHA256 algorithm is used to calculate the first hash value and the second hash value.

[0017] It should be further noted that in step S404, after writing the data block, a post-write verification sub-step is also included, specifically including: Reread the data already written to the backup partition, calculate its third hash value, and compare it with the first hash value of the data block. If the comparison results are consistent, then this post-verification is passed; If the comparison results are inconsistent, the current data block write is determined to have failed, and write failure handling for the current data block is triggered.

[0018] It should be further explained that the handling of write failure for the current data block is as follows: re-execute the transmission and writing of the current data block, and perform the post-write verification sub-step again; if the post-write verification still fails within the preset number of times, the entire flashing process is terminated, and the vehicle controller continues to run in the current operating partition.

[0019] It should be further noted that a fault rollback step is also included: if the signature verification fails in either step S3 or step S5, the flashing process is terminated, the temporary state is cleared, and the vehicle controller continues to run in the current operating partition.

[0020] It should be further explained that in step S5, taking the data in the current backup partition as the firmware image to be upgraded specifically means: after writing all the firmware data to be upgraded, reading the entire storage space of the backup partition as a whole, and taking the read continuous data as the complete firmware image to be upgraded.

[0021] It should be further explained that step S5, which involves using the verification public key and digital signature to perform secondary asymmetric signature verification on the firmware image to be upgraded, specifically includes: S501. Read the firmware image to be upgraded from the backup partition and calculate its image hash value; S502. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S503. Compare the image hash value with the original hash value; if they match, the second-level asymmetric signature verification passes.

[0022] It should be further noted that in step S7, the partition switching is performed by the safe startup mechanism of the vehicle controller; The secure boot mechanism first reads the boot configuration when the vehicle controller is powered on again. If the boot configuration specifies the current backup partition as the master boot partition for the next power-on, then the integrity of the complete firmware image in the current backup partition is verified. Only after the integrity verification is passed will the boot from the current backup partition be actually executed.

[0023] It should be further noted that the integrity check is a CRC check.

[0024] It should be further noted that if the integrity verification fails, the secure boot mechanism ignores the boot configuration and controls the vehicle controller to continue booting from the currently running partition.

[0025] Secondly, this application provides a vehicle controller sensorless silent flashing system based on a dual-partition architecture, used to implement the aforementioned vehicle controller sensorless silent flashing method, including: The firmware package acquisition module is used to obtain the firmware package, corresponding digital signature and verification public key of the vehicle controller to be upgraded from the cloud server when the vehicle is connected to the network, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The flashing process trigger module is used to trigger the flashing process when preset vehicle status conditions are met or preset periodic time points are reached. The Level 1 signature verification module is used to perform Level 1 asymmetric signature verification on firmware packages using the signature verification public key and digital signature. The data writing module is used to write the firmware data to be upgraded from the firmware package to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and only writes the data blocks that are inconsistent with the existing data in the backup partition as the firmware data to be upgraded. The secondary signature verification module is used to use the data in the current backup partition as the firmware image to be upgraded, and to perform secondary asymmetric signature verification on the firmware image to be upgraded using the signature verification public key and digital signature. The startup configuration update module is used to update the startup configuration of the vehicle controller and specify the current backup partition as the primary boot partition for the next power-on. The partition switching module is used to switch the partition in which the vehicle controller is running to the current backup partition when the vehicle controller is powered on again, and to make that partition the new current running partition.

[0026] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described vehicle controller silent flashing method.

[0027] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described vehicle controller's sensorless silent flashing method.

[0028] As can be seen from the above technical solutions, this application has the following advantages: 1. This application organically combines intelligent state triggering, differential high-efficiency transmission, dual security verification and seamless switching mechanism, working synergistically on a dual-partition hardware architecture. Ultimately, it achieves silent flashing of the on-board controller of new energy commercial vehicles without user awareness or operational interference, while ensuring extremely high security and reliability. This fundamentally solves the contradiction between traditional upgrade methods and the continuous operation requirements of commercial vehicles.

[0029] 2. This application can accurately identify when a vehicle is in a non-operational, safe upgrade window by triggering the flashing process when preset vehicle status conditions are met or preset periodic time points are reached. This automatically triggers the task, avoiding interference with normal transportation or operation arrangements caused by initiating upgrades at inappropriate times, and realizing intelligent perception and automatic decision-making in the upgrade process.

[0030] 3. This application employs a block-based differential transmission and verification mechanism during the writing process, writing only data blocks that are inconsistent with existing data in the backup partition as firmware data to be upgraded. By comparing hash values, it intelligently skips unchanged data blocks, transmitting and writing only the differences, which greatly improves upgrade efficiency. In the context of commercial vehicle mobile network environments with limited bandwidth and time resources, it can significantly shorten the upgrade time.

[0031] 4. This application constructs a dual security defense line throughout the upgrade process by combining first-level and second-level asymmetric signature verification. First-level signature verification ensures that the firmware package downloaded to the local machine is legitimate and has not been tampered with. Second-level signature verification verifies the integrity of the entire firmware image again after all data has been written to the backup partition, providing ultimate protection for the consistency of data during transmission and writing, and greatly reducing the risk of system startup failure due to data errors or malicious tampering.

[0032] 5. This application achieves truly seamless switching by updating the startup configuration and coordinating the switching when the vehicle controller is powered on again. The controller does not need to be restarted during this upgrade cycle. All operations are completed in the background in the backup partition, and the functions of the currently running partition are not affected in any way. The new firmware will take effect seamlessly in the next normal start-stop cycle of the vehicle, thereby ensuring the absolute continuity of vehicle operation. Attached Figure Description

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

[0034] Figure 1 This is a flowchart of a method for seamless silent flashing of an onboard controller based on a dual-partition architecture, according to one embodiment of this application.

[0035] Figure 2 This is a schematic block diagram of a vehicle controller silent flashing system based on a dual-partition architecture in one embodiment of this application.

[0036] Figure 3 This is a schematic diagram of the hardware structure of an electronic device in one embodiment of this application. Detailed Implementation

[0037] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] The following describes in detail the sensorless silent flashing method for vehicle controllers involved in this application. Specific details, such as particular system structures and technologies, are presented for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0039] In the vehicle controller silent flashing method disclosed in this application, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0040] To facilitate a clear description of the technical solutions of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0041] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0042] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0043] The vehicle controller silent flashing method provided in this application embodiment is executed by a computer device. Accordingly, the vehicle controller silent flashing system based on a dual-partition architecture runs in the computer device.

[0044] Figure 1 This is a flowchart of a method for seamless silent flashing of an in-vehicle controller based on a dual-partition architecture, according to an embodiment of this application. Figure 1 The execution entity can be a vehicle-mounted controller's seamless, silent flashing system. Depending on different requirements, the order of the steps in this flowchart can be changed, and some can be omitted.

[0045] like Figure 1 As shown, this silent flashing method for vehicle controllers based on a dual-partition architecture is applied to vehicle controllers configured to contain two partitions, where the partition containing the currently running vehicle controller firmware package is defined as the currently running partition, and the other partition is defined as the backup partition. The method includes the following steps: Step S1: When the vehicle is connected to the network, obtain the firmware package of the vehicle controller to be upgraded, the corresponding digital signature and verification public key from the cloud server, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The digital signature is generated by the cloud server using a private key pair paired with the signature verification public key in the firmware package.

[0046] By pre-downloading a complete upgrade data package containing the firmware package to be upgraded, digital signature, and verification public key to the vehicle's local storage unit while the vehicle is connected to the network, all the key data required for the subsequent upgrade process is already in place. This eliminates the need to temporarily retrieve the data from the network after the process is triggered, effectively avoiding the risk of upgrade process failure or interruption due to unstable network connection, delay, or interruption. This lays a solid local data foundation for achieving a reliable, continuous, and autonomously controllable silent flashing process in the complex and ever-changing vehicle mobile network environment, ensuring the stability of the premise and data accessibility of the entire upgrade task execution.

[0047] In some specific embodiments, the core processor of the vehicle controller is the Infineon TC275 chip; the configuration of the two partitions is implemented by the dual PFLASH storage partition of the TC275 chip.

[0048] By specifically defining the core processor of the vehicle controller as the Infineon TC275 chip, and clarifying that its two partitions are implemented by the chip's inherent dual PFLASH storage partition hardware, a definite and reliable physical hardware foundation is provided for the aforementioned seamless silent flashing method. The chip architecture natively supports two independent program storage spaces (Banks), which ensures the isolation, parallel operation capability, and fast switching characteristics of the primary partition and backup partition through direct chip-level hardware resources. This ensures the stability, efficiency, and feasibility of the entire dual-partition flashing scheme in terms of storage management, operational isolation, and secure boot.

[0049] In some specific embodiments, the digital signature is generated by a cloud server using its private key to sign the firmware package; The verification public key is a public key paired with the private key of the cloud server, and is synchronously distributed to the vehicle by the cloud server.

[0050] By explicitly stating that the digital signature is generated by the private key of the cloud server and the verification public key is the paired public key that is synchronously distributed from the cloud to the vehicle, the asymmetric cryptographic infrastructure and key distribution path on which the entire security verification system relies are established. This ensures that the public key used by the vehicle to perform signature verification has a strict mathematical correspondence with the private key of the signature generator, and that the public key originates from a trusted cloud server. This constructs a trusted credential transmission chain from a trusted source to the vehicle verification point, providing a fundamental logical premise and trust anchor for the validity and authority of all subsequent signature verification operations.

[0051] In some specific embodiments, the signature verification public key is updated according to a dynamic key management strategy; Dynamic key management strategies include: The cloud server generates new asymmetric key pairs according to a preset number of times or a preset period, and distributes the new public key to the vehicle through a secure channel.

[0052] By specifying that the verification public key is updated according to a dynamic key management strategy based on a preset number of times or a cycle, and that the cloud server generates new key pairs and distributes new public keys through a secure channel, the system introduces proactive key lifecycle management capabilities to long-running vehicle terminals. This allows the system to automatically rotate to a new key pair periodically or as needed, even if the security of a specific public-private key pair degrades due to long-term use or potential leakage risks. This maintains the forward security of the asymmetric signature verification system, effectively resists long-term security threats based on key cracking or accumulation attacks, and enhances the security resilience of the entire upgrade system throughout the vehicle's lifecycle.

[0053] Step S2: When the preset vehicle status conditions are met or the preset cycle time point is reached, the flashing process is triggered.

[0054] By automatically determining and triggering the flashing process based on preset vehicle status conditions or periodic time points, the initiation of the upgrade behavior is completely freed from the reliance on manual operation or simple timers in the traditional method. It realizes intelligent and automated decision-making on the timing of the upgrade, which can accurately adapt to the actual operation and maintenance cycle of the vehicle. It ensures that the upgrade operation is automatically started only when the vehicle is in a safe and idle working condition window, thereby completely avoiding unexpected interference and interruption of the upgrade process to the vehicle's normal transportation, operation and other core operational activities, and improving the coordination between the upgrade behavior and the operating rhythm of commercial vehicles.

[0055] In some specific embodiments, the preset vehicle state conditions include: the vehicle is in a non-charging state, a stationary state, and the ignition switch is on and has not been set by the user to a mode that prohibits flashing.

[0056] By specifically defining the preset vehicle state conditions as simultaneously satisfying the non-charging state, stationary state, ignition switch on and not prohibited by the user from flashing, the intelligent triggering mechanism sets clear, quantifiable, and common-sense multi-dimensional judgment criteria that conform to vehicle safety operation common sense. This combination of conditions ensures that the flashing process will only be triggered when the vehicle is in a standby state with power but not performing critical energy interaction tasks such as driving or charging, is in an absolutely stationary and safe state, and has obtained the user's default or active permission. Thus, at the logical level, it eliminates the risk of accidental vehicle movement, charging interruption, or violation of user will caused by the upgrade operation intervention to the greatest extent, and accurately defines the working condition boundary of safe upgrade.

[0057] In some specific embodiments, the preset vehicle state conditions are determined by real-time monitoring of the vehicle's CAN bus signals.

[0058] By monitoring the vehicle's CAN bus signals in real time to determine whether preset vehicle state conditions are met, a specific and reliable data source and implementation path are provided for state perception and triggering decisions. By utilizing the standardized CAN network inside the vehicle to acquire digital signals reflecting key states such as vehicle charging, speed, ignition, and user settings in real time, state judgment can be based on real, real-time, and authoritative in-vehicle network data, rather than potentially inaccurate or delayed indirect information. This significantly improves the accuracy, real-time performance, and system reliability of state perception, ensuring strict synchronization and matching between automatic triggering decisions and actual vehicle operating conditions.

[0059] Step S3: In response to the flashing process, the firmware package is subjected to a first-level asymmetric signature verification using the signature verification public key and digital signature.

[0060] By immediately performing a first-level asymmetric signature verification on the digital signature of the firmware package using a public key synchronized from the cloud after the flashing process is triggered, the first security verification checkpoint in the upgrade process is constructed. This directly verifies that the integrity of the data content and the authenticity of the source of the firmware package have not been damaged or forged during the flow from cloud release to vehicle storage. It effectively intercepts illegal, tampered or damaged firmware packages that may be introduced due to attacks on the transmission link or damage to the storage medium, providing an initial trust basis and security access for subsequent writing of data to the critical vehicle controller.

[0061] In some specific embodiments, performing first-level asymmetric signature verification on the firmware package using a verification public key and a digital signature specifically includes: S301. Read the firmware package and calculate its firmware package hash value; S302. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S303. Compare the firmware package hash value with the original hash value; if they match, the first-level asymmetric signature verification passes.

[0062] By specifically defining the first-level asymmetric signature verification as including three sub-steps—calculating the firmware package hash value, decrypting the signature using the public key to obtain the original hash value, and comparing them—this paper clearly reveals the core calculation and comparison process of a complete asymmetric signature verification operation. It comprehensively utilizes the collision resistance of hash algorithms to ensure that the data digest uniquely represents the firmware content, and the decryption characteristics of asymmetric encryption to verify the signature source. The data integrity and authenticity are determined by the final value comparison. Thus, the abstract concept of secure "signature verification" is transformed into a series of executable and verifiable specific calculation operations, clarifying the internal implementation logic and reliability basis of this security step.

[0063] In some specific embodiments, the hardware security module in the TBOX on the vehicle side performs the first-level asymmetric signature verification of the firmware package.

[0064] By specifying that the first-level asymmetric signature verification of the firmware package is performed by the hardware security module in the vehicle-side TBOX, the critical first-level security verification task is offloaded and deployed to a separate hardware unit designed specifically for secure computing. This hardware security module typically has physical anti-tampering, side-channel attack protection, and high-performance cryptographic operation acceleration capabilities. As a result, the signature verification operation can not only be completed at a higher speed, but more importantly, it can be carried out in a higher-security execution environment isolated from the general computing environment. This greatly reduces the risk of the signature verification process itself being interfered with by software attacks or the key information being leaked, and improves the robustness of the security verification link itself.

[0065] Step S4: After the first-level asymmetric signature verification is passed, the firmware data to be upgraded in the firmware package is written to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and the data block that is inconsistent with the corresponding data in the backup partition is written as the firmware data to be upgraded.

[0066] After the primary verification is passed, a block-based differential transmission and verification mechanism is adopted to filter and write only data blocks that are inconsistent with the existing data in the backup partition. This transforms the firmware data transmission and writing process from the traditional full-coverage mode to an intelligent incremental update mode. When the firmware to be upgraded is only slightly different from the current version, it can greatly reduce the total amount of data that needs to be transmitted between the vehicle's internal and external devices and written to the controller's flash memory. This significantly shortens the overall flashing operation time, reduces the occupation of in-vehicle communication bandwidth and controller write lifespan, and improves the execution efficiency of the upgrade process.

[0067] In some specific embodiments, the block differential transmission and verification mechanism specifically includes: S401. Divide the data in the firmware package into multiple fixed-size data blocks; S402. For each data block, calculate its first hash value; S403. Obtain the second hash value of the existing data at the corresponding location in the backup partition; S404. Compare the first hash value with the second hash value; if they match, skip the transmission and writing of the current data block; otherwise, transmit the current data block as the firmware to be upgraded and write it to the backup partition of the vehicle controller.

[0068] By specifically defining the block-based differential transmission and verification mechanism, including data block segmentation, calculation of the first hash value, acquisition of the second hash value at the corresponding location of the backup partition, and comparison to determine whether to skip, this paper elaborates on the implementation method of the core efficiency improvement method of "writing only inconsistent data blocks". By performing fine-grained hash fingerprint pre-comparison on a data block basis, redundant data blocks whose content has not changed are intelligently identified before transmission and writing, and subsequent operations on them are accurately skipped. This transforms the efficiency optimization logic from a conceptual level into clear and cyclically executable algorithmic steps, providing a clear operating procedure for achieving efficient differential upgrades.

[0069] In some specific embodiments, the data block size in step S401 is 4KB.

[0070] By specifically limiting the data block size to 4KB, a standardized operational granularity adapted to the characteristics of storage hardware is set for the block differential mechanism. This size is usually well aligned with the programming and erasing units of flash memory, the size of file system clusters, or network transmission packets. Using this fixed block size not only simplifies the logical complexity of block division, addressing, and management, but also reduces the read and write amplification effect caused by misalignment of block boundaries, thereby achieving a good balance between algorithm complexity and actual storage operation efficiency, ensuring that the differential comparison and writing process can be carried out efficiently and systematically.

[0071] In some specific embodiments, the SHA256 algorithm is used to calculate the first hash value and the second hash value.

[0072] By explicitly using the SHA256 algorithm to calculate the first and second hash values ​​involved in block differential transmission, a specific cryptographic hash function standard is provided for the unique identification and comparison of data blocks. The SHA256 algorithm has the characteristics of fixed output length (256 bits), high computational efficiency, and is widely regarded as having strong collision resistance. Applying it to the generation of data block fingerprints can ensure that data blocks with different contents have different hash values ​​with a very high probability. This makes the "skip" judgment based on hash value consistency extremely reliable, effectively avoiding the risk of data blocks that should be transmitted being skipped incorrectly due to hash collisions, and ensuring the accuracy and reliability of the differential mechanism.

[0073] In some specific embodiments, step S404, after writing the data block, further includes a post-write verification sub-step, specifically including: Reread the data already written to the backup partition, calculate its third hash value, and compare it with the first hash value of the data block. If the comparison results are consistent, then this post-verification is passed; If the comparison results are inconsistent, the current data block write is determined to have failed, and write failure handling for the current data block is triggered.

[0074] By adding a post-write verification sub-step after the data block write operation in step S404, namely rereading the written data and calculating the third hash value and comparing it with the original first hash value, an immediate consistency checkpoint is added to the write operation of each data block. This step can effectively capture accidental write errors that may be caused by circuit interference, storage cell defects or programming voltage fluctuations during the physical process of writing data from the transmission buffer to the non-volatile flash memory storage medium. This enables real-time, block-by-block verification of the write operation results, extending the guarantee of data integrity from the transmission link to the final physical storage level.

[0075] In some specific embodiments, the write failure handling for the current data block is as follows: re-execute the transmission and writing of the current data block, and perform the post-write verification sub-step again; if the post-write verification still fails within a preset number of times, terminate the entire flashing process, and keep the vehicle controller running in the current operating partition.

[0076] By specifying the handling of data block write failures as retrying transmission and writing within a preset number of times and verifying again, and terminating the entire process while maintaining the current running partition if it still fails, a recovery and response mechanism with fault tolerance and loss mitigation capabilities is designed for local and temporary faults that may occur during the block write process. This mechanism first attempts to overcome occasional write errors that may be caused by transient interference through a limited number of retries, providing an opportunity to continue the upgrade if the retry is successful; when the retry failure indicates that it may be a persistent fault, the system is globally terminated to control system risks and ensure that the vehicle controller always runs on a known and usable stable version, thereby improving the robustness of the upgrade process in the face of occasional anomalies in the underlying hardware.

[0077] Step S5: After writing is complete, the data in the current backup partition is used as the firmware image to be upgraded. The signature verification public key and digital signature are used to perform secondary asymmetric signature verification on the firmware image to be upgraded.

[0078] By performing a second-level asymmetric signature verification on the complete firmware image formed by the newly written data and the original data of the partition after writing all the difference data blocks to the backup partition, a secure verification mechanism for the final storage state is established, independent of the initial signature verification. This mechanism can effectively detect any bit flips, write errors, or malicious injections that may occur during the entire complex process of data transmission, reception, and especially writing to non-volatile storage media. This ensures that the entire firmware image to be used for booting is completely consistent with the original version signed by a trusted source at the bit level, providing ultimate consistency guarantee after writing.

[0079] In some specific embodiments, a fault rollback step is also included: if any signature verification in step S3 or step S5 fails, the flashing process is terminated, the temporary state is cleared, and the vehicle controller continues to run in the current operating partition.

[0080] By setting up independent fault rollback steps, it is stipulated that if the signature verification at any level in step S3 or S5 fails, the flashing process will be terminated immediately, the temporary state will be cleared, and the controller will continue to run in the current partition. This establishes a clear and decisive system-level security response strategy for abnormal situations in the core security verification process. Once any key signature verification fails, it indicates that there is a fundamental problem with the credibility or integrity of the upgrade data. At this time, the rollback strategy can effectively prevent untrusted or damaged firmware from being activated or causing further impact on the system by immediately stopping the process, clearing the intermediate state, and locking the system to a known secure version. This strictly controls the risk of single-point security verification failure at the process level and ensures the absolute security of the vehicle's basic operating functions.

[0081] In some specific embodiments, using the data in the current backup partition as the firmware image to be upgraded specifically means: after writing all the firmware data to be upgraded, reading the entire storage space of the backup partition as a whole, and using the read continuous data as the complete firmware image to be upgraded.

[0082] By specifically defining the firmware image to be upgraded as continuous data obtained by reading the entire storage space of the backup partition after writing, the precise generation method of the secondary signature verification operation object is clarified. That is, the secondary signature verification is not for a collection of scattered data blocks or only for the newly written part, but for verifying the complete binary image that will be used for booting in the physical storage space of the backup partition. This definition ensures that the secondary signature verification can cover the actual content of each storage unit in the partition, including newly written blocks, unmodified blocks, and possible fill areas, thereby achieving a comprehensive and complete verification of the integrity of the final boot medium without omissions, which is in line with the essential requirement of ensuring the overall consistency of data after storage.

[0083] In some specific embodiments, the use of a verification public key and digital signature to perform secondary asymmetric signature verification on the firmware image to be upgraded specifically includes: S501. Read the firmware image to be upgraded from the backup partition and calculate its image hash value; S502. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S503. Compare the image hash value with the original hash value; if they match, the second-level asymmetric signature verification passes.

[0084] By specifically defining the two-level asymmetric signature verification as including three sub-steps—reading the backup partition image and calculating its image hash value, decrypting the digital signature using the public key to obtain the original hash value, and comparing them—the specific process of the final security review operation executed on the controller is clearly defined. This process is logically symmetrical with the first-level signature verification but operates on different objects. It emphasizes hash calculation and comparison of the final static data written to the storage medium, thereby transforming the security goal of "verifying data after writing" into an executable verification step that is as rigorous as the initial verification but with a different object. This highlights the value and implementation method of the second-level signature verification as an independent security checkpoint.

[0085] Step S6: After the secondary asymmetric signature verification is successful, update the boot configuration of the vehicle controller and designate the current backup partition as the primary boot partition for the next power-on.

[0086] After passing the secondary verification, the system only updates the boot configuration of the vehicle controller to designate the backup partition as the primary boot partition for the next power-on, instead of immediately resetting or restarting the controller. This binds the timing of the new firmware's activation to the vehicle's normal start-stop cycle. This operation itself does not interrupt any of the controller's current running tasks based on the original partition firmware, thus achieving "silent" issuance and "delayed" execution of the old and new version switching command. This ensures that the continuity of all vehicle functions during this power-on cycle is not affected in any way, providing a key logical control means for seamless switching.

[0087] Step S7: When the vehicle controller is powered on again, switch the partition in which the vehicle controller is running to the current backup partition and set that partition as the new current running partition.

[0088] By delaying the actual switching action of the vehicle controller's operating partition until its next normal power-on, and automatically switching the operating environment to the prepared backup partition at that moment, the final effect of the firmware upgrade is perfectly integrated into the natural operation of the vehicle being turned off and restarted. For users and the upper-level system, this critical version change does not involve any additional, perceptible controller function interruption or restart waiting time, thus achieving a truly "user-unobtrusive" flashing process in the final stage, ensuring the continuity of the vehicle user experience and zero interruption of operational services.

[0089] In some specific embodiments, partition switching is performed by the secure boot mechanism of the onboard controller; The secure boot mechanism first reads the boot configuration when the vehicle controller is powered on again. If the boot configuration specifies the current backup partition as the master boot partition for the next power-on, then the integrity of the complete firmware image in the current backup partition is verified. Only after the integrity verification is passed will the boot from the current backup partition be actually executed.

[0090] By restricting partition switching to a secure boot mechanism within the vehicle controller, and only actually booting after reading the boot configuration and verifying the integrity of the backup partition upon the next power-on, the execution authority for this critical partition switching action is granted to the secure boot module in the controller's underlying firmware, which has higher privileges and runs before applications. This mechanism utilizes the hardware root of trust and the isolated environment of the boot phase. Only after the new firmware image passes an additional integrity check does the final boot pointer jump occur. This makes partition switching not only a logical configuration change, but also a controlled boot process protected by hardware and subject to additional security checks, greatly enhancing the security and reliability of the switching process itself.

[0091] In some specific embodiments, integrity verification is performed using CRC verification.

[0092] By specifically limiting the integrity verification performed by the secure boot mechanism to CRC check, a lightweight, computationally fast, and easily hardware-implemented cyclic redundancy check algorithm is specified for the final review stage before boot. Although CRC check is not as cryptographically strong as hash functions, it has a very strong error detection capability and can efficiently detect random bit errors that may occur in the firmware image during storage or transmission. Applying it to the final fast check in the secure boot stage can provide an effective additional screening for the basic structural integrity of the new firmware image with almost no increase in boot time overhead, further reducing the probability of boot failure due to physical bit errors of the storage medium.

[0093] In some specific embodiments, if the integrity check fails, the secure boot mechanism ignores the boot configuration and controls the vehicle controller to continue booting from the currently running partition.

[0094] By stipulating that if the integrity verification in the safe boot mechanism fails, the boot configuration will be ignored and booting will continue from the currently running partition, a clear and safe fault recovery path is set for the verification failure that may occur at the very end of the safe boot switching process. Even if all the preceding processes have passed, but a problem is found in the hardware-level verification at the last moment of boot, the mechanism can automatically stop the switch to the new partition and roll back to the original partition that is known to be good. This design realizes full-chain fault rollback coverage from software verification to hardware verification, ensuring that even in the extremely rare case of verification escape or data corruption at boot, the vehicle can still maintain the most basic bootable and runnable state, providing the highest level of system availability guarantee.

[0095] The following are embodiments of the vehicle controller sensorless silent flashing system based on a dual-partition architecture provided in this application. This vehicle controller sensorless silent flashing system based on a dual-partition architecture belongs to the same inventive concept as the vehicle controller sensorless silent flashing methods in the above embodiments. For details not described in detail in the embodiments of the vehicle controller sensorless silent flashing system, please refer to the embodiments of the vehicle controller sensorless silent flashing method based on a dual-partition architecture described above.

[0096] like Figure 2 As shown, the vehicle controller silent flashing system based on a dual-partition architecture includes: The firmware package acquisition module is used to obtain the firmware package, corresponding digital signature and verification public key of the vehicle controller to be upgraded from the cloud server when the vehicle is connected to the network, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The flashing process trigger module is used to trigger the flashing process when preset vehicle status conditions are met or preset periodic time points are reached. The Level 1 signature verification module is used to perform Level 1 asymmetric signature verification on firmware packages using the signature verification public key and digital signature. The data writing module is used to write the firmware data to be upgraded from the firmware package to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and only writes the data blocks that are inconsistent with the existing data in the backup partition as the firmware data to be upgraded. The secondary signature verification module is used to use the data in the current backup partition as the firmware image to be upgraded, and to perform secondary asymmetric signature verification on the firmware image to be upgraded using the signature verification public key and digital signature. The startup configuration update module is used to update the startup configuration of the vehicle controller and specify the current backup partition as the primary boot partition for the next power-on. The partition switching module is used to switch the partition in which the vehicle controller is running to the current backup partition when the vehicle controller is powered on again, and to make that partition the new current running partition.

[0097] The vehicle controller silent flashing system in this embodiment is used to implement a silent flashing method for vehicle controllers based on a dual-partition architecture.

[0098] This application also provides an electronic device for implementing the various embodiments of this application. Figure 3 To illustrate the hardware structure of an electronic device according to various embodiments of this application, as shown in the following diagram... Figure 3 As shown, the electronic device includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor.

[0099] Those skilled in the art will understand that the electronic device structure involved in the embodiments of this application does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0100] In embodiments of this application, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0101] In this application embodiment, the processor can be implemented using at least one of an Application-Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such implementations can be implemented within a controller. For software implementations, implementations such as processes or functions can be implemented with separate software modules that allow the performance of at least one function or operation. The software code can be implemented by a software application (or program) written in any suitable programming language, and the software code can be stored in memory and executed by the controller.

[0102] In addition, the electronic device includes some functional modules not shown, which will not be described in detail here.

[0103] Those skilled in the art will understand that the various aspects of the electronic device provided in this application can be implemented as a system, method, or program product. Therefore, the various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0104] This application also provides a storage medium storing a program product capable of implementing a sensorless silent flashing method for an in-vehicle controller based on a dual-partition architecture. In some possible implementations, various aspects of this application can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this application.

[0105] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0106] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for seamless silent flashing of an onboard controller based on a dual-partition architecture, characterized in that, Applied to an onboard controller configured to contain two partitions, wherein the partition currently running the onboard controller firmware package is defined as the currently running partition, and the other partition is defined as the backup partition, the method includes the following steps: S1. When the vehicle is connected to the network, obtain the firmware package of the on-board controller to be upgraded, the corresponding digital signature and verification public key from the cloud server, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The digital signature is generated by the cloud server using a private key pair paired with the signature verification public key in the firmware package; S2. Trigger the flashing process when the preset vehicle status conditions are met or the preset periodic time point is reached; S3. In response to the flashing process, use the signature verification public key and digital signature to perform a first-level asymmetric signature verification on the firmware package; S4. After the first-level asymmetric signature verification is passed, the firmware data to be upgraded in the firmware package is written to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and writes the data block that is inconsistent with the data in the corresponding position in the backup partition as the firmware data to be upgraded. S5. After writing is complete, the data in the current backup partition is used as the firmware image to be upgraded. The signature verification public key and digital signature are used to perform secondary asymmetric signature verification on the firmware image to be upgraded. S6. After the secondary asymmetric signature verification is successful, update the boot configuration of the vehicle controller and designate the current backup partition as the primary boot partition for the next power-on. S7. When the vehicle controller is powered on again, switch the partition in which the vehicle controller is running to the current backup partition and set that partition as the new current running partition.

2. The vehicle controller silent flashing method as described in claim 1, characterized in that, In step S2, the preset vehicle status conditions include: the vehicle is in a non-charging state, a stationary state, and the ignition switch is on and has not been set by the user to a mode that prohibits flashing.

3. The vehicle controller silent flashing method as described in claim 1, characterized in that, In step S3, the first-level asymmetric signature verification of the firmware package using the signature verification public key and digital signature specifically includes: S301. Read the firmware package and calculate its firmware package hash value; S302. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S303. Compare the firmware package hash value with the original hash value; if they match, the first-level asymmetric signature verification passes.

4. The vehicle controller silent flashing method as described in claim 1, characterized in that, In step S4, the block differential transmission and verification mechanism specifically includes: S401. Divide the data in the firmware package into multiple fixed-size data blocks; S402. For each data block, calculate its first hash value; S403. Obtain the second hash value of the existing data at the corresponding location in the backup partition; S404. Compare the first hash value with the second hash value; if they match, skip the transmission and writing of the current data block; otherwise, transmit the current data block as the firmware to be upgraded and write it to the backup partition of the vehicle controller.

5. The vehicle controller silent flashing method as described in claim 1, characterized in that, In step S5, the secondary asymmetric signature verification of the firmware image to be upgraded using the verification public key and digital signature specifically includes: S501. Read the firmware image to be upgraded from the backup partition and calculate its image hash value; S502. Use the signature verification public key to decrypt the digital signature and obtain the original hash value generated by the cloud server; S503. Compare the image hash value with the original hash value; if they match, the second-level asymmetric signature verification passes.

6. The vehicle controller non-sensory silent flashing method as described in claim 1, characterized in that, In step S7, the partition switching is performed by the on-board controller's secure startup mechanism; The secure boot mechanism first reads the boot configuration when the vehicle controller is powered on again. If the boot configuration specifies the current backup partition as the master boot partition for the next power-on, then the integrity of the complete firmware image in the current backup partition is verified. Only after the integrity verification is passed will the boot from the current backup partition be actually executed.

7. The vehicle controller silent flashing method as described in claim 1, characterized in that, If the integrity check fails, the secure boot mechanism ignores the boot configuration and controls the on-board controller to continue booting from the currently running partition.

8. A vehicle controller seamless silent flashing system based on a dual-partition architecture, characterized in that, To implement the sensorless silent flashing method for vehicle controllers as described in any one of claims 1-7, the method includes: The firmware package acquisition module is used to obtain the firmware package, corresponding digital signature and verification public key of the vehicle controller to be upgraded from the cloud server when the vehicle is connected to the network, and pre-download the firmware package, digital signature and verification public key to the local storage unit of the vehicle. The flashing process trigger module is used to trigger the flashing process when preset vehicle status conditions are met or preset periodic time points are reached. The Level 1 signature verification module is used to perform Level 1 asymmetric signature verification on firmware packages using the signature verification public key and digital signature. The data writing module is used to write the firmware data to be upgraded from the firmware package to the backup partition of the vehicle controller. The writing process adopts a block differential transmission and verification mechanism, and only writes the data blocks that are inconsistent with the existing data in the backup partition as the firmware data to be upgraded. The secondary signature verification module is used to use the data in the current backup partition as the firmware image to be upgraded, and to perform secondary asymmetric signature verification on the firmware image to be upgraded using the signature verification public key and digital signature. The startup configuration update module is used to update the startup configuration of the vehicle controller and specify the current backup partition as the primary boot partition for the next power-on. The partition switching module is used to switch the partition in which the vehicle controller is running to the current backup partition when the vehicle controller is powered on again, and to make that partition the new current running partition.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes a computer program, it implements the steps of the vehicle controller's sensorless silent flashing method as described in any one of claims 1-7.

10. A storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the vehicle controller non-sensory silent flashing method as described in any one of claims 1-7.

Images