Method and system for software integration and product automatic generation based on SOC chip and medium

Abstract

The application relates to a SOC chip-based software package integration and product automatic generation method, system and medium, which comprises the following steps: uploading a SOC self-research product package, a supplier SOC product package and a model file to an input folder; receiving product package name input and responding to a packaging instruction; checking whether input files in the input folder meet preset requirements; when the input files meet the preset requirements, decompressing the supplier SOC product package and the SOC self-research product package; traversing a modules directory in the SOC self-research product package, judging whether each module folder under the modules directory is empty; when there is an empty module folder, outputting abnormal information and terminating the packaging process; when each module folder under the modules directory has content, packaging the supplier SOC product package, the SOC self-research product package and the model file to generate a SOC integrated package product; and saving the SOC integrated package product to an output folder.

Description

Technical Field

[0001] This invention relates to the field of software integration and automated construction technology, and in particular to a method, system and medium for software package integration and automated product generation based on SOC chip. Background Technology

[0002] As the complexity of intelligent driving software increases, the number of modules, supplier deliverables, self-developed code versions, and model files in vehicle-side SOC software are all showing an increasing trend. A complete SOC package typically consists of two types of artifacts: one is the supplier-delivered SOC integration software package, and the other is a self-developed artifact package formed by compiling and integrating self-developed source code. In traditional processes, CI personnel typically rely on command lines to manually execute steps such as packaging, decompressing, copying, replacing, verifying, and uploading to complete the SOC package creation. While this method can complete the SOC package creation, the operation process is highly dependent on personnel experience, and commands and parameters are often maintained separately by different CI personnel, lacking a unified tool entry point and a unified execution standard.

[0003] However, the aforementioned traditional approach has several shortcomings. First, since the final SOC integrated package relies on CI personnel manually inputting packaging instructions and confirming the packaging results, errors in the order of instruction input, parameters, paths, or artifact names can lead to missing package content, version mixing errors, incorrect artifact naming, or incomplete output files. Second, different CI personnel may maintain different versions of scripts, command templates, or operating habits locally, resulting in inconsistencies in SOC package artifacts generated by different projects, personnel, and stages. Third, when the number of projects increases, personnel changes, or artifact versions iterate frequently, the traditional method is prone to problems such as inconsistent integrated artifacts, missing modules, long packaging time, and difficulty in tracing errors. In addition, although existing CI pipelines can compile and package self-developed code, the pipeline itself may not completely intercept anomalies. For example, a module may fail to compile, but the pipeline may not report the error in time, resulting in an empty module folder in the modules directory of the SOC self-developed artifact package. If CI personnel continue to manually package according to the old process, self-developed artifact packages with missing modules may still be integrated into the final SOC package. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a method, system and medium for software package integration and automatic product generation based on SOC chips. Through a unified automated integration process and module integrity verification mechanism, it can effectively solve the problems of inconsistent operation, missing modules, version mixing errors and difficulty in tracing errors in the traditional manual packaging method, thereby improving the production efficiency and quality reliability of SOC packaged products.

[0005] To achieve the above objectives, the present invention adopts the following technical solution.

[0006] In a first aspect, the present invention provides a method for software integration and automated product generation based on a SOC chip, which adopts the following technical solution: Upload the SOC self-developed product package, the supplier's SOC product package, and the model files to the input folder; Receives product package name input and responds to packaging instructions; Check whether the input files in the input folder meet the preset requirements; When the input file meets the preset requirements, decompress the supplier's SOC product package and the SOC self-developed product package; Traverse the modules directory in the SOC self-developed product package and determine whether each module folder under the modules directory is empty; If an empty module folder exists, output an error message and terminate the package creation process; When all module folders under the modules directory contain content, the supplier's SOC product package, the SOC self-developed product package, and the model file are packaged to generate an integrated SOC product package; and Save the SOC integrated packaged product to the output folder.

[0007] Furthermore, the above method further includes: Calculate the verification value of the SOC integrated packaged product; and A verification file is generated in the output folder. The verification file records the name of the SOC integrated packaged product and its corresponding verification value.

[0008] Furthermore, in the above method, the verification value is the MD5 value.

[0009] Furthermore, the above method further includes: A documentation file is generated in the output folder, which records tutorial information for deploying the software to the vehicle.

[0010] Furthermore, in the above method, checking whether the input files in the input folder meet the preset requirements includes: Check whether the self-developed SOC product package, the supplier's SOC product package, and the model file all exist in the input folder; and Check if the number of files in the corresponding directory meets the preset rules.

[0011] Furthermore, in the above method, before receiving the product package name input and responding to the packaging instruction, the method further includes: Clear or reset the output folder; and Read the configuration file, which stores the path parameters, file naming rules, and project-specific configurations required for package creation.

[0012] Furthermore, the above method further includes: During the packaging process, execution information is output to the log area of ​​the front-end page in real time. The execution information includes the execution steps and the reasons for any exceptions.

[0013] Furthermore, in the above method, the step of packaging the supplier's SOC product package, the SOC self-developed product package, and the model file to generate an integrated SOC product package includes: Copy the specified directory; Replace the changed module; Retain integrated modules that do not require recompilation; Write to the model file; and Perform a compression and packaging operation.

[0014] Furthermore, the above method further includes: In response to the upload command, the SOC integrated package product and related output files in the output folder are uploaded to the cloud drive.

[0015] Furthermore, in the above method, the SOC self-developed product package is obtained by compiling and packaging the self-developed source code through a continuous integration pipeline, while the supplier SOC product package is delivered by the supplier.

[0016] Secondly, the present invention provides a software package integration and automated product generation system based on a SOC chip, which adopts the following technical solution: The upload module is used to upload SOC self-developed product packages, supplier SOC product packages, and model files to the input folder; The instruction receiving module is used to receive the product package name input and respond to the packaging instruction; The inspection module is used to check whether the input files in the input folder meet the preset requirements; The decompression module is used to decompress the supplier's SOC product package and the SOC self-developed product package when the input file meets the preset requirements. The verification module is used to traverse the modules directory in the SOC self-developed product package and determine whether each module folder under the modules directory is empty; The exception handling module is used to output exception information and terminate the package creation process when an empty module folder exists. The packaging module is used to package the supplier's SOC product package, the SOC self-developed product package, and the model file into a complete SOC integrated product package when all module folders under the modules directory contain content; and The save module is used to save the SOC integrated packaged product to the output folder.

[0017] Thirdly, the present invention provides a readable storage medium, which adopts the following technical solution: A readable storage medium storing computer instructions that, when executed by a processor, implement any one of the aspects described in the first aspect above.

[0018] In summary, compared with the prior art, the present invention has at least one of the following beneficial technical effects: The software package integration and automated artifact generation method based on SOC chips disclosed herein automatically traverses the modules directory of the SOC self-developed artifact package and checks whether each module folder is empty during the packaging process. This enables timely detection of module compilation failures caused by upstream CI pipeline anomalies before packaging, avoiding the integration of self-developed artifact packages with missing modules into the final SOC package, thereby effectively intercepting the risk of missing modules. At the same time, by replacing traditional manual command-line operations with a unified automated integration process, it eliminates artifact inconsistencies caused by differences in operating habits among different CI personnel, improving the efficiency, accuracy, and traceability of SOC package artifact generation. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart of an embodiment of the software package integration and automatic article generation method based on SOC chip disclosed herein is shown.

[0021] Figure 2 A sub-flowchart of an embodiment of the present disclosure for checking whether an input file meets preset requirements is shown.

[0022] Figure 3 A sub-flowchart of one embodiment of the present disclosure for packaging and generating a SOC integrated whole packaged article is shown.

[0023] Figure 4 A sub-flowchart of an embodiment of this disclosure for generating verification files and instruction files and uploading them to a cloud drive is shown.

[0024] Figure 5 A structural block diagram of an embodiment of the software package integration and automated product generation system based on a SOC chip disclosed herein is shown. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, it should be understood that the specific embodiments described herein are only for illustration and explanation of this application and are not intended to limit this application.

[0026] It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments of this application. Furthermore, the descriptions of each embodiment in the following embodiments have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0027] The method steps described in this embodiment of the invention can be executed in the order described in the specific implementation, or the execution order of each step can be adjusted according to actual needs, provided that the technical problem can be solved. These are not listed one by one here.

[0028] The present invention will be further described in detail below with reference to the accompanying drawings.

[0029] This disclosure relates to the field of software integration and automated build technology, and in particular to an automated method for generating artifacts for the complete integration of software packages for System-on-Chips (SoCs). An SoC is a dedicated integrated circuit containing complete embedded software. In applications such as autonomous driving, the complete artifact package of vehicle-side SoC software typically consists of a vendor-delivered SoC integration package and a self-developed artifact package compiled and integrated based on self-developed source code. Continuous Integration (CI) is a software development practice in which CI personnel are responsible for compiling the self-developed SoC artifact package, receiving vendor SoC artifact packages, and ultimately creating and releasing the complete SoC package.

[0030] This disclosure provides a method for the integrated software package and automated artifact generation based on SOC chips. It uses automated tools to unify and encapsulate packaging instruction sets that were originally scattered across the local machines of various CI personnel. The tool then performs operations such as packaging, decompression, replacement, verification, output, and uploading according to a pre-defined process, thus automating and platformizing the SOC integrated artifact manufacturing process. In some implementations, the tool is deployed in a Linux environment, and CI personnel access it through a browser or a front-end page provided by the tool. Before the tool runs, input and output folders are pre-set in the tool's root directory, with the input folder serving as a unified input directory and the output folder as a unified output directory. By fixing the input and output directories, path mismatches and file mixing issues caused by different CI personnel using different paths locally are avoided.

[0031] Figure 1 The overall flow of the software package integration and automated artifact generation method based on SOC chip disclosed herein is illustrated. (Refer to...) Figure 1 The method includes steps S101 to S107.

[0032] In step S101, the SOC self-developed artifact package, the supplier's SOC artifact package, and the model files are uploaded to the input folder. The SOC self-developed artifact package is obtained by compiling and packaging the self-developed source code using the continuous integration pipeline. The SOC self-developed artifact package includes a modules directory and multiple module folders. The supplier's SOC artifact package is delivered by the supplier and is delivered to the CI side via email or other means, serving as one of the inputs for the SOC whole package integration. The model files are provided by the development side and need to be integrated or deployed along with the SOC whole package. The above three types of files constitute the input files for creating the SOC whole package. By placing the input files uniformly in the input folder, the backend script can read and process based on a fixed directory, without requiring CI personnel to manually switch directories or enter complex paths.

[0033] Step S102 receives the product package name input and responds to the packaging instruction. The CI personnel enter the package name of the final SOC integrated package artifact in the input area of ​​the front-end page. This package name serves as the name of the subsequent packaged output file and is also written into the verification file and description file for product identification and subsequent deployment. After the package name is entered, the CI personnel click the "Package" button. The front-end then passes the packaging request, the input package name, and related parameters to the back-end script, which begins the automated packaging process.

[0034] Step S103 checks whether the input files in the input folder meet the preset requirements. The tool checks whether the SOC self-developed product package, supplier SOC product package, and model files in the input folder all exist, and checks whether the number of files in the corresponding directories meets the preset rules. When the input files do not meet the preset requirements, the tool outputs an error message and terminates the package creation process to avoid continuing to execute erroneous integration.

[0035] When the input files meet the preset requirements, the process proceeds to step S104, decompressing the supplier's SOC product package and the SOC self-developed product package. During decompression, the tool decompresses the supplier's SOC product package to a preset temporary directory and verifies the completeness of the decompression result based on the preset directory structure. The tool decompresses the SOC self-developed product package, expands its contents to the preset temporary directory, and prepares it for combination with the supplier's SOC product package and model files. All of the above decompression processes are completed automatically by the tool; CI personnel do not need to manually input decompression commands.

[0036] Step S105 iterates through the `modules` directory in the SOC self-developed artifact package, checking if each module folder under the `modules` directory is empty. The tool iterates through each module folder under the `modules` directory, checking if each module folder contains valid compiled artifacts. If an empty module folder exists, it indicates that an error occurred during the CI pipeline compilation process, or the compiled artifact was not correctly packaged. In this case, the tool outputs an error message and terminates the packaging process. In some implementations, the tool outputs the name of the problematic module in the log area to identify which specific module has a problem. This verification step allows for secondary interception of problems not detected in the CI pipeline, preventing the integration of SOC self-developed artifact packages with missing modules.

[0037] When all module folders under the `modules` directory contain content, the process proceeds to step S106, which packages the supplier's SOC deliverable package, the SOC self-developed deliverable package, and the model files to generate the final SOC integrated package artifact. During the packaging step, the tool combines the supplier's SOC deliverable package, the SOC self-developed deliverable package, and the model files into the final SOC integrated package artifact according to a unified instruction set and configuration rules. This process includes copying the specified directory, replacing changed modules, retaining integrated modules that do not require recompilation, writing model files, and performing compression packaging. Because the above operations are uniformly executed by the tool script, the packaging logic remains consistent even when different CI personnel operate the same project.

[0038] Step S107 saves the SOC integrated packaged product to the output folder. After the SOC integrated packaged product is generated, the tool saves it to the output folder. In some embodiments, the output folder also includes a verification file and a description file. The verification file records the name of the SOC integrated packaged product and its corresponding verification value, and the description file records tutorial information for deploying the software to the vehicle.

[0039] The process of checking whether the input files in the input folder meet the preset requirements in step S103 above can be referred to Figure 2 To understand further. Figure 2 A sub-process for checking whether an input file meets preset requirements is shown, which includes steps S201 to S203.

[0040] In step S201, the tool checks whether the SOC self-developed product package, supplier SOC product package, and model file all exist in the input folder. The tool sequentially confirms whether the input folder contains the files or compressed packages corresponding to the SOC self-developed product package, the files or compressed packages corresponding to the supplier SOC product package, and the model file. If any of the above three types of files is missing, the tool determines that the input file does not meet the preset requirements and outputs an error message in the log area, indicating the missing file type.

[0041] Step S202 checks whether the number of files in the corresponding directory meets the preset rules. In some implementations, for directories that require a unique input file, the tool checks whether there is only one file or folder at each level. For example, when there are multiple candidate files in the directory where the SOC self-developed product package is stored, the tool cannot determine which file should be used for subsequent integration, and in this case, the tool determines that the number of files does not meet the preset rules. In some implementations, the tool also checks whether the file names meet the preset rules, such as checking whether the file names contain preset prefixes, suffixes, or version identifiers. When too many files, too few files, or file names that do not meet the rules are detected, the tool determines that the input files do not meet the preset requirements and outputs the corresponding error information in the log area.

[0042] When the checks in steps S201 and S202 pass, the process proceeds to step S203, where the tool determines that the input files meet the preset requirements and continues with the subsequent decompression and packaging processes. Through these sub-processes, the tool can verify the existence and quantity of input files in the early stages of the packaging process. When it detects that the input files do not meet the preset requirements, it promptly terminates the packaging process, avoiding incorrect integration due to missing or confused input files.

[0043] Based on the input file inspection sub-process described above, the initialization steps before starting the packaging process are explained below. Before receiving the product package name input and responding to the packaging command, the tool performs initialization operations to ensure that the packaging environment is in a usable state.

[0044] The tool clears or resets the output folder. Before each packaging process begins, the tool clears or resets the output folder to prevent files left over from the previous packaging process from interfering with the current packaging result. In some implementations, the tool deletes all files and subdirectories under the output folder and recreates an empty output folder structure. In other implementations, the tool retains the output folder itself and only clears its contents. By clearing or resetting the output folder, the tool ensures that the output results of each packaging process are independent of each other, avoiding confusion between historical and current artifacts.

[0045] The tool reads a configuration file, which stores path parameters, file naming rules, and project-specific configurations required for package creation. Path parameters include the input folder path, output folder path, temporary directory path, and storage paths for various artifact packages. File naming rules define the naming format for the SOC integrated package artifacts, verification files, and documentation files, including filename prefixes, suffixes, version identifiers, and timestamp formats. Project-specific configurations differentiate the package creation rules for different projects, enabling the backend script to execute the corresponding package creation rules for each project during package creation. In some implementations, the configuration file is stored in JSON or YAML format, and the backend script parses the configuration file and loads the configuration parameters upon startup. In some implementations, the configuration file also stores cloud disk upload configuration information, including parameters such as the cloud disk address, access credentials, and upload target path.

[0046] The tool creates a temporary directory to store decompressed files and intermediate processing results. This temporary directory serves as the workspace during the packaging process, storing the decompressed contents of supplier SOC product packages and SOC self-developed product packages, as well as intermediate files generated during packaging. In some implementations, the tool creates a new temporary directory at the start of each packaging process and cleans up its contents after the process ends.

[0047] The tool checks whether the script's runtime environment meets the requirements. In some implementations, the tool checks whether the necessary dependencies for package creation are installed in the current runtime environment, such as compression / decompression tools, file verification tools, and file transfer tools. When the runtime environment lacks these dependencies, the tool outputs a message in the log area.

[0048] The tool verifies whether its execution permissions meet the requirements. In some implementations, the tool checks whether the current user has read and write permissions to the input folder, output folder, and temporary directory, as well as execution permissions to the backend script. If the execution permissions do not meet the requirements, the tool outputs a permission error message in the log area. Through the above initialization steps, the tool completes environment preparation and configuration loading before formally executing the package creation process, providing the basic conditions for subsequent operations such as file upload, input checking, decompression, and packaging.

[0049] After the above initialization steps are completed and the input folder passes verification, the tool enters the decompression stage. The decompression stage decompresses both the supplier's SOC product package and the SOC self-developed product package separately, preparing the file content for subsequent module verification and overall packaging operations.

[0050] The tool decompresses the supplier's SOC deliverable package. During decompression, the tool extracts the supplier's SOC deliverable package to a preset temporary directory and verifies the completeness of the decompression result based on the preset directory structure. In some implementations, the tool checks whether the decompressed directory hierarchy and file distribution meet expectations to ensure that the contents of the supplier's SOC deliverable package can be correctly read and subsequently processed.

[0051] The tool decompresses the SOC self-developed artifact package. It expands the contents of the SOC self-developed artifact package to a preset temporary directory, preparing it for combination with the supplier's SOC artifact package and model files. After decompression, the tool can access the modules directory and individual module folders within the SOC self-developed artifact package, providing a foundation for subsequent module integrity verification.

[0052] The entire decompression process described above is completed automatically by the tool; CI personnel do not need to manually enter commands such as tar, unzip, cp, and mv. Through automated decompression, the tool can process product packages from different sources according to uniform decompression rules, avoiding decompression failures or file overwriting issues caused by incorrect parameters or paths when CI personnel manually enter decompression commands.

[0053] After the above decompression stage is completed, the tool enters the packaging stage, combining the supplier's SOC product package, the SOC self-developed product package, and the model files into the final SOC integrated package product. Figure 3 The sub-process for packaging and generating SOC integrated whole packaged articles is shown, which includes steps S301 to S305.

[0054] Step S301: Copy the specified directory. The tool copies the specified directory after the supplier's SOC product package is decompressed to a temporary working directory, according to the directory structure defined in the configuration file. In some implementations, the tool copies the directories and files at each level of the supplier's SOC product package to the corresponding target locations according to preset directory mapping rules. During the copying process, the tool maintains the original directory hierarchy to ensure that subsequent module replacement and file writing operations can correctly locate the target path.

[0055] Step S302 replaces the changed modules. When this project involves changes to some modules, the tool retrieves the recompiled module artifacts from the uncompressed SOC self-developed artifact package and replaces the corresponding modules in the entire package according to unified rules. In some implementations, the tool identifies the changed modules in the SOC self-developed artifact package based on the module replacement rules defined in the configuration file, and copies the changed modules to the corresponding locations in the copied directory in step S301, overwriting the original module files. Through this replacement operation, the tool can integrate the latest compiled self-developed modules into the final SOC package.

[0056] Step S303 retains integrated modules that do not require recompilation. When the project falls under the scenario where compiled integrated modules do not require recompilation, the tool directly reuses the existing module artifacts and incorporates them into the final SOC package. In some implementations, the tool identifies integrated modules that do not require recompilation based on the module retention rules defined in the configuration file and maintains the original content of these modules unchanged during the packaging process. Through this retention operation, the tool can be compatible with both integration scenarios that do not require recompilation and scenarios where modules are changed and recompiled to replace the integrated modules.

[0057] Step S304: Write the model file. The tool writes the model file provided by the development team to a specified location in the entire package directory. In some implementations, the tool copies the model file to the corresponding location in the entire package directory structure according to the model file storage path defined in the configuration file. After the model file is written, it is integrated with the SOC entire package so that it can be correctly loaded and used when deployed to the vehicle.

[0058] Step S305 performs a compression and packaging operation to generate the SOC integrated package artifact. The tool performs a compression and packaging operation on the integrated directory to generate the final SOC integrated package artifact. In some implementations, the tool compresses the integrated directory into a single compressed file according to the compression format and naming rules defined in the configuration file, and uses the artifact package name entered by the CI personnel on the front-end page as the compressed file name. After the compression and packaging operation is completed, the SOC integrated package artifact is generated in a temporary directory, waiting to be saved to the output folder later.

[0059] During the packaging process, the tool adjusts the directory structure to conform to the preset structure requirements of the final SOC package. In some implementations, the tool adjusts the integrated directory according to the directory structure specifications defined in the configuration file, including creating missing subdirectories, moving files to specified locations, and deleting unnecessary temporary files. Through directory structure adjustments, the tool ensures that the final generated integrated SOC artifact meets the directory hierarchy and file distribution specifications required for vehicle deployment.

[0060] Since steps S301 to S305 are all executed uniformly by the tool script, the same project can still maintain consistent packaging logic when operated by different CI personnel, avoiding differences in products caused by different CI personnel using different commands or parameters.

[0061] After the SOC integrated packaged product is generated and saved to the output folder, the tool enters the stage of generating verification and instruction files, and decides whether to upload the product to the cloud disk based on the operation instructions of the CI personnel. Figure 4 The sub-process for generating a verification file and a description file and uploading them to a cloud drive is shown. This sub-process includes steps S401 to S405.

[0062] Step S401 calculates the checksum of the SOC integrated package artifact. The tool performs a checksum calculation operation on the generated SOC integrated package artifact to obtain the integrity identifier of the SOC integrated package artifact. In some implementations, the checksum is the MD5 value. The tool performs a hash calculation on the SOC integrated package artifact file using the MD5 algorithm to obtain a fixed-length MD5 checksum. This MD5 checksum is used to perform integrity verification on the SOC integrated package artifact during subsequent artifact uploading, downloading, deployment, or delivery, thereby determining whether the SOC integrated package artifact has been damaged or incorrectly replaced during transmission or storage.

[0063] Step S402 generates a verification file in the output folder. The tool creates a verification file in the output folder, which records the name of the SOC integrated packaged product and its corresponding verification value. In some implementations, the verification file is named checksum.txt, and the checksum.txt file records the product name of the SOC integrated packaged product and the MD5 value calculated in step S401. Using the verification file, relevant personnel can verify the integrity of the SOC integrated packaged product after receiving it based on the MD5 value recorded in the verification file.

[0064] Step S403 generates a documentation file in the output folder. The tool creates a documentation file in the output folder, which records tutorial information for deploying the software to the vehicle. In some implementations, the documentation file is named readme.txt, and the readme.txt file includes the artifact name, deployment target, deployment order, basic operation instructions, precautions, or other instructions related to this package creation. By having the tool uniformly generate the documentation file, the workload of CI personnel manually writing deployment instructions can be reduced, and significant differences in the format of deployment instructions output by different CI personnel can be avoided.

[0065] Step S404 determines whether an upload command has been received. After the verification file and specification file are generated, the tool waits for the CI personnel's operation command. In some implementations, the CI personnel trigger the upload command through the upload button provided on the front-end page. When the tool receives the upload command, the process proceeds to step S405 to perform the cloud disk upload operation; when the tool does not receive the upload command, the process ends, and the CI personnel directly access the output folder to obtain the SOC integrated package artifact and related output files.

[0066] Step S405 responds to the upload command, uploading the SOC integrated package artifact and related output files from the output folder to the cloud drive. Based on parameters such as the cloud drive address, access credentials, and upload target path saved in the configuration file, the tool uploads the SOC integrated package artifact, verification files, and instruction files from the output folder to the cloud drive. After the upload is complete, the tool outputs the upload result in the log area. In some implementations, the tool displays a success message, file name, file size, or file path on the front-end page to allow CI personnel to confirm the upload result.

[0067] If the upload fails, the tool retains the SOC integrated package artifact and related output files in the local output folder, and displays the reason for the failure in the log area. By retaining the local artifact and outputting the reason for the failure, CI personnel can troubleshoot network, permission, or path issues based on the log information, and re-execute the upload operation after resolving the problem.

[0068] Based on the upload steps described above, the following section explains the log output and front-end interaction during the package creation process. During the package creation process, the tool outputs execution information to the log area of ​​the front-end page in real time. This information includes the execution steps and the reasons for any exceptions.

[0069] The front-end page includes a log printing area, which prints execution information such as INFO, SUCCESS, and ERROR in real time during tool execution, allowing CI personnel to intuitively see the currently executed steps and the reasons for any exceptions. In some implementations, the tool outputs execution information to the front-end log area at each step. For example, it outputs the start time and task name when package creation begins, a cleanup success message after clearing the output folder, a check success message after input checks pass, a decompression success message after decompressing the supplier's SOC artifact package and the SOC's self-developed artifact package, and the name of the exception module when the modules directory check fails. Through this log output, CI personnel can monitor the package creation progress directly on the front-end page without needing to access the back-end server to check the script execution status.

[0070] The front-end login function uses the `login.py` script to handle authentication logic related to login and upload. In some implementations, the front-end page's button control area includes operation buttons such as a login button, a one-click package creation button, and a one-click upload button. When a CI user triggers the login operation via the login button, the front-end forwards the login request to the back-end, which then calls the `login.py` script to execute the authentication logic. The `login.py` script verifies the CI user's identity information and, upon successful authentication, allows the CI user to perform subsequent package creation and upload operations.

[0071] After successful packaging, the tool outputs the SOC integrated package generation path in the log area. In some implementations, the tool outputs a success message after the checksum.txt and readme.txt files are generated. By outputting the SOC integrated package generation path in the log area, CI personnel can quickly locate the final artifact's storage location.

[0072] When the packaging process is successfully executed, a pop-up window on the front-end page indicates successful packaging, and the output area displays the path or file name of the final product. In some implementations, the output area displays the file name, file size, or file path of the SOC integrated packaged artifact. Through the pop-up window and the output area display, CI personnel can intuitively confirm the packaging results and obtain the final product based on the displayed path or file name.

[0073] Figure 5 A block diagram of a software package integration and automated product generation system based on a SOC chip is shown. (Refer to...) Figure 5 The software package integration and automatic product generation system based on SOC chip includes an upload module, an instruction receiving module, an inspection module, a decompression module, a verification module, an exception handling module, a packaging module, and a storage module.

[0074] The upload module is used to upload SOC self-developed product packages, supplier SOC product packages, and model files to the input folder. In some implementations, the upload module provides a file selection interface, through which CI personnel select locally stored SOC self-developed product packages, supplier SOC product packages, and model files. The upload module then transfers the selected files to the corresponding subdirectories in the input folder. The upload module is connected to the instruction receiving module, which can obtain file information from the input folder after the file upload is complete.

[0075] The instruction receiving module receives the product package name input and responds to packaging instructions. CI personnel enter the package name of the SOC integrated packaged product in the input area of ​​the front-end page, and the instruction receiving module receives this package name input. When the CI personnel click the "Make Package" button, the instruction receiving module responds to the packaging instruction and passes the package name and packaging request to subsequent modules. The instruction receiving module is connected to the inspection module; after the packaging instruction is triggered, the inspection module begins performing input file inspection operations.

[0076] The inspection module checks whether the input files in the input folder meet preset requirements. It checks whether the SOC self-developed product package, supplier SOC product package, and model files all exist in the input folder, and whether the number of files in the corresponding directories meets preset rules. If the input files do not meet the preset requirements, the inspection module outputs an error message and terminates the package creation process. The inspection module is connected to the decompression module; when the input files meet the preset requirements, the decompression module begins the decompression operation.

[0077] The decompression module is used to decompress the supplier's SOC product package and the SOC self-developed product package when the input file meets preset requirements. The decompression module decompresses the supplier's SOC product package to a preset temporary directory and expands the contents of the SOC self-developed product package to the preset temporary directory. The decompression module is connected to the verification module; after the decompression operation is complete, the verification module can access the decompressed file contents.

[0078] The verification module iterates through the `modules` directory in the SOC self-developed artifact package, determining whether each module folder under `modules` is empty. It checks each module folder within `modules` to see if a valid compiled artifact exists. The verification module is connected to the packaging module; when all module folders under `modules` contain content, the packaging module begins the packaging operation. The verification module is also connected to the exception handling module; when an empty module folder is detected, the verification module passes the exception information to the exception handling module.

[0079] The exception handling module outputs exception information and terminates the packaging process when an empty module folder exists. The exception handling module receives exception information from the verification module, outputs the name of the exception module in the log area, and terminates subsequent packaging and saving operations. In some implementations, the exception handling module also receives error information from the checking module; when the input file does not meet preset requirements, the exception handling module outputs a corresponding error message.

[0080] The packaging module is used to package the supplier's SOC artifact package, the SOC self-developed artifact package, and the model files into a complete SOC integrated artifact when all module folders under the modules directory contain content. The packaging module performs operations such as copying specified directories, replacing changed modules, retaining integrated modules that do not require recompilation, writing model files, and performing compression packaging according to a unified instruction set and configuration rules. The packaging module is connected to the saving module; after the complete SOC integrated artifact is generated, the saving module performs the saving operation.

[0081] The save module is used to save the SOC integrated packaged artifact to the output folder. The save module moves or copies the SOC integrated packaged artifact generated by the packaging module from the temporary directory to the output folder. In some implementations, the save module also saves verification files and instruction files to the output folder.

[0082] In some implementations, the SOC chip-based software package integration and automated artifact generation system further includes a backend database functional unit. This backend database functional unit is used to store packaging tasks, upload records, artifact information, log information, or historical execution results. In some implementations, the backend database functional unit records the task identifier, execution time, execution status, and execution result of each packaging task. In some implementations, the backend database functional unit stores upload records, including upload time, uploaded file name, upload target path, and upload status. In some implementations, the backend database functional unit stores artifact information, including the name, version, generation time, and checksum of the SOC integrated package artifact. In some implementations, the backend database functional unit stores log information, including execution information such as INFO, SUCCESS, and ERROR output during the packaging process. In some implementations, the backend database functional unit stores historical execution results, allowing CI personnel to retrieve the execution status and artifact information of historical packaging tasks by querying the backend database functional unit.

[0083] This invention also discloses a readable storage medium.

[0084] A computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments. The computer-readable storage medium may include any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. The computer program includes computer program code. The computer program code may be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable storage medium may include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0085] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0086] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for software integration and automated product generation based on a SOC chip, characterized in that, include: Upload the SOC self-developed product package, the supplier's SOC product package, and the model files to the input folder; Receives product package name input and responds to packaging instructions; Check whether the input files in the input folder meet the preset requirements; When the input file meets the preset requirements, decompress the supplier's SOC product package and the SOC self-developed product package; Traverse the modules directory in the SOC self-developed product package and determine whether each module folder under the modules directory is empty; If an empty module folder exists, output an error message and terminate the package creation process; When each module folder under the modules directory contains content, the supplier's SOC product package, the SOC self-developed product package, and the model file are packaged together to generate an integrated SOC product package. as well as Save the SOC integrated packaged product to the output folder.

2. The method according to claim 1, characterized in that, The method further includes: Calculate the verification value of the SOC integrated packaged product; and A verification file is generated in the output folder. The verification file records the name of the SOC integrated packaged product and its corresponding verification value.

3. The method according to claim 2, characterized in that, The verification value is the MD5 hash.

4. The method according to claim 1, characterized in that, The method further includes: A documentation file is generated in the output folder, which records tutorial information for deploying the software to the vehicle.

5. The method according to claim 1, characterized in that, The step of checking whether the input files in the input folder meet the preset requirements includes: Check whether the self-developed SOC product package, the supplier's SOC product package, and the model file all exist in the input folder; and Check if the number of files in the corresponding directory meets the preset rules.

6. The method according to claim 1, characterized in that, Before receiving the product package name input and responding to the packaging instruction, the method further includes: Clear or reset the output folder; and Read the configuration file, which stores the path parameters, file naming rules, and project-specific configurations required for package creation.

7. The method according to claim 1, characterized in that, The method further includes: During the packaging process, execution information is output to the log area of ​​the front-end page in real time. The execution information includes the execution steps and the reasons for any exceptions.

8. The method according to claim 1, characterized in that, The step of packaging the supplier's SOC product package, the SOC self-developed product package, and the model file to generate an integrated SOC product package includes: Copy the specified directory; Replace the changed module; Retain integrated modules that do not require recompilation; Write to the model file; and Perform a compression and packaging operation.

9. The method according to claim 1, characterized in that, The method further includes: In response to the upload command, the SOC integrated package product and related output files in the output folder are uploaded to the cloud drive.

10. The method according to claim 1, characterized in that, The self-developed SOC product package is obtained by compiling and packaging the self-developed source code through a continuous integration pipeline, while the supplier's SOC product package is delivered by the supplier.

11. A software package integration and automated product generation system based on a SOC chip, characterized in that, include: The upload module is used to upload SOC self-developed product packages, supplier SOC product packages, and model files to the input folder; The instruction receiving module is used to receive the product package name input and respond to the packaging instruction; The inspection module is used to check whether the input files in the input folder meet the preset requirements; The decompression module is used to decompress the supplier's SOC product package and the SOC self-developed product package when the input file meets the preset requirements. The verification module is used to traverse the modules directory in the SOC self-developed product package and determine whether each module folder under the modules directory is empty; The exception handling module is used to output exception information and terminate the package creation process when an empty module folder exists. The packaging module is used to package the supplier's SOC product package, the SOC self-developed product package, and the model file into an integrated SOC product package when each module folder under the modules directory contains content. as well as The save module is used to save the SOC integrated packaged product to the output folder.

12. A readable storage medium, characterized in that, The readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-10.

Images