OTA (over-the-air) switching scheduling method based on MCU (microprogrammed control unit) hardware double partitions

Abstract

The invention relates to an OTA zone switching scheduling method based on MCU hardware double partitions. The method comprises the steps that S1, a memory of an MCU is divided into a firmware A zone and a firmware B zone in advance, and preset zone switching parameters are stored; s2, obtaining a region switching instruction and determining an original firmware region and a new firmware region; s3, writing real-time area cutting parameters of the new firmware area into a preset address according to the area cutting instruction; s4, in the preset address, verifying the real-time switching area parameter of the new firmware area and the stored preset switching area parameter of the firmware A area or the firmware B area: if the verification is passed, executing the step S5; if the verification fails, executing the step S8; s5, writing the real-time area switching parameters of the new firmware area into a fixed address, and performing area switching parameter protection; s6, executing a restart operation by calling an MCU soft reset function; s7, executing the program of the new firmware area when the area cutting process succeeds; and S8, executing the program of the original firmware area if the area switching process fails. According to the method, the reliability and the safety of area switching (parameters) in the automobile OTA upgrading process can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile MCU software upgrading, and particularly relates to an OTA area switching scheduling method based on MCU hardware dual-partition. BACKGROUND

[0002] With the continuous improvement of the intelligentization and networking of automobiles, automobiles have changed from traditional mechanical transportation tools to intelligent mobile terminals integrating electronics, communications and software. Software accounts for an increasing proportion in the realization of automobile functions, covering power control, automatic driving, intelligent cockpit, vehicle body electronics and other fields. OTA (Over-the-Air) allows automobiles to automatically download and install software updates through wireless networks without the need for users to go to 4S stores or repair sites, greatly improving the convenience and timeliness of software upgrading.

[0003] In the process of automobile OTA upgrading, area switching (Firmware Switching) is the core link to ensure the safety and continuous operation of the system. Since the automobile electronic control unit (ECU) needs to continuously perform key tasks, OTA upgrading cannot interrupt the current firmware operation. At present, the area switching in the process of automobile OTA upgrading mainly has the following problems: 1) Insufficient safety of switching parameters: switching parameters (such as firmware version number, switching address, verification key, etc.) are usually stored in a general storage area, lacking a special protection mechanism. Attackers can tamper with the parameters through physical contact or wireless interfaces, causing the system to switch to malicious firmware or illegal addresses, leading to functional abnormalities or security vulnerabilities. 2) Low reliability of switching process: the existing verification mechanism only performs static verification on the new firmware, without considering the consistency of parameters in dynamic environments. In scenarios such as electromagnetic interference and power fluctuations, single-bit flips may occur in the memory, causing the verified firmware to actually have hidden errors.

[0004] In summary, the existing OTA area switching technology has significant defects in safety and reliability, and it is urgent to solve the above problems through innovative architecture design. SUMMARY

[0005] In view of the above problems of the prior art, the technical problem to be solved by the present application is to provide an OTA area switching scheduling method based on MCU hardware dual-partition, which improves the reliability and safety of area switching in the process of automobile OTA upgrading by designing independent firmware A area and firmware B area combined with specific address verification and storage of switching parameters.

[0006] To solve the above technical problems, the present application adopts the following technical solutions:

[0007] An OTA area switching scheduling method based on MCU hardware dual-partition, comprising:

[0008] S1: pre-dividing the memory of the MCU into a firmware A area and a firmware B area, and storing preset switching area parameters of the firmware A area and the firmware B area;

[0009] S2: obtaining a switching area instruction during OTA upgrading, and determining an original firmware area and a new firmware area;

[0010] S3: writing real-time switching area parameters of the input new firmware area into a preset address according to the switching area instruction;

[0011] S4: in the preset address, checking the real-time switching area parameters of the new firmware area with the stored preset switching area parameters of the firmware A area or the firmware B area: if the checking is passed, performing step S5; if the checking fails, performing step S8;

[0012] S5: writing the real-time switching area parameters of the new firmware area into a fixed address for switching area parameter protection;

[0013] S6: performing a restart operation by calling an MCU soft reset function;

[0014] S7: the switching area process is successful, and the program of the new firmware area is executed;

[0015] S8: the switching area process fails, and the program of the original firmware area is executed.

[0016] Preferably, in step S1, the following steps are specifically included:

[0017] S101: setting a PLASH address segment of the firmware A area and a PLASH address segment of the firmware B area respectively;

[0018] S102: storing preset switching area parameters S1 of the firmware A area and preset switching area parameters S2 of the firmware B area into a protected NVM area respectively.

[0019] Preferably, in step S2, if the currently executed address is the PLASH address segment of the firmware A area, the switching area instruction is switching from the original firmware area firmware A area to the new firmware area firmware B area; if the currently executed address is the PLASH address segment of the firmware B area, the switching area instruction is switching from the original firmware area firmware B area to the new firmware area firmware A area.

[0020] In step S3, if the switching area instruction is switching from the original firmware area firmware A area to the new firmware area firmware B area, the real-time switching area parameters X2 of the new firmware area firmware B area are written into the preset address; if the switching area instruction is switching from the original firmware area firmware B area to the new firmware area firmware A area, the switching area parameters X1 of the new firmware area firmware A area are written into the preset address.

[0021] Preferably, in step S3, the preset address is a RAM address segment, which is an address specially divided for switching area parameters, and other parameters cannot be written into.

[0022] Preferably, in step S4, if the real-time switching parameter X2 of the new firmware area firmware B area is written to the preset address, the preset switching parameter S2 of the stored firmware B area is read, and the real-time switching parameter X2 is compared with the preset switching parameter S2: if the real-time switching parameter X2 is consistent with the preset switching parameter S2, the verification passes, otherwise the verification fails;

[0023] If the real-time switching parameter X1 of the new firmware area firmware A area is written to the preset address, the preset switching parameter S1 of the stored firmware A area is read, and the real-time switching parameter X1 is compared with the preset switching parameter S1: if the real-time switching parameter X1 is consistent with the preset switching parameter S1, the verification passes, otherwise the verification fails.

[0024] Preferably, in step S2, when the switching instruction is obtained, the firmware A area and the firmware B area are first subjected to health self-checking, and after the self-checking passes, the original firmware area and the new firmware area are determined and the subsequent steps are executed;

[0025] The processing steps of the health self-checking are as follows:

[0026] S201: generating the header additional information of the firmware A area and the firmware B area based on the hardware unique identifier of the MCU;

[0027] S202: performing basic verification on the firmware A area and the firmware B area based on the header additional information of the firmware A area and the firmware B area combined with the current time stamp;

[0028] S203: performing cross verification on the firmware A area and the firmware B area based on the basic verification result combined with the original data of the firmware A area and the firmware B area;

[0029] S204: calculating the dynamic tolerance value of the firmware A area and the firmware B area based on the state data of the MCU and the basic threshold value;

[0030] S205: calculating the health score of the firmware A area and the firmware B area based on the basic verification result, the cross verification result and the dynamic tolerance value: if the health score of the firmware A area and the firmware B area exceeds the safety threshold value, the self-checking passes; otherwise, the self-checking fails.

[0031] Preferably, in step S201, the following steps are included:

[0032] 1) calculating the hash HA of the firmware A area and the hash HB of the firmware B area;

[0033] 2) taking the hardware unique identifier UID as a seed, generating a hardware root key HRK through HKDF-Expand;

[0034] 3) encrypting the hash HA and HB by the hardware root key (HRK) to get the ciphertext CA and CB of the firmware A area and the firmware B area;

[0035] 4) generating the obfuscated value OA and OB of the firmware A area and the firmware B area by combining the hash HA and HB with the hardware unique identifier (UID);

[0036] 5) encapsulating the ciphertext CA and the obfuscated value OA of the firmware A area and the ciphertext CB and the obfuscated value OB of the firmware B area to get the header additional information of the firmware A area and the firmware B area.

[0037] Preferably, the step S202 specifically comprises the following steps:

[0038] 1) extracting the ciphertext CA and the obfuscated value OA and the ciphertext CB and the obfuscated value OB from the header additional information of the firmware A area and the firmware B area;

[0039] 2) calculating a time factor Thash by the MCU real-time clock timestamp;

[0040] 3) deriving the dynamic key DKA and DKB of the firmware A area and the firmware B area by the time factor Thash;

[0041] 4) decrypting the ciphertext CA and CB by the dynamic key DKA and DKB respectively to get the decrypted hash HA_dec and HB_dec of the firmware A area and the firmware B area;

[0042] 5) calculating the expected obfuscated value OA_exp and OB_exp of the firmware A area and the firmware B area by the decrypted hash HA_dec and HB_dec;

[0043] 6) if the obfuscated value OA of the firmware A area is equal to the expected obfuscated value OA_exp, the basic verification of the firmware A area passes; otherwise, the basic verification fails;

[0044] if the obfuscated value OB of the firmware B area is equal to the expected obfuscated value OB_exp, the basic verification of the firmware B area passes; otherwise, the basic verification fails;

[0045] The step S203 specifically comprises the following steps:

[0046] 1) judging whether the basic verification of the firmware A area and the firmware B area passes: if yes, executing the subsequent steps; otherwise, directly executing the step S204;

[0047] 2) calculating the real-time hash HA_live and HB_live of the firmware A area and the firmware B area;

[0048] 3) Comparing the live hashes HA_live and HB_live of the firmware A region and the firmware B region with the decrypted hashes HA_dec and HB_dec of the firmware A region and the firmware B region:

[0049] If the live hash HA_live of the firmware A region is equal to the decrypted hash HA_dec, the cross verification of the firmware A region passes; otherwise, the cross verification fails.

[0050] If the live hash HB_live of the firmware B region is equal to the decrypted hash HB_dec, the cross verification of the firmware B region passes; otherwise, the cross verification fails.

[0051] Preferably, in step S204, the following steps are specifically included:

[0052] 1) Obtaining the temperature sensor reading Ta of the MCU and the supply voltage monitoring value Va;

[0053] 2) Obtaining the pre-stored temperature reference value Tr and voltage reference value Vr, and the basic tolerance threshold ΔH_base = 1;

[0054] 3) Calculating the temperature stress coefficient σT through the temperature sensor reading Ta and the temperature reference value Tr;

[0055] σT = 1 + 0.02 × |Ta - Tr|;

[0056] 4) Calculating the voltage stress coefficient σV through the supply voltage monitoring value Va and the voltage reference value Vr;

[0057] σV = 1 + 0.05 × |Va - Vr|;

[0058] 5) Calculating the comprehensive stress factor σ_total through the temperature stress coefficient σT and the voltage stress coefficient σV;

[0059] σ_total = σT × σV;

[0060] 6) Calculating the dynamic tolerance value ΔH_adj after state compensation through the comprehensive stress factor σ_total and the basic tolerance threshold Δh_base;

[0061] ΔH_adj = ceil(ΔH_base × σ_total);

[0062] In the formula, ceil represents the ceiling function.

[0063] Wherein, if the basic verification fails, the dynamic tolerance value ΔH_adj = Δh_base = 1.

[0064] Preferably, in step S205, the calculation logic of the health score is as follows:

[0065] 1) Set the basic health score of firmware A area and firmware B area as 100 points;

[0066] 2) Set the deduction rules:

[0067] If the basic verification fails, deduct S=20 points;

[0068] If the basic verification passes and the cross verification fails, deduct S=15 points;

[0069] If the basic verification and cross verification pass, and the dynamic tolerance value 0.8<ΔH_adj<1, deduct S=10 points;

[0070] If the basic verification and cross verification pass, and the dynamic tolerance value 0.6<ΔH_adj<0.8, deduct S=5 points;

[0071] If the basic verification and cross verification pass, and the dynamic tolerance value ΔH_adj<0.6, deduct S=0 points;

[0072] 3) Calculate the wear coefficient of MCU:

[0073] Wear coefficient = number of erasing and writing times / 10000;

[0074] 4) Health score = (100-S) x wear coefficient;

[0075] 5) Health self-checking:

[0076] If the health score> safety threshold 80, the self-checking passes; otherwise, the self-checking fails.

[0077] Compared with the prior art, the OTA area switching scheduling method based on the MCU hardware dual partition in the application has the following beneficial effects:

[0078] In the application, the memory of the MCU is divided into independent firmware A area and firmware B area in advance, and the area switching parameters are stored. By dividing the memory of the MCU into independent partitions to form a dual-area independent storage architecture, if a firmware area fails to upgrade or abnormally during the OTA upgrade process, the other area can still operate normally, so that the system is ensured not to be completely paralyzed due to single upgrade failure; and by using the pre-stored preset area switching parameters, the system can quickly identify and switch to the available firmware area, thereby significantly reducing the system downtime risk and improving the stability of area switching during the OTA upgrade process of the automobile. At the same time, the dual-area design allows the new firmware to be independently downloaded and verified in the non-active area without interrupting the current system operation; and the storage of the area switching parameters provides a standardized benchmark for the area switching operation, so that the system can quickly switch the firmware version according to the actual demand without repeatedly configuring the parameters. The design of the application shortens the upgrade time and supports flexible management of multiple versions of firmware, thereby meeting the functional requirements in different scenarios.

[0079] The application performs the check of the cut area parameter in the preset address. By writing the real-time cut area parameter of the new firmware area into the preset address, the possibility of unauthorized access or tampering is limited, ensuring the integrity of the cut area parameter in the transmission and storage process; and the special design of the preset address forms a physical level of security isolation, effectively preventing the damage of the parameter caused by malicious attacks or misoperations, thereby improving the reliability of the cut area (parameter) in the process of automobile OTA upgrade. At the same time, after the check is passed, the cut area parameter is written into the fixed address, and the cut area parameter is ensured to remain after the system restarts or powers off through the fixed address, avoiding the cut area failure caused by the loss of temporary storage; and the special design of the fixed address isolates the parameter from other data of the system, reducing the risk of being covered or cleared, thereby improving the security of the cut area (parameter) in the process of automobile OTA upgrade.

[0080] The application executes the program of the new firmware area after the cut area is successful, and executes the program of the original firmware area after the cut area fails. Through the mechanism of rolling back to the original firmware, the system realizes the closed-loop management of upgrade-verification-rollback, so that even if the new firmware has potential defects, the system can automatically switch to the stable version, avoiding service interruption caused by upgrade failure, thereby improving the fault tolerance of the system and ensuring the continuity of the key business. At the same time, the system can automatically complete the firmware switching, avoiding the risk of data loss caused by upgrade failure. BRIEF DESCRIPTION OF DRAWINGS

[0081] In order to make the purpose, technical scheme and advantages of the application clearer, the application will be further described in detail below in combination with the drawings, in which:

[0082] Figure 1 It is a logic block diagram of the OTA cut area scheduling method based on MCU hardware dual partition. DETAILED DESCRIPTION

[0083] In order to make the purpose, technical scheme and advantages of the application clearer, the application will be further described in detail below in combination with the drawings, in which:

[0084] It should be noted that similar reference numerals and letters refer to like items in the accompanying drawings, and thus, once an item is defined in one drawing, it is not necessary to further define and explain it in subsequent drawings. In the description of the application, it needs to be explained that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the product of the application is usually placed during use, and are only for the convenience of describing the application and simplifying the description, and thus cannot be understood as indicating or implying that the indicated device or element must have a particular orientation, be constructed and operated in a particular orientation, and thus cannot be understood as limiting the application. In addition, the terms "first", "second", "third", and the like are only used for differentiation in description and cannot be understood as indicating or implying relative importance. In addition, the terms "horizontal", "vertical", and the like do not mean that the components must be absolutely horizontal or vertical, but can be slightly inclined. For example, "horizontal" only means that its direction is more horizontal relative to "vertical", and does not mean that the structure must be completely horizontal, but can be slightly inclined. In the description of the application, it also needs to be explained that, unless otherwise explicitly specified and limited, the terms "arrangement", "installation", "connection", "connection" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the application can be understood according to the specific circumstances.

[0085] The specific embodiments are further described in detail below:

[0086] Embodiment one:

[0087] An OTA region switching scheduling method based on MCU hardware dual partition is disclosed in this embodiment.

[0088] As shown in Figure 1 , the OTA region switching scheduling method based on MCU hardware dual partition comprises:

[0089] S1: The memory of the MCU is pre-divided into firmware A region and firmware B region, and the preset region switching parameters of the firmware A region and the firmware B region are stored through the protected NVM area;

[0090] S2: Obtain the region switching instruction during OTA upgrade, and determine the original firmware region and the new firmware region;

[0091] In this embodiment, the region switching instruction is a request RID as a region switching instruction controlled by the T-BOX through the UDS routine control service, and the instruction is confirmed in advance by the T-BOX and the MCU controller, and the instruction is agreed.

[0092] The UDS (Unified Diagnostic Services) is a diagnostic protocol widely used in the automotive industry.

[0093] S3: write the real-time region switching parameter of the input new firmware region to the preset address according to the region switching instruction;

[0094] S4: in the preset address, check the real-time region switching parameter of the new firmware region with the preset region switching parameter of the stored firmware A region or firmware B region: if the check is passed, execute step S5; if the check fails, execute step S8;

[0095] S5: write the real-time region switching parameter of the new firmware region to the fixed address for region switching parameter protection;

[0096] In step S5, if the check fails, do not write the real-time region switching parameter, keep the original program, and feed back the result of the region switching failure to the T-BOX through the UDS service.

[0097] S6: execute the restart operation by calling the MCU soft reset function;

[0098] In this embodiment, the Bootloader program of the MCU executes the MCU restart by calling the MCU soft reset function, and the parameters of UCB_SWAP_ORIG, UCB_SWAP_COPY, UCB_OPT and UCB_PLAS all take effect after the MCU restart.

[0099] S7: the region switching process is successful, and the program of the new firmware region is executed;

[0100] S8: the region switching process fails, and the program of the original firmware region is executed.

[0101] The application divides the memory of the MCU into independent firmware A region and firmware B region and stores the region switching parameters in advance. By dividing the memory of the MCU into independent regions to form a dual-region independent storage architecture, if a firmware region fails to upgrade or abnormally during the OTA upgrade process, the other region can still operate normally, so that the system will not completely malfunction due to single upgrade failure; and by the preset region switching parameters stored in advance, the system can quickly identify and switch to the available firmware region, significantly reducing the system downtime risk, thereby improving the stability of region switching during the OTA upgrade process of the automobile. At the same time, the dual-region design allows the new firmware to be independently downloaded and verified in the non-active region without interrupting the current system operation; and the storage of the region switching parameters provides a standardized benchmark for the region switching operation, so that the system can quickly switch the firmware version according to the actual demand without repeated parameter configuration. The design of the application shortens the upgrade time and supports flexible management of multiple versions of firmware, meeting the functional requirements in different scenarios.

[0102] The present application performs the check of the cut area parameter in the preset address. By writing the real-time cut area parameter of the new firmware area into the preset address, the possibility of unauthorized access or tampering is limited, ensuring the integrity of the cut area parameter in the transmission and storage process; and the special design of the preset address forms a physical level of security isolation, effectively preventing the damage of the parameter caused by malicious attacks or misoperations, thereby improving the reliability of the cut area (parameter) in the process of automobile OTA upgrade. At the same time, after the check is passed, the cut area parameter is written into the fixed address, which ensures that the cut area parameter can still be retained after the system restarts or powers off through the fixed address, avoiding the failure of the cut area caused by the loss of temporary storage; and the special design of the fixed address isolates the parameter from other data of the system, reducing the risk of being covered or cleared, thereby improving the security of the cut area (parameter) in the process of automobile OTA upgrade.

[0103] The present application executes the program of the new firmware area after the cut area is successful, and executes the program of the original firmware area after the cut area fails. Through the mechanism of rolling back to the original firmware, the system realizes the closed-loop management of upgrade-verification-rollback, so that even if the new firmware has potential defects, the system can automatically switch to the stable version, avoiding service interruption caused by upgrade failure, thereby improving the fault tolerance of the system and ensuring the continuity of the key business. At the same time, the system can automatically complete the firmware switching, avoiding the risk of data loss caused by upgrade failure.

[0104] In step S1, the following steps are specifically included:

[0105] S101: respectively setting the PLASH address segment of the firmware A area and the PLASH address segment of the firmware B area;

[0106] In this embodiment, the PLASH address segment of the firmware A area is 0x800XXXXX-0x803XXXXX; and the PLASH address segment of the firmware B area is 0x806XXXXX-0x809XXXXX.

[0107] S102: respectively storing the preset cut area parameter S1 of the firmware A area and the preset cut area parameter S2 of the firmware B area into the protected NVM area.

[0108] In step S2, if the currently executed address is the PLASH address segment of the firmware A area, the cut area instruction is to switch from the original firmware area firmware A area to the new firmware area firmware B area; if the currently executed address is the PLASH address segment of the firmware B area, the cut area instruction is to switch from the original firmware area firmware B area to the new firmware area firmware A area;

[0109] In step S3, if the switching instruction is to switch from the original firmware area firmware A area to the new firmware area firmware B area, the real-time switching parameter X2 of the new firmware area firmware B area is written into the preset address; if the switching instruction is to switch from the original firmware area firmware B area to the new firmware area firmware A area, the switching parameter X1 of the new firmware area firmware A area is written into the preset address.

[0110] In step S3, the preset address is a RAM address segment 7000XXXX-7000XXXX, which is an address specially divided for the switching parameter and other parameters cannot be written into, so that the parameter is ensured not to be tampered with by other programs running.

[0111] The Bootloader program of the MCU writes the real-time switching parameter X1 of the firmware A area or the real-time switching parameter X2 of the firmware B area into the preset address by calling the NVM writing function, and the success rate of NVM writing is confirmed by the scheduling of the task function of the program.

[0112] In step S4, if the real-time switching parameter X2 of the new firmware area firmware B area is written into the preset address, the preset switching parameter S2 of the stored firmware B area is read by the Bootloader program of the MCU, and the real-time switching parameter X2 is compared with the preset switching parameter S2: if the real-time switching parameter X2 is consistent with the preset switching parameter S2, the verification is passed, otherwise the verification fails.

[0113] If the real-time switching parameter X1 of the new firmware area firmware A area is written into the preset address, the preset switching parameter S1 of the stored firmware A area is read by the Bootloader program of the MCU, and the real-time switching parameter X1 is compared with the preset switching parameter S1: if the real-time switching parameter X1 is consistent with the preset switching parameter S1, the verification is passed, otherwise the verification fails.

[0114] In step S5, after the switching parameter verification succeeds, the Bootloader program of the MCU writes the real-time switching parameter of the new firmware area into the fixed addresses UCB_SWAP_ORIG and UCB_SWAP_COPY; after writing, the UCB_SWAP_ORIG and UCB_SWAP_COPY are protected by setting the parameters of UCB_OPT and UCB_PLASH, to prevent being tampered with by programs, causing the MCU to fail to start.

[0115] Embodiment two:

[0116] On the basis of embodiment one, the technical scheme of health self-verification of the firmware A area and the firmware B area is further designed.

[0117] The OTA area switching scheduling method based on the MCU hardware dual partition, when the area switching instruction is acquired, first carries out health self-checking on the firmware A area and the firmware B area, after the self-checking is passed, the original firmware area and the new firmware area are determined and subsequent steps are executed;

[0118] The processing steps of the health self-checking are as follows:

[0119] S201: based on the hardware unique identifier of the MCU, the header additional information of the firmware A area and the firmware B area is generated;

[0120] S202: based on the header additional information of the firmware A area and the firmware B area and the current timestamp, the firmware A area and the firmware B area are subjected to basic verification;

[0121] S203: based on the basic verification result and the original data of the firmware A area and the firmware B area, the firmware A area and the firmware B area are subjected to cross verification;

[0122] S204: based on the state data of the MCU and the basic threshold value, the dynamic tolerance value of the firmware A area and the firmware B area is calculated;

[0123] S205: based on the basic verification result, the cross verification result and the dynamic tolerance value, the health score of the firmware A area and the firmware B area is calculated: if the health score of the firmware A area and the firmware B area exceeds the safety threshold value, the self-checking is passed; otherwise, the self-checking fails.

[0124] The application is based on the header additional information of the firmware A area and the firmware B area and the current timestamp for basic verification. The header additional information is generated based on the hardware unique identifier of the MCU, has non-replicability, and forms a unique digital fingerprint after being bound with firmware data. The dynamic verification mechanism combined with the current timestamp can effectively resist replay attacks, and even if an attacker obtains a legal firmware, it is also impossible to forge a matching timestamp or hardware identifier, thereby blocking illegal firmware injection from the source and significantly improving system security. At the same time, the introduction of the timestamp enables the system to identify the new and old degree of the firmware version, which can avoid the functional defects or security vulnerabilities caused by the system rollback to a low version.

[0125] The application is based on the basic verification result and the firmware original data for cross verification. The basic verification focuses on the matching of the header additional information and the timestamp, and the cross verification compares the firmware original data (such as code segment, configuration parameter) with the hash value or check recorded in the header information, thereby realizing double-layer verification of the header and the data.

[0126] The application calculates the dynamic tolerance value based on the state data of the MCU and the basic threshold value. The state data (such as temperature, voltage) of the MCU directly affects the memory read-write stability, and the dynamic tolerance value calculated by detecting the state data of the MCU can effectively reflect the influence of environmental factors on the MCU and the area switching success rate.

[0127] The present application calculates a health score based on multi-dimensional results and realizes self-checking. The health score integrates the results of basic verification, cross verification and dynamic tolerance value, quantifies the state of the firmware area into a continuous value of 0-100, and such quantitative evaluation provides fine data support for firmware maintenance, thereby improving the rationality of area cutting in the automobile OTA upgrade process. At the same time, the comparison result of the health score and the safety threshold directly determines whether the self-checking passes. If the score is lower than the threshold, the system can automatically select to roll back to the backup firmware or enter the safety mode to avoid running with disease; if the score is close to the threshold, the system can trigger a warning and limit part of the non-critical functions (such as reducing the level of automatic driving), while continuously monitoring the trend of the health score, and through the hierarchical response mechanism, the fault tolerance capability and user experience of the system are significantly improved, and the impact of OTA upgrade failure is minimized.

[0128] In step S201, the following steps are specifically included:

[0129] 1) Calculate the SHA-3 512-bit hash HA of the firmware A area and the BLAKE3 512-bit hash HB of the firmware B area;

[0130] 2) Take the hardware unique identifier UID as a seed to generate a hardware root key HRK through HKDF-Expand;

[0131] 3) Encrypt the hashes HA and HB through the hardware root key HRK to obtain the ciphertexts CA and CB of the firmware A area and the firmware B area;

[0132] CA = AES-256-CBC(HA, HRK, IV = 0x00...);

[0133] CB = AES-256-CBC(HB, HRK, IV = 0x00...);

[0134] 4) Generate the obfuscation values OA and OB of the firmware A area and the firmware B area by combining the hardware unique identifier UID with the hashes HA and HB;

[0135] OA = HA XOR(UID[0:31]||UID[32:63]);

[0136] OB = HB XOR(UID[32:63]||UID[0:31]);

[0137] 5) Package the ciphertext CA and the obfuscation value OA of the firmware A area, and the ciphertext CB and the obfuscation value OB of the firmware B area to obtain the header additional information of the firmware A area and the firmware B area.

[0138] The header additional information of the firmware A area = [OA|CA|version number];

[0139] Header Additional Info of Firmware B region = [OB | CB | version number].

[0140] In step S202, the following steps are included:

[0141] 1) Extract the ciphertext CA and confusion value OA, and the ciphertext CB and confusion value OB from the header additional information of the firmware A region and the firmware B region;

[0142] 2) Calculate the time factor Thash through the MCU real-time clock (RTC) timestamp;

[0143] Thash = SHA-256 (RTC_timestamp || "KEY_SALT");

[0144] 3) Derive the dynamic keys DKA and DKB of the firmware A region and the firmware B region through the time factor Thash;

[0145] DKA = HMAC-SHA256 (HRK, THash || "A_KEY");

[0146] DKB = HMAC-SHA256 (HRK, THash || "B_KEY");

[0147] 4) Decrypt the ciphertext CA and CB through the dynamic keys DKA and DKB respectively to obtain the decrypted hashes HA_dec and HB_dec of the firmware A region and the firmware B region;

[0148] HA_dec = AES-256-CBC_Decrypt (CA, DKA, IV = 0x00...);

[0149] HB_dec = AES-256-CBC_Decrypt (CB, DKB, IV = 0x00...);

[0150] 5) Calculate the expected confusion values OA_exp and OB_exp of the firmware A region and the firmware B region through the decrypted hashes HA_dec and HB_dec;

[0151] OA_exp = HA_dec XOR (UID[0:31] || UID[32:63]);

[0152] OB_exp = HB_dec XOR (UID[32:63] || UID[0:31]);

[0153] 6) If the confusion value OA of the firmware A region is equal to the expected confusion value OA_exp, the basic verification of the firmware A region passes; otherwise, the basic verification fails;

[0154] If the obfuscation value OB of the firmware B region equals the expected obfuscation value OB exp, the firmware B region basic verification passes; otherwise, the basic verification fails.

[0155] In step S203, the following steps are specifically included:

[0156] 1) Determine whether the basic verification of the firmware A region and the firmware B region passes: if yes, execute the subsequent steps; otherwise, directly execute step S204;

[0157] 2) Calculate the real-time hashes HA live and HB live of the firmware A region and the firmware B region;

[0158] HA live = SHA-3 512 (original data of the firmware A region);

[0159] HB live = BLAKE3 512 (original data of the firmware B region);

[0160] 3) Compare the real-time hashes HA live and HB live of the firmware A region and the firmware B region with the decrypted hashes HA dec and HB dec of the firmware A region and the firmware B region:

[0161] If the real-time hash HA live of the firmware A region equals the decrypted hash HA dec, the firmware A region cross-verification passes; otherwise, the cross-verification fails;

[0162] If the real-time hash HB live of the firmware B region equals the decrypted hash HB dec, the firmware B region cross-verification passes; otherwise, the cross-verification fails.

[0163] In step S204, the following steps are specifically included:

[0164] 1) Obtain the temperature sensor reading Ta and the supply voltage monitoring value Va of the MCU;

[0165] 2) Obtain the pre-stored temperature reference value Tr and voltage reference value Vr, and the basic tolerance threshold ΔH base = 1;

[0166] 3) Calculate the temperature stress coefficient σT through the temperature sensor reading Ta and the temperature reference value Tr;

[0167] σT = 1 + 0.02 × |Ta - Tr|

[0168] 4) Calculate the voltage stress coefficient σV through the supply voltage monitoring value Va and the voltage reference value Vr;

[0169] σV = 1 + 0.05 × |Va - Vr;

[0170] 5) Calculate the comprehensive stress factor σ_total by the temperature stress coefficient σT and the voltage stress coefficient σV;

[0171] σ_total = σT x σV;

[0172] 6) Calculate the dynamic tolerance value ΔH_adj after state compensation by the comprehensive stress factor σ_total and the basic tolerance threshold Δh_base;

[0173] ΔH_adj = ceil(ΔH_base x σ_total);

[0174] Wherein, if the basic verification fails, the dynamic tolerance value ΔH_adj = Δh_base = 1.

[0175] In step S205, the calculation logic of the health score is as follows:

[0176] 1) Set the basic health score of the firmware A area and the firmware B area to 100 points;

[0177] 2) Set the deduction rules:

[0178] If the basic verification fails (the basic verification failure no longer performs cross verification), the dynamic tolerance value ΔH_adj = 1, and the deduction S = 20 points;

[0179] If the basic verification passes, and the cross verification fails, the deduction S = 15 points;

[0180] If the basic verification and the cross verification both pass, and the dynamic tolerance value 0.8 < ΔH_adj < 1, the deduction S = 10 points;

[0181] If the basic verification and the cross verification both pass, and the dynamic tolerance value 0.6 < ΔH_adj < 0.8, the deduction S = 5 points;

[0182] If the basic verification and the cross verification both pass, and the dynamic tolerance value ΔH_adj < 0.6, the deduction S = 0 points;

[0183] 3) Calculate the wear coefficient of the MCU:

[0184] Wear coefficient = number of erasing and writing times / 10000;

[0185] 4) Health score = (100-S) x wear coefficient;

[0186] 5) Health self-checking:

[0187] If the health score > safety threshold 80, the self-checking passes; otherwise, the self-checking fails.

[0188] Finally, it needs to be explained that the above examples are only used to illustrate the technical solutions of the present application but not to limit the technical solutions, and those of ordinary skill in the art should understand that the technical solutions of the present application are modified or equivalently replaced without departing from the purpose and scope of the technical solutions, which should be covered in the scope of claims of the present application.

Claims

1. An OTA partitioning scheduling method based on dual-partition MCU hardware, characterized in that, include: S1: Pre-divide the MCU's memory into firmware area A and firmware area B, and store the preset partitioning parameters for firmware area A and firmware area B. S2: Obtain the partition switching command during OTA upgrade and determine the original firmware partition and the new firmware partition; S3: Write the real-time partitioning parameters of the new firmware area into the preset address according to the partitioning command; S4: In the preset address, verify the real-time partitioning parameters of the new firmware area with the preset partitioning parameters of the stored firmware area A or firmware area B: if the verification passes, proceed to step S5; if the verification fails, proceed to step S8. S5: Write the real-time partitioning parameters of the new firmware area to a fixed address; S6: Perform a restart operation by calling the MCU soft reset function; S7: The partition switching process was successful. The program for the new firmware partition will be executed. S8: The partition switching process failed, and the program in the original firmware area was executed.

2. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 1, characterized in that: Step S1 specifically includes the following steps: S101: Set the PLASH address range of firmware A area and the PLASH address range of firmware B area respectively; S102: Store the preset partitioning parameters S1 of firmware A and the preset partitioning parameters S2 of firmware B into the protected NVM area respectively.

3. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 2, characterized in that: In step S2, if the currently executed address is the PLASH address segment of firmware A, the partition switching instruction is to switch from the original firmware A to the new firmware B; if the currently executed address is the PLASH address segment of firmware B, the partition switching instruction is to switch from the original firmware B to the new firmware A. In step S3, if the partition switching instruction is to switch from the original firmware area A to the new firmware area B, then the real-time partition switching parameter X2 of the new firmware area B is written to the preset address; if the partition switching instruction is to switch from the original firmware area B to the new firmware area A, then the partition switching parameter X1 of the new firmware area A is written to the preset address.

4. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 1, characterized in that: In step S3, the preset address is a RAM address segment, which is a specific address allocated for the partitioning parameters, and other parameters cannot be written.

5. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 3, characterized in that: In step S4, if the real-time switching parameter X2 of firmware B in the new firmware area is written to the preset address, then the preset switching parameter S2 of the stored firmware B area is read, and the real-time switching parameter X2 is compared with the preset switching parameter S2: if the real-time switching parameter X2 is consistent with the preset switching parameter S2, then the verification passes; otherwise, the verification fails. If the real-time switching parameter X1 of firmware A in the new firmware area is written to the preset address, then the preset switching parameter S1 of firmware A stored in the firmware area is read, and the real-time switching parameter X1 is compared with the preset switching parameter S1: if the real-time switching parameter X1 is consistent with the preset switching parameter S1, the verification passes; otherwise, the verification fails.

6. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 1, characterized in that: In step S2, when the partition switching command is obtained, the firmware A partition and firmware B partition are first subjected to a health self-check. After the self-check passes, the original firmware partition and the new firmware partition are determined and subsequent steps are executed. The steps for health self-verification are as follows: S201: Based on the MCU's unique hardware identifier, generate additional header information for firmware A and firmware B areas; S202: Based on the header appended information of firmware A and firmware B, combined with the current timestamp, perform basic verification of firmware A and firmware B. S203: Based on the basic verification results and the original data of firmware A and firmware B, perform cross-verification on firmware A and firmware B. S204: Calculate dynamic tolerance value based on MCU status data and basic threshold; S205: Based on the basic verification results, cross-verification results, and dynamic tolerance value, calculate the health score of firmware A area and firmware B area: if the health score of firmware A area and firmware B area exceeds the security threshold, the self-verification passes; otherwise, the self-verification fails.

7. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 6, characterized in that: Step S201 specifically includes the following steps: 1) Calculate the hash HA of firmware area A and the hash HB of firmware area B; 2) Using the hardware unique identifier UID as a seed, generate the hardware root key HRK through HKDF-Expand; 3) By encrypting the hashes HA and HB using the hardware root key HRK, the ciphertexts CA and CB of firmware A and firmware B are obtained; 4) Generate obfuscation values ​​OA and OB for firmware A and firmware B by combining hash HA and HB with the hardware unique identifier UID; 5) Encapsulate the ciphertext CA and obfuscation value OA of firmware A area and the ciphertext CB and obfuscation value OB of firmware B area to obtain the header additional information of firmware A area and firmware B area.

8. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 7, characterized in that: Step S202 specifically includes the following steps: 1) Extract the ciphertext CA and obfuscation value OA, as well as the ciphertext CB and obfuscation value OB from the header append information of firmware area A and firmware area B; 2) Calculate the time factor Thash using the MCU's real-time clock timestamp; 3) Derive the dynamic keys DKA and DKB for firmware A and firmware B areas using the time factor Thash; 4) Decrypt the ciphertexts CA and CB using dynamic keys DKA and DKB respectively to obtain the decryption hashes HA_dec and HB_dec for firmware A and firmware B areas; 5) Calculate the expected obfuscation values ​​OA_exp and OB_exp for firmware A and firmware B by decrypting hashes HA_dec and HB_dec; 6) If the obfuscation value OA of firmware A is equal to the expected obfuscation value OA_exp, then the basic verification of firmware A passes; otherwise, the basic verification fails. If the obfuscation value OB in firmware B area is equal to the expected obfuscation value OB_exp, then the basic verification of firmware B area passes; otherwise, the basic verification fails. Step S203 specifically includes the following steps: 1) Determine whether the basic verification of firmware A and firmware B has passed: if it has passed, proceed to the next step; otherwise, proceed directly to step S204. 2) Calculate the real-time hashes HA_live and HB_live for firmware A and firmware B areas; 3) Compare the real-time hashes HA_live and HB_live of firmware A and firmware B with the decryption hashes HA_dec and HB_dec of firmware A and firmware B: If the real-time hash HA_live of firmware A is equal to the decryption hash HA_dec, then the cross-validation of firmware A passes; otherwise, the cross-validation fails. If the real-time hash HB_live of firmware B is equal to the decryption hash HB_dec, then the cross-validation of firmware B passes; otherwise, the cross-validation fails.

9. The OTA partitioning scheduling method based on MCU hardware dual partitions as described in claim 8, characterized in that: Step S204 specifically includes the following steps: 1) Obtain the temperature sensor reading Ta and the power supply voltage monitoring value Va of the MCU; 2) Obtain the pre-stored temperature reference value Tr and voltage reference value Vr, as well as the basic tolerance threshold ΔH_base = 1; 3) Calculate the temperature stress coefficient σT using the temperature sensor reading Ta and the temperature reference value Tr; σT = 1 + 0.02 × |Ta - Tr|; 4) Calculate the voltage stress coefficient σV using the power supply voltage monitoring value Va and the voltage reference value Vr; σV=1+0.05×|Va-Vr|; 5) Calculate the comprehensive stress factor σ_total using the temperature stress coefficient σT and the voltage stress coefficient σV; σ_total = σT × σV; 6) Calculate the dynamic tolerance value ΔH_adj after state compensation using the comprehensive stress factor σtotal and the basic tolerance threshold Δh_base; ΔH_adj=ceil(ΔH_base×σ_total); In the formula: ceil represents the floor function; If the basic verification fails, the dynamic tolerance value ΔH_adj = Δh_base = 1.

10. The OTA partitioning scheduling method based on dual-partition MCU hardware as described in claim 9, characterized in that: In step S205, the calculation logic for the health score is as follows: 1) Set the base health score for firmware A and firmware B to 100 points; 2) Set the deduction rules: If the basic verification fails, a deduction of S = 20 points will be made; If the basic validation passes but the cross-validation fails, a deduction of S = 15 points will be made. If both basic validation and cross-validation pass, and the dynamic tolerance value is 0.8 < ΔH_adj < 1, then the deduction S = 10 points. If both basic validation and cross-validation pass, and the dynamic tolerance value is 0.6 < ΔH_adj < 0.8, then the deduction S = 5 points. If both basic validation and cross-validation pass, and the dynamic tolerance value ΔH_adj < 0.6, then the deduction S = 0 points; 3) Calculate the wear coefficient of the MCU: Wear coefficient = Number of erase / write cycles / 10000; 4) Health score = (100-S) × wear coefficient; 5) Health self-verification: If the health score is greater than the safety threshold of 80, the self-verification passes; otherwise, the self-verification fails.

Images