Firmware upgrade breakpoint resuming method and system for motormeter, and electronic equipment

By using A/B surface design and breakpoint resume technology, the problems of long upgrade time and insufficient security caused by network interruption or vehicle power failure during automotive instrument OTA upgrades are solved, achieving reliable and secure firmware upgrades.

CN121832985APending Publication Date: 2026-04-10DENSO KOTEI AUTOMOTIVE ELECTRONICS (WUHAN) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-05
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

Existing OTA upgrade technology for automotive instruments requires the retransmission of all data when the network is interrupted or the vehicle loses power, resulting in long upgrade times and disruption to normal driving. Furthermore, it lacks customized reliability design and cannot meet the automotive industry's stringent standards for functional safety.

Method used

By employing A/B plane design and breakpoint resume technology, redundant backups of the currently running plane and the plane to be upgraded are stored in the EMMC. Data is divided into logical blocks and differentially restored. Combined with layered signature verification, the reliability and security of the upgrade process are ensured.

Benefits of technology

It shortened the upgrade time, avoided upgrade failures due to network interruptions or vehicle power outages, ensured that the vehicle's instrument panel operated normally during the upgrade process, and met functional safety standards.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121832985A_ABST
    Figure CN121832985A_ABST
Patent Text Reader

Abstract

The invention provides a firmware upgrading breakpoint resuming method and system of an automobile instrument, electronic equipment and a storage medium, and reliable upgrading is realized by taking double-panel redundancy, breakpoint resuming and hierarchical verification as a core and depending on an EMMC storage design: an initialization stage: reading current operation surface information of the instrument in the EMMC, determining a to-be-upgraded surface based on an A / B surface design, and carrying out data processing on the to-be-upgraded surface; backing up a running surface mark to an independent partition, and reading A / B surface breakpoint resume information at the same time; in the data processing stage, an upgrade package is divided into 8M groups according to head information, 1K packages are transmitted, a first package is decrypted by using a UDS protocol IV value, a subsequent package is decrypted by using a previous package plaintext and 16 bytes later, differential reduction based on a single block is synchronously executed, and after each package is written into an EMMC, recovery information such as data size and IV value is stored in a reverse partition of a breakpoint resume effective surface; in the verification and activation stage, the data length is confirmed firstly, signature verification is carried out according to 8M batches, then signature verification is carried out on all logic blocks in a full-experience mode, finally, a backup is compared with a current running surface mark, and if the backup is consistent with the current running surface mark, an effective to-be-upgraded surface is written into a starting partition.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology for automotive electronic devices, and more particularly to a method, system, electronic device, and storage medium for resuming firmware upgrades for automotive instrument panels. Background Technology

[0002] With the rapid iteration of intelligent connected vehicle technology, user demands for automotive instrument cluster functions have expanded from basic driving data display to diverse scenarios such as navigation interaction, entertainment control, and driver assistance information integration. To quickly respond to these demands, OTA (Over-the-Air Technology) has become the mainstream method for firmware upgrades of automotive instrument cluster ECUs (Electronic Control Units). OTA enables instrument cluster function iterations and vulnerability fixes without requiring users to visit a service center for maintenance, significantly improving upgrade convenience. Currently, most mainstream intelligent connected vehicles are equipped with OTA upgrade functionality, covering core in-vehicle devices such as instrument clusters and infotainment systems, becoming one of the core competitive advantages for intelligent vehicles to achieve "continuous evolution."

[0003] However, as a critical information interaction terminal during driving, the reliability and safety requirements of automotive instrument panels are far higher than those of ordinary consumer electronic devices. Existing OTA (Over-The-Air) upgrade technology has significant timeliness deficiencies when applied to automotive instrument panels. Because instrument panel firmware upgrades involve large amounts of data (typically tens or even hundreds of megabytes), if network interruptions or vehicle power outages occur during the upgrade process, traditional OTA requires retransmitting all data. This is not only time-consuming (a single upgrade can extend to several hours) but may also disrupt normal driving by occupying instrument panel resources for an extended period. Furthermore, ordinary OTA lacks customized reliability design for automotive instrument panels and cannot meet the stringent functional safety standards of the automotive industry (such as ISO 26262, International Organization for Standardization 26262, the functional safety standard for road vehicles).

[0004] Furthermore, the shortcomings of existing technologies in terms of data reliability and activation security exacerbate the risks of instrument panel upgrades. On the one hand, upgrade data and operational information do not employ redundant backup designs. Instrument panel storage relies on EMMC (Embedded Multi-Media Card). If data tampering or write errors occur in the EMMC storage unit, it will directly lead to upgrade package verification failure, or even render the instrument panel unusable. On the other hand, the determination of the surface to be activated during the activation process depends on external commands, lacking a built-in operational surface backup and verification mechanism. If the external commands are incorrect, it will lead to "activation of incorrect surfaces" (such as mistakenly activating surfaces that have not been upgraded), causing instrument panel malfunctions. These defects not only seriously affect the user experience but may also cause abnormal information display during driving, posing a potential threat to driving safety. Therefore, there is an urgent need for an automotive instrument panel firmware upgrade solution that balances reliability, timeliness, and security. Summary of the Invention

[0005] This invention provides a method, system, electronic device, and storage medium for resuming firmware upgrades for automotive instrument clusters, addressing the technical problem that while existing intelligent connected vehicles have implemented OTA upgrade functionality to facilitate ECU upgrades for automotive instrument clusters, the reliability and timeliness of instrument cluster firmware upgrades are insufficient due to the relatively complex functions and extremely stringent safety requirements of automobiles.

[0006] In a first aspect, embodiments of the present invention provide a firmware upgrade resume method for an automotive instrument cluster, wherein the automotive instrument cluster has an A / B side design, and the method includes: S1. Read the information of the current running plane stored in the embedded multimedia card EMMC, determine the plane to be upgraded based on the information of the current running plane, the plane to be upgraded is the opposite of the current running plane; copy the flag information of the current running plane to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC. S2. Read the header information of the upgrade packet corresponding to each logical block of the upgrade surface to be upgraded. Divide the upgrade packet into multiple groups according to the header information and transmit each group of data in 1K size. Decrypt the data according to the information at the end of the previous packet, and write the data into the EMMC after differential restoration. After processing each data packet, store the relevant recovery information in the recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, store it in the reverse partition of the current breakpoint resume valid surface. S3. After all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the face to be upgraded in a preset batch and perform signature verification. After the verification is successful, write the signature value and signature validity of the current logical block into the designated partition of the EMMC. S4. Perform a full verification check on all logic blocks of the surface to be upgraded. After the verification check is passed, set the validity flag of the surface to be upgraded to valid. S5. Read the running surface flag information of the backup partition and the current running surface flag information. If they match, determine that the surface to be activated is the surface to be upgraded. After determining that the surface to be activated is valid, write it into the boot information partition of the EMMC to complete the firmware upgrade activation.

[0007] Preferably, both the A and B sides of the vehicle instrument panel are stored in the EMMC, and each of the A and B sides contains three redundant backups of the startup surface information, the validity information of the A / B side, the A / B side group information, and the signature information of each logic block. After reading the information of the current running surface in S1, the process also includes: The validity of the current operating surface marking information is determined, and then compared with the three redundant backups. If the three backups are completely consistent, the current operating surface information is used for startup. If two backups are consistent, the operating surface corresponding to the consistent backup is used for startup. If the three backups are inconsistent, the default surface is used for startup, which is surface A or surface B. The startup process involves loading the firmware program of the corresponding operating surface and initializing the hardware and software functions after the instrument is powered on, so that the instrument can enter a working state that can normally display driving data and respond to operation commands.

[0008] Preferably, in S1, the breakpoint resume information adopts an A / B-plane storage design, including the data packet installation completion point, the number of processed groups ID, the processed block sequence number, the block size, the current total number of logical block groups, the decryption IV value for recovery, the data group size, and the recovery flag.

[0009] Preferably, S2 specifically includes: S21. Read the header information of the upgrade package corresponding to each logical block of the surface to be upgraded. The header information includes at least the number of upgrade packages, the data type, and the Unified Diagnostic Service (UDS) upgrade protocol information. S22. Divide each logical block of the upgrade package into multiple data groups, each data group being 8M in size. Transmit the data packets of each data group in 1K size. The first data packet is decrypted using the IV value transmitted by the UDS protocol. Subsequent data packets are decrypted using the last 16 bytes of the plaintext after the previous data packet is decrypted as the IV. Perform differential restoration on the decrypted data based on the differential algorithm. The differential algorithm generates differential upgrade data based on the single block data of the current instrument firmware version and the target version. S23. After processing each data packet and writing the data to the EMMC, store the size, offset, and decryption IV value of the processed data to the breakpoint resume recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, the recovery information is stored in the reverse partition of the current breakpoint resume valid side.

[0010] Preferably, in step S3, the size of the preset batch is 8M; when performing signature verification, the signature data is sent in advance by the UDS protocol instruction, and the signature data has been determined during the upgrade package creation stage; the signature verification operation is performed by a third-party library. After writing the signature value and signature validity of the current logical block to the designated partition of the EMMC, the signature value and signature validity information also need to be stored as triple redundant backups. The triple redundant backups are consistent with the triple redundant backup storage rules of the A / B side in S2. The specific storage rules of the triple redundant backups are as follows: allocate three independent backup partitions for the signature value and signature validity information in the EMMC, ensure that the data in the three partitions is consistent when writing, and compare the consistency of the three backups when verifying the signature later.

[0011] Preferably, in step S4, when performing a full experience check on all logic blocks of the surface to be upgraded, all logic blocks include logic blocks that need to be upgraded and logic blocks that do not need to be upgraded. Among them, the signature information and signature validity flag of the logical blocks that do not need to be upgraded need to be copied from the EMMC partition where the current running plane is located, as determined in S1, to the logical block signature storage partition corresponding to the plane to be upgraded; after the copying is completed, the consistency between the copied signature information and the signature information of the current running plane needs to be verified first, and then it will be included in the full trial signature scope after the consistency verification is passed. During the signature verification process, three redundant backups of the signature information of each logical block need to be read. If at least two of the three redundant backups of any logical block have invalid signature validity flags, the entire signature verification process is deemed to have failed, and the firmware upgrade process is immediately terminated.

[0012] Preferably, in step S5, if the running surface flag information of the backup partition read is inconsistent with the current running surface flag information, the activation operation is immediately terminated and an activation failure signal is returned, while maintaining the normal working state of the current running surface. When determining that the surface to be activated is valid, three redundant backups of the validity information of the surface to be activated need to be read. The surface to be activated is only confirmed to be valid if the validity flags of at least two of the three redundant backups are valid. Otherwise, the activation operation is terminated and the normal working state of the currently running surface is maintained.

[0013] Secondly, this invention provides a firmware upgrade breakpoint resume system for an automotive instrument panel, wherein the automotive instrument panel has an A / B panel design, and the system includes: An embedded multimedia card EMMC is configured with a running plane storage area for storing current running plane information, a backup partition for storing current running plane flag information, a designated partition for storing breakpoint resume information, a recovery partition for storing relevant recovery information, and a boot information partition for storing boot information. The information reading and upgradeable face determination module is configured to read the information of the current operating face stored in the embedded multimedia card EMMC, determine the upgradeable face based on the information of the current operating face, wherein the upgradeable face is the opposite of the current operating face; copy the flag information of the current operating face to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC; The upgrade package processing and recovery information storage module is configured to read the header information of the upgrade package corresponding to each logical block of the upgrade surface to be upgraded, divide the upgrade package into multiple groups according to the header information for transmission, transmit each group of data in 1K size, decrypt according to the information at the end of the previous packet, and write the data to the EMMC after differential restoration; after processing each data packet, the relevant recovery information is stored in the recovery partition of the EMMC, and the recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information, and is stored in the reverse partition of the current breakpoint resume valid surface when writing; The signature verification and information storage module is configured to, after all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the face to be upgraded in a preset batch and perform signature verification; after the verification is successful, the signature value and signature validity of the current logical block are written to the designated partition of the EMMC. The full verification and validity flag setting module is configured to perform a full verification on all logic blocks of the surface to be upgraded, and set the validity flag of the surface to be upgraded to valid after the verification is passed. The activation determination and startup information writing module is configured to read the running surface flag information and the current running surface flag information of the backup partition. If they match, the surface to be activated is determined to be the surface to be upgraded. After the surface to be activated is determined to be valid, it is written to the startup information partition of the EMMC to complete the firmware upgrade activation.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the firmware upgrade breakpoint resume method for an automotive instrument panel as described in the first aspect of the present invention.

[0015] Fourthly, embodiments of the present invention provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the firmware upgrade breakpoint resume method for an automotive instrument panel as described in the first aspect of the present invention.

[0016] This invention provides a method, system, electronic device, and storage medium for firmware upgrade of automotive instrument panels with breakpoint resumption. It is based on dual-panel redundancy, breakpoint resumption, and layered verification, and relies on EMMC storage design to achieve reliable upgrades: In the initialization phase, the current operating plane information of the instrument panel is read from the EMMC. Based on the A / B plane design, the plane to be upgraded (the opposite of the current operating plane) is determined, and the operating plane flag is backed up to a separate partition. Simultaneously, breakpoint resumption information (including installation completion point, decrypted IV value, etc.) of the A / B plane is read. In the data processing phase, the upgrade package is divided into 8M groups according to the header information, and transmitted in 1K packets. The first packet is decrypted using the UDS protocol IV value, and subsequent packets are decrypted using the plaintext of the previous packet followed by 16 bytes. Differential restoration based on a single block is performed synchronously. After each packet is written to the EMMC, the data size, IV value, and other recovery information are stored in the opposite partition of the valid breakpoint resumption plane. In the verification and activation phase, the data length is first confirmed and verified in 8M batches. Then, all logical blocks are fully verified (the signature of unupgraded blocks is copied from the operating plane). Finally, the backup flag is compared with the current operating plane flag; if they match, the valid plane to be upgraded is written to the startup partition. A / B side storage + three redundant backups prevent data tampering / loss; breakpoint resume A / B side design ensures recovery from abnormal interruptions; differential restoration reduces data transmission volume, and breakpoint resume avoids repeated transmission; layered signature verification (single block + full data) ensures firmware legitimacy, and pre-activation flag comparison avoids sectional errors; shortens upgrade waiting time, upgrades do not affect the current instrument operation, and facilitates the functional iteration of intelligent connected vehicles. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a firmware upgrade breakpoint resume method for an automotive instrument panel according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the specific process of upgrading package processing and recovery information storage according to an embodiment of the present invention; Figure 3 This is a block diagram of a firmware upgrade breakpoint resume system for an automotive instrument panel according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the physical structure according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a system, product, or device that includes a series of components or units is not limited to the listed components or units, but may optionally include unlisted components or units, or may optionally include other components or units inherent to such products or devices. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

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

[0023] This invention provides a method for resuming interrupted firmware upgrades in automotive instrument clusters, such as... Figure 1 As shown, the car instrument panel has an A / B panel design, and the method includes: S1. Read the information of the current running plane stored in the embedded multimedia card EMMC, determine the plane to be upgraded based on the information of the current running plane, the plane to be upgraded is the opposite of the current running plane; copy the flag information of the current running plane to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC. S2. Read the header information of the upgrade packet corresponding to each logical block of the upgrade surface to be upgraded. Divide the upgrade packet into multiple groups according to the header information and transmit each group of data in 1K size. Decrypt the data according to the information at the end of the previous packet, and write the data into the EMMC after differential restoration. After processing each data packet, store the relevant recovery information in the recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, store it in the reverse partition of the current breakpoint resume valid surface. S3. After all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the face to be upgraded in a preset batch and perform signature verification. After the verification is successful, write the signature value and signature validity of the current logical block into the designated partition of the EMMC. S4. Perform a full verification check on all logic blocks of the surface to be upgraded. After the verification check is passed, set the validity flag of the surface to be upgraded to valid. S5. Read the running surface flag information of the backup partition and the current running surface flag information. If they match, determine that the surface to be activated is the surface to be upgraded. After determining that the surface to be activated is valid, write it into the boot information partition of the EMMC to complete the firmware upgrade activation.

[0024] This invention addresses the firmware upgrade scenario for instrument clusters in intelligent connected vehicles. As automotive instrument clusters become increasingly feature-rich (e.g., navigation updates, display optimizations, new driver assistance prompts), firmware iterations require over-the-air (OTA) updates. However, vehicles have extremely high requirements for the security and reliability of their instrument clusters. Upgrades must not affect the current normal operation of the instrument cluster (e.g., displaying vehicle speed and fuel level), nor should upgrade failures due to network interruptions, vehicle power outages, or other anomalies render the instrument cluster unusable. Therefore, this solution utilizes A / B plane isolation, breakpoint resumption, and layered verification to address the issues of low upgrade reliability, the need for retransmission after interruption, and error-prone activation.

[0025] Specifically, the A / B side design stores the firmware of the automotive instrument panel in two independent partitions (A side and B side) of the EMMC (embedded multimedia card). Only one side works at a time (called the current operating side, which is responsible for the normal function of the instrument panel), while the other side is used for upgrades (called the upgrade side). The two are completely isolated, and the upgrade does not affect the operation of the current operating side. Furthermore, both A and B sides contain three redundant backups of startup information, validity information, group information, and logic block signature information, that is, the same information is stored three times to prevent single data from being tampered with or lost.

[0026] Logical Blocks / Data Groups: Upgrade packages are divided into logical blocks. For example, the display module firmware and navigation module firmware of the instrument are each a logical block. Each logical block is further divided into 8M data groups, and the data groups are transmitted in 1K data packets. This is equivalent to splitting a large file into small packages, which facilitates transmission and breakpoint recovery.

[0027] Resume interruption information: Progress data recorded before the upgrade was interrupted, including the completion point of the processed data packets, the ID of the number of processed groups, the sequence number of the processed block (the smaller unit within the data group), the IV value for decryption (the key to decrypt the data packets), etc., which is used to continue the upgrade from the breakpoint after the interruption without retransmitting all the data.

[0028] Relevant recovery information: Real-time progress data generated during the upgrade process is consistent with the breakpoint resume information (processed data size, offset, decryption IV value, etc.). After each 1K data packet is processed, it is stored in the EMMC recovery partition and written to the reverse partition of the current breakpoint resume valid side. For example, if the current valid side is side A, it is stored in the side B recovery partition to prevent overwriting historical data.

[0029] Signature verification: This involves using digital signatures to confirm that the data has not been tampered with. When the upgrade package is created, a unique signature data (similar to an anti-counterfeiting code) is generated. After the upgrade, a third-party library verifies whether the data matches the signature. If they match, it means that the data is legitimate and has not been modified.

[0030] Full-experience signature verification: Signature verification is performed on all logic blocks of the surface to be upgraded (including logic blocks that need to be upgraded and logic blocks that do not need to be upgraded), rather than just verifying a single logic block, to ensure that the entire surface to be upgraded is legal and usable.

[0031] In S1 of this embodiment, the information of the currently running surface refers to the firmware configuration of the surface (surface A or face B) currently being used by the instrument, including the validity of the surface, group information, logical block location, etc. Upgradeable side: The opposite side of the current operating side (e.g., if the operating side is side A, the upgradeable side is side B), which is specifically used to receive new firmware and does not affect the operation of the operating side; Running face identifier information: A unique identifier to distinguish between face A and face B (e.g., face A identifier = 01, face B identifier = 02). After being copied to the backup partition, it is used to confirm whether the face to be activated is correct during subsequent activation.

[0032] In step S1, the current running plane information is first read from EMMC, the plane to be upgraded is determined by the reverse rules, and the running plane flag information is copied to the backup partition of EMMC (to prevent the flag from being tampered with later); finally, the breakpoint resume information of the specified partition of EMMC is read. If the upgrade was interrupted before, the progress can be restored directly using this information.

[0033] Furthermore, in this embodiment S2, the upgrade package header information, i.e. the instruction manual of each logic block upgrade package, includes how many 8M data groups the upgrade package contains, the data type (such as display module data, navigation module data), and UDS upgrade protocol information (a diagnostic upgrade protocol commonly used in the automotive industry, used to transmit decryption parameters and upgrade instructions). Differential restoration: Compare the differences between the instrument’s current firmware version and the target version, transmit only the difference data (not the entire firmware), and then use an algorithm to restore the complete target version data (similar to a patch update, rather than re-downloading the entire software). The recovery partition corresponds one-to-one with the A / B side: The recovery partition is also divided into A / B sides, which match the A / B side of the resumed data information. When writing, it is stored on the reverse side of the current valid side. For example, if the current valid side of the resumed data information is side A, the recovery information is stored in the B side recovery partition to prevent the current recovery information from being lost when the upgrade is interrupted.

[0034] In S2, the upgrade packet header information of each logical block of the plane to be upgraded is read first, and the upgrade packet is split into 8M data groups according to the header information. Then, each data group is transmitted as a 1K data packet. The first packet is decrypted using the IV value of the UDS protocol, and subsequent packets are decrypted using the last 16 bytes of the plaintext of the previous packet (ensuring decryption continuity). After decryption, the complete data is obtained through differential reconstruction and written to the plane to be upgraded in the EMMC. After processing each data packet, the recovery information such as the size of the processed data, offset, and decryption IV value is immediately stored in the corresponding recovery partition. Packet splitting (large → 8M group → 1K packet) + differential reconstruction reduces the amount of data transmitted and shortens the upgrade time; breakpoints are recoverable, and recovery information is stored in real time. Even if the network is interrupted or the vehicle loses power, it can continue from the breakpoint after restarting using the recovery information without retransmission; data security is ensured by sequential decryption and writing to the isolated plane to be upgraded, avoiding data corruption or impact on the operating plane.

[0035] Furthermore, in S3, the preset batch is read in 8M increments, meaning the preset batch size is 8M, corresponding to the data group = 8M in S2, ensuring that the reading range and processing range are consistent; the signature value and signature validity of the current logical block, the anti-counterfeiting information of each logical block upgrade package, the signature value is the unique digital signature of the upgrade package, and the signature validity is the identifier of whether the signature is legal. After both are written to the designated partition of EMMC, three redundant backups are also made (stored in 3 copies to prevent loss).

[0036] After all data packets have been processed, first confirm that the total length of the processed data is consistent with the preset length of the upgrade package (excluding missing data); then read the data of each logical block of the upgrade plane in 8M batches, and verify whether the data matches the signature value through a third-party library (signature verification); after verification, write the signature value and signature validity of the logical block to the designated partition of EMMC, and make three redundant backups.

[0037] Signature verification ensures that the data in each logical block has not been maliciously modified (e.g., by a hacker injecting illegal code); only when a single logical block passes verification can it proceed to the subsequent full-scale verification, thus avoiding rework due to problems with a single block during the overall verification.

[0038] Furthermore, in S4, only those who have passed the full experience check are eligible for activation of the upgrade panel, to prevent the activation of a panel with a local problem from causing instrument malfunction.

[0039] Furthermore, in S5, the "to be activated" face is the face to be upgraded after passing the full trial signature, and it is the object to be switched to the running face in the future. The EMMC startup information partition is the partition that is read first when the instrument starts up. It contains the face (A / B face) to be loaded on the next startup. After writing the to be activated face information, the instrument will load the new firmware on the next startup. First, the running face flag information copied earlier is read from the EMMC backup partition and compared with the flag information of the current running face. If they are inconsistent (indicating that the flag has been tampered with), the activation is terminated immediately; if they are consistent, it is confirmed that the to be activated face is the previously determined to be upgraded face. Then, the three redundant backups of the validity information of the to be activated face are read. Only if the validity flags of at least two backups are valid is the to be activated face considered valid. Finally, the to be activated face information is written to the EMMC startup information partition to complete the activation (the instrument will use the new firmware on the next startup).

[0040] Based on the above embodiments, as a preferred implementation, both the A and B sides of the automotive instrument panel are stored in the EMMC, and each of the A and B sides contains three redundant backups of startup information, A / B side validity information, A / B side group information, and signature information of each logic block. After reading the information of the current running surface in S1, the process also includes: The validity of the current operating surface marking information is determined, and then compared with the three redundant backups. If the three backups are completely consistent, the current operating surface information is used for startup. If two backups are consistent, the operating surface corresponding to the consistent backup is used for startup. If the three backups are inconsistent, the default surface is used for startup, which is surface A or surface B. The startup process involves loading the firmware program of the corresponding operating surface and initializing the hardware and software functions after the instrument is powered on, so that the instrument can enter a working state that can normally display driving data and respond to operation commands.

[0041] Specifically, when the instrument cluster leaves the factory, the EMMC pre-divides it into two independent partitions, A and B. Each partition fully stores startup information, validity information, group information, and logic block signature information, and each piece of information comes with three redundant backups. In daily use, only one partition (such as partition A) is used as the current operating partition. The instrument cluster loads firmware from partition A to realize functions such as vehicle speed display and navigation. When an upgrade is required, the new firmware will be written to the partition to be upgraded (such as partition B). At this time, partition A will operate normally. Even if the data on partition B is corrupted during the upgrade process, it will not affect the current operation of the instrument cluster.

[0042] After reading the information of the currently running plane, it will determine and start in the following order: Step 1: Validity check: First check if the flag of the current running plane is valid (e.g., whether it is 01 or 02). If it is invalid, proceed directly to the next step of backup comparison; if it is valid, continue to verify the backup. Step 2: Compare the three redundant backups: Read the three backups of the current running plane information and select the boot plane according to the following rules: If all three backups are completely identical, the data is reliable, and the system will start directly according to the current operating plane information. If two backups are identical and one is inconsistent: the two identical backups shall be used as the standard, and the corresponding operating plane shall be started (two identical backups are more reliable than one). If all three backups are inconsistent: This indicates that the information of the current running plane is unreliable, and the system will switch to the default plane for startup. Step 3: Load Firmware: After determining the starting face, the instrument panel loads the firmware program from that face to initialize the hardware (such as activating the display screen and connecting the vehicle speed sensor) and software (such as starting the navigation and fuel calculation module). Step 4: Entering working state: After initialization is completed, the instrument displays data such as vehicle speed and fuel level, responds to operation commands, and the startup process ends.

[0043] Preventing startup failure: Through legality judgment and comparison of three lengthy backups, even if the information on the current operating surface is partially damaged, it can still start through the backup or default surface, which can prevent the instrument from failing to work due to the wrong startup surface selection; The startup result is predictable: clear judgment rules (3 consistent copies → current face, 2 consistent copies → consistent face, neither consistent → default face) ensure that each startup has a clear basis and will not result in a chaotic situation where face A is sometimes shown and face B is sometimes shown.

[0044] Based on the above embodiments, as a preferred implementation, in S1, the breakpoint resume information adopts an A / B-plane storage design, including the data packet installation completion point, the number of processed groups ID, the processed block sequence number, the block size, the current total number of logical block groups, the decryption IV value for recovery, the data group size, and the recovery flag.

[0045] Specifically, the breakpoint resume information is a data set that records the progress and key parameters before the instrument firmware upgrade is interrupted. It is used to continue the upgrade from the breakpoint after the interruption, rather than retransmitting all the data. It is the core basis for realizing the breakpoint resume function. The A / B side storage design is consistent with the A / B side logic of the instrument firmware storage. In the EMMC, two independent partitions (A-side breakpoint partition and B-side breakpoint partition) are allocated for breakpoint resumption information. Only one partition is active at any given time (storing the latest breakpoint information), while the other is inactive (storing historical breakpoint information), preventing data loss due to single-point corruption. The data packet installation completion point records the position of the last 1K data packet successfully processed and written to the EMMC, such as the 120th 1K data packet in group 5. After an interruption, transmission can resume from the next data packet at that point. The processed group ID records the number of the group that has been processed (e.g., group 3 has been processed), used for quickly locating unprocessed groups. The processed block sequence number records the number of the block that has been processed (e.g., the 25th block in group 3), which is matched with the data packet installation completion point. Each 8M group contains multiple block units. This system enables refined breakpoint location; the block size is the number of bytes in a single block unit, used to calculate the total amount of processed data and confirm the accuracy of the breakpoint location; the total number of current logical block groups is the total number of 8M groups contained in the current logical block to be upgraded (such as the display module logical block and the navigation module logical block), used to determine whether the logical block has been partially processed; the recovery decryption IV value is the key parameter for decrypting 1K data packets. The IV value of the first packet comes from the UDS protocol, and the IV value of subsequent packets is the plaintext of the previous packet followed by 16 bytes. This parameter records the IV value of the last data packet before the interruption, ensuring the continuity of decryption logic during recovery and upgrade; the data group size is the fixed number of bytes in each 8M group, used to verify whether the processed data conforms to the group division rules and avoid data corruption; the recovery flag marks which side of the current breakpoint resume information A / B side is the valid side. For example, flag = A indicates that the breakpoint partition on side A stores the latest information, used to locate the reverse partition when writing new breakpoint information, avoiding overwriting valid information.

[0046] Based on the above embodiments, as a preferred implementation method, such as Figure 2 As shown, S2 specifically includes: S21. Read the header information of the upgrade package corresponding to each logical block of the surface to be upgraded. The header information includes at least the number of upgrade packages, the data type, and the Unified Diagnostic Service (UDS) upgrade protocol information. Specifically, the Unified Diagnostic Service (UDS) upgrade protocol information. This is the diagnostic and upgrade protocol commonly used in the automotive industry, which includes upgrade instructions, decryption parameter (such as IV value) transmission rules, and serves as the language standard for communication between devices during the upgrade process.

[0047] S22. Divide each logical block of the upgrade package into multiple data groups, each data group being 8M in size. Transmit the data packets of each data group in 1K size. The first data packet is decrypted using the IV value transmitted by the UDS protocol. Subsequent data packets are decrypted using the last 16 bytes of the plaintext after the previous data packet is decrypted as the IV. Perform differential restoration on the decrypted data based on the differential algorithm. The differential algorithm generates differential upgrade data based on the single block data of the current instrument firmware version and the target version. After decryption, based on the difference data of a single block between the current version and the target version, the decrypted difference data is restored to the complete target version block data through a differential algorithm, in preparation for writing to the EMMC.

[0048] S23. After processing each data packet and writing the data to the EMMC, store the size, offset, and decryption IV value of the processed data to the breakpoint resume recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, the recovery information is stored in the reverse partition of the current breakpoint resume valid side.

[0049] By reading the breakpoint resume information A / B side validity flags through S1, the current valid side (e.g., side A) is determined, and the recovery information is written to the reverse partition of the valid side (e.g., the B side recovery partition). After writing is completed, the validity flag of the recovery partition is updated to that of the reverse partition (e.g., side B is set to valid, and side A is set to invalid), ensuring that the latest information is read the next time storage or recovery is performed.

[0050] Based on the above embodiments, as a preferred implementation, in step S3, the size of the preset batch is 8M; when performing signature verification, the signature data is sent in advance by the UDS protocol instruction, and the signature data has been determined during the upgrade package creation stage, and the signature verification operation is performed through a third-party library; After writing the signature value and signature validity of the current logical block to the designated partition of the EMMC, the signature value and signature validity information also need to be stored as triple redundant backups. The triple redundant backups are consistent with the triple redundant backup storage rules of the A / B side in S2. The specific storage rules of the triple redundant backups are as follows: allocate three independent backup partitions for the signature value and signature validity information in the EMMC, ensure that the data in the three partitions is consistent when writing, and compare the consistency of the three backups when verifying the signature later.

[0051] UDS (Unified Diagnostic Service) is a common upgrade communication protocol in the automotive industry. The signature data is a digital anti-counterfeiting code generated for each logic block during the upgrade package creation stage. Before the upgrade, this anti-counterfeiting code is transmitted to the instrument cluster via the UDS protocol for subsequent verification of data tampering. The signature data is determined during the upgrade package creation stage and is generated by the upgrade package creation tool based on the target version firmware data. It corresponds one-to-one with the firmware data; if the firmware data is modified, the signature data will not match, ensuring the uniqueness of the verification. A third-party library performs signature verification, which relies on a professional encrypted verification library (not the instrument cluster's self-developed simple logic). This type of library has undergone security... The authentication process accurately determines whether the read firmware data is consistent with the signature data transmitted by UDS, avoiding misjudgments caused by vulnerabilities in self-developed logic. The three redundant backups store three identical copies of the same information in the EMMC, specifically the backups of the signature value and signature validity information, to prevent the loss or corruption of a single data copy. The three redundant backup storage rules allocate three independent backup partitions (non-shared partitions) for the signature value and signature validity information in the EMMC. When writing, it ensures that the data in the three partitions is completely consistent (e.g., writing simultaneously or verifying consistency after writing). During subsequent signature verification, the three backups are compared to avoid signature verification failure due to errors in a single backup.

[0052] Based on the above embodiments, as a preferred implementation, in step S4, when performing a full experience check on all logical blocks of the surface to be upgraded, all logical blocks include logical blocks that need to be upgraded and logical blocks that do not need to be upgraded. Among them, the signature information and signature validity flag of the logical blocks that do not need to be upgraded need to be copied from the EMMC partition where the current running plane is located, as determined in S1, to the logical block signature storage partition corresponding to the plane to be upgraded; after the copying is completed, the consistency between the copied signature information and the signature information of the current running plane needs to be verified first, and then it will be included in the full trial signature scope after the consistency verification is passed. During the signature verification process, three redundant backups of the signature information of each logical block need to be read. If at least two of the three redundant backups of any logical block have invalid signature validity flags, the entire signature verification process is deemed to have failed, and the firmware upgrade process is immediately terminated.

[0053] In automotive instrument cluster firmware upgrades, there is often a need to upgrade only certain functional modules, such as updating only the navigation module firmware while the display module and sensor interaction module do not require upgrades. If signature verification is only performed on the logic blocks that need to be upgraded, ignoring the logic blocks that do not need to be upgraded, the data of the logic blocks that do not need to be upgraded may be corrupted (e.g., EMMC storage errors) or tampered with, leading to a complete instrument cluster failure after activating the upgrade surface, such as the display module failing to function. Furthermore, if only one copy of the critical signature information is stored, storage corruption can easily render the signature verification baseless. The optimal design of S4 addresses these three key requirements: full-scale reliability verification, prevention of copying errors, and prevention of single-point storage failures. By covering all logic blocks, performing consistency verification after copying, and using three redundant backup signature verification methods, it ensures the overall legality and usability of the upgrade surface, solving the reliability issues of instrument cluster upgrades. Full-scale signature verification guarantees overall reliability. After copying the signature information of the logic blocks that do not need to be upgraded from the operating surface to the upgrade surface, the copied signature information is compared with the original signature information on the operating surface to confirm that the copying process was error-free.

[0054] Based on the above embodiments, as a preferred implementation, in step S5, if the running plane flag information of the backup partition read is inconsistent with the current running plane flag information, the activation operation is immediately terminated and an activation failure signal is returned, while maintaining the normal working state of the current running plane. When determining that the surface to be activated is valid, three redundant backups of the validity information of the surface to be activated need to be read. The surface to be activated is only confirmed to be valid if the validity flags of at least two of the three redundant backups are valid. Otherwise, the activation operation is terminated and the normal working state of the currently running surface is maintained.

[0055] S5 is the final activation step in automotive instrument panel firmware upgrades. Prior to this, the data processing for the surface to be upgraded (S2), single-block signature verification (S3), and full-experience signature verification (S4) have been completed. However, if the wrong surface is selected during activation (e.g., accidentally activating an unupgraded surface) or an invalid surface is activated (e.g., damaged validity information for the surface to be activated), it will directly lead to a black screen on the instrument panel and the inability to display critical information such as vehicle speed / fuel level, seriously affecting driving safety. Simultaneously, during the upgrade process, electromagnetic interference and EMMC storage fluctuations may cause the backed-up running surface flag information to be tampered with. Activating directly without verification carries an extremely high risk. When an activation failure signal is returned, the problem can be located through specific reasons such as inconsistent flag information or invalid validity backups (e.g., damaged backup partition or missing full-experience signature verification for the surface to be activated), reducing subsequent after-sales troubleshooting time. Therefore, the optimal design of S5 focuses on three core requirements: activation error prevention, invalid surface interception, and uninterrupted current operation. It strengthens the final safety line through flag information comparison and three lengthy backup checks, and verifies validity before activation, addressing the technical problem of insufficient reliability in instrument panel upgrades.

[0056] Secondly, an embodiment of the present invention provides a firmware upgrade breakpoint resume system for automotive instrument panels, based on the firmware upgrade breakpoint resume method for automotive instrument panels in the above-described format example, such as... Figure 3 As shown, the car instrument panel has an A / B side design, and the system includes: An embedded multimedia card EMMC is configured with a running plane storage area for storing current running plane information, a backup partition for storing current running plane flag information, a designated partition for storing breakpoint resume information, a recovery partition for storing relevant recovery information, and a boot information partition for storing boot information. The information reading and upgradeable face determination module 310 is configured to read the information of the current operating face stored in the embedded multimedia card EMMC, determine the upgradeable face based on the information of the current operating face, wherein the upgradeable face is the opposite of the current operating face; copy the flag information of the current operating face to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC. The upgrade package processing and recovery information storage module 320 is configured to read the header information of the upgrade package corresponding to each logical block of the upgrade surface to be upgraded, divide the upgrade package into multiple groups for transmission according to the header information, transmit each group of data in 1K size, decrypt according to the information at the end of the previous packet, and write the data into the EMMC after differential restoration; after processing each data packet, the relevant recovery information is stored in the recovery partition of the EMMC, and the recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information, and is stored in the reverse partition of the current breakpoint resume valid surface when writing; The signature verification and information storage module 330 is configured to, after all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the upgrade face in a preset batch and perform signature verification; after the verification is successful, write the signature value and signature validity of the current logical block into the designated partition of the EMMC. The full verification and validity flag setting module 340 is configured to perform a full verification on all logic blocks of the surface to be upgraded, and set the validity flag of the surface to be upgraded to valid after the verification is passed. The activation determination and startup information writing module 350 is configured to read the running surface flag information and the current running surface flag information of the backup partition. If they match, the surface to be activated is determined to be the surface to be upgraded. After the surface to be activated is determined to be valid, it is written to the startup information partition of the EMMC to complete the firmware upgrade activation.

[0057] Based on the same concept, this invention also provides a schematic diagram of a physical structure, such as... Figure 4As shown, the server may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions stored in the memory 430 to execute the steps of the firmware upgrade breakpoint resume method for automotive instruments as described in the above embodiments.

[0058] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 described in the various embodiments of the present invention. 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.

[0059] Based on the same concept, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a master control device to control the master control device to implement the steps of the firmware upgrade breakpoint resume method for automotive instruments as described in the above embodiments.

[0060] Based on the same technical concept, this application also provides a computer program, which, when executed by a main control device, is used to implement the above-described method embodiments.

[0061] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0062] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0063] The various embodiments of the present invention can be combined arbitrarily to achieve different technical effects.

[0064] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0065] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0066] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for resuming interrupted firmware upgrades in an automotive instrument cluster, wherein the automotive instrument cluster has an A / B panel design, characterized in that... The method includes: S1. Read the information of the current running plane stored in the embedded multimedia card EMMC, determine the plane to be upgraded based on the information of the current running plane, the plane to be upgraded is the opposite of the current running plane; copy the flag information of the current running plane to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC. S2. Read the header information of the upgrade packet corresponding to each logical block of the upgrade surface to be upgraded. Divide the upgrade packet into multiple groups according to the header information and transmit each group of data in 1K size. Decrypt the data according to the information at the end of the previous packet, and write the data into the EMMC after differential restoration. After processing each data packet, store the relevant recovery information in the recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, store it in the reverse partition of the current breakpoint resume valid surface. S3. After all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the face to be upgraded in a preset batch and perform signature verification. After the verification is successful, write the signature value and signature validity of the current logical block into the designated partition of the EMMC. S4. Perform a full verification check on all logic blocks of the surface to be upgraded. After the verification check is passed, set the validity flag of the surface to be upgraded to valid. S5. Read the running surface flag information of the backup partition and the current running surface flag information. If they match, determine that the surface to be activated is the surface to be upgraded. After determining that the surface to be activated is valid, write it into the boot information partition of the EMMC to complete the firmware upgrade activation.

2. The firmware upgrade breakpoint resume method for automotive instrument panels according to claim 1, characterized in that, The A / B sides of the automotive instrument panel are both stored in the EMMC, and each A / B side contains three redundant backups of startup surface information, A / B side validity information, A / B side group information, and signature information of each logic block. After reading the information of the current running surface in S1, the process also includes: The validity of the current running plane flag information is determined, and then compared with the three redundant backups. If the three backups are completely consistent, the current running plane information is used for startup; if two backups are consistent, the running plane corresponding to the consistent backup is used for startup. If the three backup information are inconsistent, the default face will be used for startup, which is face A or face B. Startup means that after the instrument is powered on, the firmware program of the corresponding operating face is loaded and the hardware and software functions are initialized, so that the instrument can enter the working state that can display driving data and respond to operation commands normally.

3. The firmware upgrade breakpoint resumption method for automotive instrument panels according to claim 1, characterized in that, In S1, the breakpoint resume information adopts an A / B-plane storage design, including the data packet installation completion point, the number of processed groups ID, the processed block sequence number, the block size, the current total number of logical block groups, the decryption IV value for recovery, the data group size, and the recovery flag.

4. The firmware upgrade breakpoint resume method for automotive instrument panels according to claim 1, characterized in that, S2 specifically includes: S21. Read the header information of the upgrade package corresponding to each logical block of the surface to be upgraded. The header information includes at least the number of upgrade packages, the data type, and the Unified Diagnostic Service (UDS) upgrade protocol information. S22. Divide each logical block of the upgrade package into multiple data groups, each data group being 8M in size. Transmit the data packets of each data group in 1K size. The first data packet is decrypted using the IV value transmitted by the UDS protocol. Subsequent data packets are decrypted using the last 16 bytes of the plaintext after the previous data packet is decrypted as the IV. Perform differential restoration on the decrypted data based on the differential algorithm. The differential algorithm generates differential upgrade data based on the single block data of the current instrument firmware version and the target version. S23. After processing each data packet and writing the data to the EMMC, store the size, offset, and decryption IV value of the processed data to the breakpoint resume recovery partition of the EMMC. The recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information. When writing, the recovery information is stored in the reverse partition of the current breakpoint resume valid side.

5. The firmware upgrade breakpoint resumption method for automotive instrument panels according to claim 4, characterized in that, In S3, the size of the preset batch is 8M; when performing signature verification, the signature data is sent in advance by the UDS protocol instruction, and the signature data has been determined during the upgrade package production stage. The signature verification operation is performed through a third-party library. After writing the signature value and signature validity of the current logical block to the designated partition of the EMMC, the signature value and signature validity information also need to be stored as triple redundant backups. The triple redundant backups are consistent with the triple redundant backup storage rules of the A / B side in S2. The specific storage rules of the triple redundant backups are as follows: allocate three independent backup partitions for the signature value and signature validity information in the EMMC, ensure that the data in the three partitions is consistent when writing, and compare the consistency of the three backups when verifying the signature later.

6. The firmware upgrade breakpoint resumption method for automotive instrument panels according to claim 1, characterized in that, In step S4, when performing a full experience check on all logic blocks of the surface to be upgraded, all logic blocks include logic blocks that need to be upgraded and logic blocks that do not need to be upgraded. Among them, the signature information and signature validity flag of the logical blocks that do not need to be upgraded need to be copied from the EMMC partition where the current running plane is located, as determined in S1, to the logical block signature storage partition corresponding to the plane to be upgraded; after the copying is completed, the consistency between the copied signature information and the signature information of the current running plane needs to be verified first, and then it will be included in the full trial signature scope after the consistency verification is passed. During the signature verification process, three redundant backups of the signature information of each logical block need to be read. If at least two of the three redundant backups of any logical block have invalid signature validity flags, the entire signature verification process is deemed to have failed, and the firmware upgrade process is immediately terminated.

7. The firmware upgrade breakpoint resumption method for automotive instrument panels according to claim 1, characterized in that, In step S5, if the running surface flag information of the backup partition read is inconsistent with the current running surface flag information, the activation operation is immediately terminated and an activation failure signal is returned, while maintaining the normal working state of the current running surface. When determining that the surface to be activated is valid, three redundant backups of the validity information of the surface to be activated need to be read. The surface to be activated is only confirmed to be valid if the validity flags of at least two of the three redundant backups are valid. Otherwise, the activation operation is terminated and the normal working state of the currently running surface is maintained.

8. A firmware upgrade breakpoint resume system for an automotive instrument panel, wherein the automotive instrument panel has an A / B panel design, characterized in that, The system includes: An embedded multimedia card EMMC is configured with a running plane storage area for storing current running plane information, a backup partition for storing current running plane flag information, a designated partition for storing breakpoint resume information, a recovery partition for storing relevant recovery information, and a boot information partition for storing boot information. The information reading and upgradeable face determination module is configured to read the information of the current operating face stored in the embedded multimedia card EMMC, determine the upgradeable face based on the information of the current operating face, wherein the upgradeable face is the opposite of the current operating face; copy the flag information of the current operating face to the backup partition of the EMMC, and at the same time read the breakpoint resume information of the specified partition of the EMMC; The upgrade package processing and recovery information storage module is configured to read the header information of the upgrade package corresponding to each logical block of the upgrade surface to be upgraded, divide the upgrade package into multiple groups according to the header information for transmission, transmit each group of data in 1K size, decrypt according to the information at the end of the previous packet, and write the data to the EMMC after differential restoration; after processing each data packet, the relevant recovery information is stored in the recovery partition of the EMMC, and the recovery partition corresponds one-to-one with the A / B side of the breakpoint resume information, and is stored in the reverse partition of the current breakpoint resume valid surface when writing; The signature verification and information storage module is configured to, after all data packets of the upgrade package have been processed, confirm that the upgrade data length meets the standard, and then read the data of the corresponding logical block of the face to be upgraded in a preset batch and perform signature verification; after the verification is successful, the signature value and signature validity of the current logical block are written to the designated partition of the EMMC. The full verification and validity flag setting module is configured to perform a full verification on all logic blocks of the surface to be upgraded, and set the validity flag of the surface to be upgraded to valid after the verification is passed. The activation determination and startup information writing module is configured to read the running surface flag information and the current running surface flag information of the backup partition. If they match, the surface to be activated is determined to be the surface to be upgraded. After the surface to be activated is determined to be valid, it is written to the startup information partition of the EMMC to complete the firmware upgrade activation.

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 the program, it implements the steps of the firmware upgrade breakpoint resume method for automotive instrument panels as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the firmware upgrade breakpoint resume method for automotive instruments as described in any one of claims 1 to 7.