Method for generating software upgrade package and electronic device

Abstract

This application provides a method for generating a software upgrade package and an electronic device, relating to the field of intelligent connected vehicle technology. The method includes: detecting a software upgrade package generation request, the request including a target hardware identifier for a vehicle, the target hardware identifier identifying the hardware to be upgraded in the vehicle; obtaining a baseline image file, the baseline image file representing a common environment image file for different hardware; obtaining a target configuration resource corresponding to the target hardware identifier based on the target hardware identifier, the target configuration resource including a target configuration file; and generating a software upgrade package corresponding to the target hardware identifier based on the baseline image file and the target configuration file. This method can generate a software upgrade package based on a unified baseline image file and the target configuration file corresponding to the target hardware identifier, thereby improving the efficiency of software upgrade package generation.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to a method for generating a software upgrade package and an electronic device in the field of intelligent connected vehicle technology. Background Technology

[0002] With the rapid development of intelligent connected vehicles, in-vehicle software systems are becoming increasingly complex, containing multiple Electronic Control Units (ECUs). Updating vehicle hardware functions can be achieved by generating a software upgrade package and sending it to the vehicle. However, due to the significant differences in the build toolchains, configuration parameters, and packaging scripts required by different hardware, related technologies typically create a corresponding image file for each type of hardware in the vehicle to adapt to different models and hardware. This results in a large number and size of image files, leading to low efficiency in generating software upgrade packages.

[0003] Therefore, improving the efficiency of software upgrade package generation is a technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a method for generating a software upgrade package and an electronic device. The method can generate a software upgrade package based on a unified base image file and a target configuration file corresponding to the target hardware identifier, avoiding the repeated construction of image files for each hardware, reducing the number and size of image files, and thus improving the generation efficiency of the software upgrade package.

[0005] Firstly, a method for generating a software upgrade package is provided, the method comprising: A software upgrade package generation request was detected. The generation request includes a target hardware identifier for the vehicle, which identifies the hardware in the vehicle to be upgraded. Obtain a baseline image file, which represents an environment image file common to different hardware; Based on the target hardware identifier, the target configuration resource corresponding to the target hardware identifier is obtained, and the target configuration resource includes the target configuration file; Based on the baseline image file and the target configuration file, a software upgrade package corresponding to the target hardware identifier is generated.

[0006] In the embodiments of this application, when a software upgrade package generation request is detected, the target configuration resource is determined based on the target hardware identifier in the generation request; the software upgrade package is generated based on the target configuration resource and the base image file. Compared to related technologies where each type of hardware in a vehicle corresponds to an independent image file, resulting in a large number and size of image files and low efficiency in generating software upgrade packages, this application addresses this problem by encapsulating a common environment image for different hardware into a base image file; the software upgrade package is generated based on the common base image file and the target configuration file corresponding to the target hardware identifier. Since this application uses a common base image file, environment configuration can be quickly achieved through the base image file, eliminating the need to build separate environments for different hardware. Therefore, the cumbersome process of repeatedly performing environment configuration operations (e.g., including system deployment, dependency installation, and environment deployment) before generating the software upgrade package can be avoided. This reduces the maintenance cost of image files and the time spent on environment preparation, thereby improving the efficiency of software upgrade package generation.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the target configuration resource further includes an upgrade package generation script; The step of generating a software upgrade package corresponding to the target hardware identifier based on the baseline image file and the target configuration file includes: Based on the baseline image file, a container instance is generated, which is used to provide isolated, independent running processes and execution environments. Write the target configuration file and the script into the temporary working directory of the container instance; The software upgrade package is generated by calling and running the upgrade package generation script in the temporary working directory through the script execution engine in the base image file.

[0008] In the embodiments of this application, isolated container instances are generated based on a baseline image, providing independent running processes and execution environments with consistent environments for different upgrade package generation tasks. This avoids mutual interference between build environments while ensuring the parallel execution capability of generating software upgrade packages. By writing the target configuration file and script into the temporary working directory of the container instance and running the upgrade package generation script based on the script execution engine built into the baseline image file, it is ensured that the software upgrade package can be generated according to the generation process planned in the software upgrade package generation script. There is no need to configure the running environment for build tasks with different hardware identifiers, which effectively shortens the time spent on environment preparation and switching.

[0009] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the generation method further includes: Obtain the target mapping relationship; The step of obtaining the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier includes: Based on the target hardware identifier and the target mapping relationship, the target configuration resources are obtained. The target mapping relationship includes a first mapping relationship or a second mapping relationship. The first mapping relationship represents the mapping relationship between hardware identifiers and configuration resources, and the second mapping relationship represents the mapping relationship between a first parameter and configuration resources. The first parameter includes a hardware identifier and an upgrade version.

[0010] In the embodiments of this application, a target mapping relationship is obtained, and the target configuration resource is determined based on the target mapping relationship and the target hardware identifier. This ensures that when determining the target configuration resource, there is no need for manual retrieval and matching of configuration files one by one, simplifying the process of finding and locating configuration resources. In addition, through a unified mapping relationship, it is convenient for version maintenance, iterative updates, and rapid retrieval of configuration resources, which can reduce time consumption and error rate compared to manual configuration.

[0011] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, determining the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier and the target mapping relationship includes: If the target mapping relationship is the first mapping relationship, the target configuration resource is determined based on the target hardware identifier and the first mapping relationship; If the target mapping relationship is the second mapping relationship, the upgrade version of the hardware to be upgraded is obtained based on the software upgrade package generation request; the target configuration resource is determined based on the target hardware identifier, the upgrade version and the second mapping relationship.

[0012] In the embodiments of this application, if the target mapping relationship is a first mapping relationship, the target configuration resource is obtained based on the target hardware identifier and the first mapping relationship; if the target mapping relationship is a second mapping relationship, the target configuration resource is obtained based on the target hardware identifier, the upgrade version, and the second mapping relationship. This ensures that this application can not only quickly match configuration resources through hardware identifiers, but also achieve differentiated adaptation of configuration resources under different upgrade versions by combining hardware identifiers and upgrade versions, adapting to packaging scenarios with multiple version iterations of the same hardware.

[0013] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, determining the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier and the target mapping relationship includes: Based on the target hardware identifier and the target mapping relationship, a first configuration resource corresponding to the target hardware identifier is determined in the target mapping relationship; Verify the first configured resource; If the first configuration resource passes the verification, the first configuration resource is determined as the target configuration resource.

[0014] In the embodiments of this application, the configuration resource directly obtained according to the target mapping relationship is determined as the first configuration resource. This enables rapid location and accurate retrieval of configuration resources based on preset mapping rules, eliminating the tedious processes of manual screening, path searching, and manual matching, and improving the response speed of obtaining the first configuration resource. Verifying the first configuration resource, and determining it as the target configuration resource if the verification passes, avoids using incorrect configuration resources to generate software upgrade packages, reducing the risk of package creation failure or subsequent vehicle upgrade malfunctions due to incorrect configuration resources, thereby ensuring the accuracy of target configuration resource retrieval.

[0015] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the target mapping relationship further includes a verification value and a digital signature corresponding to the hardware identifier; the verification of the first configuration resource includes: Based on the target mapping relationship, query the first verification value and the first digital signature corresponding to the target hardware identifier; Generate a second verification value corresponding to the first configuration resource, and verify the legality of the first digital signature; If the first verification value is consistent with the second verification value, and the first digital signature passes the validity verification, then the first configuration resource verification is determined to be successful.

[0016] In the embodiments of this application, a second verification value of the first configuration resource is compared with a first verification value obtained from a target mapping query. If the first verification value matches the second verification value, it indicates that the first configuration resource and the target configuration resource are consistent, meaning that the target configuration resource has not been lost, damaged, or tampered with during transmission, ensuring the integrity of the first configuration resource. On the other hand, the digital signature of the configuration resource is verified to ensure the legitimacy of the first configuration resource. This application uses a dual verification mechanism to verify both the integrity and security of the configuration resource. If both dimensions pass verification, the first configuration resource is determined as the target configuration resource, ensuring that a complete and legitimate target configuration resource can be obtained. This effectively avoids problems such as upgrade package generation failure, firmware adaptation anomalies, and vehicle upgrade malfunctions caused by damaged, tampered, or untrusted sources of configuration resources.

[0017] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the generation method further includes: After generating the software upgrade package corresponding to the hardware identifier, delete the temporary working directory in the container instance and the target configuration resources in the temporary working directory.

[0018] In the embodiments of this application, after generating the software upgrade package, the temporary working directory and the target configuration resources in the temporary working directory in the container instance are promptly deleted. This ensures that temporary data and differentiated configuration content generated by a single package generation task can be cleared in a timely manner, avoiding the waste of resources caused by temporary files occupying storage space for a long time. It also ensures that the system resources occupied by a single package generation task can be quickly recovered and reused, facilitating the rapid scheduling of the next round of upgrade package generation tasks.

[0019] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the generation method further includes: The target configuration resource is stored in the cache area; If a request to generate a software update package for the target hardware identifier is detected again, the target configuration resource is retrieved from the cache area.

[0020] In the embodiments of this application, target configuration resources are stored in a cache area. When a software upgrade package generation request with the same target hardware identifier is received again, the target configuration resources can be retrieved directly and quickly from the cache area without having to go through the process of searching, obtaining, and verifying through mapping relationships again. Since this application can reuse cached target configuration resources, it can shorten the preparation cycle of configuration resources, reduce network bandwidth consumption, improve the response speed of upgrade package generation requests, and effectively improve the batch generation efficiency and concurrent processing capability of software upgrade packages.

[0021] In conjunction with the first aspect and the above implementation methods, in some implementation methods of the first aspect, the generation method further includes: When the configuration resource bound to the first mapping relationship is updated, a change data fragment is obtained. The change data fragment is a data fragment obtained by performing differential calculation on the original configuration resource before the update and the configuration resource after the update. Based on the changed data fragment and the target configuration resource in the cache area, an updated target configuration resource is generated.

[0022] In the embodiments of this application, a differential calculation method is used to obtain the changed data fragments corresponding to the version update. This eliminates the need to re-fetch the complete configuration resource file, reducing the amount of data transmitted over the network and minimizing transmission latency caused by repeated downloads of large files. The updated target configuration resource is generated by merging and recombining the original target configuration resource stored in the cache area with the changed data fragments, without discarding the original cached resources. This allows for full reuse of existing cached data and significantly shortens the configuration resource update readiness time. Compared to the full update mode during version updates, the incremental update method used in this application only synchronizes and merges localized changes, resulting in faster configuration updates and lower resource overhead. This improves the overall efficiency of software upgrade package generation from the perspectives of configuration version iteration and cache reuse.

[0023] Secondly, a vehicle control device is provided, the device comprising: The acquisition module is used to detect the software upgrade package generation request and acquire the baseline image file. The generation request includes the target hardware identifier of the vehicle. The target hardware identifier is used to identify the hardware in the vehicle to be upgraded. The baseline image file is used to represent an environment image file that is common to different hardware. The processing module is configured to obtain the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier, wherein the target configuration resource includes a target configuration file; and generate a software upgrade package corresponding to the target hardware identifier based on the base image file and the target configuration file.

[0024] Thirdly, an electronic device is provided, comprising a memory and a processor, the memory for storing executable program code, and the processor for calling and running the executable program code from the memory, causing the electronic device to perform the generation method in the first aspect or any possible implementation thereof.

[0025] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to execute the generation method described in the first aspect or any possible implementation thereof.

[0026] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when run on a computer, causes the computer to perform the generation method described in the first aspect or any possible implementation thereof. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of a scenario provided in an embodiment of this application; Figure 2This is a schematic diagram of the system architecture of a software upgrade package generation system provided in an embodiment of this application; Figure 3 This is a schematic flowchart illustrating a method for generating a software upgrade package provided in an embodiment of this application; Figure 4 This is a schematic flowchart illustrating another method for generating a software upgrade package provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a software upgrade package generation device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0030] With the rapid development of intelligent connected vehicles, in-vehicle software systems are becoming increasingly complex, typically containing multiple Electronic Control Units (ECUs). By generating a software upgrade package and sending it to the vehicle, updates to the vehicle's hardware functions can be achieved. In practical applications, to ensure environmental consistency of the software upgrade package, the complete operating environment of the in-vehicle system is packaged into a reproducible, one-click deployable image file. The software upgrade package is then generated using this image file, making the resulting software package applicable to different vehicles.

[0031] However, due to the significant differences in the build toolchains, configuration parameters, and packaging scripts required by different hardware, related technologies typically create a separate and complete image file for each type of hardware in each vehicle in order to adapt to different vehicle models and hardware. This results in a large number of image files with large file sizes, leading to low efficiency in generating software upgrade packages.

[0032] The following example illustrates the technical problems existing in the relevant technologies.

[0033] For example, related technologies require customized complete image files for different vehicle ECUs (body ECUs, powertrain ECUs, in-vehicle entertainment ECUs) and different configurations of the same ECU. This necessitates building dedicated environments for each type of hardware, maintaining multiple independent image templates, and managing, storing, maintaining, and adapting each image file individually. This results in a large number of image files of various types, high overall storage space requirements, high image repository storage costs, and a sharp decline in the efficiency of image retrieval, management, and searching. When common basic components (e.g., operating system security patches) need to be upgraded, all relevant dedicated images must be traversed and rebuilt, a cumbersome and error-prone process that makes it difficult to ensure synchronized updates of all images, leading to difficulties in image maintenance and updates. Furthermore, when generating software upgrade packages for corresponding hardware, the need to call dedicated independent images and frequently switch between different image environments results in time-consuming environment preparation and high image loading overhead. This not only increases image operation and maintenance management costs and resource consumption but also extends the preparation cycle for upgrade package generation, ultimately leading to low overall efficiency in software upgrade package generation.

[0034] Therefore, improving the efficiency of software upgrade package generation is a technical problem that needs to be solved.

[0035] In view of this, this application provides a method for generating a software upgrade package and an electronic device. Through embodiments of this application, when a software upgrade package generation request is detected, the target configuration resource is determined based on the target hardware identifier in the generation request; the software upgrade package is generated based on a common baseline image file and the target configuration file corresponding to the target hardware identifier. Since this application does not require building separate environments for different hardware, it avoids the cumbersome process of repeatedly performing environment configuration operations before generating the software upgrade package (e.g., system deployment, dependency installation, and environment deployment), reducing the maintenance cost of image files and the time spent on environment preparation, thereby improving the efficiency of software upgrade package generation.

[0036] The following is combined with Figures 1 to 4 The method for generating software upgrade packages provided in the embodiments of this application will be described in detail.

[0037] Figure 1 This is a schematic diagram of a scenario provided in an embodiment of this application.

[0038] For example, such as Figure 1As shown, scenario 100 includes a cloud server 110 and a vehicle 120. When the cloud server 110 detects a request to generate a software upgrade package, it generates the software upgrade package and stores it on the cloud server. When the vehicle 120 triggers an upgrade command, it sends an upgrade trigger command to the cloud server. In response to this command, the cloud server 110 compares the upgrade version of the vehicle 120 with the upgrade version stored on the cloud server 110 to determine whether an upgrade is needed. If the upgrade conditions are met, the cloud server 110 pushes the pre-made and stored software upgrade package to the vehicle 120 via the OTA platform. The vehicle 120 downloads, verifies, and secures the software upgrade package to complete the functional upgrade of the hardware in the vehicle 120.

[0039] For example, the cloud server includes a software upgrade package generation system, which generates software upgrade packages. The following section combines... Figure 2 The system architecture of the software upgrade package generation system is described.

[0040] Figure 2 This is a schematic diagram of the system architecture of a software upgrade package generation system provided in an embodiment of this application.

[0041] like Figure 2 As shown in system architecture 200, the software upgrade package generation system includes a mirror repository, a cloud-based configuration resource management center, an intelligent task scheduler, a dynamic assembly execution cluster, and a configuration resource caching module. The functions of each module are further explained below.

[0042] For example, an image repository is used to store baseline image files. Baseline image files provide a unified and streamlined runtime environment, which typically contains the minimum common dependencies required to generate software upgrade packages, including the operating system, environment configuration, core runtime network tools, and general script execution engine, but does not contain any specific hardware packaging logic or scripts.

[0043] For example, the cloud-based configuration resource management center provides storage, version management, access control, and distribution services for configuration resources. Specifically, the storage service of the cloud-based configuration resource management center is used to centrally store upgrade package generation scripts, compilation scripts, configuration scripts, and differentiated configuration files related to generating upgrade packages. The version management service is used to record versions, trace iterations, and lock versions for each configuration resource; for example, when the vehicle's ECU configuration is upgraded from version V1.0 to version V1.1, the system automatically retains historical versions, records modifications, and supports rolling back to older versions. The access control service manages access permissions to configuration resources to prevent malicious tampering that could lead to package creation errors, ensuring the security and standardization of scripts and configurations. The distribution service means that when building clusters or container instances that require package creation, the cloud-based configuration resource management center can accurately distribute the configuration resources corresponding to the hardware identifier and upgrade version to the temporary directories of cache nodes and container instances as needed.

[0044] Understandably, centralized cloud-based configuration resource management allows for unified code review, version locking, access control, and operation auditing of all packaged logic, meeting the security and traceability requirements of automotive-grade software production and ensuring the security and compliance control of vehicle software upgrades.

[0045] For example, the intelligent task scheduler is used to parse tasks, match configuration resources, manage container lifecycles, and coordinate the process of pulling configuration resources. Specifically, the intelligent task scheduler is used to generate software upgrade package requests, automatically disassemble task information, identify key parameters such as target hardware identifiers, upgrade versions, and vehicle platform, and sort out the execution requirements and priorities of the package creation task, transforming complex business tasks into scheduling instructions that the system can recognize and execute. After identifying key parameters, the intelligent task scheduler, based on the parsed hardware identifiers, upgrade versions, and other parameters, calls preset mapping relationships to accurately match the corresponding target configuration resources and package creation scripts from the cloud script configuration management center. The intelligent task scheduler can manage the entire lifecycle of container instances from creation and startup, package creation, task completion, and destruction and recycling. It starts container instances based on a baseline image, monitors the container status during package creation task execution, and automatically destroys containers and cleans up temporary directories after the package creation task is completed, realizing automatic creation, automatic release, and cyclical reuse of container resources.

[0046] For example, the dynamic assembly execution cluster consists of a container platform and container instances running on it. It is responsible for assembling and generating scripts and executing package creation tasks on demand. Specifically, according to the task scheduling instructions, the dynamic assembly execution cluster temporarily loads the upgrade package generation script and target configuration file required for the current package creation into the corresponding container instance. After the container instance is equipped with the script and configuration, it automatically runs the compilation, assembly, packaging, and signing processes according to the execution engine built into the base image, and completes the software upgrade package creation task. After the task is completed, the container is automatically destroyed and resources are released, waiting for the next on-demand scheduling.

[0047] For example, the configuration resource caching module is used to cache the acquired configuration resources. When a request for the same version of configuration resources is received later, the configuration resources can be retrieved directly from the cache, enabling rapid reuse of subsequent similar package-making tasks and improving the speed of acquiring configuration resources.

[0048] Figure 3 This is a schematic flowchart illustrating a method for generating a software upgrade package provided in an embodiment of this application.

[0049] For example, Figure 3 The generation method 300 shown can be executed by an electronic device, wherein the electronic device can be a server, for example, the electronic device can be... Figure 1 The cloud server 110 shown, or can be provided by Figure 2 The software upgrade package shown is generated by a system or can be executed by a processor or chip in an electronic device.

[0050] like Figure 3 As shown, the software upgrade package generation method 300 includes steps S310 to S340. The software upgrade package generation method shown in steps S310 to S340 will be described in detail below.

[0051] S310, a request to generate a software upgrade package has been detected.

[0052] The generated request includes the vehicle's target hardware identifier, which identifies the hardware in the vehicle to be upgraded. The hardware to be upgraded includes the ECU or the vehicle platform. The vehicle platform refers to a unified logical carrier that categorizes and aggregates a class of vehicle models that share a common underlying hardware architecture, electrical architecture, chassis architecture, software infrastructure, and adaptation specifications. It is a hierarchical grouping management unit for vehicle R&D, hardware adaptation, software version management, OTA packaging, and upgrade strategy control.

[0053] For example, software upgrade requests can be triggered in various ways, either manually by administrators on the cloud-based OTA management platform or automatically by the system upon detecting that certain conditions are met. For instance, after the ECU firmware, configuration scripts, and version parameters have been iterated, administrators can manually trigger a package creation command in the cloud-based OTA management backend, and proactively initiate a software upgrade package generation request containing the target hardware identifier, based on the target hardware's hardware identifier. Another example is that after the cloud-based configuration resource management center completes the review and release of the target hardware's scripts and configuration files, the system automatically triggers a software upgrade package generation request corresponding to the target hardware's identifier. Alternatively, the cloud server can set up gray-scale rollout and vehicle model version update plans, automatically triggering a software upgrade package generation request when a preset time is reached or batch release conditions are met.

[0054] For example, the software upgrade package generation system continuously listens for upgrade request events; when it hears a package generation request message, it obtains and identifies the request parameters of the software upgrade package generation request, including key parameters such as target hardware identifier, upgrade version, vehicle model platform, etc.

[0055] S320, obtain the baseline image file.

[0056] The baseline image file represents a common environment image file for different hardware, containing the minimum common dependencies required to generate a software upgrade package, including the operating system, kernel runtime, network tools, and general script execution engine.

[0057] The operating system refers to the underlying system kernel built into the base image. It serves as the foundation for the entire container instance's operation, providing process management, file management, user permissions, and basic system call capabilities, ensuring a unified and compatible underlying system environment for all container instances. The core runtime refers to the basic runtime dependencies, interpreters, and compilation components required to run the package generation program and parse the upgrade package generation scripts, ensuring that package generation scripts for various hardware types can be parsed and executed correctly. Network tools refer to the built-in basic network capability components in the base configuration file, used by container instances to pull remote configuration resources, access the cloud configuration resource management center and configuration resource caching module. These network tools have basic networking, file transfer, and API call capabilities, supporting remote acquisition and interaction of configuration resources. The general script execution engine is the unified script parser and executor built into the base image, used to identify and run upgrade package generation scripts of various formats.

[0058] The aforementioned general-purpose script execution engine is designed to support multiple scripting languages. The scripts in the cloud script library can be in various formats such as Shell scripts (scripts written using terminal commands), Python scripts (scripts written using the Python programming language), and Makefile scripts (a special script format used for compiling, building, and running projects). The general-purpose script execution engine automatically selects the corresponding interpreter to execute based on the script file extension or metadata.

[0059] It should be noted that the baseline image provides a general underlying environment and execution capabilities, encapsulating the minimum basic dependency environment needed for all hardware to create packages. It does not contain any specific software upgrade package creation logic or scripts, ensuring that the baseline image can be adapted to the packaging process of various hardware without the need to create separate dedicated images for different hardware.

[0060] For example, a baseline image file is stored in an image repository. The baseline image file is retrieved from the image repository and combined with the target hardware identifier in the upgrade request to generate a software upgrade package.

[0061] S330 obtains the target configuration resources corresponding to the target hardware identifier based on the target hardware identifier.

[0062] The target configuration resources include the target configuration file and the upgrade package generation script. The target configuration file includes the parameter configuration file and the resource file.

[0063] The upgrade package generation script is an executable program script that generates software upgrade packages. It is the core execution flow file for package creation and typically defines complete package creation steps, such as firmware splicing, partition packaging, format encapsulation, hash calculation, digital signature, compression packaging, and other process instructions. It is called and run by the general script execution engine in the image and automatically completes the creation of the software upgrade package according to the preset process.

[0064] The parameter configuration file represents the hardware and model parameter configuration of the vehicle. It is used to provide personalized adaptation parameters for the upgrade package generation script, so that the same package generation script can generate upgrade packages adapted to different hardware and different versions according to different configurations. The parameter configuration file includes hardware identification adaptation parameters, ECU partition address, compilation parameters, version information, upgrade strategy and verification rules, etc.

[0065] Resource files represent the basic static resources required during the package creation process. They are used by the upgrade package generation script to call, assemble, and encapsulate them into the software upgrade package. The contents of resource files include, for example, the underlying firmware binary file, icon resources, and version baseline file. Among them, the underlying firmware binary file is a machine code file that the ECU hardware can directly recognize and run, used for subsequent vehicle-side flashing to replace the old firmware; icon resources are images, icons, and user interface (UI) resource files used by the vehicle's central control, instrument panel, and other cockpit devices. These are static interface materials that are packaged along with the firmware during package creation and replace the vehicle's display interface icons and skin resources after the upgrade; the version baseline file is the standard version benchmark file for the entire vehicle or each ECU, used to verify the legality of the baseline version, determine upgrade compatibility, and lock the version iteration chain during package creation.

[0066] The method for determining the target configuration resources is explained in further detail below: Specifically, the target mapping relationship is obtained; based on the target hardware identifier and the target mapping relationship, the target configuration resource is obtained; wherein, the target mapping relationship includes a first mapping relationship or a second mapping relationship, the first mapping relationship is used to represent the mapping relationship between the hardware identifier and the configuration resource, and the second mapping relationship is used to represent the mapping relationship between the first parameter and the configuration resource, the first parameter includes the hardware identifier and the upgrade version.

[0067] For example, the upgrade package generation scripts and configuration files required for each piece of vehicle hardware are pre-determined; each configuration resource is associated with its corresponding hardware identifier, and this association is the target mapping relationship; the target mapping relationship is stored in a cloud configuration resource management center according to a predefined directory structure. After obtaining the base image file, the server retrieves the target configuration resources from the cloud configuration resource management center based on the target mapping relationship and the target mapping relationship contained in the generation request.

[0068] Understandably, this application determines the target configuration resource based on the target mapping relationship and the target hardware identifier, ensuring that when determining the target configuration resource, there is no need for manual retrieval and matching of configuration files one by one, thus simplifying the process of finding and locating configuration resources. In addition, the unified mapping relationship facilitates the version maintenance, iterative updates, and rapid retrieval of configuration resources, reducing time consumption and error rate compared to manual configuration.

[0069] For example, the target mapping relationship includes two types of mapping relationships: the first mapping relationship represents the mapping relationship between hardware identifier and configuration resource, and the second mapping relationship represents the mapping relationship between the first parameter (hardware identifier and upgrade version) and configuration resource.

[0070] For example, since the target mapping relationship includes a second mapping relationship, the same hardware identifier corresponds to multiple versions of configuration resources. Therefore, the cloud configuration resource management center can realize version control of configuration resources, thereby supporting A / B testing, canary release, or version rollback of upgrade packages.

[0071] A / B testing involves simultaneously providing two different versions of the upgrade package, A and B, to two batches of vehicles, randomly or selectively, for parallel testing and comparison. By analyzing actual vehicle data, stability, power consumption, user experience, and failure rate are compared to determine the upgrade package with the better practical performance. Gray-scale release refers to the gradual rollout of software upgrade packages, not a one-time full rollout to all vehicles, but rather a phased rollout in small batches, observing stability, failures, lag, and errors. If no issues are found, the rollout is gradually expanded until full coverage, thus controlling risk and preventing problems with the new version from causing widespread vehicle malfunctions. Version rollback refers to downgrading to the previous stable version of the upgrade package if a vehicle experiences a failure, incompatibility, or functional malfunction after upgrading to a new version. Version rollback includes automatic rollback and background rollback. Automatic rollback occurs when upgrade detection fails, verification fails, or startup fails, automatically reverting to the stable version. Background rollback involves issuing instructions through the operations platform to roll back to the stable version in batches.

[0072] It's important to note that in automotive OTA (Over-The-Air) package creation scenarios, there are both general scenarios where configuration matching can be achieved solely based on hardware identifiers, and version-specific scenarios where matching requires combining both the hardware identifier and the upgrade version. For example, for hardware without version differences, regardless of software version iterations, the hardware adaptation parameters, partition configurations, and basic package creation rules remain completely unchanged. The configuration can be determined based on the hardware identifier without needing to input version parameters. Therefore, the first mapping relationship can determine the configuration resources without requiring redundant checks using version parameters. However, for hardware with version differences, even hardware with the same hardware identifier may experience changes in partitioning strategies, compilation parameter adjustments, adaptation rule revisions, and encryption signature policy updates during version updates. These changes cannot be distinguished solely by the hardware identifier. Therefore, it's necessary to combine the hardware identifier and the upgrade version to form the first parameter, and then use the second mapping relationship to accurately match the configuration resources under that upgrade version, avoiding the mixing of old and new version configuration resources.

[0073] In one implementation, if the target mapping relationship is a first mapping relationship, the target configuration resource is determined based on the target hardware identifier and the first mapping relationship; if the target mapping relationship is a second mapping relationship, the upgrade version of the hardware to be upgraded is obtained based on the software upgrade package generation request; and the target configuration resource is determined based on the target hardware identifier, the upgrade version, and the second mapping relationship.

[0074] For example, when the hardware to be upgraded is hardware without version differences, the target mapping relationship is determined as the first mapping relationship; the target configuration resource is obtained according to the target hardware identifier and the first mapping relationship; when the hardware to be upgraded is hardware with version differences, the target mapping relationship is determined as the second mapping relationship; the upgrade version is obtained from the software upgrade package generation request; the target configuration resource is determined according to the target hardware identifier, the upgrade version and the second mapping relationship.

[0075] For example, for hardware A in a vehicle, during a version upgrade, the hardware structure, storage partition, underlying driver, and hardware adaptation parameters remain fixed. In the initial version V1.0, the configuration resource matched using the first mapping relationship is Cfg-A01. Combined with the V1.0 air conditioning firmware, a V1.0 upgrade package is generated, enabling basic air conditioning control on the vehicle side after the upgrade. In the subsequent feature iteration upgrade V1.1, only the air conditioning application firmware is updated (optimizing temperature control logic and adding automatic constant temperature function). The configuration resource Cfg-A01 remains unchanged, the base image remains unchanged, and the mapping relationship remains unchanged. The same Cfg-A01 is still directly retrieved through the first mapping, and combined with the new V1.1 firmware, a V1.1 version upgrade package is generated. For hardware B in the initial V1.0 stage, the configuration resource obtained by matching the hardware identifier and version through the second mapping relationship is Cfg-B01-V1.0. Combined with the V1.0 firmware, an upgrade package is generated, and the vehicle side functions normally. After the version was upgraded to V2.0, the UI resource configuration was updated due to changes in both the firmware and configuration resources. At this time, the old version's configuration resources could no longer be used. Therefore, the configuration resource Cfg-B01-V2.0 was accurately retrieved by the hardware identifier and V2.0 through the second mapping, and the new firmware of V2.0 was used to generate the V2.0 upgrade package.

[0076] It should be noted that the above is a schematic illustration of the first mapping relationship, the second mapping relationship, the hardware, and the corresponding configuration resources of the hardware, used to determine the target configuration resources in two cases: when there are version differences and when there are no version differences. This application does not specifically limit the specific mapping relationship, hardware, and configuration resources.

[0077] In the embodiments of this application, if the target mapping relationship is a first mapping relationship, the target configuration resource is obtained based on the target hardware identifier and the first mapping relationship; if the target mapping relationship is a second mapping relationship, the target configuration resource is obtained based on the target hardware identifier, the upgrade version, and the second mapping relationship. This ensures that this application can not only quickly match configuration resources through hardware identifiers, but also achieve differentiated adaptation of configuration resources under different upgrade versions by combining hardware identifiers and upgrade versions, adapting to packaging scenarios with multiple version iterations of the same hardware.

[0078] It should be noted that the target configuration resource is obtained from the cloud-based configuration resource management center of the server. During the acquisition process, the configuration resource may be corrupted, tampered with, or of unreliable origin, potentially causing the software upgrade package generation to fail. Therefore, this application verifies the software upgrade package during the acquisition of the target configuration resource to ensure that accurate configuration resources are obtained.

[0079] In one implementation, determining the target configuration resource corresponding to the target hardware identifier includes: determining the first configuration resource corresponding to the target hardware identifier in the target mapping relationship based on the target hardware identifier and the target mapping relationship; verifying the first configuration resource; and if the first configuration resource passes the verification, determining the first configuration resource as the target configuration resource.

[0080] Understandably, the configuration resource directly obtained based on the target mapping relationship is identified as the first configuration resource. This allows for rapid location and accurate retrieval of configuration resources based on preset mapping rules, eliminating the tedious processes of manual screening, path searching, and manual matching, thus improving the response speed of obtaining the first configuration resource. Verifying the first configuration resource, and confirming it as the target configuration resource if it passes verification, avoids using incorrect configuration resources to generate software upgrade packages, reducing the risk of package creation failures or subsequent vehicle upgrade malfunctions due to incorrect configuration resources, thereby ensuring the accuracy of target configuration resource retrieval.

[0081] Optionally, if the first configuration resource verification fails, the number of times the first configuration resource verification fails is determined. If the number of times the first configuration resource verification fails is less than or equal to a preset number (e.g., 3 times), the first configuration resource is re-determined based on the target hardware identifier and the target mapping relationship. If the number of times the first configuration resource verification fails is greater than the preset number, a prompt message is output, indicating that the target configuration resource acquisition is abnormal.

[0082] In the embodiments of this application, by limiting the number of times the first configuration resource can be acquired, problems such as link anomalies or missing or corrupted configuration resources can be avoided, preventing the system from retriesing indefinitely, consuming cluster computing power, network bandwidth, and cache storage resources, and preventing process blocking. When the number of retries exceeds a preset number, automatic acquisition stops and a prompt message is output to ensure that abnormal states can be reported in a timely manner, facilitating rapid location of the cause of the fault.

[0083] The following is a further explanation of the verification process for the first configuration resource: In one implementation, verifying the first configuration resource includes: querying the first verification value and the first digital signature corresponding to the target hardware identifier based on the target mapping relationship; generating a second verification value corresponding to the first configuration resource, and verifying the legality of the first digital signature; if the first verification value and the second verification value are consistent, and the legality verification of the first digital signature is passed, then it is determined that the first configuration resource has passed the verification.

[0084] The target mapping relationship also includes the verification value and digital signature corresponding to the hardware identifier; the verification value is used to verify the integrity of the configuration resources, and the digital signature is used to verify the legality of the configuration resources.

[0085] For example, when publishing configuration resources, the cloud-based configuration resource management center performs a hash operation on the original complete configuration resource to obtain a verification value (i.e., a standard hash value), which is then bound and stored with a hardware identifier. Subsequently, when retrieving a target configuration resource, the center obtains the first configuration resource corresponding to the target hardware identifier from the target mapping relationship, along with the standard hash value (first verification value) corresponding to the target hardware identifier. The same hash algorithm is used to calculate the real-time hash value (second verification value) of the first configuration resource. The integrity of the first configuration resource is verified by comparing the first verification value and the second verification value. If the first verification value and the second verification value are consistent, it is determined that the target configuration resource is consistent with the first configuration resource, meaning that the configuration resource was transmitted intact without loss or tampering, and the integrity verification of the first configuration resource passes.

[0086] For example, the configuration resource is pre-encrypted and signed using a private key to generate a digital signature, which is then bound to the hardware identifier and stored in a mapping relationship. When acquiring the target configuration resource, the first digital signature corresponding to the target hardware identifier is obtained from the target mapping relationship; the digital signature is decrypted and verified using a legitimate public key on the local end; simultaneously, a digest of the currently acquired configuration resource is regenerated and compared with the decrypted digest. If the comparison matches, it indicates that the configuration resource source is legitimate, the publishing entity is trustworthy, and the content has not been tampered with, and the digital signature verification passes; if the comparison does not match, it indicates that the resource source is illegal, it has been tampered with midway, or the signature has expired, and the digital signature verification fails.

[0087] In the embodiments of this application, a second verification value of the first configuration resource is compared with a first verification value obtained from a target mapping query. If the first verification value matches the second verification value, it indicates that the first configuration resource and the target configuration resource are consistent, meaning that the target configuration resource has not been lost, damaged, or tampered with during transmission, ensuring the integrity of the first configuration resource. On the other hand, the digital signature of the configuration resource is verified to ensure the legitimacy of the first configuration resource. This application uses a dual verification mechanism to verify both the integrity and security of the configuration resource. If both dimensions pass verification, the first configuration resource is determined as the target configuration resource, ensuring that a complete and legitimate target configuration resource can be obtained. This effectively avoids problems such as upgrade package generation failure, firmware adaptation anomalies, and vehicle upgrade malfunctions caused by damaged, tampered, or untrusted sources of configuration resources.

[0088] S340 generates a software upgrade package corresponding to the target hardware identifier based on the baseline image file and the target configuration file.

[0089] Specifically, generating the software upgrade package corresponding to the target hardware identifier includes: generating a container instance based on the baseline image file; writing the target configuration file and the upgrade package generation script into the temporary working directory of the container instance; and generating the software upgrade package by calling and running the upgrade package generation script in the temporary working directory through the script execution engine in the baseline image file.

[0090] Container instances provide isolated, independent running processes and execution environments to handle single software upgrade package generation tasks, achieving environment uniformity, task isolation, and on-demand resource reuse. Each software upgrade package upgrade process corresponds to an independent container instance, and the upgrade package generation scripts and configuration resources in different container instances are isolated.

[0091] The temporary working directory is a separate temporary folder or directory space created inside the container after the container instance is created. It serves as a dedicated temporary storage space for the current software upgrade package task. The temporary working directory primarily stores the content required to generate the software upgrade package, including target configuration resources, the ECU firmware file to be packaged, hash checksums, files generated during the signing process, log files, and the software upgrade package file.

[0092] For example, the intelligent task scheduler instantiates and creates container instances based on a baseline image and using the baseline image as a template. The container instance includes the complete runtime environment of the baseline image, including: operating system, core runtime, network tools, and general script execution engine.

[0093] For example, after generating the container instance, the target configuration file and the upgrade package generation script are written to the container instance's temporary working directory. The script execution engine locates and loads the upgrade package generation script in the temporary working directory, and parses and runs the upgrade package generation script logic line by line, including reading the configuration file, loading firmware and resource files, and performing operations such as partitioning, packaging, and compression. Before the upgrade package generation script has finished executing, a standard format software upgrade package is generated in the temporary working directory.

[0094] In the embodiments of this application, isolated container instances are generated based on a baseline image, providing independent running processes and execution environments with consistent environments for different upgrade package generation tasks. This avoids mutual interference between build environments while ensuring the parallel execution capability of generating software upgrade packages. By writing the target configuration file and script into the temporary working directory of the container instance and running the upgrade package generation script based on the script execution engine built into the baseline image file, it is ensured that the software upgrade package can be generated according to the generation process planned in the software upgrade package generation script. There is no need to configure a running environment for build tasks with different hardware identifiers, which greatly shortens the time spent on environment preparation and switching.

[0095] Optionally, the generation method further includes: after generating the software upgrade package corresponding to the hardware identifier, deleting the temporary working directory and the target configuration resources in the temporary working directory in the container instance.

[0096] It should be noted that since a container instance is instantiated from a base image and is for a single package generation task, the contents of the container instance are only related to the current software upgrade package. Deleting the container instance and its contents will not affect the base image or the generation process of subsequent software upgrade packages.

[0097] In the embodiments of this application, after generating the software upgrade package, the temporary working directory and the target configuration resources in the temporary working directory in the container instance are promptly deleted. This ensures that temporary data and differentiated configuration content generated by a single package generation task can be cleared in a timely manner, avoiding the waste of resources caused by temporary files occupying storage space for a long time. It also ensures that the system resources occupied by a single package generation task can be quickly recovered and reused, facilitating the rapid scheduling of the next round of upgrade package generation tasks.

[0098] In one implementation, the target configuration resource is stored in a cache area; if a request to generate a software update package for the target hardware identifier is detected again, the target configuration resource is retrieved from the cache area.

[0099] For example, target configuration resources are cached in a cloud-based configuration resource caching module. When a software upgrade package generation request for the same target hardware identifier is received again, the target configuration resources can be quickly retrieved directly from the cache area without having to repeat the process of searching, obtaining, and verifying through mapping relationships. Because this application can reuse cached target configuration resources, it can shorten the configuration resource preparation cycle, reduce network bandwidth consumption, improve the response speed of upgrade package generation requests, and effectively improve the batch generation efficiency and concurrent processing capability of software upgrade packages.

[0100] It's important to note that the container's temporary working directory resides inside the container, is dedicated to a single task, is destroyed after use, and only stores the configuration resources, firmware, and intermediate files corresponding to the current upgrade package. The configuration resource cache area is globally shared in the cloud, cached long-term, reused across multiple tasks, and only caches target configuration resources, not firmware. Because the cache area is independent of the container instance's temporary working directory and base image repository, it provides a shared cache storage for target configuration resources that can be reused across instances for all package creation tasks. Therefore, deleting a container instance and its related content will not affect the configuration resources stored in the cache area.

[0101] In one implementation, configuration resources in the cache area are cleaned up based on their access time and frequency. For example, if a configuration resource in the cache area has a recent access time and a high access frequency, the configuration resource is retained; if a configuration resource in the cache area has a long access time interval and a low access frequency, the configuration resource is deleted to avoid resource redundancy.

[0102] Optionally, when the configuration resource bound to the target mapping relationship is updated, a change data fragment is obtained. The change data fragment is a data fragment obtained by differential calculation between the original configuration resource before the update and the updated configuration resource. Based on the change data fragment and the target configuration resource in the cache area, the updated target configuration resource is generated.

[0103] For example, the process of obtaining changed data fragments through differential calculation is illustrated as follows: When the configuration resource bound to the target mapping relationship undergoes a version update, the original version of the configuration resource before the update and the updated version of the configuration resource are divided into blocks of equal size according to a fixed byte size, resulting in data blocks of equal size. A hash digest is calculated for each data block to obtain its hash value. An index table is created using the hash values ​​of each database in the original version of the configuration resource. The hash value of the updated version is then searched and matched against the index table. If a match is successful, it is determined that the content of the data block is completely consistent, and the content of the data block has not changed during the version update. If a match fails, it is determined that the content of the data block has changed. The data blocks with changed content are concatenated in the original file address order to form the changed data fragment corresponding to the version update.

[0104] For example, after obtaining the changed data fragment, the starting offset address, data block length, and data block sequence number of the changed data block are recorded to facilitate subsequent restoration and splicing. Based on the changed data fragment and the target configuration resource in the cache area, according to the block segmentation rules and offset addresses, data blocks whose content has not changed reuse data blocks in the cached target configuration resource, and data blocks whose content has changed in the cache area are replaced with changed data fragments. The unchanged data blocks in the cache area are spliced ​​with the changed data fragments, and verified to synthesize a complete configuration resource, realizing differential incremental upgrades and significantly reducing the upgrade package size and transmission traffic.

[0105] In the embodiments of this application, a differential calculation method is used to obtain the changed data fragments corresponding to the version update. This eliminates the need to re-fetch the complete configuration resource file, reducing the amount of data transmitted over the network and minimizing transmission latency caused by repeated downloads of large files. The updated target configuration resource is generated by merging and recombining the original target configuration resource stored in the cache area with the changed data fragments, without discarding the original cached resources. This allows for full reuse of existing cached data and significantly shortens the configuration resource update readiness time. Compared to the full update mode during version updates, the incremental update method used in this application only synchronizes and merges localized changes, resulting in faster configuration updates and lower resource overhead. This improves the overall efficiency of software upgrade package generation from the perspectives of configuration version iteration and cache reuse.

[0106] In the above embodiments, when a software upgrade package generation request is detected, the target configuration resource is determined based on the target hardware identifier in the generation request; the software upgrade package is then generated based on the target configuration resource and the base image file. Compared to related technologies that create corresponding image files for each type of hardware in the vehicle, resulting in a large number and size of image files and low efficiency in generating software upgrade packages, this application addresses this issue by encapsulating a common environment image file for different hardware into a base image file; the software upgrade package is generated based on the common base image file and the target configuration file corresponding to the target hardware identifier. Since this application does not require building separate environments for different hardware, it avoids the cumbersome processes of repeated system deployment, dependency installation, and environment configuration before generating the software upgrade package, reducing the maintenance cost of image files and the time spent on environment preparation, thereby improving the efficiency of software upgrade package generation.

[0107] Figure 4 This is a schematic flowchart illustrating another method for generating a software upgrade package provided in this application embodiment.

[0108] For example, Figure 4 The generation method 400 shown can be executed by an electronic device, wherein the electronic device can be a server, for example, the electronic device can be... Figure 1The cloud server 110 shown, or can be provided by Figure 2 The software upgrade package shown is generated by a system or can be executed by a processor or chip in an electronic device.

[0109] like Figure 4 As shown, the software upgrade package generation method 400 includes S401 to S411. The software upgrade package generation method shown in S401 to S411 will be described in detail below.

[0110] S401, A request to generate a software upgrade package has been detected.

[0111] For example, the request may include a target hardware identifier for the vehicle, which identifies the hardware in the vehicle that needs to be upgraded.

[0112] S402, determine the target hardware identifier based on the generation request.

[0113] For example, the software upgrade package generation system continuously listens for upgrade request events; when it hears a package generation request message, it obtains and identifies the request parameters, including key parameters such as the target hardware identifier, upgrade version, and vehicle platform.

[0114] Alternatively, the implementation methods of S401 and S402 can be found in [reference needed]. Figure 3 The relevant descriptions of S310 will not be repeated here.

[0115] S403, Obtain the baseline image file.

[0116] For example, a baseline image file is used to represent an environment image file common to different hardware, containing the minimum common dependencies required to generate a software upgrade package, including the operating system, kernel runtime, network tools, and a common script execution engine.

[0117] Alternatively, the implementation of S403 can be found in [reference needed]. Figure 3 The relevant descriptions of the S320 will not be repeated here.

[0118] S404, determine the first configuration resource based on the target hardware identifier and the target mapping relationship.

[0119] For example, the target mapping relationship is obtained; the target configuration resource is obtained based on the target hardware identifier and the target mapping relationship; wherein, the target mapping relationship includes a first mapping relationship or a second mapping relationship, the first mapping relationship is used to represent the mapping relationship between the hardware identifier and the configuration resource, and the second mapping relationship is used to represent the mapping relationship between the first parameter and the configuration resource, the first parameter includes the hardware identifier and the upgrade version.

[0120] S405 verifies the first configuration resource.

[0121] For example, query the first verification value and the first digital signature corresponding to the target hardware identifier; generate the second verification value corresponding to the first configuration resource, and verify the legality of the first digital signature; if the first verification value and the second verification value are consistent, and the legality verification of the first digital signature is passed, then it is determined that the first configuration resource verification is passed.

[0122] S406, Has the first configuration resource been verified?

[0123] For example, it is determined whether the first configuration resource passes the verification; if the first configuration resource passes the verification, the first configuration resource is determined as the target configuration resource; if the first configuration resource fails the verification, the first configuration resource is re-determined based on the target hardware identifier and the target mapping relationship.

[0124] S407, the first configuration resource is determined as the target configuration resource.

[0125] For example, if the first configuration resource passes the verification, it means that the integrity and security of the first configuration resource have both passed the verification. Therefore, the first configuration resource is determined as the target configuration resource.

[0126] Alternatively, the implementation methods of S404 to S407 can be found in [reference needed]. Figure 3 The relevant descriptions of the S330 will not be repeated here.

[0127] S408 generates a container instance based on a baseline image file.

[0128] For example, based on a baseline image, a container instance is instantiated using the baseline image as a template. The container instance includes the complete runtime environment of the baseline image. The container instance provides isolated, independent running processes and execution environments, carrying out a single software upgrade package generation task, achieving environment unification, task isolation, and on-demand resource reuse.

[0129] S409, Write the target configuration resource to the container instance.

[0130] For example, after generating the container instance, the target configuration file and the upgrade package generation script are written to the container instance's temporary working directory to ensure that the container instance includes the files required for the software upgrade package generation process.

[0131] The S410 uses the script execution engine of the base image file to call the upgrade package generation script and generate the software upgrade package.

[0132] For example, the script execution engine locates and loads the upgrade package generation script in the temporary working directory, and parses and runs the upgrade package generation script logic line by line, including reading configuration files, loading firmware and resource files, and performing operations such as partitioning, packaging, and compression. Before the upgrade package generation script finishes executing, a standard format software upgrade package is generated in the temporary working directory.

[0133] S411, Delete the target configuration resource and container instance in the container instance.

[0134] For example, after generating the software upgrade package, promptly delete the temporary working directory and the target configuration resources within it in the container instance. This ensures that temporary data and differentiated configuration content generated during a single package generation task are cleared in a timely manner, preventing temporary files from occupying storage space for extended periods and wasting resources.

[0135] Alternatively, the implementation methods of S408 to S411 can be found in [reference needed]. Figure 3 The relevant descriptions of the S340 are not repeated here.

[0136] In the embodiments of this application, by separating variable package creation configuration resources from a standardized runtime environment, software upgrade packages for various heterogeneous hardware can be generated on a single general-purpose base image by dynamically pulling and executing target configuration resources. Since only one or a few base images need to be maintained, the data storage volume of the image repository is reduced, thereby lowering the storage, management, and maintenance costs of the image repository. Because script modification, testing, and release are independent of the base image, rapid iteration and deployment of package creation scripts can be achieved, effectively shortening the change cycle of the software upgrade package generation process. Furthermore, compared to different image files corresponding to different hardware, the highly unified base image layer of this application allows for caching and reuse of the base image between different package creation tasks. Therefore, container instance startup speed is faster, network transmission load is lighter, and package creation efficiency is effectively improved.

[0137] Figure 5 This is a schematic diagram of a software upgrade package generation device provided in an embodiment of this application.

[0138] For example, such as Figure 5 As shown, the software upgrade package generation device 500 includes: The acquisition module 510 is used to detect the software upgrade package generation request, acquire the base image file, and the generation request includes the target hardware identifier of the vehicle. The target hardware identifier is used to identify the hardware to be upgraded in the vehicle. The base image file is used to represent the environment image file that is common to different hardware. The processing module 520 is used to obtain the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier, the target configuration resource including the target configuration file; and to generate the software upgrade package corresponding to the target hardware identifier based on the base image file and the target configuration file.

[0139] Optionally, as an embodiment, the processing module 520 is specifically used to: generate a container instance based on a base image file, the container instance being used to provide mutually isolated independent running processes and execution environments; write the target configuration file and script into the temporary working directory of the container instance; and call and run the upgrade package generation script in the temporary working directory through the script execution engine in the base image file to generate a software upgrade package.

[0140] Optionally, as an embodiment, the acquisition module 510 is further configured to: acquire a target mapping relationship, wherein the target mapping relationship includes a first mapping relationship or a second mapping relationship, the first mapping relationship being used to represent the mapping relationship between hardware identifier and configuration resource, and the second mapping relationship being used to represent the mapping relationship between a first parameter and configuration resource, wherein the first parameter includes hardware identifier and upgrade version; The processing module 520 is specifically used to: obtain the target configuration resources based on the target hardware identifier and the target mapping relationship.

[0141] Optionally, as an embodiment, the processing module 520 is specifically used for: if the target mapping relationship is a first mapping relationship, determining the target configuration resource based on the target hardware identifier and the first mapping relationship; if the target mapping relationship is a second mapping relationship, obtaining the upgrade version of the hardware to be upgraded based on the software upgrade package generation request; and determining the target configuration resource based on the target hardware identifier, the upgrade version, and the second mapping relationship.

[0142] Optionally, as an embodiment, the processing module 520 is specifically used to: determine the first configuration resource corresponding to the target hardware identifier in the target mapping relationship based on the target hardware identifier and the target mapping relationship; verify the first configuration resource; if the first configuration resource passes the verification, determine the first configuration resource as the target configuration resource.

[0143] Optionally, as an embodiment, the processing module 520 is specifically used to: query the first verification value and the first digital signature corresponding to the target hardware identifier based on the target mapping relationship; generate the second verification value corresponding to the first configuration resource, and perform legality verification on the first digital signature; if the first verification value and the second verification value are consistent, and the legality verification of the first digital signature is passed, then it is determined that the first configuration resource verification is passed.

[0144] Optionally, as an embodiment, the processing module 520 is further configured to: after generating the software upgrade package corresponding to the hardware identifier, delete the temporary working directory and the target configuration resources in the temporary working directory in the container instance.

[0145] Optionally, as an embodiment, the processing module 520 is specifically used to: store the target configuration resource in the cache area; and if a request to generate a software update package for the target hardware identifier is detected again, retrieve the target configuration resource from the cache area.

[0146] Optionally, as an embodiment, the processing module 520 is further configured to: when the configuration resource bound to the target mapping relationship undergoes a version update, obtain a changed data fragment, wherein the changed data fragment is a data fragment obtained by performing differential calculation on the original configuration resource before the update and the updated configuration resource; and generate an updated target configuration resource based on the changed data fragment and the target configuration resource in the cache area.

[0147] It should be noted that the control devices of the aforementioned vehicles are embodied in the form of functional units. The term "module" here can be implemented in software and / or hardware, without specific limitations.

[0148] For example, a "module" can be a software program, hardware circuit, or a combination of both that implements the above functions. Hardware circuits may include application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors) and memory for executing one or more software or firmware programs, combined logic circuits, and / or other suitable components that support the described functions.

[0149] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0150] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0151] For example, electronic device 600 includes: processor 610, memory 620 and executable program code 630.

[0152] For example, electronic device 600 can be a server (e.g., a cloud server). Electronic device 600 includes one or more processors 610, which can support the generation method of software upgrade packages in the method embodiments of electronic device 600. Processor 610 can be a general-purpose processor or a special-purpose processor. For example, processor 610 can be a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gates, transistor logic devices, or discrete hardware components.

[0153] For example, processor 610 can be used to control electronic device 600, execute software programs, and process data from the software programs. Electronic device 600 may also include a communication unit for receiving and transmitting signals.

[0154] For example, the electronic device 600 may include one or more memories 620, on which executable program code 630 is stored. The executable program code 630 can be run by the processor 610 to generate instructions, causing the processor 610 to execute the software upgrade package generation method described in the above method embodiments according to the instructions.

[0155] Optionally, the memory 620 may also store data. Optionally, the processor 610 may also read data stored in the memory 620, which may be stored at the same memory address as the executable program code 630, or the data may be stored at a different memory address than the executable program code 630.

[0156] For example, the processor 610 and memory 620 can be configured separately or integrated together, for example, integrated on a system-on-a-chip of the terminal device.

[0157] For example, the memory 620 can be used to store related programs of the software upgrade package generation method provided in the embodiments of this application. The processor 610 can be used to call the executable program code 630 stored in the memory 620 when controlling the electronic device to execute the software upgrade package generation method of the embodiments of this application. For example, a software upgrade package generation request is detected, the generation request includes a target hardware identifier of the vehicle, the target hardware identifier is used to identify the hardware to be upgraded in the vehicle; a reference image file is obtained, the reference image file is used to represent an environment image file common to different hardware; based on the target hardware identifier, a target configuration resource corresponding to the target hardware identifier is obtained, the target configuration resource includes a target configuration file; based on the reference image file and the target configuration file, a software upgrade package corresponding to the target hardware identifier is generated.

[0158] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for generating a software upgrade package according to any of the foregoing embodiments.

[0159] The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), Compact Disc Read-Only Memory (CD-ROMs), microdrives, and magneto-optical disks, read-only memory (ROMs), random access memory (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), dynamic random access memory (DRAMs), video random access memory (VRAMs), flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0160] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement a method for generating a software upgrade package as described in the above embodiments.

[0161] In addition, the electronic device provided in the embodiments of this application may specifically be a chip, component or module. The electronic device may include a connected processor and a memory. The memory is used to store instructions, and the processor can call and execute the instructions to make the chip execute a software upgrade package generation method in the above embodiments.

[0162] The electronic devices, computer-readable storage media, computer program products, or chips provided in this application are all used to execute the corresponding software upgrade package generation method provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding software upgrade package generation method provided above, and will not be repeated here.

[0163] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0164] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0165] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating a software upgrade package, characterized in that, The generation method includes: A software upgrade package generation request was detected. The generation request includes a target hardware identifier for the vehicle, which identifies the hardware in the vehicle to be upgraded. Obtain a baseline image file, which represents an environment image file common to different hardware; Based on the target hardware identifier, the target configuration resource corresponding to the target hardware identifier is obtained, and the target configuration resource includes the target configuration file; Based on the baseline image file and the target configuration file, a software upgrade package corresponding to the target hardware identifier is generated.

2. The generation method according to claim 1, characterized in that, The target configuration resources also include upgrade package generation scripts; The step of generating a software upgrade package corresponding to the target hardware identifier based on the baseline image file and the target configuration file includes: Based on the baseline image file, a container instance is generated, which is used to provide isolated, independent running processes and execution environments. Write the target configuration file and the upgrade package generation script into the temporary working directory of the container instance; The software upgrade package is generated by calling and running the upgrade package generation script in the temporary working directory through the script execution engine in the base image file.

3. The generation method according to claim 1, characterized in that, The generation method further includes: Obtain the target mapping relationship; The step of obtaining the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier includes: Based on the target hardware identifier and the target mapping relationship, the target configuration resources are obtained; The target mapping relationship includes a first mapping relationship or a second mapping relationship. The first mapping relationship represents the mapping relationship between hardware identifiers and configuration resources, and the second mapping relationship represents the mapping relationship between a first parameter and configuration resources. The first parameter includes hardware identifiers and upgrade versions.

4. The generation method according to claim 3, characterized in that, The step of obtaining the target configuration resource based on the target hardware identifier and the target mapping relationship includes: If the target mapping relationship is the first mapping relationship, the target configuration resource is determined based on the target hardware identifier and the first mapping relationship; If the target mapping relationship is the second mapping relationship, the upgrade version of the hardware to be upgraded is obtained based on the software upgrade package generation request; the target configuration resource is determined based on the target hardware identifier, the upgrade version and the second mapping relationship.

5. The generation method according to claim 3, characterized in that, The step of determining the target configuration resource corresponding to the target hardware identifier based on the target hardware identifier and the target mapping relationship includes: Based on the target hardware identifier and the target mapping relationship, a first configuration resource corresponding to the target hardware identifier is determined in the target mapping relationship; Verify the first configured resource; If the first configuration resource passes the verification, the first configuration resource is determined as the target configuration resource.

6. The generation method according to claim 5, characterized in that, The target mapping relationship also includes the verification value and digital signature corresponding to the hardware identifier; the verification of the first configuration resource includes: Based on the target mapping relationship, query the first verification value and the first digital signature corresponding to the target hardware identifier; Generate a second verification value corresponding to the first configuration resource, and verify the legality of the first digital signature; If the first verification value is consistent with the second verification value, and the first digital signature passes the validity verification, then the first configuration resource verification is determined to be successful.

7. The generation method according to any one of claims 1 to 6, characterized in that, The generation method further includes: After generating the software upgrade package corresponding to the hardware identifier, delete the temporary working directory in the container instance and the target configuration resources in the temporary working directory.

8. The generation method according to any one of claims 1 to 6, characterized in that, The generation method further includes: The target configuration resource is stored in the cache area; If a request to generate a software update package for the target hardware identifier is detected again, the target configuration resource is retrieved from the cache area.

9. The generation method according to claim 8, characterized in that, The generation method further includes: When the configuration resource bound to the target mapping relationship is updated, the change data fragment is obtained. The change data fragment is a data fragment obtained by performing differential calculation on the original configuration resource before the update and the configuration resource after the update. Based on the changed data fragment and the target configuration resource in the cache area, an updated target configuration resource is generated.

10. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the electronic device to perform the generation method according to any one of claims 1 to 9.

Images