Methods, devices, and computer equipment for automatically pushing software upgrade packages

Abstract

This application relates to the field of computer software technology, and discloses a method, apparatus, and computer device for automatically pushing software upgrade packages. The method involves: acquiring multiple controller upgrade packages for a target vehicle; if the controller upgrade package passes integrity verification, encrypting the controller upgrade package in blocks to obtain multiple encrypted data blocks; processing the encrypted data blocks to obtain a vehicle upgrade package for the target vehicle; if the target vehicle meets the upgrade conditions, pushing the vehicle upgrade package to the target vehicle so that the target vehicle can use the vehicle upgrade package to upgrade the software of the controller in the target vehicle. Its beneficial effect is to improve the automation of software upgrades.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a method, apparatus and computer device for automatically pushing software upgrade packages. Background Technology

[0002] With the rise of intelligent and connected vehicles, automotive software and systems are being updated at an accelerated pace. As a core component in ensuring software quality and safety, automotive test benches play a crucial role in improving R&D efficiency through automated testing technology.

[0003] In current automated testing systems, testers can configure test gimbal tasks to deploy test applications on the actual vehicle or test bench, driving the Firmware Over-The-Air (FOTA) program to obtain upgrade information from the gimbal and complete the automated upgrade, thus achieving a certain degree of automation in the testing process.

[0004] However, many key steps in the implementation of the above methods require the participation of testers, resulting in poor automation. Summary of the Invention

[0005] This application provides a method, apparatus, and computer device for automatically pushing software upgrade packages, which solves the technical problem of poor automation effect caused by excessive participation of testers in the automated testing process, and achieves the technical effect of improving the efficiency of automatic push of software upgrade packages.

[0006] To achieve the above objectives, the main technical solutions adopted in this application include:

[0007] In a first aspect, embodiments of this application provide a method for automatically pushing software upgrade packages, the method comprising:

[0008] Obtain multiple controller upgrade packages for the target vehicle;

[0009] If the controller upgrade package is determined to pass the integrity verification, the controller upgrade package is then divided into blocks for encryption to obtain multiple encrypted data blocks.

[0010] The encrypted data block is processed to obtain the vehicle upgrade package for the target vehicle;

[0011] If the target vehicle is determined to meet the upgrade conditions, the vehicle upgrade package is pushed to the target vehicle so that the target vehicle can use the vehicle upgrade package to upgrade the software of the controller in the target vehicle.

[0012] The automatic push method for software upgrade packages proposed in this application ensures the accuracy, security, and reliability of the target vehicle controller software upgrade through integrity verification, block encryption, and conditional push mechanisms, effectively improving upgrade efficiency and reducing risks.

[0013] In one example, the controller upgrade package is encrypted in blocks to obtain multiple encrypted data blocks, including:

[0014] The controller upgrade package is processed according to the preset size to obtain multiple initial data blocks;

[0015] The initial data block is encrypted using the first encryption algorithm to obtain multiple encrypted data blocks and ciphertext lengths.

[0016] In this example, a method for securely encrypting upgrade packages in blocks and obtaining ciphertext length information is achieved by dividing the controller upgrade package into blocks of a preset size and encrypting the initial data blocks separately using a first encryption algorithm.

[0017] In one example, the controller upgrade package is processed according to the preset size to obtain multiple initial data blocks, including:

[0018] If the size of the controller upgrade package is less than or equal to the preset size, then the controller upgrade package is used as the initial data block;

[0019] If the size of the controller upgrade package is greater than the preset size, then the controller upgrade package is split into multiple initial data blocks according to the preset size;

[0020] If the size of the initial data block is smaller than the preset size, then a preset filling algorithm is used to fill the initial data block to the preset size.

[0021] In this example, a method for standardized block processing of upgrade packages is achieved by flexibly handling controller upgrade packages according to preset sizes, namely, directly retaining packages smaller than or equal to the preset size, splitting packages larger than the preset size and filling insufficient blocks to the preset size.

[0022] In one example, the initial data block is encrypted using a first encryption algorithm to obtain multiple encrypted data blocks and ciphertext lengths, including:

[0023] Generate a symmetric key and initialization vector;

[0024] The initial data block is encrypted using the first encryption algorithm, the symmetric key, and the initialization vector to obtain the encrypted data block.

[0025] The length of the ciphertext is obtained by summing the lengths of each of the encrypted data blocks.

[0026] In this example, a method for secure encryption of the upgrade package and ciphertext length statistics is achieved by generating a symmetric key and an initialization vector, and then using a first encryption algorithm to combine the two to encrypt the initial data block and sum the ciphertext length.

[0027] In one example, generating the symmetric key and initialization vector includes:

[0028] Randomly generate a ciphertext of a first preset length;

[0029] The data of a second preset length starting from the first position in the ciphertext is used as the symmetric key;

[0030] Use the data of the third preset length starting from the second position in the ciphertext as the initialization vector;

[0031] Wherein, the sum of the second preset length and the third preset length is less than or equal to the first preset length; and the second position is not within the second preset length starting from the first position.

[0032] In this example, a method for efficiently generating and isolating secure key materials is achieved by extracting the symmetric key and initialization vector from the randomly generated ciphertext at specific positions and lengths, and ensuring that the sum of their lengths does not exceed the total length of the ciphertext and that their positions do not overlap.

[0033] In one example, the encrypted data block is processed to obtain a vehicle upgrade package for the target vehicle, including:

[0034] The encrypted data blocks are assembled in a preset order to generate a vehicle upgrade package for the target vehicle.

[0035] In this example, a method is used to generate a vehicle upgrade package that is structurally complete and adapted to the upgrade requirements of the target vehicle by sequentially assembling encrypted data blocks in a preset order.

[0036] In one example, determining that the controller upgrade package passes integrity verification includes:

[0037] Obtain the identifier of the controller that needs to be upgraded in the target vehicle, and the identifier of the controller upgrade package contained in the controller upgrade package;

[0038] If each controller identifier has a matching controller upgrade package identifier, then the controller upgrade package is determined to have passed the integrity check.

[0039] In this example, a method is used to verify the integrity of the controller upgrade package and ensure upgrade compatibility by accurately matching and verifying the target vehicle controller identifier with the upgrade package identifier.

[0040] In one example, determining that the target vehicle meets the upgrade criteria includes:

[0041] If the test bench where the vehicle is located is idle and the vehicle is parked, and the remaining battery capacity of the vehicle is greater than the preset capacity, then the target vehicle is determined to meet the upgrade conditions.

[0042] In this example, a method is used to accurately select vehicles that meet the safety upgrade requirements by comprehensively judging the test bench's idle status, the vehicle's parking status, and whether the remaining battery capacity meets the standards.

[0043] In one example, the method further includes:

[0044] The controller upgrade package is signed using a preset certificate private key to generate signature information;

[0045] The second encryption algorithm is used to process the symmetric key, ciphertext length, signature information, and public key certificate to generate a digital envelope;

[0046] The digital envelope is used to assist the target vehicle in decrypting the vehicle upgrade package.

[0047] In this example, an authentication and protection method for securely decrypting vehicle upgrade packages is achieved by using a certificate private key to sign the upgrade package and integrating key information using a second encryption algorithm to generate a digital envelope.

[0048] In one example, the method further includes:

[0049] Obtain feedback information from the target vehicle after upgrading the controller software;

[0050] Based on the feedback information, determine the upgrade result of the target vehicle; and when the upgrade result indicates that the upgrade has failed, determine the reason for the upgrade failure based on the feedback information.

[0051] Based on the stated reason for failure, a retry mechanism is initiated.

[0052] In this example, a method for accurately diagnosing and automatically repairing software upgrade anomalies is achieved by obtaining upgrade feedback information from the target vehicle, analyzing the upgrade results, locating the cause of failure, and then initiating a retry mechanism.

[0053] Secondly, embodiments of this application provide an automatic software upgrade package push device, the device comprising:

[0054] The acquisition module is used to acquire multiple controller upgrade packages for the target vehicle;

[0055] The processing module is configured to, upon determining that the controller upgrade package has passed the integrity verification, encrypt the controller upgrade package in blocks to obtain multiple encrypted data blocks; and process the encrypted data blocks to obtain the vehicle upgrade package for the target vehicle.

[0056] The push module is used to push the vehicle upgrade package to the target vehicle when it is determined that the target vehicle meets the upgrade conditions, so that the target vehicle can use the vehicle upgrade package to upgrade the software of the controller in the target vehicle.

[0057] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method described in any of the above embodiments.

[0058] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to perform the method described in any of the above embodiments.

[0059] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which are used to cause a computer to perform the method described in any of the above embodiments. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0061] Figure 1 This is a flowchart of the automatic push method for software upgrade packages according to an embodiment of this application;

[0062] Figure 2 This is a flowchart illustrating the encryption process implemented in an embodiment of this application.

[0063] Figure 3 This is a flowchart of the automatic push method for software upgrade packages according to an embodiment of this application;

[0064] Figure 4 A communication diagram illustrating the automatic push method for software upgrade packages;

[0065] Figure 5 A block diagram of an automatic software upgrade package push device provided in this application embodiment;

[0066] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0068] As the automotive industry rapidly advances towards intelligence and connectivity, the frequency of updates to automotive software and systems is increasing. As a crucial component in ensuring the quality and safety of automotive software, automotive test benches face numerous challenges. Among these challenges, the use of Over-the-Air (OTA) technology and encrypted software upgrade packages provides technical support for these updates.

[0069] OTA (Over-The-Air) updates are a technology that remotely pushes upgrade packages to devices via wireless networks (such as mobile networks and Wi-Fi) to update device software or firmware. This OTA technology is widely used in smartphones, smart cars, IoT devices, industrial controllers, and other fields. It allows devices to automatically or manually complete system version upgrades, add features, and fix vulnerabilities without physically connecting to a computer or dedicated equipment, simplifying device maintenance processes and improving update efficiency and convenience. It is a crucial supporting technology for intelligent and remote device management.

[0070] Software upgrade package encryption technology encrypts OTA upgrade packages, ensuring their security during transmission. This encryption technology aims to prevent unauthorized access, theft, tampering, or forgery, ensuring the integrity and reliability of the upgrade process. This method of encrypting OTA upgrade packages using software upgrade package encryption technology can be widely applied in fields such as smart cars and the Internet of Things.

[0071] In one implementation, the software upgrade package encryption technology can use symmetric encryption algorithms such as Advanced Encryption Standard (AES) to efficiently encrypt the upgrade package.

[0072] In another implementation, the software upgrade package encryption technology can also be combined with asymmetric encryption algorithms such as the Rivest-Shamir-Adleman algorithm (RSA) and Elliptic Curve Cryptography (ECC) to generate digital signatures to verify legitimacy and integrity.

[0073] In another implementation, the software upgrade package encryption technology can also achieve dynamic key management through hardware security modules (HSM), trusted execution environments (TEE), etc.

[0074] In another implementation, the software upgrade package encryption technology can also employ layered encryption for different parts of the upgrade package to balance security and efficiency.

[0075] In another implementation, the software upgrade package encryption technology can also be integrated with protocols such as Hypertext Transfer Protocol Secure (HTTPS) and Transport Layer Security (TLS) to form dual protection.

[0076] Currently, in automated testing systems, testers typically configure test tasks by setting up test PTZs. Furthermore, testers can deploy test applications on the actual vehicle under test or test bench, enabling these applications to receive test tasks and control Firmware Over-The-Air (FOTA) applications to retrieve upgrade information from the PTZ and perform upgrade operations, thus achieving automated upgrades. However, this process primarily relies on the configuration and execution of test tasks, with limited automation of the software upgrade package delivery process, and fails to address issues related to software upgrade package encryption and test bench adaptive configuration.

[0077] Furthermore, currently, in simulation test benches, testers can typically build multi-protocol simulation platforms and use development boards to simulate Electronic Control Units (ECUs) to automate the verification of vehicle network communication environments and OTA upgrade processes, supporting upgrade package distribution. However, this process lacks encryption protection for software upgrade packages and does not incorporate compatibility design for different test benches.

[0078] Furthermore, in current push methods, OTA upgrade package pushes rely heavily on manual operations. After the Continuous Integration (CI) system generates the software upgrade package, it needs to be manually uploaded to the OTA platform or the push needs to be manually triggered. Moreover, the OTA platform typically waits for all packages to be collected before packaging the entire package, making the process cumbersome. Therefore, when dealing with multi-controller software upgrades, there is a problem of low efficiency, making it difficult to meet the testing needs of rapid iteration.

[0079] As can be seen from the three scenarios above, the current software upgrade package push process suffers from insufficient automation. After the CI system generates software upgrade packages for each controller on the vehicle side, they need to be manually packaged, then manually uploaded to the OTA platform, and the Vehicle Identification Number (VIN) needs to be manually imported to trigger the push. This process relies excessively on manual intervention in key processes such as CI package upload, package triggering, and bench screening. This can lead to errors due to fatigue or negligence, resulting in missed uploads, version mismatches, or delays in packaging, directly reducing process efficiency. Furthermore, the high error rate of manual recording and information transmission can cause test bench upgrade failures, increasing rework costs.

[0080] Furthermore, current software update packages generally suffer from inadequate encryption mechanisms, leading to insufficient software security. OTA packages during the testing phase may contain unpublished functional code or key information. However, current push notifications employ partial encryption, decrypting the first 1MB of data in the update package using 256-bit Advanced Encryption Standard Galois / Counter Mode (AES-256-GCM) before concatenating it with the remaining received plaintext data. This method could be easily obtained by attackers and reverse engineered to extract critical code, potentially leading to the theft or tampering of unpublished code, algorithms, and other information in OTA software update packages during the testing phase. This could result in the leakage of core technologies, affecting the confidentiality of subsequent versions. Moreover, a tampered software update package installed on a test bench may output incorrect test data, interfering with the assessment of the update package's validity and even damaging the test bench hardware, thus compromising test security.

[0081] Furthermore, the current test benches lack an autonomous judgment mechanism, resulting in poor compatibility. Different test equipment has varying hardware configurations, current software versions, and test tasks. Currently, the common "one-size-fits-all" upgrade strategy leads to some test benches being unable to upgrade due to ongoing test tasks, insufficient storage space, or resource consumption. Moreover, the "one-size-fits-all" strategy interrupts the currently executing test process, causing bench anomalies. To address this, it is typically necessary to manually select executable benches initially, and then manually investigate the reasons for failures and re-upgrade, reducing the flexibility of test bench upgrades.

[0082] Furthermore, the lack of automated data exchange interfaces between CI, the OTA platform, and the test bench leads to isolated operation of each system. The OTA platform cannot obtain the integrity status of the controller's software upgrade package in real time, requiring manual confirmation of "whether all packages have arrived," resulting in delays in package packaging. Test bench status information cannot be fed back to the OTA platform, the push strategy cannot be dynamically adjusted, and adaptability is poor.

[0083] To address the aforementioned issues, this application proposes a method for automatically pushing fully encrypted OTA software upgrade packages to test benches.

[0084] This method establishes an automated data link between the CI, OTA platforms, and test benches, constructing a closed-loop interaction system. Based on this interaction link, the method achieves fully automated push of OTA software upgrade packages. This method is applied to the OTA platform. Specifically, the OTA platform provides interfaces for pushing upgrade packages via Jfrog links from the CI platform, integrates a complete package packaging toolkit, implements a fully encrypted upgrade package solution, provides test bench VIN code grouping, proactively pushes task updates via Message Queuing Telemetry Transport (MQTT), and provides test VIN query and download upgrade interfaces.

[0085] This method automatically pushes the package link to the vehicle controller on the test bench via the interface between the CI and OTA platforms. The OTA platform automatically detects the package integrity and triggers packaging. This method eliminates manual intervention through automation, improves testing efficiency, and reduces human error. Furthermore, through this interaction link, the method achieves real-time feedback on package and test bench status, allowing for dynamic adjustment of the push strategy and ensuring the reliability and flexibility of the upgrade process.

[0086] Furthermore, this method employs a full encryption mechanism combining symmetric and asymmetric encryption to ensure that OTA software upgrade packages can be encrypted using dynamic keys. This encryption mechanism guarantees that one OTA software upgrade package corresponds to one key, ensuring the security of the OTA software upgrade package and key during transmission and storage, preventing theft and tampering, protecting technical secrets during the testing phase, and enhancing the security of the software upgrade package. The symmetric encryption key K is a one-time pad.

[0087] Furthermore, this method, through pre-group management and bench self-judgment mechanism, enables test benches to choose whether to upgrade based on their own status such as task execution and resource availability, avoiding test interruption or failure caused by forced push and improving bench adaptability.

[0088] Therefore, based on the method of this application, the problems of low efficiency, weak security and poor compatibility in the current OTA software upgrade package update process are solved, and an efficient, safe and intelligent solution is provided for OTA upgrades of test benches.

[0089] According to an embodiment of this application, an embodiment of an automatic software upgrade package push method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0090] This embodiment provides a method for automatically pushing software upgrade packages, which can be used on the aforementioned OTA platform. This OTA platform can run on a computer device, such as a mobile phone, tablet computer, personal computer, or server. Figure 1 This is a flowchart of the automatic push method for software upgrade packages according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0091] S101. Obtain multiple controller upgrade packages for the target vehicle.

[0092] For example, the OTA platform establishes a secure communication connection with a data warehouse provided by a third-party supplier, and actively pulls or receives controller upgrade packages uploaded to the data warehouse by technicians.

[0093] In one implementation, the OTA platform can obtain data update information from the data warehouse. The OTA platform can also proactively retrieve controller upgrade packages uploaded to the data warehouse by technical personnel when the data in the data warehouse is updated.

[0094] In another implementation, a data push mechanism can be set up in the data warehouse. This push mechanism can control the data warehouse to proactively send the controller upgrade package uploaded to the data warehouse by technicians to the OTA platform.

[0095] In one implementation, the OTA platform selects suitable controller upgrade packages based on information such as vehicle model and hardware version, and stores them locally.

[0096] In one implementation, the OTA platform can identify the vehicles that require software upgrades. These vehicles can be designated as target vehicles. The OTA platform can manage multiple target vehicles simultaneously.

[0097] In one implementation, each target vehicle may include multiple controllers. During a single upgrade process, multiple controller upgrade packages can be used simultaneously to upgrade multiple controllers.

[0098] In one implementation, the controller upgrade package may contain update code, configuration files, and verification data for partial or complete software updates in a controller. A controller upgrade package may correspond to a version number.

[0099] In one implementation, the data warehouse provided by the third-party vendor can be a JFrog repository, a consortium blockchain, a Docker container, etc. Alternatively, the data warehouse provided by the third-party vendor can also be replaced by edge devices.

[0100] S102. If it is determined that the controller upgrade package passes the integrity verification, the controller upgrade package is divided into blocks for encryption to obtain multiple encrypted data blocks.

[0101] For example, the OTA platform first performs an integrity check on the obtained controller upgrade package. This integrity check verifies that the currently obtained controller upgrade package is the complete set of controller upgrade packages corresponding to the controller that the target vehicle needs to update.

[0102] If the verification is successful, the OTA platform will divide the controller upgrade package into multiple data blocks according to a preset size, and encrypt these data blocks using a preset encryption algorithm to obtain multiple encrypted data blocks.

[0103] In one implementation, the OTA platform can verify the integrity of the controller upgrade package by checking whether the hash value or digital signature of the controller upgrade package is consistent with expectations.

[0104] For example, the integrity of a controller upgrade package can be determined by comparing its hash value with the hash value pre-stored in each controller, thus ensuring that the file has not been tampered with. This hash value can be calculated using a 256-bit Secure Hash Algorithm (SHA-256).

[0105] For example, by comparing the digital signature of the controller upgrade package with the digital signature pre-stored in each controller, it can be determined whether the controller upgrade package is complete, thereby ensuring that the file has not been tampered with.

[0106] In one implementation, the OTA platform can segment the controller upgrade package, dividing packages larger than a preset size into initial data blocks of the preset size. Furthermore, the OTA platform can pad controller upgrade packages smaller than the preset size so that the padded package equals the preset size. This configuration can result in multiple initial data blocks of the preset size. Encryption based on these initial data blocks of the same size can improve encryption efficiency and data security.

[0107] In one implementation, the OTA platform can encrypt each initial data block individually to obtain encrypted data blocks.

[0108] In one implementation, the encryption process can use either a symmetric encryption algorithm or an asymmetric encryption algorithm to encrypt each data block.

[0109] S103. Process the encrypted data block to obtain the vehicle upgrade package for the target vehicle.

[0110] For example, the OTA platform can integrate the encrypted data blocks to generate a vehicle upgrade package that conforms to the communication protocol. This facilitates the OTA platform's transmission of the vehicle upgrade package to the target vehicle.

[0111] In one implementation, the OTA platform can also add version number, timestamp, and dependency description information to the vehicle upgrade package to ensure that the upgrade package is compatible with the target vehicle hardware.

[0112] In one implementation, the OTA platform can encapsulate encrypted data blocks according to CAN, Ethernet, or vehicle wireless protocols. During this encapsulation process, the OTA platform can concatenate the encrypted data blocks according to the data length required by the protocol, and add a message header and a verification field to the concatenated encrypted data blocks.

[0113] In one implementation, the OTA platform can concatenate all encrypted data blocks and then compress them to obtain a vehicle upgrade package. This vehicle upgrade package can be a compressed file. Using this compressed file can reduce transmission bandwidth.

[0114] In one implementation, the OTA platform can upload the encrypted vehicle upgrade package to a Content Delivery Network (CDN).

[0115] S104. If it is determined that the target vehicle meets the upgrade conditions, the vehicle upgrade package is pushed to the target vehicle so that the target vehicle can use the vehicle upgrade package to upgrade the software of the controller in the target vehicle.

[0116] For example, the OTA platform locates the target vehicle by vehicle identification number or device ID and obtains the target vehicle's parameter information, thereby determining whether the target vehicle meets the upgrade conditions based on the parameter information.

[0117] If the target vehicle meets the upgrade requirements, the OTA platform will push the vehicle upgrade package to the target vehicle. After receiving the vehicle upgrade package, the target vehicle can decrypt the vehicle upgrade package and use the various controller upgrade packages in the decrypted vehicle upgrade package to upgrade the target vehicle's controller.

[0118] In one implementation, the target vehicle can receive the vehicle upgrade package via a T-Box or an onboard terminal. The target vehicle's T-Box or onboard terminal can then decrypt the vehicle upgrade package after verifying its integrity.

[0119] In one implementation, the target vehicle's T-Box or on-board terminal can send the decrypted upgrade packages for each controller to the corresponding controller, thereby upgrading the target vehicle's controller.

[0120] In one implementation, the OTA platform can determine the target vehicle's battery level, network status, and whether the current task meets the requirements based on the target vehicle's parameters. If the vehicle is parked, has sufficient battery power, and a stable network, then the target vehicle can be determined to meet the upgrade requirements.

[0121] In one implementation, after generating the vehicle upgrade package, the OTA platform can send upgrade messages to some test benches via the MQTT protocol. The OTA platform can obtain feedback information from the test benches. Based on this feedback information, the OTA test benches can determine whether they and their target vehicles meet the upgrade requirements.

[0122] Optionally, this section of test benches can be test benches from a test group selected by the tester. For example, 10 test benches from the "C01 Functional Test Group".

[0123] Optionally, the upgrade message may include the digital envelope ID “ENV001”, version V2.1, and upgrade content.

[0124] In this embodiment, the controller upgrade package is obtained through the OTA platform, and integrity verification, block encryption and integration processing are completed. Combined with the technical means of dynamic vehicle status filtering and secure push, the automation level of the target vehicle's controller upgrade is improved, and the security of the upgrade package during transmission is enhanced.

[0125] In one example, the process of encrypting the controller upgrade package in blocks to obtain multiple encrypted data blocks in step S102 above includes:

[0126] S1021. Process the controller upgrade package according to the preset size to obtain multiple initial data blocks.

[0127] For example, the OTA platform has a preset size. For example, the preset size can be 512KB, 1MB, etc.

[0128] The OTA platform can segment the acquired controller upgrade package according to this preset size. The OTA platform can generate multiple initial data blocks by repeatedly reading the file content and extracting data segments of specified lengths. The size of each extracted initial data block is equal to the preset size.

[0129] When the controller upgrade package is smaller than the preset size, or when the remaining data in the controller upgrade package is smaller than the preset size after truncating multiple initial data blocks of the preset size, the controller can fill the data to obtain an initial data block of the preset size.

[0130] In one implementation, the OTA platform can use a fixed-length segmentation method when segmenting the controller upgrade package. The OTA platform can evenly divide the upgrade package according to the preset number of bytes.

[0131] In another implementation, the OTA platform can use a dynamic segmentation method when splitting the controller upgrade package. The OTA platform can adjust the block size based on file content characteristics to reduce cross-block data dependencies. For example, the size of the initial data block can be adjusted based on file content such as function boundaries and data headers. Optionally, this adjustment method involves reducing the size of the initial data block. Optionally, the final generated initial data block size must be less than or equal to the preset size.

[0132] In one implementation, the OTA platform can use a streaming processing method when splitting the controller upgrade package, reading and splitting simultaneously to avoid memory overflow.

[0133] S1022. The initial data block is encrypted using the first encryption algorithm to obtain multiple encrypted data blocks and ciphertext lengths.

[0134] For example, the OTA platform can use a preset first encryption algorithm to independently encrypt each initial data block to generate ciphertext. The OTA platform can record the actual length of the encrypted data block and calculate the ciphertext length.

[0135] In one implementation, the first encryption algorithm can be a symmetric encryption algorithm such as AES-256-GCM or ChaCha20-Poly1305.

[0136] In one implementation, the OTA platform can generate a set of symmetric keys and initialization vectors for each initial data block and encrypt the initial data block.

[0137] In another implementation, the OTA platform can generate a set of symmetric keys and initialization vectors for each controller upgrade package, and encrypt each initial data block of the controller upgrade package.

[0138] In another implementation, the OTA platform can generate a set of symmetric keys and initialization vectors for each target vehicle, and encrypt the initial data blocks of multiple controller upgrade packages for that target vehicle.

[0139] In another implementation, the OTA platform can generate a set of symmetric keys and initialization vectors within a preset time period, and encrypt the initial data blocks of each controller upgrade package for each target vehicle within that preset time period.

[0140] In this example, by dividing the controller upgrade package into blocks of a preset size and encrypting the initial data blocks separately using the first encryption algorithm, the block encryption of the controller upgrade package is achieved, thereby improving the encryption security of the controller upgrade package.

[0141] In one example, the specific process of processing the controller upgrade package according to a preset size to obtain multiple initial data blocks in step S1021 above may include:

[0142] S10211. If the size of the controller upgrade package is less than or equal to the preset size, the controller upgrade package will be used as the initial data block.

[0143] For example, the OTA platform processes controller upgrade packages one by one. The OTA platform first checks the size of the controller upgrade package. If its number of bytes does not exceed the preset size, the complete upgrade package is directly regarded as an initial data block without further segmentation.

[0144] S10212. If the size of the controller upgrade package is greater than the preset size, the controller upgrade package will be split into multiple initial data blocks according to the preset size.

[0145] For example, if the OTA platform checks the size of the controller upgrade package and determines that the number of bytes in the controller upgrade package exceeds a preset size, the OTA platform can sequentially extract the file content according to the preset size to generate multiple consecutive initial data blocks.

[0146] S10213. If the size of an initial data block is smaller than the preset size, the preset filling algorithm is used to fill the initial data block to the preset size.

[0147] For example, after processing all controller upgrade packages, the OTA platform can sequentially process each initial data block. The OTA platform can check the size of each initial data block. If the number of bytes in an initial data block is found to be less than a preset size, the OTA platform can use a preset padding algorithm to add plaintext to the end of the initial data block to bring it to the preset size.

[0148] In one implementation, the padding algorithm can be PKCS#1, PKCS#7, or similar algorithms. Using this algorithm ensures that the padding content is reversible, allowing for accurate removal after decryption on the vehicle side.

[0149] In one implementation, the initial data block size after filling is equal to the preset size.

[0150] In this example, by splitting and / or padding the controller upgrade package according to a preset size, the initial data block obtained is ensured to be of the preset size, thereby achieving standardized block processing of the controller upgrade package and improving subsequent processing efficiency.

[0151] In one example, step S1022 above, which involves encrypting the initial data block using the first encryption algorithm to obtain multiple encrypted data blocks and ciphertext lengths, includes:

[0152] S10221. Generate the symmetric key and initialization vector.

[0153] For example, before encrypting the initial data block, the OTA platform needs to generate a symmetric key and an initialization vector for symmetric encryption.

[0154] In one implementation, the symmetric key and the initialization vector are parameters required during the encryption process using the first encryption algorithm.

[0155] Optionally, the first encryption algorithm can be a symmetric encryption algorithm. For example, the first encryption algorithm can be the AES_256 GCM algorithm.

[0156] In one implementation, the lengths of the symmetric key and the initialization vector can be determined based on the data length required by the first encryption algorithm. For example, the symmetric key can be 32 bits, and the initialization vector can be 12 bits.

[0157] In one implementation, the symmetric key can be generated by a pre-defined first generator to ensure its unpredictability.

[0158] In one implementation, the initialization vector can be generated by a preset second generator to ensure that the initialization vector meets the requirements of the first encryption algorithm and to ensure that the same plaintext block is encrypted to obtain different ciphertexts, thereby enhancing security.

[0159] In one implementation, the symmetric key and initialization vector can be generated simultaneously by a pre-defined third generator to ensure generation efficiency.

[0160] S10222. Using the first encryption algorithm, the initial data block is encrypted with a symmetric key and an initialization vector to obtain an encrypted data block.

[0161] For example, the OTA platform can use a first encryption algorithm, combined with the generated symmetric key and initialization vector, to independently encrypt each initial data block. During the encryption process, the algorithm mixes the plaintext with the symmetric key and initialization vector to generate ciphertext, resulting in an encrypted data block.

[0162] In one implementation, the OTA platform can also attach an authentication tag to the ciphertext in the encrypted data block. For example, this authentication tag can be a Galois / Counter Mode (GCM) Message Authentication Code (MAC). Setting this authentication tag can ensure data integrity and confidentiality.

[0163] In one implementation, when the first encryption algorithm requires parameters other than the symmetric key and the initialization vector, the OTA platform can also generate the corresponding parameters according to the first encryption algorithm, thereby ensuring the encryption effect of the first encryption algorithm on the initial data block.

[0164] S10223. Obtain the length of each encrypted data block to get the ciphertext length.

[0165] For example, after encrypting all initial data blocks, the OTA platform can obtain the actual length of each encrypted data block and use that length as the ciphertext length of the encrypted data block.

[0166] In one implementation, the ciphertext length is used to split the data during the decryption process.

[0167] In one implementation, the actual length of each encrypted data block may include the length of the ciphertext and the authentication tag.

[0168] In one implementation, the OTA platform can obtain the ciphertext length by traversing all encrypted data blocks and reading the length attribute of each encrypted data block.

[0169] In one implementation, the OTA platform can directly obtain the encrypted length of each initial data block during the encryption process to obtain the ciphertext length of each encrypted data block.

[0170] In one implementation, if the encrypted data block is further compressed, the OTA platform can obtain the data length of the compressed encrypted data block as the ciphertext length.

[0171] In one implementation, the OTA platform can also calculate the total ciphertext length by counting the lengths of all encrypted data blocks.

[0172] In this example, after generating a symmetric key and an initialization vector, the initial data block is encrypted using the first encryption algorithm in combination with the symmetric key and the initialization vector to obtain an encrypted data block. The length of the ciphertext is obtained by summing the lengths of all encrypted data blocks, thereby improving the data encryption effect and enhancing data security.

[0173] In one example, the specific implementation process of generating the symmetric key and initialization vector in step S10221 above may include:

[0174] S102211. Randomly generate a ciphertext of the first preset length.

[0175] For example, the OTA platform generates a random byte sequence of a first preset length using a generator, and uses this byte sequence as ciphertext.

[0176] In one implementation, the generator can be a cryptographically secure random number generator.

[0177] In one implementation, the first preset length is a value set based on the combined length requirements of the symmetric key and the initialization vector.

[0178] The data length of the symmetric key can be denoted as the second preset length. The data length of the initialization vector can be denoted as the third preset length. Furthermore, the sum of the second preset length and the third preset length is less than or equal to the first preset length.

[0179] For example, if a 256-bit symmetric key and a 128-bit initialization vector are required to be derived, the ciphertext length must be at least 48 bytes (384 bits).

[0180] For example, if a 32-bit symmetric key and a 12-bit initialization vector need to be derived, the ciphertext length must be at least 44 bits.

[0181] In one implementation, the OTA platform can generate a ciphertext of a first preset length based on the Operating System Cryptographically Secure Pseudorandom Number Generator (OS-CSPRNG) in the operating system.

[0182] In another implementation, the OTA platform can use a hardware random number generator to generate a secret text of a first preset length. For example, this hardware random number generator can be an Intel Random Number Generator Instruction (RDRAND), a Hardware Security Module Built-in Random Number Generator (HSM-RNG), etc.

[0183] In another implementation, the OTA platform can generate ciphertext of a first preset length using a key derivation function generator. For example, this key derivation function can be an HMAC-based Extract-and-Expand Key Derivation Function (HKDF).

[0184] S102212, Use the data of the second preset length starting from the first position in the ciphertext as the symmetric key.

[0185] For example, the OTA platform extracts a data segment with a starting position of the first position and a length of the second preset length from the ciphertext generated in step S102211, and uses it as the symmetric key of the symmetric encryption algorithm.

[0186] In one implementation, the second preset length is the length of the symmetric key required by the first encryption algorithm. For example, when the first encryption algorithm is AES-256, the second preset length can be 32 bytes.

[0187] In one implementation, the first position is the offset from the starting position in the ciphertext used to extract the symmetric key. For example, when the first position is 1, it indicates that truncation starts from the first bit. When the first position is n, it indicates that truncation starts from the nth bit.

[0188] In one implementation, the first position can be a fixed position.

[0189] In another implementation, the first position can be a dynamic position randomly determined within a first preset range.

[0190] Optionally, the starting position of the first preset range can be the first bit of the secret text, and the ending position of the first preset range can be the difference between the first preset length and the second preset length. Setting the ending position ensures that after the first position is determined, data of the second preset length is extracted starting from the first position.

[0191] For example, when the ciphertext is 64 bits and the symmetric key is 32 bits, the first position can be any value from 1 to 32.

[0192] S102213. Use the data of the third preset length starting from the second position in the secret text as the initialization vector.

[0193] For example, the OTA platform extracts a data segment with a starting position of the second position and a length of the third preset length from the ciphertext generated in step S102211, and uses it as the initialization vector of the symmetric encryption algorithm.

[0194] The selection of the second position must satisfy the condition that it does not overlap with the key truncation range. Therefore, the second position is not within the second preset length starting from the first position.

[0195] In one implementation, the third preset length is the data length of the initialization vector. This data length can be determined based on the first encryption algorithm. For example, when the first encryption algorithm uses GCM mode, the third preset length can be 12 bits.

[0196] In one implementation, the initialization vector is unique.

[0197] Optionally, each symmetric key uniquely corresponds to an initialization vector.

[0198] Optionally, each symmetric key can correspond to an initialization vector when performing encryption.

[0199] In one implementation, the second position is the starting byte offset of the initialization vector extracted from the ciphertext.

[0200] In one implementation, when the first position is a fixed position, the second position can also be a fixed position.

[0201] In one implementation, if the data of a third preset length starting from the second position is continuous data, then the second position can be a dynamically determined position randomly within a second preset range. This second preset range can be determined based on the ciphertext after the symmetric key has been truncated.

[0202] Optionally, if the ciphertext contains only one continuous data block, the OTA platform can determine the second preset range from this continuous data block. The starting position of the second preset range can be the starting position of the continuous data block. The ending position of the second preset range can be the difference between the ending position of the continuous data block and the third preset length.

[0203] For example, when the ciphertext is 64 bits and the symmetric key is 32 bits, if the symmetric key is truncated from bits 1 to 32 or bits 33 to 64, then the remaining data in the ciphertext is continuous data. For example, when the ciphertext is 64 bits and the symmetric key is truncated from bits 33 to 64, the second position can be any value from 1 to 20.

[0204] Optionally, if the ciphertext includes two consecutive data blocks, the OTA platform can delete the consecutive data block whose data size is less than a third preset length. Furthermore, the OTA platform can determine the second preset range based on the remaining consecutive data blocks.

[0205] If there is one remaining continuous data block, the starting position of the second preset range can be the starting position of that continuous data block. The ending position of the second preset range can be the difference between the ending position of the continuous data block and the third preset length.

[0206] For example, when the ciphertext is 64 bits and the symmetric key is 32 bits, bits 11-42 of the symmetric key are truncated. In this case, the remaining data in the ciphertext consists of two consecutive data blocks: 1-10 and 43-64. Since the first consecutive data block has 10 bits, which is less than the third preset length of 12, it is deleted. The OTA platform determines the second preset range to be 43-52 based on the second consecutive data block.

[0207] If there are two consecutive data blocks remaining, the second preset range can be determined by the above method, which determines two non-consecutive ranges.

[0208] For example, when the ciphertext is 64 bits and the symmetric key is 32 bits, bits 17-48 of the symmetric key are truncated. In this case, the remaining data in the ciphertext consists of two consecutive data blocks: 1-16 and 49-64. Since the number of both consecutive data blocks is greater than the third preset length, the OTA platform determines the second preset range to be 1-4 and 49-52.

[0209] In one implementation, if the data of a third preset length starting from the second position is non-continuous, then the second position can be a dynamically determined position randomly within the third preset range. This third preset range can be determined based on the ciphertext after the symmetric key has been truncated.

[0210] Optionally, the OTA platform can reassemble the data in the ciphertext that was not intercepted by the symmetric key into a new data block. The OTA platform can determine the second preset range from this new data block. The starting position of the second preset range can be the starting position of the new data block. The ending position of the second preset range can be the difference between the ending position of the new data block and the third preset length.

[0211] In this example, by extracting the symmetric key and initialization vector from the randomly generated ciphertext at specific positions and lengths, and ensuring that the two do not overlap, the secure and efficient generation of the symmetric key and initialization vector is achieved, and the isolation between the symmetric key and initialization vector is ensured, thereby improving the security of subsequent encryption.

[0212] In one example, step S103 above, which involves processing the encrypted data block to obtain the vehicle upgrade package for the target vehicle, includes:

[0213] S1031. Concatenate encrypted data blocks according to a preset order to generate a vehicle upgrade package for the target vehicle.

[0214] For example, the OTA platform can concatenate multiple encrypted data blocks in a preset order to generate a complete vehicle upgrade package.

[0215] In one implementation, the preset order can be the arrangement order of each encrypted data block in each controller upgrade package.

[0216] In one implementation, the preset order may further include the arrangement order of the various controller upgrade packages in the target vehicle.

[0217] In one implementation, the splicing method can be direct splicing.

[0218] Optionally, since each initial data block is the same size, the encrypted data blocks obtained after encryption using the same encryption algorithm are also the same size. Therefore, by using direct concatenation, the encrypted data blocks can be split according to the ciphertext length during decryption at the vehicle end.

[0219] Alternatively, since the OTA platform has recorded the size of each encrypted data block, the encrypted data blocks can be split according to their ciphertext length during decryption at the vehicle end.

[0220] In one implementation, the concatenation method can be to insert preset symbols. For example, the preset symbols can be symbols that will not appear in the ciphertext, such as ";" or " / ". Alternatively, the preset symbols can be strings that will not appear consecutively in the ciphertext, such as "\t", "0x00", "0xFF", or ":20:".

[0221] In one implementation, the OTA platform can embed data block information at the beginning or end of each encrypted data block.

[0222] Optionally, the data block information may include the concatenation order of each encrypted data block. Writing this concatenation order ensures correct concatenation after splitting.

[0223] Optionally, the data block information may include a version number, signature, and other information. Writing this information enables verification of each encrypted data block, improving the security of parsing on the vehicle side.

[0224] In this example, the complete construction of the vehicle upgrade package is achieved by sequentially assembling encrypted data blocks in a preset order, thereby improving the efficiency and security of vehicle upgrade package generation.

[0225] In one example, step S102 above, where the OTA platform determines that the controller upgrade package has passed the integrity verification, includes:

[0226] S1023. Obtain the identifier of the controller that needs to be upgraded in the target vehicle, and the identifier of the controller upgrade package contained in the controller upgrade package.

[0227] For example, the OTA platform can pre-store the controller identifiers of each controller in each target vehicle. After obtaining the controller upgrade package, the OTA platform can parse the controller upgrade package to obtain the controller upgrade package identifier contained in the controller upgrade package.

[0228] In one implementation, the controller identifier can be the controller's hardware number, software version number, unique device ID, etc. Optionally, the controller identifier can also be an encoding of the above data after processing by a hash or other digest algorithm.

[0229] S1024. If each controller identifier has a matching controller upgrade package identifier, then the controller upgrade package is determined to have passed the integrity check.

[0230] For example, the OTA platform can compare each controller identifier that needs to be upgraded for the target vehicle with the controller upgrade package identifier. If all controller identifiers that need to be upgraded for the target vehicle are successfully matched with the controller upgrade package identifier, the OTA platform can determine that the controller upgrade package has passed the integrity verification.

[0231] In one implementation, if a controller identifier fails to match a controller upgrade package identifier, it can be determined that the controller identifier does not have a corresponding controller upgrade package, and the OTA platform can then determine that the controller upgrade package has failed the integrity check.

[0232] In one implementation, if a controller identifier does not have a matching controller upgrade package identifier, the OTA platform can determine that the controller upgrade package has failed the integrity check.

[0233] In one implementation, integrity verification is used to verify whether all controller upgrade packages required by the target vehicle in a single upgrade have been downloaded to the local machine by the OTA platform.

[0234] In one implementation, if the integrity check fails, the OTA platform can re-obtain the controller upgrade package corresponding to the controller identifier that was not matched.

[0235] In one implementation, if the integrity check still fails after repeatedly obtaining the controller upgrade package corresponding to the controller identifier, the OTA platform can generate an exception alert to remind testers to check and handle the exception.

[0236] For example, if the OTA platform detects that the links to all three controller upgrade packages for the target vehicle have been received, the OTA platform can automatically download each controller upgrade package through these links. Subsequently, the OTA platform can calculate the hash values ​​of the three controllers for the target vehicle and compare these hash values ​​with the input parameters in the controller upgrade packages. The hash value is the controller identifier. The input parameter is the controller upgrade package identifier. If the hash value matches the input parameter, the subsequent encrypted packaging process is triggered. If the hash value does not match the input parameter, an integrity verification failure is returned. The OTA platform can merge the three controller upgrade packages according to the overall package structure of vehicle model C01 to generate a complete OTA package. This complete OTA package is the vehicle upgrade package.

[0237] In this example, by comparing the identifier of the controller that needs to be upgraded for the target vehicle with the identifier of the upgrade package for precise matching and verification, the completeness of the controller upgrade package required for the target vehicle upgrade is ensured, thereby improving the effect of automated upgrade.

[0238] In one example, the determination process for determining whether the target vehicle meets the upgrade conditions in step S104 above may include:

[0239] S1041. If the test bench where the vehicle is located is idle and the vehicle is parked, and the remaining battery capacity of the vehicle is greater than the preset capacity, then the target vehicle is determined to meet the upgrade conditions.

[0240] For example, the OTA platform first obtains the occupancy status of the test bench and the vehicle's status parameters in real time through communication with the test bench management system and the vehicle's T-Box. The vehicle's status parameters may include parking status and remaining battery capacity information.

[0241] The OTA platform can determine that a test bench is in an idle state when it is found that the test bench is not performing any tasks. After determining that the test bench is in an idle state, the OTA platform can further determine whether the vehicle's status parameters meet the requirements.

[0242] The OTA platform can determine that a target vehicle meets the upgrade requirements when it is in parking mode and the remaining battery capacity is greater than the preset capacity.

[0243] In one implementation, the test bench is a hardware device used to simulate the vehicle's operating environment or to conduct specific tests, and can be connected to the vehicle to monitor its status or perform upgrade operations.

[0244] In one implementation, when the test bench is in an idle state, it indicates that the test bench is not currently performing a test task.

[0245] In one implementation, when the target vehicle is in parking mode, it is stationary and securely locked, typically activated by a gear (such as P), handbrake, or electronic parking brake (EPB) system, ensuring the vehicle does not move unexpectedly during the upgrade process. At this point, the vehicle's speed can be determined to be 0.

[0246] In one implementation, when the remaining battery capacity is greater than a preset capacity, it indicates that the remaining battery power of the target vehicle is sufficient to support the vehicle's subsequent upgrades. This preset capacity can be a percentage of the battery's charge level. For example, the preset capacity could be 10%.

[0247] In this example, by comprehensively judging the test bench's idle status, the vehicle's parking status, and whether the remaining battery capacity meets the standards, the target vehicle is accurately selected. This avoids launching the vehicle upgrade package onto a vehicle that cannot perform the update, which could cause the vehicle's ongoing test task to fail or cause the vehicle to malfunction, thereby improving the vehicle upgrade success rate.

[0248] Based on the above embodiments, during the testing process, vehicles of the same type typically include multiple vehicles. Therefore, a vehicle upgrade package actually needs to upgrade multiple vehicles. Consequently, the OTA platform needs to screen the multiple vehicles linked to it and determine multiple eligible vehicles as target vehicles.

[0249] In one example, each test bench can be connected to a test vehicle. A testing area typically includes multiple test benches. Some of these test benches can be used for testing the same vehicle model, and these multiple test benches can be grouped into a test group.

[0250] In one implementation, when a test bench is newly registered to the OTA platform, if it needs to receive automatic OTA updates, it must be manually added to the corresponding group according to the vehicle model and year. For example, "C01 Functional Test Group" (containing 10 test benches, used to verify basic functions) and "C01 Stress Test Group" (containing 5 test benches).

[0251] In one example, during each upgrade, the OTA platform can identify the test group that needs to perform the upgrade. The OTA platform can then select target vehicles that meet the upgrade requirements from the test benches within that test group. For instance, when the vehicle upgrade package is compatible with model C01, the "C01 Functional Test Group" is selected as the target group for the upgrade.

[0252] In one implementation, the OTA platform can push the vehicle upgrade package to the vehicles in the test group according to preset rules. For example, if the number of vehicles to be upgraded is small (currently 10), the push strategy can be set to "push all 10 vehicles at once". Or, if the number of vehicles to be upgraded is 100, the push strategy can be set to "push 10 vehicles at once".

[0253] In one implementation, the push process does not consider network load. When the network is unstable, the OTA platform can further optimize the push method based on the network condition, starting with the need for a single push. For example, 10 racks can be pushed at once. When the network condition is good, these 10 racks can be pushed all at once. When the network condition is poor, these 10 racks can be pushed in two separate pushes.

[0254] In one example, during the encryption process described above, the OTA platform also needs to generate a digital envelope. This digital envelope may contain information required for decryption. This digital envelope assists the target vehicle in decrypting the vehicle upgrade package. The vehicle can request this digital envelope during decryption, thereby enabling the decryption of the vehicle upgrade package. This process may include:

[0255] S104. Sign the controller upgrade package using the preset certificate private key to generate signature information.

[0256] For example, after the OTA platform completes the integrity verification of the controller upgrade package, it can record the complete controller upgrade package by means of a signature, so that the vehicle can verify the integrity of the upgrade package based on the signature information after obtaining the vehicle upgrade package.

[0257] In one implementation, the OTA platform can call a pre-deployed certificate private key to perform encryption operations on the hash value of the upgrade package or the entire file, generating a digital signature that matches the private key.

[0258] In one implementation, the certificate private key is typically stored in the hardware security module (HSM).

[0259] In one implementation, the certificate private key is the private portion of the asymmetric encryption key pair held by the OTA platform.

[0260] In one implementation, the signature information is ciphertext data generated by encryption with a private key, containing a unique identifier of the upgrade package (such as a hash value) and a timestamp, used for vehicle-side verification.

[0261] In one implementation, the OTA platform can calculate the hash value of the entire upgrade package file and encrypt the hash value with a private key to generate signature information, thereby achieving full file signing.

[0262] In another implementation, the OTA platform can divide the upgrade package into multiple data blocks, calculate the hash of each block and sign it, thus achieving block signing.

[0263] In another implementation, the OTA platform can sign only the key metadata in the upgrade package, reducing the amount of computation.

[0264] S105. Using the second encryption algorithm, process the symmetric key, ciphertext length, signature information, and public key certificate to generate a digital envelope.

[0265] For example, the OTA platform can obtain the symmetric key and ciphertext length generated during the encryption process. The OTA platform can also obtain the signature information obtained in step S104. Furthermore, the OTA platform can obtain a pre-stored public key certificate. The OTA platform can use a second encryption algorithm to encrypt the symmetric key, ciphertext length, signature information, and public key certificate to obtain a digital envelope.

[0266] In one implementation, the digital envelope securely transmits the symmetric key to the vehicle, along with metadata of the upgrade package, assisting the vehicle in completing the decryption and verification process. Upon receiving the digital envelope, the vehicle first uses its private key to decrypt it and obtain the symmetric key, then uses the symmetric key to decrypt the upgrade package, and finally verifies the signature and public key certificate.

[0267] In one implementation, the public key certificate is a public key paired with the private key, embedded in the digital certificate, and issued by a trusted authority (CA) to verify the legitimacy of the signature.

[0268] In one implementation, the second encryption algorithm can be an asymmetric encryption algorithm. The private key used by this second encryption algorithm needs to correspond to the public key stored on the vehicle side.

[0269] For example, the second encryption algorithm could be the RSA-2048 algorithm.

[0270] In one implementation, the OTA platform can release a new upgrade task after generating a digital envelope and distribute the digital envelope to the rack.

[0271] In one implementation, the digital envelope can be stored in the storage area of ​​the OTA platform, and a query interface is provided to support the test bench to actively query the latest digital envelope, so that the test bench can query and obtain the digital envelope.

[0272] In one implementation, the digital envelope may include at least the following information: upgrade package ID, encryption algorithm version, AES key for decrypting the upgrade file, OTA certificate for verifying the upgrade package signature, upgrade package information list, upgrade package file size, upgrade package download URL, product model corresponding to the upgrade package, software version number corresponding to the upgrade package, hardware version number corresponding to the upgrade package, upgrade package name, SHA256 value of the upgrade package file, controller pyid corresponding to the upgrade package, and encryption signature corresponding to the upgrade package.

[0273] In this example, a digital envelope is obtained by encrypting the symmetric key, ciphertext length, signature information, and public key certificate. This method enables secure decryption of the vehicle upgrade package on the target vehicle, thus improving the security of the decryption process.

[0274] In one example, the OTA platform can also obtain the upgrade results of the target vehicle and process them accordingly. This process may include:

[0275] S106. Obtain feedback information from the target vehicle after upgrading the controller software.

[0276] For example, after the OTA platform pushes the controller software upgrade package to the target vehicle, it can wait for and obtain feedback information from the target vehicle after the controller software has been upgraded.

[0277] In one implementation, the OTA platform can receive feedback information through a two-way communication channel established with the vehicle's T-Box or in-vehicle gateway.

[0278] In one implementation, the feedback information may include execution result data generated by the vehicle during or after the upgrade process, including success / failure status, error codes, timestamps, etc.

[0279] Optionally, the feedback information may also include detailed logs, status codes, and key event information recorded by the vehicle during the upgrade process.

[0280] Optionally, the feedback information may also include results of steps such as whether the upgrade package decryption was successful, whether the firmware writing was completed, and whether the controller restarted normally.

[0281] Optionally, in some scenarios, the feedback information may also include comparison data of firmware versions before and after the upgrade.

[0282] In one implementation, the OTA platform needs to parse these feedback data in real time and store them in a log database for subsequent analysis, while also triggering the subsequent upgrade result determination process.

[0283] In one implementation, the feedback information can be proactively reported by the vehicle when a feedback is triggered at a critical upgrade node.

[0284] In another implementation, the feedback information can be sent periodically by the OTA platform to the vehicle to obtain the upgrade progress and final results.

[0285] S107. Based on the feedback information, determine the upgrade result for the target vehicle. And if the upgrade result indicates upgrade failure, determine the reason for the upgrade failure based on the feedback information.

[0286] For example, after receiving feedback information from the vehicle, the OTA platform can parse the status code or result flag to obtain the upgrade result. Then, the OTA platform can determine whether the upgrade was successful based on this upgrade result.

[0287] If the upgrade is successful, the vehicle will be marked as upgraded and archived.

[0288] If the upgrade fails, the OTA platform needs to further analyze the error codes, log fragments, or descriptive text in the feedback information, match them with a predefined failure reason library, and determine the specific reason for the failure.

[0289] Optionally, for cases of non-matching anomalies, the platform can trigger a manual review process, where maintenance personnel can supplement the reasons based on historical vehicle data and on-site investigation results.

[0290] For example, the reason for the failure could be "signature verification failed", "insufficient storage space", "controller unresponsive", etc.

[0291] In one implementation, the OTA platform can map error codes reported by vehicles to cause descriptions in the platform's knowledge base. For example, error code 0xA1B2 can be mapped to an expired signature certificate.

[0292] In another implementation, the OTA platform can extract key failure information from the feedback logs using natural language processing by extracting keywords from the logs. For example, the extracted failure reason could be a Flash write error.

[0293] In another implementation, the OTA platform can use root cause analysis algorithms, combined with multi-dimensional data such as vehicle model, firmware version, and network status, to infer the root cause of upgrade failure using decision trees or machine learning models.

[0294] In another implementation, the OTA platform can categorize failures to determine the cause. For example, network-related categories could include "4G signal loss" or "DNS resolution failure." Firmware-related categories could include "hash value mismatch" or "version conflict." Hardware-related categories could include "controller memory corruption" or "unstable power supply." Operation-related categories could include "user interrupted upgrade" or "insufficient permissions."

[0295] S108. Based on the reason for failure, initiate the retry mechanism.

[0296] For example, once the OTA platform determines the reason for the upgrade failure, it can trigger the retry process again according to the retry mechanism corresponding to the failure reason.

[0297] In one implementation, different failure reasons can correspond to different retry procedures. For example, failures caused by network anomalies can trigger periodic retries. Similarly, failures due to insufficient permissions can trigger manual handling by testers.

[0298] In one implementation, if a test bench fails due to a network interruption, the bench will trigger a retry and request a download every 5 minutes within 2 hours, forming a complete upgrade loop and ensuring test coverage.

[0299] In one implementation, if the failure is due to a controller upgrade failure, the test bench can wait for the tester to manually retry the upgrade. Alternatively, it can wait for the tester to manually remove the vehicle upgrade package, then manually download and upgrade it again.

[0300] In one implementation, the OTA platform can also pull controller logs and determine if there are any issues with the controller upgrade package. If the controller upgrade package has a problem, the OTA platform can wait for the testers to re-upload the controller upgrade package before packaging it into a vehicle upgrade package. After generating the vehicle upgrade package, the OTA platform can then re-push the upgrade information to the test bench.

[0301] In this example, a method for accurately diagnosing and automatically repairing software upgrade anomalies is achieved by obtaining upgrade feedback information from the target vehicle, analyzing the upgrade results, locating the cause of failure, and then initiating a retry mechanism.

[0302] Based on the above embodiments, taking the 10 test benches of the "C01 Functional Test Group" as an example, the automatic upgrade process may include:

[0303] When 10 racks receive MQTT messages, assuming 6 racks are currently idle, the rack software on these 6 racks will collect controller information upon receiving the MQTT message. If the other 4 racks are in testing mode, their rack software may experience data collection failures. This failure usually occurs because some controllers on the rack are under testing, preventing normal information return and causing timeouts and data collection failures.

[0304] After receiving information from the controller, the bench software determines whether the target vehicle corresponding to that bench meets the upgrade requirements. If the bench's battery capacity is greater than 10%, it is currently parked, and its speed is 0, the bench software determines that the upgrade requirements are met. At this point, the bench software sends a download request to the OTA platform. This download request may include the bench's VIN and its respective public key.

[0305] The other four test benches temporarily store the MQTT message.

[0306] The OTA platform verifies that the VINs of the six racks are in the authorized list. The OTA platform sends a digital envelope "ENV001" and a CDN download address to the six racks. For example, the download address can be "cdn / C01_2.1_AC.zip".

[0307] The test bench downloads the encrypted vehicle upgrade package from the CDN and decrypts "K_enc" using its own private key to obtain key K. The test bench then uses key K to decrypt the vehicle software package. The test bench can also verify the integrity of the vehicle software package using SHA-256 verification and install it after confirming its integrity.

[0308] Assuming that out of the 6 test benches downloading the vehicle upgrade package, 5 successfully upgraded and reported the results, while 1 failed due to insufficient storage space, the OTA platform can record the reason for the failure of one of the 6 test benches after receiving the feedback information.

[0309] Once the rack has completed its space clearing operation, it can trigger a retry. Alternatively, the OTA platform can trigger a retry after detecting that the rack has completed its space clearing operation.

[0310] After the test is completed, the four temporary message storage racks can retrieve digital envelopes and complete the upgrade through the query interface.

[0311] In this embodiment, compared to the current unified push of upgrade packages, which is prone to upgrade failure or test interruption due to differences in platform status (such as ongoing testing or insufficient resources), this embodiment addresses this issue by pre-storing platform groups (by model, task type, version, etc.) and using a strategy-based push (such as batching). This allows the OTA platform to pre-group platforms by platform model, task type, etc., and only push to compatible target groups. From an adaptation logic perspective, the grouping mechanism ensures that upgrade packages are only pushed to matching platforms, avoiding incompatible platforms receiving invalid information.

[0312] Meanwhile, this embodiment utilizes a messaging mechanism combining MQTT push and proactive querying, along with a platform autonomously determining upgrade conditions (task status - if the platform already has an upgrade task and hasn't upgraded, it won't make a download request; storage - during the download process, the platform will continuously monitor the remaining space and stop downloading if it cannot meet the minimum operating space; network - if the download address is not found, it will retry periodically). This allows the platform to autonomously determine whether to upgrade based on its own status (whether a task is being executed, storage space, network stability). The platform's autonomous selection mechanism allows the platform to upgrade in a "non-working state" or when "resources are sufficient," reducing test interruptions caused by forced pushes.

[0313] Therefore, this design can improve adaptability to different test bench hardware and task states, reduce upgrade failure rate, and enhance the reliability of test bench upgrades.

[0314] Figure 2 This is a flowchart illustrating the encryption process implemented in an embodiment of this application, as shown below. Figure 2 As shown, the process includes the following steps:

[0315] S201, the OTA platform receives a plaintext file. This plaintext file is the controller upgrade package described in step S101 above. One plaintext file corresponds to one controller upgrade package.

[0316] S202, the OTA platform determines whether the plaintext file is larger than 1M. This 1M is the preset size described in step S1021 above.

[0317] S203. If the file size is less than or equal to 1M, the OTA platform can use AES-256 to encrypt the plaintext file.

[0318] In one implementation, the OTA platform can output the ciphertext length.

[0319] In one implementation, the OTA platform can use the PKCS #1 padding algorithm to pad the plaintext file to 1MB before encrypting it.

[0320] In another implementation, the OTA platform can encrypt the plaintext file and then pad the encrypted file to a target length. This target length can be the ciphertext length after encrypting 1MB of plaintext.

[0321] In one implementation, the AES-256 encryption algorithm uses the GCM algorithm.

[0322] In one implementation, the encryption algorithm can randomly generate 64-bit AES ciphertext through an OTA platform, use the first 32 bits as the symmetric key (key K), use the next 12 bits as the initialization vector, and reserve the rest.

[0323] S204. If the file size is greater than 1MB, the OTA platform can split the plaintext file into multiple initial data blocks. Each initial data block may include at least one 1MB plaintext block and a final plaintext block. The final plaintext block is typically less than or equal to 1MB.

[0324] The S205 and OTA platforms can use AES-256 to encrypt the initial data block.

[0325] For example, the OTA platform can directly encrypt 1MB of plaintext using AES-256 to obtain the ciphertext. This ciphertext is the encrypted data block. Furthermore, the OTA platform can output the length of the ciphertext.

[0326] For plaintext at the end, if the size of the plaintext at the end is less than 1MB, the OTA platform can use the PKCS #1 padding algorithm to pad the plaintext file to 1MB before encrypting it. Alternatively, the OTA platform can encrypt the plaintext file and then pad the encrypted file to the target length.

[0327] S206. The OTA platform can concatenate all the ciphertext to obtain the final fully encrypted ciphertext file. This fully encrypted ciphertext file is the vehicle upgrade package obtained in step S103 above.

[0328] For example, the OTA platform can concatenate the various ciphertext files according to a preset order to obtain a fully encrypted ciphertext file.

[0329] In this example, a dual encryption method is used: "symmetric encryption (such as AES-256) encrypts the entire OTA package + asymmetric encryption (such as RSA-2048) encrypts the symmetric key". The encrypted package is stored and transmitted as "encrypted package + key ciphertext = digital envelope". Combined with CDN storage and permission verification, the security of the package is ensured during transmission and storage, and unauthorized access or tampering is prevented.

[0330] Given the current imperfections in encryption mechanisms, which pose risks of software package theft and tampering, this application employs symmetric encryption to ensure overall packet encryption efficiency and asymmetric encryption to ensure key transmission security. Furthermore, only authorized testbeds can decrypt the package using their own private keys, forming a "double protection" system. Even if the encrypted packet is intercepted, it cannot be decrypted without the private key of an authorized testbed. Simultaneously, hash verification further ensures packet integrity. Therefore, this mechanism effectively prevents unauthorized access or tampering of software packages (including unpublished code or keys) during the testing phase, significantly improving security.

[0331] Figure 3 This is a flowchart of the automatic software upgrade package push method according to an embodiment of this application. Figure 4 This is a diagram illustrating the communication between the CI system, OTA platform, CDN, and vehicle terminal during this process. For example... Figure 3 and Figure 4 As shown, the process includes the following steps:

[0332] The S301 and CI systems build upgrade packages for each controller and call the OTA platform interface to push download links.

[0333] For example, the CI system for automotive electronics automatically compiles and generates controller upgrade packages of version V2.1 for three controllers (ECU1, ECU2, ECU3) of a certain vehicle model, uploads them to the JFrog repository, and generates links:

[0334] - ECU1: jfrog / ecu1_v2.1.zip

[0335] - ECU2: jfrog / ecu2_v2.1.zip

[0336] - ECU3: jfrog / ecu3_v2.1.zip

[0337] The CI system calls the "package link push interface" of the OTA platform to push the above link to the OTA platform.

[0338] S302: The OTA platform automatically downloads the controller upgrade package and calls the full package packaging tool to automatically print the OTA software full package according to the format.

[0339] For example, the OTA platform completes the download based on the three links in step S301, and marks "3 / 3 packets received" upon completion of the download.

[0340] The OTA platform can also obtain metadata uploaded by the CI system. This metadata may include information such as vehicle model ID: C01, version: V2.1, and hash values ​​of each controller (hash values ​​are calculated using the SHA-256 algorithm).

[0341] The S303 and OTA platforms will fully encrypt the entire package and upload it to CDN storage to generate a digital envelope.

[0342] S304, OTA platform for automatic push of rack management and delineation.

[0343] The S305 and OTA platform push MQ messages to the target platform and provide an interface for querying upgrade tasks.

[0344] S306 and test benches can choose to download and upgrade the software, and upload the records for the platform to keep.

[0345] In this example, based on this automated process, end-to-end automation is achieved from controller upgrade package generation to test bench upgrade. The CI system automatically pushes the controller upgrade package link, the OTA platform automatically detects the integrity of the package, packages and encrypts it, and the test bench autonomously determines the upgrade timing and performs the upgrade, realizing a fully automated process.

[0346] Compared to the current cumbersome and error-prone process of manually uploading software packages, triggering push notifications, and waiting for the entire package to be collected, this application automatically generates controller upgrade packages through the CI system and pushes the link to the OTA platform. The OTA platform monitors the integrity of the package in real time and automatically packages it, eliminating the need for manual intervention. This reduces the time cost of manual operations (such as manual waiting and upload time) and the error rate (such as missed or incorrect transmission), significantly improving the efficiency of the test bench upgrade process. Furthermore, the seamless connection between "controller upgrade package generation → full package push" enables high-frequency updates of the test bench, thereby better meeting testing needs.

[0347] Building upon the above embodiments, after the CI system generates the controller upgrade package, it can also write the controller upgrade package hash value and metadata (version, model) to the blockchain. This controller upgrade package hash value and metadata can be stored on the blockchain's distributed storage nodes, generating a download address with a blockchain timestamp.

[0348] The OTA platform verifies the hash integrity of all controller upgrade packages via blockchain. This integrity verification process is automatically determined through on-chain state. The OTA platform can package the controller upgrade packages and encrypt them using a blockchain public key system. The OTA platform can directly perform asymmetric encryption on the entire package using the on-chain public key from the test bench. For example, the encryption algorithm can be an Elliptic Curve Cryptography Public Key Cryptographic Algorithm (ECC SM2). This method does not require a separate encryption key.

[0349] The test bench registers its own status via a blockchain smart contract. This status can include information such as online / offline status and task type. The OTA platform invokes the contract to automatically match a target test bench and pushes an on-chain message containing its distributed storage address. After verifying the message's legitimacy via the contract, the test bench downloads the message autonomously and decrypts it using its on-chain private key.

[0350] Based on the above embodiments, after the CI system generates the controller upgrade package, it can also send the controller upgrade package to the edge node to realize the layout of the controller upgrade package on the edge node and realize the localized distribution of the controller upgrade package through the edge node.

[0351] Edge nodes receive packets in real time and generate local access links. After detecting packet integrity, the edge node uses a hardware encryption chip to generate an encrypted packet. An upgrade notification is then broadcast to the target rack via the local area network.

[0352] The test bench pre-stores a key negotiation mechanism with the edge nodes. Upon receiving a notification, it determines whether to upgrade based on local computing power, directly downloads the encrypted package at high speed from the edge nodes, and decrypts it using the negotiated key. For example, this negotiated key can be used for Diffie-Hellman key exchange.

[0353] The upgrade results of the test bench can be aggregated and synchronized to the cloud via edge nodes. In the event of an upgrade anomaly, the edge node can be maintained locally to retry the upgrade.

[0354] Based on the above embodiments, after the CI system generates the controller upgrade package, it can also package it into a container image (such as a Docker image) and push it to a container repository (such as Harbor). The image tag of this controller upgrade package can contain metadata such as version and model.

[0355] The OTA platform does not require "merging entire packages." Instead, it dynamically selects the necessary controller images based on the test bench requirements using container orchestration tools (such as Kubernetes) and generates an encrypted image pull list (including image addresses and version constraints). The container images themselves are encrypted at the repository level, and the pull list is encrypted using the bench's public key. The OTA platform pushes the encrypted list to the target bench, which then decrypts it and directly pulls the required images from the container repository.

[0356] The bench checks its own resources (CPU, memory) to see if they meet the requirements for running the image through the container runtime, and decides autonomously to pull and upgrade. The upgrade results are fed back through the container health check mechanism.

[0357] Accordingly, please refer to Figure 5 This application provides an automatic software upgrade package push device 500, which includes:

[0358] The acquisition module 501 is used to acquire multiple controller upgrade packages for the target vehicle.

[0359] The processing module 502, upon determining that the controller upgrade package has passed integrity verification, performs block encryption on the controller upgrade package to obtain multiple encrypted data blocks. These encrypted data blocks are then processed to obtain the vehicle upgrade package for the target vehicle.

[0360] The push module 503 is used to push the vehicle upgrade package to the target vehicle when it is determined that the target vehicle meets the upgrade conditions, so that the target vehicle can use the vehicle upgrade package to upgrade the software of the controller in the target vehicle.

[0361] In one example, processing module 502 is used for:

[0362] The controller upgrade package is processed according to a preset size to obtain multiple initial data blocks.

[0363] The initial data block is encrypted using the first encryption algorithm to obtain multiple encrypted data blocks and ciphertext lengths.

[0364] In one example, processing module 502 is used for:

[0365] If the size of the controller upgrade package is less than or equal to the preset size, the controller upgrade package will be used as the initial data block.

[0366] If the size of the controller upgrade package is larger than the preset size, the controller upgrade package will be split into multiple initial data blocks according to the preset size.

[0367] If the size of an initial data block is smaller than the preset size, the preset filling algorithm will be used to fill the initial data block to the preset size.

[0368] In one example, processing module 502 is used for:

[0369] Generate a symmetric key and an initialization vector.

[0370] The initial data block is encrypted using the first encryption algorithm, a symmetric key, and an initialization vector to obtain an encrypted data block.

[0371] The length of the ciphertext is obtained by summing the lengths of each encrypted data block.

[0372] In one example, processing module 502 is used for:

[0373] Randomly generate a ciphertext of the first preset length.

[0374] Use the second preset length of data starting from the first position in the ciphertext as the symmetric key.

[0375] Use the third preset length of data starting from the second position in the ciphertext as the initialization vector.

[0376] The sum of the second preset length and the third preset length is less than or equal to the first preset length. The second position is not within the second preset length starting from the first position.

[0377] In one example, processing module 502 is used for:

[0378] The encrypted data blocks are assembled in a preset order to generate the vehicle upgrade package for the target vehicle.

[0379] In one example, processing module 502 is used for:

[0380] Obtain the identifier of the controller that needs to be upgraded in the target vehicle, as well as the identifier of the controller upgrade package contained in the controller upgrade package.

[0381] If each controller identifier has a matching controller upgrade package identifier, then the controller upgrade package is determined to have passed the integrity check.

[0382] In one example, push module 503 is used for:

[0383] If the test bench where the vehicle is located is idle and the vehicle is parked, and the vehicle's remaining battery capacity is greater than the preset capacity, then the target vehicle is determined to meet the upgrade conditions.

[0384] In one example, processing module 502 is used for:

[0385] The controller upgrade package is signed using a preset certificate private key to generate signature information.

[0386] The second encryption algorithm is used to process the symmetric key, ciphertext length, signature information, and public key certificate to generate a digital envelope.

[0387] The digital envelope is used to assist the target vehicle in decrypting the vehicle upgrade package.

[0388] In one example, push module 503 is used for:

[0389] Obtain feedback information from the target vehicle after upgrading the controller software.

[0390] Based on the feedback information, determine the upgrade result for the target vehicle. If the upgrade result indicates failure, determine the reason for the failure based on the feedback information.

[0391] The retry mechanism is activated based on the reason for the failure.

[0392] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0393] In this embodiment, the automatic software upgrade package push device is presented in the form of a functional unit. Here, a unit refers to an application-specific integrated circuit (ASIC), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0394] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application, such as... Figure 6 As shown, the computer device includes one or more processors 601, memory 602, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0395] The processor 601 may be a central processing unit, a network processor, or a combination thereof. The processor 601 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CLP), a field-programmable gate array (FPGA), a general-purpose array logic (GPRS), or any combination thereof.

[0396] The memory 602 stores instructions executable by at least one processor 601 to cause at least one processor 601 to perform the method shown in the above embodiments.

[0397] Memory 602 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function. The data storage area may store data created based on the use of the computer device. Furthermore, memory 602 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, memory 602 may optionally include memory remotely located relative to processor 601, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0398] Memory 602 may include volatile memory, such as random access memory. Memory may also include non-volatile memory, such as flash memory, hard disk, or solid-state drive. Memory 602 may also include combinations of the above types of memory.

[0399] The computer device also includes a communication interface 603 for communicating with other devices or communication networks.

[0400] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc. Further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0401] This application provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method of any embodiment of this application.

[0402] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

[0403] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0404] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0405] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0406] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0407] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1The function specified in one or more boxes.

[0408] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0409] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0410] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0411] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0412] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A software upgrade package automatic pushing method, characterized in that, The method comprises: obtaining a plurality of controller upgrade packages of a target vehicle; if it is determined that the controller upgrade package passes the integrity check, processing the controller upgrade package according to a preset size to obtain a plurality of initial data blocks; generating a random byte sequence of a first preset length based on the length of the symmetric key to be generated and the length of the initialization vector, and taking the random byte sequence as a ciphertext; wherein the first preset length is greater than or equal to the sum of the data length of the initialization vector and the data length of the symmetric key; starting from the first position of the ciphertext, intercepting data of a second preset length as the symmetric key; if the ciphertext after the symmetric key has been intercepted only includes one continuous data block, determining a second preset range in the continuous data block, and based on the second position in the second preset range, intercepting the initialization vector starting from the second position; if the ciphertext after the symmetric key has been intercepted includes two continuous data blocks, deleting the continuous data block with a data volume less than a third preset length, and then, in the remaining continuous data blocks, determining a second preset range and based on the second position in the second preset range, intercepting the initialization vector starting from the second position; otherwise, reassembling the data in the ciphertext that has not been intercepted by the symmetric key into a new data block, determining a second preset range in the new data block, and based on the second position in the second preset range in the new data block, intercepting the initialization vector starting from the second position; wherein the third preset length is the length of the initialization vector; and the symmetric key and the initialization vector have no overlap; mixing the plaintext with the symmetric key and the initialization vector through a first encryption algorithm to generate a ciphertext, thereby obtaining an encrypted data block; processing the encrypted data block to obtain a vehicle upgrade package of the target vehicle; if it is determined that the target vehicle meets the upgrade condition, pushing the vehicle upgrade package to the target vehicle, so that the target vehicle uses the vehicle upgrade package to upgrade the software of the controller in the target vehicle.

2. The method of claim 1, wherein, Processing the controller upgrade package according to a preset size to obtain a plurality of initial data blocks comprises: if the size of the controller upgrade package is less than or equal to the preset size, taking the controller upgrade package as the initial data block; if the size of the controller upgrade package is greater than the preset size, splitting the controller upgrade package into a plurality of initial data blocks according to the preset size; if the size of the initial data block is less than the preset size, filling the initial data block to the preset size using a preset padding algorithm.

3. The method of claim 1, wherein, The method further comprises: obtaining the length of each encrypted data block to obtain the length of the ciphertext.

4. The method according to any one of claims 1-3, characterized in that, Processing the encrypted data block to obtain a vehicle upgrade package of the target vehicle comprises: splicing the encrypted data blocks according to a preset order to generate a vehicle upgrade package of the target vehicle.

5. The method according to any one of claims 1-3, characterized in that, Determining that the controller upgrade package passes the integrity check comprises: obtaining the controller identifier in the target vehicle that needs to be upgraded, and the controller upgrade package identifier contained in the controller upgrade package; If each of the controller identifiers matches a controller upgrade package identifier, it is determined that the controller upgrade package passes the integrity check.

6. The method according to any one of claims 1-3, characterized in that, It is determined that the target vehicle meets the upgrade condition, including: If the test bench where the current vehicle is located is in an idle state, and the vehicle is in a parked state, and the remaining battery capacity of the vehicle is greater than a preset capacity, it is determined that the target vehicle meets the upgrade condition.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: The controller upgrade package is signed using a preset private key of a certificate to generate signature information; The symmetric key, the length of the ciphertext, the signature information, and the public key certificate are processed using a second encryption algorithm to generate a digital envelope; The digital envelope is used to assist the target vehicle in decrypting the vehicle upgrade package.

8. The method of any one of claims 1-3, wherein, The method further includes: Feedback information of the target vehicle after upgrading the software of the controller is obtained; According to the feedback information, the upgrade result of the target vehicle is determined; and when the upgrade result indicates that the upgrade fails, the failure reason for the upgrade failure is determined according to the feedback information; According to the failure reason, a retry mechanism is started.

9. A software upgrade package automatic pushing device, characterized in that, The device includes: An obtaining module is configured to obtain a plurality of controller upgrade packages of a target vehicle; A processing module is configured to, if it is determined that the controller upgrade package passes the integrity check, process the controller upgrade package according to a preset size to obtain a plurality of initial data blocks; generate a random byte sequence of a first preset length based on the length of a symmetric key to be generated and an initialization vector, and use the random byte sequence as a secret text; wherein the first preset length is greater than or equal to the sum of the data length of the initialization vector and the data length of the symmetric key; a second preset length of data is cut from a first position of the secret text as the symmetric key; if the secret text after the symmetric key has been cut includes only one continuous data block, a second preset range is determined in the continuous data block, and an initialization vector is cut from a second position in the second preset range; if the secret text after the symmetric key has been cut includes two continuous data blocks, the continuous data block with a data amount less than a third preset length is deleted, a second preset range is determined in the remaining continuous data block, and an initialization vector is cut from a second position in the second preset range; otherwise, data in the secret text that has not been cut by the symmetric key is reorganized into a new data block, a second preset range is determined in the new data block, and an initialization vector is cut from a second position in the second preset range; wherein the third preset length is the length of the initialization vector; and the symmetric key and the initialization vector do not overlap; a ciphertext is generated by mixing the plaintext with the symmetric key and the initialization vector through a first encryption algorithm to obtain encrypted data blocks; and the encrypted data blocks are processed to obtain a vehicle upgrade package of the target vehicle; The push module is configured to push the vehicle upgrade package to the target vehicle to enable the target vehicle to upgrade software of a controller in the target vehicle using the vehicle upgrade package, when it is determined that the target vehicle meets the upgrade condition.

10. A computer device, comprising: The software upgrade package automatic push method comprises the following steps: The memory and the processor are connected in communication with each other, and the memory stores computer instructions.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling a computer to execute the software upgrade package automatic push method.

12. A computer program product, characterised in that, The computer instructions are used for enabling a computer to execute the software upgrade package automatic push method.

Images