Software intermediate product acquisition method, electronic device, and storage medium

Abstract

The application provides a software intermediate product acquisition method, an electronic device and a storage medium. The method is applied to the field of software integration of a vehicle. The method comprises the following steps: acquiring a vehicle type, a software version and a product identifier of a software intermediate product; determining a target storage unit of the software intermediate product according to the vehicle type; determining a target storage position of the software intermediate product according to the software version and the product identifier; and acquiring the software intermediate product from the target storage position of the target storage unit. The method can realize positioning of the target storage unit of the corresponding vehicle type based on the rough screening of the vehicle type, determine the storage position of the software intermediate product based on the software version and the product identifier, and then accurately screen the software intermediate product from the target storage position of the target storage unit. The corresponding intermediate product can be acquired only by using the software version and the product identifier, without the need of acquisition based on the naming of the software intermediate product. The method improves the identification usability of the software intermediate product and reduces the coupling degree of the naming of the intermediate product.

Description

Technical Field

[0001] This application relates to the field of vehicle software integration, and more specifically, to a method for obtaining software intermediates, electronic devices, and storage media in the field of vehicle software integration. Background Technology

[0002] During the software development and integration process, intermediate artifacts that are not yet finalized will be generated at certain stages. When multi-core software integration is involved, the intermediate artifacts will be initially archived to the SVN (Subversion) version control system or other storage media. When used for integration, they will be retrieved from SVN or other storage media.

[0003] Given the diverse and varied nature of software across different vehicle models and types, most intermediate products currently use dynamic filenames that encompass a wide range of information to enhance recognizability. However, the software integration process does not require all of this information, resulting in poor ease of locating and obtaining intermediate products during the integration process. Summary of the Invention

[0004] This application provides a method, electronic device, and storage medium for obtaining software intermediate artifacts. The method can locate the target storage unit corresponding to the vehicle model based on the coarse screening of the vehicle model, and determine the storage location of the software intermediate artifact based on the software version and artifact identifier. Then, the software intermediate artifact is accurately screened from the target storage location of the target storage unit. At the same time, the corresponding intermediate artifact can be obtained only through the software version and artifact identifier, without the need to obtain it based on the naming of the software intermediate artifact, thereby improving the ease of use of the software intermediate artifact identifier and reducing the coupling with the naming of the intermediate artifact.

[0005] In a first aspect, a method for obtaining software intermediates is provided, the method comprising the following steps: obtaining vehicle type, software version and artifact identifier of software intermediates; determining the target storage unit of software intermediates based on vehicle type; determining the target storage location of software intermediates based on software version and artifact identifier, and obtaining software intermediates from the target storage location of the target storage unit.

[0006] Through the above technical solution, the embodiments of this application can locate the target storage unit corresponding to the vehicle model based on the coarse screening of the vehicle model, and determine the storage location of the software intermediate product based on the software version and product identifier. Then, the software intermediate product can be accurately screened from the target storage location of the target storage unit. At the same time, the corresponding intermediate product can be obtained only through the software version and product identifier, without the need to obtain it based on the naming of the software intermediate product, which improves the ease of use of the software intermediate product identifier and reduces the coupling with the naming of the intermediate product.

[0007] In conjunction with the first aspect, in some possible implementations, determining the target storage unit of the software intermediate based on the vehicle type includes: determining a first mapping table between the vehicle type and the storage unit based on the vehicle type; and determining the target storage unit of the software intermediate based on the vehicle type and the first mapping table.

[0008] Through the above technical solution, the embodiments of this application can pre-establish a first mapping relationship table between vehicle type and storage unit, clarify the storage unit corresponding to each vehicle type, and after obtaining the vehicle type, query the first mapping relationship table to directly locate the target storage unit of the software intermediate product corresponding to the vehicle type, thereby realizing the focus of the storage range of the software intermediate product, avoiding blind searching in the entire storage cluster, and improving the location and acquisition efficiency of the software intermediate product.

[0009] Combining the first aspect and the above implementation methods, in some possible implementation methods, before determining the first mapping relationship table between vehicle type and storage unit based on vehicle type, the method further includes: obtaining a dataset of vehicle types; identifying each vehicle code in the dataset; dividing the target storage cluster into multiple storage units based on the vehicle codes; and generating a first mapping relationship table based on each vehicle code and the location of the corresponding storage unit.

[0010] Through the above technical solution, the embodiments of this application can divide the target storage cluster into multiple target storage units according to the vehicle code, and generate a first mapping relationship table according to the vehicle code and the location of the corresponding storage unit, which facilitates the subsequent location and screening of software intermediates.

[0011] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the target storage location of the software intermediate product is determined based on the software version and the product identifier, including: determining a second mapping table between the product identifier and the storage location based on the software version; and determining the target storage location of the software intermediate product based on the product identifier and the second mapping table.

[0012] Through the above technical solution, the embodiments of this application can pre-establish a second mapping relationship table between product identifier and storage location, and determine the target storage location of software intermediate products according to the product identifier and the second mapping relationship table, so as to achieve accurate positioning and acquisition of software intermediate products.

[0013] In combination with the first aspect and the above implementation methods, in some possible implementation methods, before determining the second mapping relationship table between the artifact identifier and the storage location based on the software version, the method further includes: obtaining at least one software intermediate artifact of the vehicle software; storing the software intermediate artifact in a target storage unit corresponding to the vehicle type; identifying the storage location of the software intermediate artifact in the target storage unit; and generating a second mapping relationship table based on the software identifier of each software intermediate artifact and its corresponding storage location.

[0014] Through the above technical solution, the embodiments of this application can obtain at least one software intermediate product of vehicle software, store the software intermediate product in the target storage unit corresponding to the vehicle type, identify the storage location of the software intermediate product in the target storage unit, generate a second mapping table according to the software identifier of each software intermediate product and the corresponding storage location, realize the standardized archiving of software intermediate products, and ensure that the storage location of each software intermediate product can be traced through the mapping table.

[0015] In combination with the first aspect and the above implementation methods, in some possible implementation methods, before obtaining the product identifier of the vehicle type, software version and software intermediate product, the method further includes: identifying the product number of all software intermediate products under the same software version; and generating the product identifier of the software intermediate product based on the software version and product number.

[0016] Through the above technical solution, the embodiments of this application can identify the product numbers of all intermediate products under the same software version before generating the product identifier, and generate a unique product identifier by combining the software version and the product number, thereby achieving standardization and unification of product identifiers and avoiding the cumbersome reference problem caused by long file names.

[0017] In combination with the first aspect and the above implementation methods, in some possible implementation methods, generating the product identifier of the software intermediate product based on the software version and product number includes: obtaining a generation template for the product identifier of the software intermediate product, the generation template including a first fill position and a second fill position; generating a first fill value based on the software version, and filling the first fill value into the first fill position; generating a second fill value based on the product number, and filling the second fill value into the second fill position; and determining the product identifier of the software intermediate product based on the completed generation template.

[0018] Through the above technical solution, the embodiments of this application can preset a product identification generation template, specify the first fill position and the second fill position, generate a first fill value according to the software version, fill the first fill value into the first fill position, use the product number as the second fill value and fill it into the second fill position, combine the filled template to form the final product identification, realize the structured generation of product identification, ensure the consistency and readability of the identification, reduce the complexity of identification generation, eliminate the need for manual identification design, and improve archiving efficiency.

[0019] In combination with the first aspect and the above implementation methods, in some possible implementation methods, before identifying the artifact number of all software intermediate artifacts under the same software version, the method further includes: obtaining the artifact type of the software intermediate artifact; and numbering all software intermediate artifacts according to the artifact type.

[0020] Through the above technical solution, the embodiments of this application can obtain the product type of software intermediate products and number all software intermediate products according to the product type, so as to achieve orderly allocation of product numbers and avoid duplicate or chaotic numbers.

[0021] Secondly, a software intermediate product acquisition device is provided, the device comprising: a first acquisition module for acquiring vehicle type, software version and product identifier of software intermediate product; a determination module for determining target storage unit of software intermediate product according to vehicle type; and a second acquisition module for determining target storage location of software intermediate product according to software version and product identifier, and acquiring software intermediate product from target storage location of target storage unit.

[0022] In conjunction with the second aspect, in some possible implementations, the determining module is further used to: determine a first mapping table between vehicle type and storage unit based on vehicle type; and determine the target storage unit of the software intermediate based on vehicle type and the first mapping table.

[0023] In conjunction with the second aspect and the above implementation methods, some possible implementation methods may further include: a first generation module, used to obtain a dataset of vehicle types before determining the first mapping relationship table between vehicle types and storage units based on vehicle types; identify each vehicle code in the dataset; divide the target storage cluster into multiple storage units based on the vehicle codes; and generate the first mapping relationship table based on each vehicle code and the location of the corresponding storage unit.

[0024] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the second acquisition module is further used to: determine a second mapping table between the artifact identifier and the storage location based on the software version; and determine the target storage location of the software intermediate artifact based on the artifact identifier and the second mapping table.

[0025] In conjunction with the second aspect and the above implementation methods, some possible implementation methods may further include: a second generation module, configured to obtain at least one software intermediate product of the vehicle software before determining the second mapping relationship table between the product identifier and the storage location based on the software version; store the software intermediate product in a target storage unit corresponding to the vehicle type; identify the storage location of the software intermediate product in the target storage unit; and generate a second mapping relationship table based on the software identifier and the corresponding storage location of each software intermediate product.

[0026] In combination with the second aspect and the above implementation methods, some possible implementation methods may also include: a third generation module, used to identify the product number of all software intermediate products under the same software version before obtaining the product identifier of the vehicle type, software version and software intermediate product; and generate the product identifier of the software intermediate product based on the software version and product number.

[0027] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the second generation module is further used to: obtain a generation template of the product identifier of the software intermediate product, the generation template including a first fill position and a second fill position; generate a first fill value according to the software version, and fill the first fill value into the first fill position; generate a second fill value according to the product number, and fill the second fill value into the second fill position; determine the product identifier of the software intermediate product according to the completed generation template.

[0028] In combination with the second aspect and the above implementation methods, some possible implementation methods may also include: a numbering module, used to obtain the product type of the software intermediate product before identifying the product number of all software intermediate products under the same software version; and to number all software intermediate products according to the product type.

[0029] Thirdly, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method of the first aspect or any possible implementation thereof.

[0030] Fourthly, a computer-readable storage medium is provided that stores a computer program, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0031] Fifthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0032] Figure 1 This is a flowchart of a method for obtaining software intermediates according to an embodiment of this application;

[0033] Figure 2 An architecture hierarchy diagram obtained from the software intermediate provided in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the storage and retrieval of software intermediates according to an embodiment of this application. Figure 4 This is a schematic diagram of a software intermediate product acquisition device provided according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0034] 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.

[0035] 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.

[0036] Before describing the solution of this application, the relevant technologies involved in this application will be introduced to aid in the understanding of the solution of this application.

[0037] When it comes to multi-core software integration, intermediate artifacts are first archived in SVN or other storage media. When integrating and using the software, they are then retrieved from SVN or other storage media, such as through SVN commands or FTP / SSH commands. However, regardless of the method used, the storage location and artifact name of the intermediate artifacts are necessary information for locating and retrieving them again. The more information required for integration work, the more inconvenient it becomes.

[0038] Specifically, in order to improve recognizability, most intermediate artifact filenames in related technologies are dynamic, with standardized but not fixed names. This naming is human-friendly, and more information can be obtained from the filename. However, for integration processes or scripts, more attention is paid to the type of intermediate artifact, or classification. Excessive information can cause inconvenience.

[0039] For example, intermediate artifact naming (operating system-level compilation artifacts) includes the following two intermediate artifacts: s32g274a-gwm-uaes--5.15.119-r0-s32g274agwmuaes-20251215174138.dtb; and fsl-image-auto-s32g274agwmuaes-20251215174138.rootfs.ext4.

[0040] A lot of information can be extracted from filenames (hardware, manufacturer, version, date, type, etc.), but for software integration, only the artifact type is needed; other information is not important. However, using such files in the integration process can cause the following problems: 1. Low usability, filenames are too long and have complex character combinations (numbers + letters + underscores), manual input is prone to errors, and referencing in code / scripts is cumbersome (requires writing the full path + long filename); 2. High coupling: If the file name or file name structure changes, all integration points (scripts, configurations, code, test cases) that reference that file name need to be modified one by one, and the transformation cost increases exponentially with the scale of integration; 3. It is not conducive to building general integration logic; matching / processing filenames will make the integration logic more complex. 4. When there are dozens of similar intermediate products, totaling tens of thousands, the operation and maintenance by integration personnel will be even more difficult.

[0041] Therefore, in order to solve the problem of inconvenience in locating and obtaining intermediate products, this application embodiment adds an additional product identifier to the intermediate products to improve the convenience of locating and obtaining them.

[0042] Figure 1 This is a schematic flowchart of a method for obtaining software intermediates provided in an embodiment of this application.

[0043] For example, such as Figure 1 As shown, the process of obtaining intermediate software artifacts includes steps S101 to S103.

[0044] In step S101, the vehicle type, software version, and product identifier of the software intermediate are obtained.

[0045] Among them, vehicle type is an identifier for vehicle model-related classification, used to distinguish different vehicle models; software version is the specific version of the vehicle software, such as A-core version and B-core version, used to locate intermediate products of different versions under the same vehicle model; product identifier is a standardized product alias.

[0046] In this application, the term "artifact" refers to a tangible, transferable, and reusable product generated during the software integration process, such as code packages, images, configuration files, and compiled binary files, which are the physical carriers of the software. Software intermediate artifacts refer to intermediate products generated at different stages during the vehicle's software integration process that have not yet been finalized and are not ultimately intended for user use. They may be incomplete or fail to meet final delivery standards. Software integration is the process of integrating disparate software modules, components, independent systems, or third-party services into a complete system with functional collaboration, data interoperability, and stable operation through standardized interfaces, protocols, or configurations. Its core objective is to eliminate "functional silos," allowing previously independent parts to form a business closed loop and meet complex practical application needs.

[0047] During the software integration process, vehicles may involve multi-core software. The core is the processor core or functional module core in the vehicle's electronic controller (such as ECU (Electronic Control Unit), MCU (Microcontroller Unit) etc.) that performs specific functions. It is an independent development unit divided according to hardware core + functional responsibility in the layered development of vehicle software. Different cores correspond to different hardware carriers or functional domains, and each independently builds software and produces its own intermediate products.

[0048] It should be noted that, in specific applications, the vehicle type can be determined by identifying the vehicle code and core code in the software version number, and the software version can be determined by the core code. For example, if the software version number is A / KE30XX0RATD0, the vehicle code is KE30 and the core code is A.

[0049] In step S102, the target storage unit of the software intermediate is determined according to the vehicle type.

[0050] The target storage unit can be a corresponding storage unit in the target storage cluster, and the storage unit corresponding to different vehicle types is different.

[0051] It is understood that the embodiments of this application determine the target storage unit of the software intermediate product based on the vehicle type, so as to obtain the software intermediate product in the target storage unit corresponding to the vehicle model, thereby achieving initial screening of the scope and improving the efficiency of subsequent positioning and acquisition of the software intermediate product.

[0052] In step S103, the target storage location of the software intermediate product is determined based on the software version and product identifier, and the software intermediate product is obtained from the target storage location of the target storage unit.

[0053] The target storage location is the specific storage path of the software intermediate artifact within the target storage unit, which is determined by associating the software version and artifact identifier.

[0054] It is understood that the embodiments of this application can accurately locate the target storage location of the software intermediate product based on the software version and product identifier, and then obtain the software intermediate product from the target storage location of the target storage unit, thereby achieving efficient location and acquisition of the software intermediate product and improving the retrieval efficiency of the software intermediate product.

[0055] This application embodiment uses vehicle model coarse screening to locate the target storage unit corresponding to the vehicle model, and determines the storage location of the software intermediate product based on the software version and product identifier. Then, the software intermediate product is accurately screened from the target storage location of the target storage unit. At the same time, the corresponding intermediate product can be obtained only by the product identifier, without the need to obtain it based on the name of the software intermediate product, which improves the ease of use of the software intermediate product identifier and reduces the coupling with the naming of the intermediate product.

[0056] For example, if you need to obtain the operating system root file system intermediate artifact of the KE30 model with kernel version KE30XA4R0001 (version number), you need to obtain the vehicle type KE30, software version KE30XA4R0001, artifact identifier A1 (corresponding intermediate artifact is rootfs.ext4). Based on KE30, the target storage unit is determined to be KE30_1. Then, by using version KE30XA4R0001 and artifact identifier A1, the corresponding storage location is determined, and the corresponding fsl-image-auto-s32g274agwmuaes-20251215174138.rootfs.ext4 intermediate artifact is obtained from KE30_1.

[0057] In one embodiment of this application, determining the target storage unit of the software intermediate based on the vehicle type includes: determining a first mapping table between the vehicle type and the storage unit based on the vehicle type; and determining the target storage unit of the software intermediate based on the vehicle type and the first mapping table.

[0058] The first mapping table is a table that stores the correspondence between vehicle types and storage units, used to quickly match the storage units corresponding to vehicle models.

[0059] It is understood that the embodiments of this application can pre-establish a first mapping relationship table between vehicle type and storage unit, clarify the storage unit corresponding to each vehicle model. When the vehicle type is obtained, the first mapping relationship table is queried to directly locate the target storage unit of the software intermediate product corresponding to that vehicle model, thereby realizing the focus of the storage range of the software intermediate product, avoiding blind searching in the entire storage cluster, and improving the location and acquisition efficiency of the software intermediate product.

[0060] For example, the first mapping table records the corresponding relationships such as KE30 model, KE30_1 storage unit for KE30, and KG65 model, KG65_1 storage unit for KG65. When the vehicle type is KE30, querying the first mapping table can directly determine the target storage unit as KE30_1, without having to search in the storage units of other models such as KG65.

[0061] In one embodiment of this application, before determining the first mapping table between vehicle type and storage unit based on vehicle type, the method further includes: obtaining a dataset of vehicle types; identifying each vehicle code in the dataset; dividing the target storage cluster into multiple storage units based on the vehicle codes; and generating a first mapping table based on each vehicle code and the location of the corresponding storage unit.

[0062] Among them, the vehicle type dataset is a collection of basic information containing various vehicle models; the vehicle code is a standardized identifier for the vehicle model, such as KE30 or KG65, which is the core basis for dividing storage units; the target storage cluster can be a distributed object storage cluster, such as the Minio distributed object storage cluster, used to store software middleware for all vehicle models.

[0063] It is understood that, according to the embodiments of this application, the target storage cluster can be divided into multiple target storage units based on the vehicle code, and a first mapping table can be generated based on the vehicle code and the location of the corresponding storage unit, which will facilitate the subsequent location and screening of software intermediates.

[0064] For example, taking the target storage cluster as a Minio cluster, the Minio cluster includes multiple Buckets, each Bucket representing a storage unit. The vehicle dataset includes four vehicle models: KE30, KG65, and A. The Minio cluster is then divided into three Buckets, named KE30-Bucket, KG65-Bucket, and A-Bucket, respectively, and a first mapping table is generated: vehicle model and storage unit location. KE30 corresponds to Minio / KE30-Bucket, KG65 corresponds to Minio / KG65-Bucket, and A corresponds to Minio / A-Bucket.

[0065] In one embodiment of this application, determining the target storage location of a software intermediate product based on the software version and the product identifier includes: determining a second mapping table between the product identifier and the storage location based on the software version; and determining the target storage location of the software intermediate product based on the product identifier and the second mapping table.

[0066] The second mapping table is a table that maps product identifiers (i.e. product aliases) to the specific storage paths of products in the target storage unit under a certain software version. It can be stored in a MySQL database.

[0067] It is understood that the embodiments of this application can pre-establish a second mapping relationship table between the product identifier and the storage location, and determine the target storage location of the software intermediate product based on the product identifier and the second mapping relationship table, so as to achieve accurate positioning and acquisition of the software intermediate product.

[0068] For example, if the current software version is KE30XA4R0001, a second mapping table between the product identifier and the storage location is determined based on the software version. When the software version KE30XA4R0001 and the product identifier A1 are obtained, the storage location can be determined by querying the second mapping table, which is the corresponding storage path under the corresponding storage unit.

[0069] In one embodiment of this application, before determining the second mapping table between the artifact identifier and the storage location based on the software version, the method further includes: obtaining at least one software intermediate artifact of the vehicle software; storing the software intermediate artifact in a target storage unit corresponding to the vehicle type; identifying the storage location of the software intermediate artifact in the target storage unit; and generating a second mapping table based on the software identifier of each software intermediate artifact and its corresponding storage location.

[0070] It is understood that the embodiments of this application can obtain at least one software intermediate product of vehicle software, store the software intermediate product in the target storage unit corresponding to the vehicle type, identify the storage location of the software intermediate product in the target storage unit, generate a second mapping table according to the software identifier of each software intermediate product and the corresponding storage location, realize the standardized archiving of software intermediate products, and ensure that the storage location of each software intermediate product can be traced through the mapping table.

[0071] For example, obtain the intermediate artifacts of KE30 model A core version KE30XA4R0001: rootfs.ext4 and dtb files; upload the intermediate artifacts to the A / KE30XA4R0001 directory of KE30-Bucket; identify the storage location: rootfs.ext4 corresponds to the path KE30-Bucket / A / KE30XA4R0001 / fsl-image-auto-xxx.rootfs.ext4, and the dtb file corresponds to the path KE30-Bucket / A / KE30XA4R0001 / s32g274a-xxx.dtb; generate a second mapping table (version KE30XA4R0001), artifact identifier and storage location. A1 corresponds to KE30-Bucket / A / KE30XA4R0001 / fsl-image-auto-xxx.rootfs.ext4, and A2 corresponds to KE30-Bucket / A / KE30XA4R0001 / s32g274a-xxx.dtb.

[0072] Furthermore, this application embodiment constructs a corresponding mapping table based on the above-mentioned vehicle model, software version, product identifier, and intermediate product hierarchy to efficiently obtain software intermediate products. In other words, this application embodiment constructs a unique mapping relationship between the storage location of intermediate products (such as the rootfs.img software entity) and vehicle model, software, and product identifier (i.e., product alias). In this way, when using intermediate products, obtaining them will be very simple and accurate. Only the version number plus the alias is needed to accurately locate and obtain the required intermediate products for use in the subsequent software integration process.

[0073] This application embodiment achieves efficient management of intermediate products for multi-core software of different vehicle models by constructing a two-level unique mapping relationship between vehicle model and storage unit, and between product alias and storage location. Producers can complete product upload and mapping registration with simple commands, and integrators can accurately obtain the required products by using the software version number and product alias. This solves the problems of complex file names, high coupling, and difficulty in managing massive numbers of products in related technologies. Moreover, the dynamic maintenance capability of the mapping relationship table supports scenarios such as version iteration and file name changes, which greatly reduces the time cost and operational complexity of the integration process. It provides reliable technical support for vehicle model software integration and has good scalability and versatility.

[0074] In one embodiment of this application, before obtaining the vehicle type, software version, and product identifier of the software intermediate, the method further includes: identifying the product number of all software intermediates under the same software version; and generating the product identifier of the software intermediate based on the software version and product number.

[0075] Among them, the product number is a serial number assigned according to the product type under the same software version, such as 1 and 2 for A core products, and 1 and 2 for M core products.

[0076] It is understood that, before generating the product identifier, the embodiments of this application can first identify the product numbers of all intermediate products under the same software version, and combine the software version and product number to generate a unique product identifier, thereby achieving standardization and unification of product identifiers and avoiding the cumbersome referencing problems caused by long file names.

[0077] For example, under software version KE30XR0R0001 (M core), there are two intermediate artifacts: fip.bin and NorFlash.bin. fip.bin should be numbered, and NorFlash.bin should be numbered. Generate artifact identifiers according to the specifications: M1 and M2.

[0078] In one embodiment of this application, generating a product identifier for a software intermediate product based on the software version and product number includes: obtaining a generation template for the product identifier of the software intermediate product, the generation template including a first fill position and a second fill position; generating a first fill value based on the software version, and filling the first fill value into the first fill position; generating a second fill value based on the product number, and filling the second fill value into the second fill position; and determining the product identifier of the software intermediate product based on the generated template after filling.

[0079] The generated template is a standardized format template used to generate product identification. The generated template may include type + number; the software version may include software type, i.e. core type, such as M or A.

[0080] It is understood that the embodiments of this application can preset a product identification generation template, specify the first fill position and the second fill position, generate a first fill value according to the software version, fill the first fill value into the first fill position, use the product number as the second fill value and fill it into the second fill position, combine the filled template to form the final product identification, realize the structured generation of product identification, ensure the consistency and readability of the identification, reduce the complexity of identification generation, eliminate the need for manual identification design, and improve archiving efficiency.

[0081] For example, if the current software version is KE30XA4R0001, the first fill value is extracted from the software version as A, the intermediate product number is 1, the second fill value is generated as 1, and after filling the template, the intermediate product identifier A1 is obtained.

[0082] In one embodiment of this application, before identifying the artifact number of all software intermediate artifacts under the same software version, the method further includes: obtaining the artifact type of the software intermediate artifact; and numbering all software intermediate artifacts according to the artifact type.

[0083] Among them, the artifact type is a functional classification of software intermediate artifacts, such as rootfs.ext4 file, dtb file, fip.bin file, NorFlash.bin file, etc.

[0084] It is understood that the embodiments of this application can obtain the product type of the software intermediate product and number all software intermediate products according to the product type, so as to achieve orderly allocation of product numbers and avoid duplicate or chaotic numbers.

[0085] For example, in the intermediate artifacts of software version KE30XA4R0001 (A core), rootfs.ext4 (type 1) and dtb file (type 2) correspond to number 1 and dtb file corresponds to number 2.

[0086] Specifically, embodiments of this application can set identifiers for software intermediate artifacts, i.e., set aliases. For example, the intermediate artifact rootfs.img can be coded as A1 (identified as the first artifact of the A-core software; similarly, other core software follow the same specification, such as the aliases of the M-core software artifacts being coded as M1, M2, M3, Mn, etc.).

[0087] In this application embodiment, the alias of the product can also be determined directly based on the preset product alias mapping relationship table. The alias is a convention in the intermediate product mapping specification, which is uniformly formulated by the platform. Whether it is the producer or the user of the intermediate product, they must be able to query and abide by the alias mapping convention. For example, the product alias mapping relationship table is shown in Table 1.

[0088] Table 1

[0089] In addition, it should be noted that different cores may have intermediate artifacts with the same name. This is another function of aliases. Suppose that both the M core and the U core generate intermediate artifacts with the same name, KE30XR0B0HW0_gwm_zcu_l_NorFlash.hex. When assigning aliases, the M core maps this type of file to M6, and the MCU maps this file to U6. When archiving intermediate artifacts, the M core is required to specify the archiving alias as M6, and the MCU archiving alias as U6.

[0090] The following details the process of uploading, registering, and obtaining software intermediate products according to the embodiments of this application. It mainly includes two parts: first, dividing the product warehouse according to the vehicle model code to initially locate the storage location of the products; second, when intermediate products are put into the warehouse, alias mapping is added, and the aliases of the same type of products are managed in a standardized manner, which can accurately locate and obtain the products.

[0091] like Figure 2 and Figure 3 As shown, the alias mapping in this application embodiment adopts a standardized format of "vehicle model code + version number + product alias" to improve positioning efficiency and accuracy; a MySQL database is used as the storage for mapping relationships; a Minio object storage cluster can be used to store software intermediate products; and a dedicated command-line tool, gwmarts, is independently developed to realize the registration, uploading, and retrieval of software intermediate products.

[0092] like Figure 2As shown, the overall implementation architecture of this application can include three layers: a user layer, an interface layer, and a core engine layer. The user layer is for use by users, including CI / CD pipelines and integration personnel. The interface layer provides command-line tools such as gwmarts and APIs. The core engine layer provides an alias mapping engine, a vehicle model matching engine, a product version management engine, and a data transmission engine. The core engine layer connects to the data layer and the storage layer. The data layer is carried by a MySQL database, which stores the product mapping table (i.e., the second mapping relationship table), the vehicle model table (i.e., the first mapping relationship table), and product metadata. The storage layer is carried by a Minio distributed object storage cluster, which is used to divide the storage location according to the vehicle model.

[0093] Figure 2 The specific implementation process includes: 1. Product upload and mapping registration.

[0094] Producers (CI / CD pipeline / integration personnel) use the gwmarts tool at the interface layer to input the vehicle model code, version number, artifact alias, and artifact to be uploaded. The vehicle model matching engine at the core engine layer queries the vehicle model table based on the vehicle model code, locates the corresponding Minio Bucket, and uploads the artifact to that Bucket. At the same time, the artifact alias mapping engine registers the vehicle model, version, artifact alias, artifact name / storage path in the artifact mapping table of the MySQL database, thus solidifying the mapping relationship.

[0095] 2. Product acquisition.

[0096] Users input the version number and artifact alias using the gwmarts tool. Based on the version number, the model is determined. The model matching engine queries the model table to locate the target Bucket (coarse screening). Then, the alias mapping engine queries the artifact mapping table to match the storage location of the artifact corresponding to the version and alias (fine screening). Finally, the data transmission engine retrieves the artifact from the target location in Minio and returns it to the user.

[0097] The following example illustrates the process of uploading, registering, and obtaining intermediate artifacts in this application. The application scenario is a multi-core software integration project for the KE30 vehicle model, covering the entire lifecycle management of intermediate artifacts across the A core (operating system layer), M core (functional control layer), and MCU core (peripheral driver layer). This ultimately supports efficient artifact invocation in the overall integration phase. The KE30 model requires the integration of 12 types of core intermediate artifacts, including operating system images, firmware files, and device tree configurations. Related technologies require manually inputting long filenames (e.g., s32g274a-gwm-uaes--5.15.119-r0-s32g274agwmuaes-20251215174138.dtb), which is not only cumbersome but also prone to integration failures due to changes in filename structure.

[0098] I. Construction of the mapping relationship table.

[0099] The mapping table is the foundation for accurate positioning. It is built on a MySQL database and includes a vehicle model-storage unit mapping table (first mapping table) and a product-storage location mapping table (second mapping table). All fields are deeply integrated with the Minio storage cluster and gwmarts command-line tool to ensure data consistency.

[0100] 1. First mapping table.

[0101] This table is used to associate vehicle model codes with Minio distributed storage cluster buckets (storage units) to implement coarse screening logic. The specific table structure and KE30 model-related data are shown in Table 2.

[0102] Table 2

[0103] The vehicle model codes in the table can use the standardized codes within the corresponding car manufacturers, and the Bucket names use the fixed format of vehicle model code _P for easy automatic recognition.

[0104] 2. Second mapping table.

[0105] This table is the core of the fine screening process. It establishes a unique mapping relationship between vehicle model, software version, product alias and the actual storage location of intermediate products. At the same time, it records product metadata for traceability. The specific table structure and KE30 multi-core intermediate products are shown in Table 3.

[0106]

[0107] In Table 3, the software version number includes the software type identifier. For example, in KE30XA4R0001, XA represents the A core, XR represents the M core, and XU represents the MCU core. The product alias strictly follows the core type + serial number specification (A core corresponds to A1, A2, A3, M core corresponds to M1, M2, MCU core corresponds to U1, U2, and Switch corresponds to S1). It is uniformly assigned by the platform and cannot be customized. The storage path can adopt a hierarchical structure of core type / software version number / function directory, which is convenient for physical storage management and can also be linked with the mapping table fields.

[0108] III. Producers upload products and register the mapping relationship.

[0109] Producers (A-core, M-core, and MCU-core builders) upload intermediate artifacts using the gwmarts command-line tool, which simultaneously triggers automatic registration of mapping relationships. This eliminates the need for manual maintenance of the mapping table, resulting in a high degree of automation. The following detailed explanation of the process uses the KE30 model's A-core, M-core, and MCU-core artifact upload as an example: (a) Uploading and mapping registration of nuclear products.

[0110] 1. Build output: After the A-core build script is executed, three types of core intermediate artifacts are generated (rootfs.ext4, dtb, kernel.bin). The file names contain redundant information such as hardware, version, and date, such as fsl-image-auto-s32g274agwmuaes-20251215174138.rootfs.ext4; 2. Upload command execution: Producers configure gwmarts upload commands in their CI / CD pipelines, eliminating the need to manually enter long filenames. Wildcards are used to batch match artifacts. The command is as follows: Upload rootfs.ext4, alias A1 (A-core Class 1 artifact: operating system image): gwmarts putx –b KE30 -p A / KE30XA4R0001 .rootfs.ext4 --aname A1; Upload the DTB file, alias A2 (A-core Class 2 artifact: Device Tree Configuration): gwmarts putx –b KE30 -p A / KE30XA4R0001 .dtb --aname A2; Upload kernel.bin, alias A3 (A-core Class 3 artifact: kernel image): gwmarts putx –b KE30 -p A / KE30XA4R0001 .bin --filter kernel --anameA3.

[0111] 3. Automated processing flow.

[0112] Vehicle model matching engine analysis - b KE30 parameter, query the first mapping relationship table, locate the target storage unit as KE30_1 Bucket; The data transfer engine stores artifacts to the Minio cluster according to the -p A / KE30XA4R0001 / function directory path (e.g., rootfs.ext4 is stored in the A / KE30XA4R0001 / rootfs / directory). The alias mapping engine extracts information such as vehicle model code (KE30), software version number (KE30XA4R0001), and product alias (A1, A2, A3) from the command. Combined with other metadata such as the product's real name, size, and upload time, it automatically inserts the information into the second mapping relationship table to complete the mapping relationship registration.

[0113] (ii) Uploading of M-core and MCU core products.

[0114] The M-core producer executes a similar command to upload fip.bin (alias M1) and NorFlash.bin (alias M2); the MCU core producer uploads 0x765_KE30XU1R0001.bin (alias U1) and KE30XU1R0001.hex (alias U2). The system automatically updates the mapping table without manual intervention. Taking the M-core upload command as an example: Upload the M-core fip.bin file, alias M1 (M-core Class 1 artifact: firmware boot file): gwmarts putx –b KE30 -p M / KE30XR0R0001 KE30XR0R0001_fip.bin --anameM1; Upload the M-core NorFlash.bin, aliased as M2 (M-core Class 2 artifact: NorFlash image): gwmarts putx –b KE30 -p M / KE30XR0R0001 KE30XR0R0001_gwm_zcu_l_NorFlash.bin --aname M2 .

[0115] IV. Integration personnel accurately obtain intermediate products.

[0116] During the final integration phase of the KE30 model (version number KE3XX01R0001), integration personnel only need to enter the software version number and the product alias to obtain the required product, eliminating the need to remember long file names or storage paths, greatly simplifying the operation process.

[0117] (a) Overall integration requirements.

[0118] The final integration requires integrating eight types of intermediate artifacts from the A-core, M-core, MCU-core, and Switch module. Traditionally, this requires manually entering eight long filenames and their full paths, and is prone to integration failures due to character errors. This application only requires entering eight combinations of version numbers and aliases.

[0119] (ii) Execution of product acquisition order.

[0120] The system integrator configures gwmarts to retrieve commands in the system integration script, as follows: Obtain the operating system image (alias A1) of kernel version KE30XA4R0001: gwmartsgetxKE30XA4R0001A1--output. / integrate / A / core / ; Retrieve the device tree configuration (alias A2) for core version KE30XA4R0001: gwmartsgetxKE30XA4R0001A2--output. / integrate / A / dtb / ; Obtain the kernel image (alias A3) for kernel version KE30XA4R0001: gwmartsgetxKE30XA4R0001A3--output. / integrate / A / kernel / ; Obtain the firmware boot file (alias M1) for M-core version KE30XR0R0001: gwmartsgetxKE30XR0R0001M1--output. / integrate / M / firmware / ; Obtain the NOR flash image (alias M2) for M-core version KE30XR0R0001: gwmartsgetxKE30XR0R0001M2--output. / integrate / M / norflash / ; Obtain the bin file (alias U1) of MCU core version KE30XU1R0001: gwmartsgetxKE30XU1R0001U1--output. / integrate / MCU / bin / ; Obtain the hex file (alias U2) of MCU core version KE30XU1R0001: gwmartsgetxKE30XU1R0001U2--output. / integrate / MCU / hex / ; Obtain the Switch version 11312008 image file (alias S1): gwmartsgetx11312008S1--output. / integrate / Switch / image / .

[0121] (III) Precise positioning and acquisition process.

[0122] Obtain vehicle model code KE30. The vehicle matching engine queries the first mapping table based on vehicle model code KE30, locks KE30_1Bucket in Minio, and completes the coarse screening. The alias mapping engine uses "software version number + product alias" as the query criteria to retrieve data from the second mapping table and performs precise matching of the target storage location. For example: Inputting KE30XA4R0001+A1 reveals the storage path as A / KE30XA4R0001 / rootfs / fsl-image-auto-s32g274agwmuaes-20251215174138.rootfs.ext4; Inputting KE30XR0R0001+M1 reveals the storage path as M / KE30XR0R0001 / firmware / KE30XR0R0001_fip.bin; The data transfer engine downloads artifacts from the target path, stores them in the local directory specified by the --output parameter, and verifies the artifact's MD5 value (the mapping table stores the MD5 value at the time of upload) to ensure artifact integrity; Once all artifacts have been acquired, a successful acquisition list will be returned, including artifact aliases, version numbers, storage paths, and other information, which integrators can directly use in subsequent integration processes.

[0123] In addition, it should be noted that this application can also easily manage scenarios such as filename changes and version iterations. The specific management methods for different scenarios are as follows: 1. Filename Change Scenario: If the naming rules of the A core dtb file change (such as adding a manufacturer identifier), and the new file name is s32g274a-gwm-uaes-abc--5.15.119-r0-s32g274agwmuaes-20251220101522.dtb, the producer only needs to re-upload the artifact (the alias is still A2), and the "artifact real name" and "storage path" fields in the second mapping table will be automatically updated. The gwmartsgetxKE30XA4R0001A2 command in the general integration script does not need to be modified, which completely solves the technical problem in related technologies where filename changes cause all integration points to be modified one by one. 2. Version Iteration Scenario: Core A releases a new version KE30XA4R0002. Producers upload new artifacts and assign aliases A1 / A2 / A3. The system adds 3 mapping records to the second mapping relationship table. The mapping relationship with the old version KE30XA4R0001 exists independently, supporting parallel management of multiple versions. The general integrator can obtain artifacts of different versions by switching version numbers.

[0124] In summary, the embodiments of this application can divide the storage warehouse (i.e., storage unit) according to the vehicle model code. Taking Minio as an example, the storage warehouse is equivalent to the Bucket concept in Minio, such as... Figure 3 As shown, when storing intermediate artifacts via the command line gwmarts, all intermediate artifacts under the same model (such as KE30) will be stored in a separate Bucket. When retrieving software artifacts, this partitioning method acts as a "coarse screening" of artifacts, that is, retrieving intermediate artifacts in a specified Bucket, thereby improving the efficiency of intermediate artifact retrieval.

[0125] Among them, the standardization of intermediate product alias mapping is established, such as Figure 3 As shown, the intermediate artifact rootfs.img is designated as A1 (identified as the first artifact of the A-core software; other core software follow the same specification, such as the artifact aliases of the M-core software being M1, M2, M3, Mn, etc.). During the intermediate artifact upload process, the vehicle model code, version number, and alias are registered in the database, establishing a unique mapping relationship between the intermediate artifact (such as the rootfs.img software entity) and the vehicle model code, version number, and alias. In this way, when using the intermediate artifact, obtaining it will be very simple and accurate; we only need to use the version number plus the alias to accurately locate and obtain the required intermediate artifact for use in subsequent software integration processes.

[0126] Based on the above process, this application forms a coarse screening + fine screening closed loop: vehicle model partitioning achieves range focusing, and alias mapping completes precise locking, greatly improving the positioning and acquisition efficiency. The method of this application is adapted to the business characteristics of vehicle model software integration, which not only avoids the search redundancy caused by overly coarse classification, but also solves the matching error caused by inconsistent identifiers, significantly reducing the time cost and operational complexity of the integration process.

[0127] Based on the above implementation process, the implementation process of this application will be described below through specific examples.

[0128] I. A-core software construction.

[0129] 1. Construct the input.

[0130] Vehicle model source code (KE30); A core version number (KE30XA4R0001).

[0131] 2. Build and execute.

[0132] The A-core build script receives input 1 above and includes operations 3 and 4 below.

[0133] 3. Construct the output (partial intermediate products).

[0134] s32g274a-gwm-uaes--5.15.119-r0-s32g274agwmuaes-20251215174138.dtb; fsl-image-auto-s32g274agwmuaes-20251215174138.rootfs.ext4; Image--5.15.119-r0-s32g274agwmuaes-20251215174138.bin; u-boot-s32g274agwmuaes.bin-sdcard; 4. Intermediate product mapping archive.

[0135] gwmarts putx –b KE30 -p A / KE30XA4R0001 .rootfs.ext4 --aname A1; gwmarts putx –b KE30 -p A / KE30XA4R0001 .dtb --aname A2.

[0136] II. M-core software.

[0137] 1. Construct the input.

[0138] Vehicle model source code (KE30); M core version number (KE30XR0R0001); A core version number (KE30XA4R0001).

[0139] 2. Build and execute.

[0140] M-core build script (receives input 1 above and includes operations 3 and 4 below).

[0141] 3. Build the output.

[0142] KE30XR0R0001_fip.bin; KE30XR0R0001_gwm_zcu_l_NorFlash.bi.

[0143] 4. Intermediate product mapping archive.

[0144] gwmarts putx –b KE30 -p M / KE30XR0R0001 KE30XR0R0001_fip.bin --anameM1; gwmarts putx –b KE30 -p M / KE30XR0R0001 KE30XR0R0001_gwm_zcu_l_NorFlash.bin --aname M2.

[0145] III. MCU Software Construction.

[0146] 1. Construct the input.

[0147] Vehicle model source code (KE30); MCU version number (KE30XU1R0001).

[0148] 2. Build and execute.

[0149] MCU build script (receives input 1 above and includes operations 3 and 4 below).

[0150] 3. Construct the output.

[0151] 0x765_ KE30XU1R0001.bin; KE30XU1R0001.hex.

[0152] 4. Intermediate product mapping archive.

[0153] gwmarts putx –b KE30 -p U / KE30XU1R0001 0x765_ KE30XU1R0001.bin --aname U1; gwmarts putx –b KE30 -p U / KE30XU1R0001 KE30XU1R0001.hex --aname U2.

[0154] IV. Overall Integration.

[0155] 1. Overall integrated input.

[0156] Overall integration version number (KE3XX01R0001); A-core version number (KE30XA4R0001); M-core version number (KE30XR0R0001); MCU version number (KE30XU1R0001); Switch version number (11312008).

[0157] 2. Overall integration execution.

[0158] The main integration script (receives input 1 above and includes operations 3 and 4 below).

[0159] Intermediate products can be obtained and integrated using the following methods: gwmarts getx KE30XA4R0001 A1; gwmarts getx KE30XA4R0001 A2; gwmarts getx KE30XR0R0001 M1; gwmarts getx KE30XR0R0001 M2; gwmarts getx KE30XU1R0001 U1.

[0160] Instead of the following method: s32g274a-gwm-uaes--5.15.119-r0-s32g274agwmuaes-20251215174138.dtb、fsl-image-auto-s32g274agwmuaes-2025121517413 8.rootfs.ext4, 0x765_KE30XU1R0001.bin, KE30XU1R0001.hex, KE30XR0R0001_fip.bin, KE30XR0R0001_gwm_zcu_l_NorFlash.bin.

[0161] 3. Overall integrated output.

[0162] KE3XX01R0001_OBD.zip; KE3XX01R0001_OTA.zip.

[0163] 4. Overall integrated product mapping archive.

[0164] gwmarts putx –b KE30 -p Z / KE3XX01R0001 KE3XX01R0001_OBD.zip --anameZ1; gwmarts putx –b KE30 -p Z / KE3XX01R0001 KE3XX01R0001_OTA.zip --anameZ2.

[0165] In other words, Bucket (KE30) + version number (KE3XX01R0001) + alias (A1) means that the producer uploads the artifact to the artifact library and registers the above information according to the agreement. The integrator can then query and obtain the artifact according to the above agreement, ensuring its uniqueness.

[0166] In addition, it should be noted that this application can achieve the same result not only through the identification mapping mechanism of intermediate products, but also through the establishment of a multi-dimensional tag system and intelligent metadata association. However, the implementation process will be more complex than identification mapping. Specifically, a multi-dimensional and flexibly combinable set of identifiers can be added for quick filtering and positioning. Intelligent metadata can be the native and associated structured information automatically extracted during generation for accurate positioning and traceability without additional identifiers.

[0167] According to the software intermediate product acquisition method proposed in the embodiments of this application, the target storage unit corresponding to the vehicle model can be located based on the coarse screening of the vehicle model, and the storage location of the software intermediate product can be determined based on the software version and product identifier. Then, the software intermediate product can be accurately screened from the target storage location of the target storage unit. At the same time, the corresponding intermediate product can be obtained only through the software version and product identifier, without the need to obtain it based on the naming of the software intermediate product, which improves the ease of use of the software intermediate product identifier and reduces the coupling with the naming of the intermediate product.

[0168] Figure 4 This is a schematic diagram of a software intermediate product acquisition device provided in an embodiment of this application.

[0169] For example, such as Figure 4 As shown, the software intermediate product acquisition device 10 may include: a first acquisition module 100, a determination module 200, and a second acquisition module 300.

[0170] The first acquisition module 100 is used to acquire the vehicle type, software version, and product identifier of the software intermediate product; the determination module 200 is used to determine the target storage unit of the software intermediate product according to the vehicle type; the second acquisition module 300 is used to determine the target storage location of the software intermediate product according to the software version and product identifier, and acquire the software intermediate product from the target storage location of the target storage unit.

[0171] In one embodiment of this application, the determining module 200 is further configured to: determine a first mapping table between vehicle type and storage unit based on vehicle type; and determine the target storage unit of the software intermediate based on vehicle type and the first mapping table.

[0172] In one embodiment of this application, the software intermediate artifact acquisition device 10 of this application embodiment further includes: a first generation module.

[0173] The first generation module is used to obtain a dataset of vehicle types before determining the first mapping relationship table between vehicle types and storage units based on vehicle types; identify the vehicle code of each vehicle type in the dataset; divide the target storage cluster into multiple storage units according to the vehicle code; and generate the first mapping relationship table according to each vehicle code and the location of the corresponding storage unit.

[0174] In one embodiment of this application, the second acquisition module 300 is further configured to: determine a second mapping table between the artifact identifier and the storage location based on the software version; and determine the target storage location of the software intermediate artifact based on the artifact identifier and the second mapping table.

[0175] In one embodiment of this application, the software intermediate artifact acquisition device 10 of this application embodiment further includes: a second generation module.

[0176] The second generation module is used to obtain at least one software intermediate product of the vehicle software before determining the second mapping relationship table between the product identifier and the storage location according to the software version; store the software intermediate product in the target storage unit corresponding to the vehicle type; identify the storage location of the software intermediate product in the target storage unit; and generate the second mapping relationship table according to the software identifier and the corresponding storage location of each software intermediate product.

[0177] In one embodiment of this application, the software intermediate artifact acquisition device 10 of this application embodiment further includes: a third generation module.

[0178] The third generation module is used to identify the product number of all software intermediate products under the same software version before obtaining the product identifier of the vehicle type, software version and software intermediate product; and to generate the product identifier of the software intermediate product based on the software version and product number.

[0179] In one embodiment of this application, the second generation module is further configured to: obtain a generation template for the product identifier of the software intermediate product, the generation template including a first fill position and a second fill position; generate a first fill value according to the software version, and fill the first fill value into the first fill position; generate a second fill value according to the product number, and fill the second fill value into the second fill position; and determine the product identifier of the software intermediate product according to the completed generation template.

[0180] In one embodiment of this application, the software intermediate product acquisition device 10 of this application embodiment further includes: a numbering module.

[0181] The numbering module is used to obtain the product type of the software intermediate product before identifying the product number of all software intermediate products under the same software version; and to number all software intermediate products according to the product type.

[0182] According to the software intermediate product acquisition device proposed in the embodiments of this application, the target storage unit corresponding to the vehicle model can be located based on the coarse screening of the vehicle model, and the storage location of the software intermediate product can be determined based on the software version and product identifier. Then, the software intermediate product can be accurately screened from the target storage location of the target storage unit. At the same time, the corresponding intermediate product can be obtained only through the software version and product identifier, without the need to obtain it based on the name of the software intermediate product, which improves the ease of use of the software intermediate product identifier and reduces the coupling with the naming of the intermediate product.

[0183] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0184] When processor 502 executes the program, it implements the software intermediate artifact acquisition method provided in the above embodiments.

[0185] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.

[0186] The memory 501 is used to store computer programs that can run on the processor 502.

[0187] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0188] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0189] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0190] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0191] This embodiment also provides a computer-readable storage medium storing a computer program. When the computer program is run on a computer, it causes the computer to execute the above-described related method steps to implement a method for obtaining software intermediates provided in the above embodiment.

[0192] This embodiment also provides a computer program product. When the computer program product is run on a computer, the computer performs the above-mentioned related steps to realize the software intermediate product acquisition method provided in the above embodiment.

[0193] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0194] 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.

[0195] 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.

[0196] 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 obtaining software intermediates, characterized in that, Includes the following steps: Obtain the product identifier of vehicle type, software version, and software intermediates; The target storage unit for the software intermediate is determined based on the vehicle type. The target storage location of the software intermediate product is determined based on the software version and the product identifier, and the software intermediate product is obtained from the target storage location of the target storage unit.

2. The method for obtaining software intermediates according to claim 1, characterized in that, Determining the target storage unit of the software intermediate based on the vehicle type includes: A first mapping table between vehicle type and storage unit is determined based on the vehicle type; The target storage unit of the software intermediate is determined based on the vehicle type and the first mapping table.

3. The method for obtaining software intermediates according to claim 2, characterized in that, Before determining the first mapping table between vehicle type and storage unit based on the vehicle type, the process also includes: Obtain the dataset for vehicle types; Identify the vehicle code for each vehicle type in the dataset; The target storage cluster is divided into multiple storage units based on the vehicle code; The first mapping table is generated based on each vehicle code and the location of its corresponding storage unit.

4. The method for obtaining software intermediates according to claim 1, characterized in that, Determining the target storage location of the software intermediate artifact based on the software version and the artifact identifier includes: A second mapping table between product identifiers and storage locations is determined based on the software version; The target storage location of the software intermediate artifact is determined based on the artifact identifier and the second mapping table.

5. The method for obtaining software intermediates according to claim 4, characterized in that, Before determining the second mapping table between product identifiers and storage locations based on the software version, the process also includes: Obtain at least one software intermediate of the vehicle software; The software intermediate is stored in the target storage unit corresponding to the vehicle type; Identify the storage location of the software intermediate artifact in the target storage unit, and generate the second mapping table based on the software identifier of each software intermediate artifact and its corresponding storage location.

6. The method for obtaining software intermediates according to claim 1, characterized in that, Before obtaining the product identifier for vehicle type, software version, and software intermediates, the following is also included: Identify the artifact number of all intermediate software artifacts under the same software version; Generate a product identifier for the software intermediate product based on the software version and the product number.

7. The method for obtaining software intermediates according to claim 6, characterized in that, The step of generating the product identifier of the software intermediate product based on the software version and the product number includes: Obtain a template for generating the product identifier of the software intermediate product, the template including a first fill bit and a second fill bit; A first fill value is generated according to the software version, and the first fill value is filled into the first fill position; A second fill value is generated based on the product number, and the second fill value is filled into the second fill position; The artifact identifier of the software intermediate artifact is determined based on the completed generated template.

8. The method for obtaining software intermediates according to claim 6, characterized in that, Before identifying the artifact number of all software intermediate artifacts under the same software version, the following is also included: Obtain the artifact type of the software intermediate artifact; All software intermediate artifacts are numbered according to the artifact type.

9. An electronic device, characterized in that, The vehicle includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the software intermediate article acquisition method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method for obtaining software intermediates as described in any one of claims 1-8.

Images