Method and system for dual backup starting and integrity verification of vehicle-mounted bus

Abstract

The application relates to a kind of double backup starting and integrity verification method and system of vehicle-mounted bus, and relates to the technical field of automobile instrument program, which comprises: collecting vehicle software list;Determine new firmware update package according to vehicle software list;New firmware update package is downloaded to the preset update backup area and is carried out integrity check;If integrity check passes, control the boot pointer in the preset boot program area is switched from the preset current running area to update backup area;Load update backup area and start, and execute the preset self-checking scheme to collect start result information;Determine update end scheme according to start result information, and execute update end scheme.The application has the effect of reducing the failure rate caused by the update of automobile instrument program, and facilitating the use of vehicle.

Description

Technical Field

[0001] This invention relates to the field of automotive instrument program technology, and in particular to a dual-backup startup and integrity verification method and system for an in-vehicle bus. Background Technology

[0002] The instrument cluster program is the embedded software in an automotive electronic system responsible for controlling the operation of the instrument panel. Its core function is to connect various vehicle sensors to the instrument panel display components, enabling the collection, processing, display, and interaction of vehicle status information.

[0003] When the car instrument cluster program needs to be updated, the new program is usually downloaded to a temporary cache first to avoid interruption of the download and transmission, which could damage the currently running instrument cluster program. After the new program is transmitted, the original program in the running area is deleted, and the new program in the cache is copied to the running area to update the car instrument cluster program. After the update is complete, the instrument cluster controller is restarted to run the new program.

[0004] Currently, during the process of updating the car instrument panel program, after the new program is transferred to the temporary cache, the entire new program in the temporary cache is copied to the running area. However, during the transfer process, the new program is prone to abnormal code or missing data, resulting in the new program copied to the running area being in a corrupted state. When the running area runs the new program, it is easy to cause instrument panel malfunctions and affect the use of the vehicle. Summary of the Invention

[0005] To reduce the failure rate caused by updating automotive instrument cluster programs and to facilitate vehicle use, this invention provides a dual-backup startup and integrity verification method and system for the vehicle bus.

[0006] In a first aspect, the present invention provides a dual-backup boot and integrity verification method for an in-vehicle bus, employing the following technical solution:

[0007] A method for dual-backup boot and integrity verification of an in-vehicle bus includes:

[0008] S1: Collect vehicle software list;

[0009] S2: Determine the new firmware update package based on the vehicle software list;

[0010] S3: Download the new firmware update package to the preset update backup area and perform integrity verification;

[0011] S4: If the integrity check passes, control the boot pointer in the preset boot program area to switch from the preset current running area to the update backup area;

[0012] S5: Load and update the backup area and start it, and execute the preset self-test scheme to collect startup result information;

[0013] S6: Determine the update termination plan based on the startup result information and execute the update termination plan;

[0014] Methods for determining the new firmware update package include:

[0015] S21: Collect vehicle number;

[0016] S22: Based on the vehicle software list, query the preset inventory database to determine the target software to update;

[0017] S23: Generate vehicle metadata by combining the target update software with the vehicle number;

[0018] S24: Query the preset offline mirror database based on vehicle metadata to determine the offline metadata;

[0019] S25: Perform integrity verification based on offline metadata;

[0020] S26: If the integrity verification passes, generate a new firmware update package based on offline metadata.

[0021] By adopting the above technical solution, the vehicle software list is collected to determine the new firmware update package. The new firmware update package is then downloaded to the preset update backup area and its integrity is verified. When the integrity verification passes, the boot pointer in the control boot program area is switched to the update backup area and loaded and started. Then, a self-test scheme is executed to collect the startup result information and determine the update end scheme. Finally, the update end scheme is executed, thereby ensuring that the data is not damaged and the functions are not abnormal, reducing the failure rate caused by updating the vehicle instrument program. Furthermore, by accurately matching the target update software with the vehicle software list and vehicle number, and by performing layered verification of metadata in the inventory database and the mirror offline database, it is not easily affected by network fluctuations, ensuring the accuracy and security of the update package.

[0022] Optional, integrity verification methods include:

[0023] S251: Retrieve timestamps, snapshot metadata, and offline signatures based on offline metadata;

[0024] S252: Determine time freshness based on timestamp;

[0025] S253: Determine the snapshot reference value based on the snapshot metadata;

[0026] S254: Determine the signature reference value based on the offline signature;

[0027] S255: Determine the verification reference value by combining time freshness, snapshot reference value and signature reference value;

[0028] S256: Determine whether the verification reference value is greater than the preset verification baseline value;

[0029] S257: If yes, output the preset verification pass information;

[0030] S258: If not, output the preset verification failure message.

[0031] By adopting the above technical solutions, a layered and progressive integrity verification system is constructed through multi-dimensional verification of timestamps, snapshot metadata, and offline signatures, as well as quantitative evaluation of verification reference values. This system can comprehensively identify anomalies in metadata in terms of time freshness, data consistency, and signature legality, ensuring that the metadata of the new firmware update package is authentic and reliable, and building a solid data security defense for subsequent program updates.

[0032] Optionally, after determining the verification reference value, the following may also be included:

[0033] S2551: Retrieve offline target metadata based on offline metadata;

[0034] S2552: Retrieve online target metadata from the preset inventory database based on offline target metadata;

[0035] S2553: Determine the target consistency reference value by combining offline target metadata and online target metadata;

[0036] S2554: Determine whether the target consistency reference value is less than the preset target consistency benchmark value;

[0037] S2555: If yes, calculate the sum of the target consistency reference value and the verification reference value, and update and replace the verification reference value;

[0038] S2556: If not, continue to output the verification reference value.

[0039] By adopting the above technical solution, cross-validation of online and offline target metadata is introduced into the integrity verification process. The verification reference value is supplemented and optimized by the target consistency reference value, which further eliminates the potential risks of metadata from a single database. This upgrades metadata verification from single-dimensional legality to multi-source consistency, significantly improving the comprehensiveness and reliability of metadata verification for new firmware update packages.

[0040] Optionally, before downloading the new firmware update package to the preset update backup area, the following steps are included:

[0041] S31: Send an authentication request to the preset instrument controller and collect random numbers;

[0042] S32: Sign the random number using the preset private key to obtain a random signature;

[0043] S33: Send a random signature to the preset instrument controller for verification using the preset public key to obtain the signature validity;

[0044] S34: Determine whether the signature validity verification was successful;

[0045] S35: If yes, then the transmission will be based on the new firmware update package;

[0046] S36: If not, output the preset interrupt connection control information.

[0047] By adopting the above technical solution, through the identity authentication process of private key signing and public key verification, the legitimacy of the update initiator is verified before the new firmware update package is transmitted, effectively intercepting illegal update requests from unauthorized devices, ensuring the security of automotive instrument program updates from the source, and preventing malicious program injection or illegal tampering.

[0048] Optionally, transmission methods based on the new firmware update package include:

[0049] S351: Generate a unique session key based on a random number;

[0050] S352: Generate packet byte values ​​based on the new firmware update package;

[0051] S353: The new firmware update package is divided into packets according to the packet byte values ​​and symmetrically encrypted according to the unique session key to obtain a single separate update package;

[0052] S354: Transmit based on a single separate update packet.

[0053] By adopting the above technical solution, through symmetric encryption of a unique session key and packet transmission mechanism, the confidentiality of data is guaranteed during the transmission of the new firmware update package, and the fault tolerance of data transmission is improved through packet design, ensuring the integrity and security of the update package during the transmission process.

[0054] Optionally, downloading the new firmware update package to a preset update backup area and performing an integrity verification includes:

[0055] S3551: Decrypt a single split update packet using the unique session key to obtain a single decrypted update packet;

[0056] S3552: Download individual decryption update packages sequentially to the preset update backup area;

[0057] S3553: After all downloads are complete, determine the actual hash value based on all individual decryption update packets;

[0058] S3554: Determine the expected hash value based on the new firmware update package;

[0059] S3555: Determine whether the actual hash value matches the expected hash value;

[0060] S3556: If yes, output the preset verification pass information;

[0061] S3557: If not, erase all individual decryption update packages.

[0062] By adopting the above technical solution, through the integrity verification process of decryption and hash value comparison, after the new firmware update package is downloaded to the update backup area, the consistency between the program data and the original update package is accurately verified, avoiding program damage caused by transmission interference or storage errors; if the verification fails, the data is erased to prevent the damaged program from occupying storage resources or causing subsequent startup failures, thus ensuring the purity and availability of the program in the update backup area.

[0063] Optionally, the following are also included before loading and updating the backup area and starting:

[0064] S51: Collects current vehicle status information;

[0065] S52: Retrieve gear information and software usage based on the vehicle's current status information;

[0066] S53: When the gear information is the preset parking gear, retrieve the usage type and usage time value based on the software usage situation;

[0067] S54: Retrieve update type based on new firmware update package;

[0068] S55: Determine the category impact value by combining the type of use and the type of update;

[0069] S56: Determine the safety status value based on the usage time value and the type of influence value;

[0070] S57: When the security status value is greater than the preset security baseline value, continue to load and update the backup area and start it.

[0071] By adopting the above technical solution, the vehicle's gear position and software usage are detected from multiple dimensions before loading and updating the backup area. This ensures that the startup operation is only performed when the vehicle is in a safe state such as parking, avoiding program conflicts or hardware anomalies caused by dynamic vehicle operation during the update process. This improves the security of starting the vehicle's instrument panel program update from the scenario level.

[0072] Optionally, methods for determining the update termination scheme include:

[0073] S61: Determine whether the startup result information is consistent with the preset startup success information;

[0074] S62: If yes, output the preset update reporting scheme and use it as the update termination scheme;

[0075] S63: If not, continue to collect startup result information and perform timing to obtain the startup duration value;

[0076] S64: When the startup duration value is greater than the preset waiting time value, the boot pointer in the preset boot program area is switched back to the current running area and the current running area is reloaded and started as a failure execution plan;

[0077] S65: Combine the failure execution plan with the preset failure alarm plan as the update termination plan.

[0078] By adopting the above technical solutions, differentiated processing of startup result information is implemented. When successful, the update is reported in a timely manner to achieve closed-loop management of the update process. When it fails, the boot pointer is automatically rolled back and an alarm is triggered to ensure that the system can quickly recover to an available state when an update is abnormal. At the same time, the alarm mechanism promptly reminds maintenance personnel to intervene, which takes into account both the automation of updates and the traceability of faults, and greatly improves user experience and fault handling efficiency.

[0079] Secondly, the present invention provides a dual-backup boot and integrity verification system for an in-vehicle bus, employing the following technical solution:

[0080] A dual-backup boot and integrity verification system for an in-vehicle bus includes:

[0081] The data acquisition module is used to collect vehicle software list, startup result information, vehicle number, random number and current vehicle status information;

[0082] The memory stores a program for implementing a dual-backup startup and integrity verification method for an onboard bus as described in any one of the first aspects;

[0083] The processor loads and executes programs stored in memory.

[0084] In summary, the present invention has at least one of the following beneficial technical effects:

[0085] 1. By collecting the vehicle software list and identifying the new firmware update package, the new firmware update package is downloaded to the preset update backup area and its integrity is verified. When the integrity verification is successful, the boot pointer in the boot program area is switched to the update backup area and loaded and started. Then, a self-test scheme is executed to collect the startup result information and determine the update end scheme. Finally, the update end scheme is executed to ensure that the data is not damaged and the functions are normal, thereby reducing the failure rate caused by updating the vehicle instrument program.

[0086] 2. By accurately matching the target software update with the vehicle software list and vehicle number, and by performing layered verification of metadata in the inventory database and the mirror offline database, it is not easily affected by network fluctuations, thus ensuring the accuracy and security of the update package.

[0087] 3. To address the differentiated processing of startup result information, the update is reported promptly upon success, achieving closed-loop management of the update process; upon failure, the boot pointer is automatically rolled back and an alarm is triggered, ensuring that the system can quickly recover to an available state when an update is abnormal. At the same time, the alarm mechanism promptly reminds maintenance personnel to intervene, balancing the automation of updates with the traceability of faults, and significantly improving user experience and fault handling efficiency. Attached Figure Description

[0088] Figure 1 This is a flowchart of the method for dual backup boot and integrity verification of the vehicle bus;

[0089] Figure 2 This is a flowchart illustrating the method for determining the new firmware update package;

[0090] Figure 3 This is a flowchart illustrating the process before downloading the new firmware update package to the preset update backup area.

[0091] Figure 4 This is a flowchart illustrating the method for downloading the new firmware update package to a preset update backup area and performing integrity verification. Detailed Implementation

[0092] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0093] A dual-backup boot and integrity verification method for vehicle bus systems is proposed. This method first collects the vehicle software inventory and serial number, matches the target update software, and generates and verifies metadata using a combination of an inventory database and an offline mirror database to ensure the legitimacy of the new firmware update package. Before transmission, the package undergoes private key signing and public key verification for authentication. Then, it is encrypted and transmitted in packets using a unique session key. After downloading to the update backup area, integrity is verified by hash value comparison; if verification fails, the data is erased. Furthermore, the method checks the vehicle's safety status before booting, then switches the boot pointer to the update backup area. After booting, a self-test is performed; if successful, a completion report is submitted; otherwise, the pointer is automatically rolled back and an alarm is triggered. This ensures data integrity and functional normal operation, reducing the failure rate caused by updating vehicle instrument cluster programs and guaranteeing the security, reliability, and recoverability of instrument cluster program updates.

[0094] Reference Figure 1 This invention discloses a method for dual-backup boot and integrity verification of an in-vehicle bus, comprising:

[0095] S1: Collect vehicle software list.

[0096] The vehicle software list refers to a list that records the software information currently running in various electronic control units of the vehicle (such as instrument ECU, engine ECU, etc.), and usually includes key information such as software name, version number, hardware compatibility model, and release time.

[0097] The host computer (such as an automotive diagnostic tool) sends software information request commands to each electronic control unit (ECU) of the vehicle through the vehicle communication interface. Each electronic control unit responds to the command and returns the software information stored in its own memory, thereby obtaining the vehicle software list.

[0098] S2: Determine the new firmware update package based on the vehicle software list.

[0099] A new firmware update package refers to a collection of upgrade files used to upgrade the software in a vehicle. The new firmware update package contains the new program code to be installed, version identifiers, hardware compatibility information, integrity checksums (such as SHA-256 hash values), and other information.

[0100] By querying the vehicle software list, the upgrade files corresponding to the software that needs to be updated are selected as the new firmware update package for convenient use later.

[0101] To further ensure the rationality of the new firmware update package, it is necessary to perform further separate analysis and calculation on the new firmware update package, which will be explained in detail through the steps shown below.

[0102] Reference Figure 2 The method for determining the new firmware update package includes the following steps:

[0103] S21: Collect vehicle number.

[0104] The vehicle number is a string or code that uniquely identifies a single vehicle (such as the Vehicle Identification Number, VIN). The vehicle number is acquired by the host computer after establishing communication with the vehicle's ECU via the vehicle communication interface.

[0105] S22: Based on the vehicle software list, query the preset inventory database to determine the target software to update.

[0106] The inventory database refers to an online, structured database that stores available software update packages for each vehicle's ECU. The inventory database pre-stores software update packages for different software, each package including information such as software name, version number, compatible hardware model, update content (e.g., feature optimization, vulnerability fixes), release date, and integrity checksum. The inventory database is accessed through real-time uploads. The target update software refers to the name of the software that needs to be updated.

[0107] By comparing the version numbers corresponding to each software name in the vehicle software list with the corresponding version numbers in the inventory database, and retrieving the software names whose version numbers in the vehicle software list are lower than those in the inventory database as target software for update, it is convenient for subsequent use.

[0108] S23: Combine target update software with vehicle number to generate vehicle metadata.

[0109] Among them, vehicle metadata refers to the structured data set corresponding to the software update for vehicle identity. Vehicle metadata includes key fields such as the version number of the target updated software, the compatible hardware model, timestamp, snapshot metadata, signature, and specific update content.

[0110] The system retrieves detailed static metadata about a vehicle, such as its hardware configuration and software version, by vehicle number. Then, it performs a compatibility check on the target software update using the retrieved static metadata. If the check passes, the data in the software update package corresponding to the target software update is used as the vehicle metadata.

[0111] S24: Query the preset offline mirror database based on vehicle metadata to determine the offline metadata.

[0112] The mirror offline database refers to a structured database that is offline and stores available software update packages for each vehicle's ECU. The content stored in the mirror offline database is identical to that stored in the inventory database, and the mirror offline database is obtained after being pre-downloaded and stored. Offline metadata refers to the baseline metadata corresponding to the vehicle metadata, stored in the pre-defined mirror offline database.

[0113] By comparing the vehicle metadata with various data in the offline image database, and selecting the software update package corresponding to the vehicle metadata in the offline image database, the data in the selected software update package is used as offline metadata for convenient subsequent use.

[0114] S25: Perform integrity verification based on offline metadata.

[0115] In this process, the integrity of offline metadata is verified to ensure that the offline metadata has not been tampered with, damaged, or lost during transmission and storage, thus ensuring that the offline metadata is completely consistent with the vehicle metadata and facilitating subsequent use.

[0116] To further ensure the rationality of integrity verification, it is necessary to perform further separate analysis and calculation on integrity verification, which will be explained in detail through the steps shown below.

[0117] The integrity verification method includes the following steps:

[0118] S251: Retrieve timestamps, snapshot metadata, and offline signatures based on offline metadata.

[0119] The timestamp refers to the precise time information recorded when the offline metadata was generated. Snapshot metadata refers to a snapshot of the software's complete version information, data structure characteristics, storage location identifiers, etc., recorded in the offline metadata at a specific moment. The offline signature is a digital signature generated after encrypting the offline metadata using the offline database's proprietary private key. Offline metadata includes timestamps, snapshot metadata, and offline signatures.

[0120] The timestamp, snapshot metadata, and offline signature can be retrieved through offline metadata, making it convenient for subsequent use.

[0121] S252: Determine time freshness based on timestamp.

[0122] Among them, time freshness refers to the metric that measures the timeliness of timestamps in offline metadata.

[0123] The time difference is calculated by comparing the timestamp with the current real-time of the system. The larger the time difference, the lower the time freshness. The product of the time difference and a preset freshness coefficient is then calculated, and the result is used as the time freshness for subsequent use.

[0124] The freshness coefficient is a coefficient used to convert time difference into time freshness. The freshness coefficient is preset by the operator according to the needs.

[0125] S253: Determine the snapshot reference value based on the snapshot metadata.

[0126] Among them, the snapshot reference value refers to the metric used to measure the completeness of snapshot metadata.

[0127] The snapshot metadata is compared with the preset snapshot baseline metadata, and the consistency of the comparison results is parameterized as a snapshot reference value for easy use in the future.

[0128] The snapshot baseline metadata is pre-stored as a state snapshot that, under normal circumstances, should contain complete version information, data structure characteristics, storage location identifiers, etc. The snapshot baseline metadata is obtained after being pre-entered by the operator.

[0129] For example, when the snapshot metadata only includes complete version information and data structure characteristics, while the snapshot base metadata includes complete version information, data structure characteristics, and storage location identifier, the number of consistent elements between the snapshot metadata and the preset snapshot base metadata is 2, while the number of snapshot base metadata is 3. In this case, the snapshot reference value is 2 / 3.

[0130] S254: Determine the signature reference value based on the offline signature.

[0131] The signature reference value is an indicator used to measure whether a digital signature has been tampered with.

[0132] The online signature is retrieved by retrieving the vehicle's metadata, and the offline signature is compared with the online signature. The consistency value of the comparison is used as a signature reference value for subsequent use.

[0133] S255: Determine the verification reference value by combining time freshness, snapshot reference value and signature reference value.

[0134] The verification reference value refers to the comprehensive reference value used when verifying based on timestamps, snapshot metadata, and offline signatures.

[0135] By weighting the time freshness, snapshot reference value, and signature reference value, and using the result as a verification reference value, subsequent use is facilitated. The specific weights of time freshness, snapshot reference value, and signature reference value are set by the operator according to actual needs.

[0136] To further ensure the reasonableness of the verification reference values, it is necessary to perform further separate analysis and calculations after the verification reference values ​​are determined. The specific steps are explained in detail below.

[0137] After determining the verification reference value, the following steps are also included:

[0138] S2551: Retrieve offline target metadata based on offline metadata.

[0139] Offline target metadata refers to the core subset of offline metadata specifically for the target update software. Offline target metadata contains detailed characteristic information about the target update software, such as the precise version number, a complete list of compatible hardware models, functional module identifiers, block checksums, and official release notes. Offline metadata includes offline target metadata.

[0140] The offline target metadata is retrieved through offline metadata, which facilitates subsequent use.

[0141] S2552: Retrieve online target metadata from the preset inventory database based on offline target metadata.

[0142] Online target metadata refers to the core subset of the target update software in the inventory database. It also contains detailed characteristic information about the target update software, such as the precise version number, a complete list of compatible hardware models, functional module identifiers, block checksums, and official release notes. Offline metadata includes offline target metadata.

[0143] By retrieving detailed feature information corresponding to the target update software to which the offline target metadata belongs from the preset inventory database and using it as online target metadata, it is convenient for subsequent use.

[0144] S2553: Determine the target consistency reference value by combining offline target metadata with online target metadata.

[0145] Among them, the target consistency reference value refers to the indicator that measures the consistency between offline target metadata and online target metadata.

[0146] By comparing the corresponding fields of offline and online target metadata and parameterizing the consistency, a target consistency reference value is obtained for convenient subsequent use.

[0147] S2554: Determine whether the target consistency reference value is less than the preset target consistency benchmark value. If yes, proceed to S2555; if no, proceed to S2556.

[0148] The target consistency benchmark value refers to the minimum level of consistency that offline target metadata and online target metadata should achieve under normal circumstances. The target consistency benchmark value is obtained through pre-input by the operator.

[0149] By judging whether the target consistency reference value is less than the preset target consistency benchmark value, it is determined whether the consistency between offline target metadata and online target metadata meets the requirements.

[0150] S2555: Calculate the sum of the target consistency reference value and the verification reference value, and update and replace the verification reference value.

[0151] When the target consistency reference value is less than the preset target consistency benchmark value, it indicates that the offline target metadata and the online target metadata are too different. Therefore, the sum of the target consistency reference value and the verification reference value is calculated, and the calculation result is used to update and replace the verification reference value, thereby improving the accuracy of the obtained verification reference value.

[0152] S2556: Continue outputting verification reference values.

[0153] When the target consistency reference value is not less than the preset target consistency benchmark value, it indicates that the offline target metadata and the online target metadata are highly consistent, so the verification reference value continues to be output.

[0154] S256: Determine whether the verification reference value is greater than the preset verification baseline value. If yes, proceed to S257; if no, proceed to S258.

[0155] The verification baseline value refers to the minimum value that integrity must be achieved during a normal update. The verification baseline value is obtained after being pre-input by the operator.

[0156] The verification is judged by whether the verification reference value is greater than the preset verification benchmark value.

[0157] S257: Output the preset verification pass information.

[0158] The verification pass information refers to the information used to indicate that the integrity verification has passed. The verification pass information is obtained after being pre-entered by the operator.

[0159] When the verification reference value is greater than the preset verification baseline value, it means that the verification is successful, so the preset verification success information is output.

[0160] S258: Output the preset verification failure message.

[0161] The verification failure message refers to the information used to indicate when the integrity verification fails. The verification failure message is obtained after the operator has pre-entered the information.

[0162] If the verification reference value is not greater than the preset verification baseline value, it means that the verification fails, so the preset verification failure message is output.

[0163] S26: If the integrity verification passes, generate a new firmware update package based on offline metadata.

[0164] If the integrity verification passes, it means that the offline metadata can be used directly for updating. Therefore, by extracting core fields such as target hardware model, new firmware version number, update type, and package format specification from the offline metadata and encapsulating them into a common update package format for automotive scenarios, the accuracy of the obtained new firmware update package is improved.

[0165] S3: Download the new firmware update package to the preset update backup area and perform integrity verification.

[0166] The update backup area refers to a pre-defined partition used for temporary storage during updates. The vehicle storage system pre-divides an update backup area, a current running area, and a boot program area. The current running area is the pre-defined partition used for runtime, and the boot program area is the partition used to boot from either the update backup area or the current running area.

[0167] Integrity verification refers to verifying the integrity of a downloaded new firmware update package.

[0168] Download the new firmware update package to the preset update backup area and perform integrity verification. For details, refer to S3551 to S3557.

[0169] To further ensure the rationality of downloading the new firmware update package to the preset update backup area, it is necessary to perform further separate analysis and calculations before downloading the new firmware update package to the preset update backup area. The specific steps are explained in detail below.

[0170] Reference Figure 3 Before downloading the new firmware update package to the preset update backup area, the following steps are included:

[0171] S31: Send an authentication request to the preset instrument controller and collect random numbers.

[0172] The instrument cluster controller refers to the core electronic control unit (ECU) pre-configured in the vehicle, responsible for managing the operation of the vehicle's instrument cluster program. An authentication request is a data packet sent by the update initiator (such as an OTA server or diagnostic tool) to the instrument cluster controller to request authentication. A random number is a string of random numbers or characters (such as a 32-bit random string) generated by the instrument cluster controller using a random number generation algorithm after receiving the authentication request; it is one-time and unique.

[0173] The update initiator sends an authentication request to a preset instrument controller. After receiving the authentication request, the instrument controller starts its built-in random number generation algorithm to generate a random number and sends it back to the update initiator, thereby obtaining the random number.

[0174] S32: Sign the random number using the preset private key to obtain a random signature.

[0175] The preset private key refers to a private key that is pre-configured and securely stored. The preset private key is held by the initiator of the update.

[0176] A random signature is a digital signature generated by encrypting a random number using a preset private key.

[0177] The random number is encrypted using a preset private key, and the resulting digital signature is used as the random signature for convenient subsequent use.

[0178] S33: Send a random signature to the preset instrument controller for verification using the preset public key to obtain the signature validity.

[0179] The preset public key refers to the public key paired with the preset private key. The preset public key is held by the instrument controller. Signature validity refers to the result obtained after verifying a random signature using the preset public key. Signature validity includes whether the signature is valid or invalid.

[0180] By sending a random signature to a preset instrument controller, the instrument controller verifies the random signature using a preset public key and uses the verification result as the validity of the signature.

[0181] S34: Determine whether the signature validity verification was successful. If yes, proceed to S35; if no, proceed to S36.

[0182] Specifically, the ability to transmit data is determined by verifying the validity of the signature.

[0183] S35: Transmission is based on the new firmware update package.

[0184] When the signature validity verification is successful, it means that the random signature was indeed generated by the paired private key and the random number was not tampered with during the signing process, so it can be transmitted. Therefore, the new firmware update package is transmitted.

[0185] To further ensure the rationality of transmission based on the new firmware update package, a more detailed analysis and calculation of transmission based on the new firmware update package is required, which will be explained in detail through the steps shown below.

[0186] The transmission method based on the new firmware update package includes the following steps:

[0187] S351: Generate a unique session key based on a random number.

[0188] Among them, the unique session key refers to the temporary symmetric key used by the update initiator and the instrument controller to encrypt the transmission of subsequent data during a communication session.

[0189] By retrieving the instrument controller hardware identifier and timestamp, and then combining them with random numbers to form mixed seed data, a preset key derivation algorithm (such as HKDF, PBKDF2, etc.) is used to perform calculations on the mixed seed data to obtain a unique session key.

[0190] The key derivation algorithm is preset by the operator.

[0191] S352: Generate packet byte values ​​based on the new firmware update package.

[0192] The packet byte value refers to the specific byte size of each packet when the new firmware update package is divided into packets.

[0193] The overall byte value is retrieved by the new firmware update package, and then the quotient between the overall byte value and the preset number of packets is calculated to obtain the packet byte value, which is convenient for subsequent use.

[0194] The number of subcontractors refers to the number of subcontractors that need to be subcontracted. The number of subcontractors is obtained after the operator has pre-entered the information.

[0195] S353: The new firmware update package is divided into packets according to the packet byte values ​​and symmetrically encrypted according to the unique session key to obtain a single separate update package.

[0196] A single split update package refers to a single update package after it has been split into multiple packages.

[0197] The encrypted new firmware update package is divided into packets by splitting the byte values ​​into packets, and then symmetrically encrypted according to the unique session key to obtain a single separate update package, which is convenient for subsequent use.

[0198] S354: Transmit based on a single separate update packet.

[0199] This is achieved by transmitting individual separate update packages sequentially, which facilitates transmission.

[0200] To further ensure the rationality of downloading the new firmware update package to the preset update backup area and performing integrity verification, it is necessary to conduct further separate analysis and calculation on downloading the new firmware update package to the preset update backup area and performing integrity verification. The specific steps are explained in detail below.

[0201] Reference Figure 4 Downloading the new firmware update package to the preset update backup area and performing integrity verification includes the following steps:

[0202] S3551: Decrypt a single split update package using the unique session key to obtain a single decrypted update package.

[0203] A single decrypted update package refers to a single update package after decryption.

[0204] By decrypting a single separate update package using a unique session key, a single decrypted update package is obtained, which is convenient for subsequent use.

[0205] S3552: Download individual decryption update packages sequentially to the preset update backup area.

[0206] This involves downloading individual decryption update packages sequentially to a preset update backup area and then reassembling them according to the transmission order for easy use later.

[0207] S3553: Once all downloads are complete, determine the actual hash value based on all individual decryption update packets.

[0208] The actual hash value refers to the hash value calculated using a preset hash algorithm after reassembling all the individual decrypted update packages into a complete new firmware update package.

[0209] Once all downloads are complete, verification can proceed. Therefore, the overall update package, formed by reassembling all the individual decrypted update packages, is calculated using a preset hash algorithm (such as SHA-256) to obtain the actual hash value for subsequent use.

[0210] S3554: Determine the expected hash value based on the new firmware update package.

[0211] The expected hash value refers to the hash value calculated for the new firmware update package using a preset hash algorithm.

[0212] The expected hash value is obtained by calculating the new firmware update package using a preset hash algorithm (such as SHA-256), which facilitates subsequent use.

[0213] S3555: Determine whether the actual hash value matches the expected hash value. If yes, proceed to S3556; if no, proceed to S3557.

[0214] The integrity check is determined by comparing the actual hash value with the expected hash value.

[0215] S3556: Output the preset verification pass information.

[0216] The verification pass information refers to the information used to indicate that the integrity verification has passed. The verification pass information is obtained after being pre-entered by the operator.

[0217] When the actual hash value matches the expected hash value, it means that the integrity check has passed, so the preset check pass information is output.

[0218] S3557: Erase all individual decryption update packages.

[0219] When the actual hash value is inconsistent with the expected hash value, it means that the integrity check fails, so all individual decryption update packages are erased.

[0220] S36: Output preset interrupt connection control information.

[0221] Among them, the interruption connection control information refers to the information used to control the interruption of transmission. The interruption connection control information is obtained after being pre-entered by the operator.

[0222] If the signature validity verification fails, it means that the random signature was not generated by the paired private key or the random number was tampered with during the signing process, and therefore cannot be transmitted. So the preset interruption control information is output.

[0223] S4: If the integrity check passes, control the boot pointer in the preset boot program area to switch from the preset current running area to the update backup area.

[0224] The boot pointer is a key address identifier recorded in the bootloader, which indicates which storage partition the bootloader should load the main program from next.

[0225] If the integrity check passes, it means that the new firmware update package downloaded in the update backup area can be run. Therefore, the boot pointer in the preset boot program area is switched from the preset current running area to the update backup area, so as to facilitate the subsequent running of the new firmware update package in the update backup area.

[0226] S5: Load and update the backup area and start it, and execute the preset self-test scheme to collect startup result information.

[0227] The self-test scheme refers to a predefined set of automated inspection processes. It includes hardware interface verification, core function testing, and version compatibility checks, used to quickly confirm whether the new firmware functions correctly after startup. The self-test scheme is pre-configured by the operator based on actual needs.

[0228] Startup result information refers to the result information used to indicate whether the startup was successful or failed.

[0229] By loading and updating the backup area and starting it, a preset self-test scheme is used to check the operation and version compatibility of the new firmware update package during startup, and the startup result information is collected for convenient use later.

[0230] To further ensure the rationality of loading and updating the backup area and starting it, it is necessary to perform further separate analysis and calculations before loading and updating the backup area and starting it. The specific steps are explained in detail below.

[0231] The following steps are also included before loading and updating the backup area and starting:

[0232] S51: Collect current vehicle status information.

[0233] Among them, the vehicle current status information refers to the real-time dynamic data set of the vehicle's core systems (power, chassis, electronics, and instrumentation) before the new firmware is started and runs stably.

[0234] The vehicle's current status information is obtained by querying the vehicle's various electronic control units.

[0235] S52: Retrieve gear information and software usage based on the vehicle's current status information.

[0236] The gear information refers to the current gear position of the vehicle's transmission, including Park (P), Reverse (R), Neutral (N), Drive (D), and manual mode gears (such as M1 and M2). Software usage information refers to the operational status data of various software modules in the instrument cluster system (such as navigation, media control, vehicle settings, and fault diagnosis) after the new firmware is activated. The current vehicle status information includes gear information and software usage status.

[0237] The system retrieves gear information and software usage data based on the vehicle's current status, facilitating future use.

[0238] S53: When the gear information is the preset parking gear, retrieve the usage type and usage time value based on the software usage.

[0239] Here, "Parking gear" refers to the gear position when the vehicle is parked. "Usage type" refers to the type of software currently running. "Usage time value" refers to the running time value of the software. Software usage includes both usage type and usage time value.

[0240] By retrieving usage data, including usage type and time, the software can be used more efficiently for future reference.

[0241] S54: Retrieve update type based on new firmware update package.

[0242] The update type refers to the software category to which the new firmware update package belongs. New firmware update packages include update types.

[0243] The update type can be retrieved through the new firmware update package for easier use later.

[0244] S55: Determine the category impact value by combining the category of use and the category of update.

[0245] Among them, the category impact value refers to the parameter value that affects the operation of the software corresponding to the updated category when the software of the used category is running.

[0246] By inputting the usage type and update type into the preset type influence database, the type influence value is obtained through matching, which facilitates subsequent use.

[0247] The category impact database is obtained by pre-storing a table that maps different usage categories and update categories to their corresponding category impact values. The category impact database is acquired by the operator running each usage category and collecting data on its impact on the update category.

[0248] S56: Determine the safety status value based on the usage time value and the type of influence value.

[0249] Among them, the security status value refers to the quantitative indicator for evaluating the security and stability of running a new firmware update package.

[0250] By weighting the usage time value and the category impact value, and using the calculation result as a safety status value, subsequent use is facilitated. The specific weights of the usage time value and the category impact value are set by the operator according to actual needs.

[0251] S57: When the security status value is greater than the preset security baseline value, continue to load and update the backup area and start it.

[0252] The security baseline value refers to the baseline value corresponding to the normal operation of a new firmware update package. The security baseline value is obtained after being pre-entered by the operator.

[0253] When the security status value is greater than the preset security baseline value, it means that the currently running software is unlikely to affect the operation of the new firmware update package, so continue to load the update backup area and start.

[0254] S6: Determine the update termination plan based on the startup result information and execute the update termination plan.

[0255] Among them, the update termination plan refers to the closing plan corresponding to the end of the update.

[0256] By analyzing the results corresponding to the startup results, the update termination plan is determined and executed, thereby ensuring that the data is not damaged and the functions are normal, reducing the failure rate caused by updating the vehicle instrument program.

[0257] To further ensure the rationality of the update termination plan, it is necessary to conduct a further separate analysis and calculation of the update termination plan, which will be explained in detail through the steps shown below.

[0258] The method for determining the end of the update process includes the following steps:

[0259] S61: Determine whether the startup result information is consistent with the preset startup success information. If yes, proceed to S62; if no, proceed to S63.

[0260] Among them, the startup success message refers to the result information used to indicate that the startup was successful. The startup success message is obtained after the operator has pre-entered the information.

[0261] The system determines whether the update was successfully completed by comparing the startup result information with the preset startup success information.

[0262] S62: Output the preset update reporting scheme and use it as the update termination scheme.

[0263] The update reporting scheme refers to the scheme corresponding to a successful update report. The update reporting scheme is obtained after pre-entry by the operator.

[0264] When the startup result information is consistent with the preset startup success information, it means that the startup has been successfully completed. Therefore, the preset update reporting scheme is output as the update termination scheme.

[0265] S63: Continue to collect startup result information and perform timing to obtain the startup duration value.

[0266] The startup duration value refers to the duration during which the new firmware update package is started.

[0267] When the startup result information is inconsistent with the preset startup success information, it means that the startup has not been successfully completed. Therefore, the startup duration value is collected.

[0268] S64: When the startup duration value is greater than the preset waiting time value, the boot pointer in the preset boot program area is switched back to the current running area and the current running area is reloaded and started as a failure execution plan.

[0269] The waiting time value refers to the maximum duration required for a new firmware update package to start under normal circumstances. This waiting time value is obtained after being pre-entered by the operator. The failure execution plan refers to the plan to be adopted when the new firmware update fails to start.

[0270] When the startup duration exceeds the preset waiting time, it indicates that the startup has failed. Therefore, the failure execution plan is to switch the boot pointer in the preset bootloader area back to the current running area, reload the current running area, and start the startup, which is convenient for subsequent use.

[0271] S65: Combine the failure execution plan with the preset failure alarm plan as the update termination plan.

[0272] Among them, the failure alarm scheme refers to the scheme that issues an alarm when the new firmware update fails to start.

[0273] By combining the failed execution plan with the preset failure alarm plan, a plan set is formed and used as the update termination plan, thereby improving the accuracy of the obtained update termination plan.

[0274] Based on the same inventive concept, embodiments of the present invention provide a dual-backup boot and integrity verification system for an in-vehicle bus, comprising:

[0275] The data acquisition module is used to collect vehicle software list, startup result information, vehicle number, random number and current vehicle status information;

[0276] The memory stores a program for implementing a dual-backup boot and integrity verification method for an onboard bus as described above.

[0277] The processor loads and executes programs stored in memory.

[0278] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0279] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for dual-backup boot and integrity verification of an in-vehicle bus, characterized in that, include: S1: Collect vehicle software list; S2: Determine the new firmware update package based on the vehicle software list; S3: Download the new firmware update package to the preset update backup area and perform integrity verification; S4: If the integrity check passes, control the boot pointer in the preset boot program area to switch from the preset current running area to the update backup area; S5: Load and update the backup area and start it, and execute the preset self-test scheme to collect startup result information; S6: Determine the update termination plan based on the startup result information and execute the update termination plan; Methods for determining the new firmware update package include: S21: Collect vehicle number; S22: Based on the vehicle software list, query the preset inventory database to determine the target software to update; S23: Generate vehicle metadata by combining the target update software with the vehicle number; S24: Query the preset offline mirror database based on vehicle metadata to determine the offline metadata; S25: Perform integrity verification based on offline metadata; S26: If the integrity verification passes, generate a new firmware update package based on offline metadata; Integrity verification methods include: S251: Retrieve timestamps, snapshot metadata, and offline signatures based on offline metadata; S252: Determine time freshness based on timestamp; S253: Determine the snapshot reference value based on the snapshot metadata; S254: Determine the signature reference value based on the offline signature; S255: Determine the verification reference value by combining time freshness, snapshot reference value and signature reference value; S256: Determine whether the verification reference value is greater than the preset verification baseline value; S257: If yes, output the preset verification pass information; S258: If not, output the preset verification failure message; Among them, vehicle metadata refers to the structured data set corresponding to the software update for vehicle identity, and the mirror offline database refers to the offline structured database that stores the available software update packages for each vehicle ECU.

2. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 1, characterized in that, After determining the verification reference value, the following is also included: S2551: Retrieve offline target metadata based on offline metadata; S2552: Retrieve online target metadata from the preset inventory database based on offline target metadata; S2553: Determine the target consistency reference value by combining offline target metadata and online target metadata; S2554: Determine whether the target consistency reference value is less than the preset target consistency benchmark value; S2555: If yes, calculate the sum of the target consistency reference value and the verification reference value, and update and replace the verification reference value; S2556: If not, continue to output the verification reference value.

3. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 1, characterized in that, Before downloading the new firmware update package to the preset update backup area, the following steps are included: S31: Send an authentication request to the preset instrument controller and collect random numbers; S32: Sign the random number using the preset private key to obtain a random signature; S33: Send a random signature to the preset instrument controller for verification using the preset public key to obtain the signature validity; S34: Determine whether the signature validity verification was successful; S35: If yes, then the transmission will be based on the new firmware update package; S36: If not, output the preset interrupt connection control information.

4. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 3, characterized in that, Transmission methods based on new firmware update packages include: S351: Generate a unique session key based on a random number; S352: Generate packet byte values ​​based on the new firmware update package; S353: The new firmware update package is divided into packets according to the packet byte values ​​and symmetrically encrypted according to the unique session key to obtain a single separate update package; S354: Transmit based on a single separate update packet.

5. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 4, characterized in that, Downloading the new firmware update package to the preset update backup area and performing an integrity verification includes: S3551: Decrypt a single split update packet using the unique session key to obtain a single decrypted update packet; S3552: Download individual decryption update packages sequentially to the preset update backup area; S3553: After all downloads are complete, determine the actual hash value based on all individual decryption update packets; S3554: Determine the expected hash value based on the new firmware update package; S3555: Determine whether the actual hash value matches the expected hash value; S3556: If yes, output the preset verification pass information; S3557: If not, erase all individual decryption update packages.

6. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 1, characterized in that, Before loading and updating the backup area and starting, the following are also included: S51: Collects current vehicle status information; S52: Retrieve gear information and software usage based on the vehicle's current status information; S53: When the gear information is the preset parking gear, retrieve the usage type and usage time value based on the software usage situation; S54: Retrieve update type based on new firmware update package; S55: Determine the category impact value by combining the type of use and the type of update; S56: Determine the safety status value based on the usage time value and the type of influence value; S57: When the security status value is greater than the preset security baseline value, continue to load and update the backup area and start it.

7. The method for dual backup boot and integrity verification of an in-vehicle bus according to claim 1, characterized in that, The methods for determining the update termination scheme include: S61: Determine whether the startup result information is consistent with the preset startup success information; S62: If yes, output the preset update reporting scheme and use it as the update termination scheme; S63: If not, continue to collect startup result information and perform timing to obtain the startup duration value; S64: When the startup duration value is greater than the preset waiting time value, the boot pointer in the preset boot program area is switched back to the current running area and the current running area is reloaded and started as a failure execution plan; S65: Combine the failure execution plan with the preset failure alarm plan as the update termination plan.

8. A dual-backup boot and integrity verification system for an in-vehicle bus, characterized in that, include: The data acquisition module is used to collect vehicle software list, startup result information, vehicle number, random number and current vehicle status information; The memory stores a program for implementing a dual-backup startup and integrity verification method for an on-board bus as described in any one of claims 1 to 7; The processor loads and executes programs stored in memory.

Images