Vehicle bottom software compiling method, system, device and medium

Abstract

The application relates to the technical field of vehicle control, in particular to a whole vehicle bottom layer software compiling method, system, device and medium, the method comprising the following steps: obtaining a compiling requirement text, a target address path and target application hardware of whole vehicle bottom layer software; determining target source code of the whole vehicle bottom layer software according to the compiling requirement text and the target address path, and calling a target server according to the target application hardware of the whole vehicle bottom layer software; and compiling the whole vehicle bottom layer software according to the target server and the target source code. Therefore, the problems of low manual compiling efficiency and difficult software change tracing are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle control technology, and in particular to a method, system, device and medium for compiling low-level software for a vehicle. Background Technology

[0002] The compilation of the underlying software for the entire vehicle relies on manual operation to complete the entire process of code registration, compilation, and encapsulation. Component adaptation is cumbersome in multi-model, multi-version development scenarios. Cross-project reuse of software components is difficult. During software iteration, version files are stored in a scattered manner, modification records are archived in inconsistent formats, and it is difficult to fully trace the software change trajectory. Summary of the Invention

[0003] This application provides a method, system, device, and medium for compiling the underlying software of a vehicle, in order to solve the problems of low efficiency of manual compilation and difficulty in tracing software changes in related technologies.

[0004] The first aspect of this application provides a method for compiling vehicle-level software, comprising the following steps: obtaining compilation requirement text, target address path, and target application hardware of the vehicle-level software; determining the target source code of the vehicle-level software based on the compilation requirement text and target address path; calling a target server based on the target application hardware of the vehicle-level software; and compiling the vehicle-level software based on the target server and the target source code.

[0005] Based on the above technical means, the embodiments of this application simultaneously acquire three types of information: compilation requirement text, target address path, and target application hardware. First, by combining the compilation requirement text and target address path, the target source code corresponding to the vehicle's underlying software is accurately located. Then, based on the target application hardware, the appropriate target server is called, and the vehicle's underlying software is automatically compiled in conjunction with the target source code. There is no need for manual screening of source code or manual selection of compilation services, which can significantly reduce the workload of manual operation. At the same time, compilation servers can be matched for different hardware, adapting to the underlying software compilation scenarios of multiple vehicle models and multiple hardware platforms, thus broadening the scope of software compilation compatibility.

[0006] Optionally, obtaining the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software includes: identifying the user's first and second interactive actions on the target interactive interface; inputting compilation-related information on the target interactive interface based on the first interactive action; and triggering a filtering operation based on the second interactive action to filter the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software based on the compilation-related information.

[0007] Based on the above technical means, the embodiments of this application rely on the target interactive interface to identify two types of user interaction actions, and input compilation-related information and trigger filtering logic through corresponding interaction actions. The compilation requirement text, target address path and target application hardware are automatically filtered out based on the interface interaction, which simplifies the pre-compilation information collection process, reduces the difficulty of users manually organizing and inputting compilation information, and improves the convenience of obtaining information in the early stage of underlying software compilation.

[0008] Optionally, the compilation requirement text and target application hardware of the vehicle's underlying software are filtered based on compilation-related information, including: extracting the project name, hardware name, and software code from the compilation-related information; querying the database based on the project name, hardware name, and software code to retrieve the compilation requirement text, target address path, and target application hardware of the vehicle's underlying software from the database.

[0009] Based on the above technical means, this application embodiment extracts the project name, hardware name and software code from the input compilation-related information, and then uses the extracted content to search the database to automatically retrieve the matching compilation requirement text, target address path and target application hardware, eliminating the need for manual searching and verification of various compilation-related materials, and improving the efficiency of matching and retrieving the information required for compilation.

[0010] Optionally, the target source code of the vehicle's underlying software is determined based on the compilation requirements text and the target address path, including: extracting information about each component from the compilation requirements text; constructing a target compilation script based on the information about each component; and obtaining the target source code from the target address path based on the target compilation script.

[0011] Based on the above technical means, the embodiments of this application extract the information of each component in the compilation requirement text and generate the corresponding compilation script. The target source code is automatically retrieved from the target address path based on the compilation script, eliminating the need for manual processing of each component and manual code acquisition, simplifying the source code acquisition process and improving the automation level of target source code retrieval.

[0012] Optionally, the target server is invoked based on the target application hardware of the vehicle's underlying software, including: obtaining a mapping table between the identifier of the target application hardware and the target server; and querying the mapping table using the identifier of the target application hardware as an index to obtain the target server.

[0013] Based on the above technical means, the embodiments of this application rely on the mapping relationship table between hardware identifiers and servers for index query, which can quickly match the corresponding target server according to the target application hardware, without the need for manual judgment of hardware compatibility compilation services, realize automatic scheduling of compilation servers, and adapt to multiple types of hardware parallel compilation scenarios.

[0014] Optionally, the underlying software of the vehicle is compiled based on the target server and the target source code, including: inputting the target source code into the target server; compiling the target source code through the target server; and uploading the data target address path based on the compilation result of the target source code.

[0015] Based on the above technical means, the embodiments of this application automatically compile the target source code to the matched target server and automatically upload the compiled output data to the corresponding target address path, eliminating the step of manually uploading the compilation product, realizing the automation of the compilation and product archiving process, and reducing manual intervention.

[0016] Optionally, the data target address path is uploaded based on the compilation result of the target source code, including: identifying the compilation result of the target source code; if the compilation result of the target source code is identified as a compilation failure, then the error log content of the target server is obtained and the error log content is uploaded to the target address path; if the compilation result of the target source code is identified as a compilation success, then the software package corresponding to the vehicle underlying software compiled by the target server is obtained and the software package corresponding to the vehicle underlying software is uploaded to the target address path.

[0017] Based on the above technical means, the embodiments of this application intelligently identify the compilation results of the source code. For both successful and failed compilation scenarios, the corresponding software packages and error log contents are automatically uploaded to the target address path, thereby realizing the classification, archiving and unified retention of the compilation results, ensuring that the compilation process is recordable and traceable, and effectively facilitating subsequent problem investigation and version management.

[0018] The second aspect of this application provides a vehicle underlying software compilation system, including: a master server and at least one slave server mounted on the master server; the master server is provided with an interactive interface, and the target source code of the vehicle underlying software is determined based on the interactive data of the interactive interface and the target server is called to execute the vehicle underlying software compilation method as described in the above embodiment, wherein the target server is one of the slave servers.

[0019] Based on the above technical means, the embodiments of this application construct a layered compilation system architecture by using a master server and mounted slave servers. By relying on the interactive interface of the master server to obtain interactive data, the target source code is automatically determined and the corresponding slave server is scheduled as the target server to execute the compilation process, thereby realizing unified scheduling and centralized management of compilation resources and ensuring the orderly, stable and automated operation of the vehicle's underlying software compilation process.

[0020] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The processor executes the program to implement the vehicle-level software compilation method as described in the above embodiments.

[0021] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the vehicle-level software compilation method as described in the above embodiments.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a method for compiling low-level software for a vehicle according to an embodiment of this application. Figure 2 This refers to the target interactive interface provided according to the embodiments of this application; Figure 3 This is a server hierarchy architecture diagram provided according to an embodiment of this application; Figure 4 This is a diagram illustrating the manual compilation process of MDGB according to an embodiment of this application; Figure 5 This is a technical roadmap for the continuous integration platform provided according to embodiments of this application; Figure 6 This is an architecture diagram of the vehicle underlying software compilation system provided according to an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0025] For the development process of automotive controller software, the underlying driver, as the isolation layer between hardware and application software, is directly related to the independent development and module encapsulation of specific hardware systems. The development and encapsulation of the underlying software can prevent hardware changes from causing overall program changes, which is of great significance for shortening the development cycle, centralizing the integration of changes, and standardizing compilation and management.

[0026] Currently, continuous integration and compilation technology for vehicle software has been widely researched and applied. This technology can automate basic processing functions such as code verification, integration compilation, version recording, and software integration for scenarios including source code submissions, component version changes, and software integration requests. It can improve software compilation and integration efficiency, enable basic version traceability, and optimize system resource utilization to a certain extent. As the underlying software functions of automakers continue to expand and the level of vehicle intelligence continues to increase, the scale and complexity of software systems are also increasing. Consequently, the industry's requirements for the refinement, automation, and platformization of underlying software integration, encapsulation, and version control are also significantly rising.

[0027] In practical applications of related technologies for underlying software development and packaging, relying on supporting compilation software, the following shortcomings still exist: First, development efficiency is low. Different vehicle models and projects have different positioning and diverse testing specifications, which frequently trigger the need for version updates of components within the integration library. However, these technologies rely on manual completion of the entire software integration and packaging process, requiring manual identification of compatible components, verification of version compatibility, and adjustment of configuration parameters. The overall process is cumbersome, labor-intensive, and prone to human error, significantly extending the software development cycle and failing to achieve cost reduction and efficiency improvement. Second, scalability is limited. A unified and standardized platform management framework has not been established, making it difficult to address multi-platform and cross-platform challenges. In development scenarios involving multiple software iterations, the inability to flexibly allocate development resources and reuse existing development results makes it difficult to port and adapt software components across projects, hindering product line expansion and rapid software iteration capabilities. Furthermore, the imperfect data traceability mechanism makes it difficult to effectively integrate historical software versions, accurately trace software change trajectories, and finely manage development change records. During software iteration, historical versions are stored in a scattered manner without systematic archiving, and change records are often disorganized and incomplete, making it impossible to fully trace operational details, clarify the reasons for changes, and understand their impact. This easily leads to redundant development, difficulties in troubleshooting, and ineffective software quality control, resulting in a significant waste of development resources.

[0028] In summary, the related technologies for compiling and integrating vehicle-level software have low levels of automation, lack a unified platform management system, and have weak data traceability capabilities, making it difficult to meet the current needs for efficient development and refined management of highly complex, multi-version, and cross-project vehicle-level software.

[0029] The following description, with reference to the accompanying drawings, outlines a method, system, device, and medium for compiling vehicle-level software according to embodiments of this application. Addressing the issues of low efficiency and difficulty in tracing software changes arising from manual compilation mentioned in the background, this application provides a continuous integration and compilation solution for vehicle-level software. Based on a Jenkins (open-source automated continuous integration master server) server architecture and mounted with an MDGB (scripting programming language) server, a continuous integration platform for vehicle-level software is built through secondary development using Python (scripting programming language). This platform is adaptable to the integrated development of vehicle controller software for various vehicle types, including hybrid, pure electric, and range-extended electric vehicles.

[0030] This application abandons the manual compilation and packaging mode, and builds an automated, scalable, and traceable underlying software development system. Relying on a Jenkins service architecture powered by an MDGB server, it obtains software development requirements and retrieves SVN (Subversion, source code version control repository) component information through a visual build interface. It automatically calls the MDGB server to complete the project build, simultaneously performing code checks and error log collection during the compilation process, and automatically uploading the build artifacts and error logs to the corresponding SVN paths. This application can visually display the build task execution time, task running status, and platform iteration information, automatically generate software codenames corresponding to build tasks, support multi-dimensional build task filtering, batch import of build parameters from Excel files, and public disk upload and storage of software package artifacts. It also adds a Matlab (model simulation tool) multi-compiler intelligent scheduling mechanism to automatically complete the model-to-code conversion process, upload the converted code back to SVN, and automatically verify the model-to-code build rules.

[0031] In addition, this application configures task management functions and a data dashboard module, and sets up a manually stop build function with controllable permissions. Only the user who triggered the task can terminate a build task that is in a running state. After a task is manually canceled, a notification is automatically pushed to the user who triggered it. Tasks that are not in a build state cannot be terminated, and users who are not the users who triggered the task do not have the permission to stop the task. The data dashboard centrally displays information about Jenkins-related projects, projects that are currently being executed, and projects that are in the queue to be executed.

[0032] Meanwhile, this application establishes a distributed platform management architecture for continuous integration of vehicle underlying software. It combines a database to classify and archive software versions in multiple dimensions, supports querying software change history and full-process traceability, and effectively solves the drawbacks of cumbersome manual operation, long development cycle, poor resource reusability, chaotic version management, and difficulty in troubleshooting related underlying software development. It achieves cost reduction and efficiency improvement, continuous integration, and refined quality control in the integrated development of vehicle underlying software.

[0033] Specifically, Figure 1This is a flowchart illustrating a method for compiling low-level software for a vehicle, as provided in an embodiment of this application.

[0034] like Figure 1 As shown, the method for compiling the underlying software of the vehicle includes the following steps: In step S101, the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software are obtained.

[0035] It is understood that the embodiments of this application uniformly obtain the requirement text, storage path and application hardware information required for compilation, complete the data collection work in the early stage of compilation, provide basic data support for the subsequent determination of source code and calling the corresponding server, and ensure the orderly progress of the subsequent compilation process.

[0036] In this embodiment of the application, obtaining the compilation requirement text, target address path, and target application hardware of the vehicle's underlying software includes: identifying the user's first and second interactive actions on the target interactive interface; inputting compilation-related information on the target interactive interface based on the first interactive action; and triggering a filtering operation based on the second interactive action to filter the compilation requirement text, target address path, and target application hardware of the vehicle's underlying software based on the compilation-related information.

[0037] It is understood that the embodiments of this application rely on the target interactive interface to identify two types of user interaction actions. Through the corresponding interaction actions, compilation-related information is entered and the filtering logic is triggered. The compilation requirement text, target address path and target application hardware are automatically filtered out based on the interface interaction, which simplifies the pre-compilation information collection process, reduces the difficulty of users manually organizing and entering compilation information, and improves the convenience of obtaining information in the early stage of underlying software compilation.

[0038] It should be noted that: The compilation requirements text is a requirements file that records the metadata of the entire vehicle software project, information on various functional components, and compilation configuration parameters, used to generate SVN build scripts; the target address path is a dedicated storage directory path in the R&D intranet SVN repository used to store source code, compiled software packages, and error logs; the target application hardware refers to various vehicle controller hardware, including MCU (Microcontroller Unit), PDCU (Power Distribution Control Unit), BMS (Battery Management System), VCU (Vehicle Control Unit), and other vehicle controllers; the target interactive interface is such as... Figure 2As shown, the project list visualization operation interface of the continuous integration platform for the vehicle's underlying software is used to enter compilation parameters and search for projects. The first interactive action is for the user to enter compilation-related parameters such as project name, controller model, and software code on the target interactive interface. The second interactive action is for the user to click the filter button on the interactive interface to trigger the data retrieval and matching operation of the continuous integration platform for the vehicle's underlying software.

[0039] Specifically, the user first Figure 2 The first interactive action is performed on the project list interface. The basic filter conditions, such as project name, controller hardware name, and software name, are filled in in the input box at the top of the page. The second interactive action is completed by clicking the filter button. The vehicle underlying software continuous integration platform searches for and matches the corresponding project. Then, the project parameter pop-up window is opened to enter the complete compilation parameters, such as vehicle model, version, and SVN source code path of each module. The compilation requirement text, SVN target address path, and adapted controller hardware information are fully collected.

[0040] In this embodiment of the application, the compilation requirement text and target application hardware of the vehicle's underlying software are filtered based on compilation-related information, including: extracting the project name, hardware name and software code from the compilation-related information; querying the database based on the project name, hardware name and software code to retrieve the compilation requirement text, target address path and target application hardware of the vehicle's underlying software from the database.

[0041] It is understood that the embodiments of this application extract the project name, hardware name and software code from the input compilation-related information, and then use the extracted content to search the database to automatically retrieve the matching compilation requirement text, target address path and target application hardware, saving the manual search and verification of various compilation supporting materials and improving the efficiency of matching and retrieving the information required for compilation.

[0042] Specifically, the vehicle's underlying software continuous integration platform extracts the project name, controller hardware model, and software code entered in the pop-up window as search keywords, queries the built-in database, and directly retrieves the project's pre-stored component compilation requirements, SVN storage paths of each module, and adapted vehicle controller hardware information.

[0043] In step S102, the target source code of the vehicle's underlying software is determined based on the compilation requirements text and the target address path, and the target server is called based on the target application hardware of the vehicle's underlying software.

[0044] It is understood that the embodiments of this application rely on the compilation requirements and address paths to accurately determine the required target source code, and at the same time call the corresponding target server according to the adapted application hardware to realize the automated matching of source code location and compilation server call, thereby improving the accuracy of compilation resource matching.

[0045] In this embodiment, determining the target source code of the vehicle's underlying software based on the compilation requirement text and the target address path includes: extracting information about each component from the compilation requirement text; constructing a target compilation script based on the information about each component; and obtaining the target source code from the target address path based on the target compilation script.

[0046] It is understood that the embodiments of this application extract the information of each component in the compilation requirement text and generate the corresponding compilation script. The target source code is automatically retrieved from the target address path based on the compilation script. There is no need to manually process each component and manually obtain the code, which simplifies the source code acquisition process and improves the automation of target source code retrieval.

[0047] It should be noted that the target source code is the .c and .h format program code of the vehicle's underlying software stored in the SVN path; the target compilation script is an SVN pull script automatically generated based on component information, used to read the target source code in the SVN repository.

[0048] Specifically, the vehicle's underlying software continuous integration platform parses complete component information and SVN addresses of each module in the parameter pop-up window, automatically generates SVN build scripts, and after executing the scripts, batch pulls the vehicle's underlying software source code from the matched SVN target address path. The execution progress of this process can be viewed visually on the build details page.

[0049] In this embodiment of the application, calling the target server based on the target application hardware of the vehicle's underlying software includes: obtaining a mapping table between the identifier of the target application hardware and the target server; and querying the mapping table using the identifier of the target application hardware as an index to obtain the target server.

[0050] It is understood that the embodiments of this application rely on the mapping table between hardware identifiers and servers for index lookup, which can quickly match the corresponding target server based on the target application hardware, without the need for manual judgment of hardware compatibility compilation services, and realize automatic scheduling of compilation servers to adapt to multiple types of hardware parallel compilation scenarios.

[0051] It should be noted that the target server is the MDGB slave server mounted on the Jenkins master server, used for the PDCU vehicle-level software integration and compilation; the mapping table is a data table that pre-stores the association between the unique identifier of the controller hardware and the corresponding compilation server. Figure 3 Server-level architecture.

[0052] Specifically, the vehicle's underlying software continuous integration platform reads the filtered controller hardware identifiers such as MCUs and PDCUs, retrieves the mapping table between the hardware and the compilation server for index lookup, and automatically calls the MDGB compilation server adapted to the hardware to carry out integration work.

[0053] In step S103, the underlying software of the vehicle is compiled based on the target server and the target source code.

[0054] It is understood that the embodiments of this application compile the target source code by matching the target server, thereby realizing the automated compilation of the vehicle's underlying software, simplifying the compilation process, replacing the manual compilation method, and effectively improving the compilation efficiency of the vehicle's underlying software.

[0055] In this embodiment of the application, compiling the underlying software of the vehicle based on the target server and the target source code includes: inputting the target source code into the target server; compiling the target source code through the target server; and uploading the data target address path based on the compilation result of the target source code.

[0056] It is understood that the embodiments of this application send the target source code to the matched target server to complete automatic compilation, and automatically upload the compilation output data to the corresponding target address path, eliminating the step of manually uploading the compilation product, realizing the automation of the compilation and product archiving process, and reducing manual intervention.

[0057] Specifically, the vehicle's underlying software continuous integration platform pushes the retrieved source code to the matching MDGB server. The server then sequentially performs code copying and integration compilation operations. The progress of each step is displayed visually on the build details page using color blocks. After compilation, the build results are distinguished, and the corresponding data is automatically uploaded to the preset SVN storage path.

[0058] In this embodiment of the application, uploading data to the target address path based on the compilation result of the target source code includes: identifying the compilation result of the target source code; if the compilation result of the target source code is identified as a compilation failure, then obtaining the error log content of the target server compilation and uploading the error log content to the target address path; if the compilation result of the target source code is identified as a compilation success, then obtaining the software package corresponding to the vehicle underlying software compiled by the target server and uploading the software package corresponding to the vehicle underlying software to the target address path.

[0059] It is understood that the embodiments of this application intelligently identify the compilation results of the source code. For both successful and failed compilation scenarios, the corresponding software packages and error log contents are automatically uploaded to the target address path, thereby realizing the classification, archiving and unified retention of compilation results, ensuring that the compilation process is recordable and traceable, and effectively facilitating subsequent problem investigation and version management.

[0060] Specifically, the vehicle underlying software continuous integration platform identifies the compilation results output by the MDGB server; when the build fails, it automatically generates a complete compilation error log and uploads it to the corresponding SVN path. Users can view and download the log online on the failure details page to troubleshoot component configuration issues; when the build succeeds, it exports the vehicle underlying software integration package and uploads it to the matching SVN path. The page displays the SVN download address corresponding to the package, and all build records are stored in the history page of the vehicle underlying software continuous integration platform, allowing users to review the details of each software iteration at any time.

[0061] According to the vehicle underlying software compilation method proposed in this application, by simultaneously acquiring three types of information—compilation requirement text, target address path, and target application hardware—the method first accurately locates the target source code corresponding to the vehicle underlying software by combining the compilation requirement text and target address path. Then, it calls the appropriate target server based on the target application hardware and automatically compiles the vehicle underlying software in conjunction with the target source code. This eliminates the need for manual screening of source code and manual selection of compilation services, significantly reducing the workload of manual operations. At the same time, it can match compilation servers for different hardware, adapting to the underlying software compilation scenarios of multi-model and multi-hardware vehicle underlying software continuous integration platforms, thus broadening the scope of software compilation compatibility.

[0062] The following will illustrate the manual compilation process of MDGB in related technologies through a specific embodiment, such as... Figure 4 As shown, the specific steps are as follows: In step S401, when the underlying software and model files are changed, the developers need to manually register all .c and .h format program files in the project one by one. The file registration interface displays a large number of .c and .h source code files under the vehicle communication, diagnostic and functional modules. They need to be manually selected and entered into the MDGB software one by one, and cannot be automatically recognized and imported in batches.

[0063] In step S402, after all source code files are manually registered, the developers manually open the local MDGB compilation software and manually start the compilation process to perform the compilation operation.

[0064] In step S403, after the MDGB software is compiled, it generates program files in a2l (ASAP2, automotive electronic control standard calibration file format) and hex (hexadecimal program image file) formats. The user manually determines whether the current project requires software encapsulation. If encapsulation is not required, the hex file is manually uploaded to the HIL (Hardware-In-the-Loop) continuous integration platform for testing the vehicle's underlying software. If encapsulation is required, the user manually completes the software calibration and encapsulation operations. After encapsulation, the file is uploaded to the HIL continuous integration platform for testing the vehicle's underlying software, thus completing all software output work.

[0065] The manual compilation process described above presents two major pain points: First, after compiling the underlying and application layer software separately, MDGB is required to manually register each .c and .h file in the software. This process relies entirely on manual input, which is tedious and prone to missing files. Second, if compilation fails, the MDGB console will output compilation error messages. For example, the console interface may explicitly indicate that the build.compile (the internal compilation and build stage identifier of the MDGB compilation software) stage failed. In this case, developers need to manually go to the local software directory to find the corresponding project.log (the complete runtime log file generated by the MDGB compilation project). The log will record detailed error information such as undefined variables and duplicate declarations. Developers have to manually search the logs line by line to locate code problems and make manual modifications. There is no automated log collection or online viewing function throughout the process, resulting in low efficiency in troubleshooting.

[0066] The technical approach of the continuous integration platform proposed in this application will be described next through a specific embodiment, such as... Figure 5 As shown, the specific steps are as follows: In step S501, the operator enters the storage path corresponding to the component information on the integrated development platform interface; the corresponding interface is shown in the parameter configuration pop-up window. The pop-up window completely fills in all component paths and version parameters, such as vehicle model, version number, ASW of each layer and SVN source code address of the project. After filling in, click the "Build based on current parameters" button to submit the compilation requirements and complete the pre-compilation information entry.

[0067] In step S502, the vehicle's underlying software continuous integration platform reads all the input component information, automatically parses it, and generates an adapted SVN build script.

[0068] In step S503, the SVN script generated by the vehicle's underlying software continuous integration platform automatically pulls the source code of the vehicle's underlying software from the pre-filled SVN address. The execution progress of this pulling process can be visualized as color blocks on the build details page.

[0069] In step S504, the vehicle's underlying software continuous integration platform automatically calls the MDGB server's open interface to carry out software integration work, without requiring manual opening of the MDGB software or manual registration of .c / .h source code files.

[0070] In step S505, automated code checks are performed synchronously throughout the entire compilation process to identify exceptions in code syntax, definitions, and declarations in advance.

[0071] In step S506, the vehicle underlying software continuous integration platform performs the vehicle underlying software compilation and integration operation, and automatically identifies the execution result of the compilation and integration, processing it in two branches: Branch 1: If the compilation and integration process fails, the vehicle's underlying software continuous integration platform automatically generates a complete error tracing log and uploads the log file to the corresponding SVN path entered in step S701. The failure is indicated by a color block in the integration failure section of the build interface. The page provides functions for viewing and downloading the log. The log fully records details of compilation errors such as undefined variables and abnormal parameter configurations. Developers can directly retrieve the log online and use the log stored in SVN to trace the fault without manually searching for the log file in their local folder.

[0072] Branch Two: If the compilation and integration are successful, the vehicle's underlying software continuous integration platform will automatically generate an integrated vehicle software package and automatically upload and store it according to the previously entered SVN path. A colored block will be visible on the successful build interface, displaying the SVN download address of the generated package, which can be directly downloaded for subsequent testing.

[0073] Once the software package or error log is uploaded to the corresponding SVN path, the build process ends.

[0074] This application provides a visual interface for the continuous integration platform of the vehicle's underlying software, which includes a historical data visualization interface. All historical build tasks are fully preserved, and the page records the execution time, operator, SVN address of the build artifact, and complete iteration details for each build. R&D personnel can access historical build records at any time, view the entire execution status of each software build online, and collaboratively view compilation information across departments. This fully realizes the traceability of software versions across the entire chain and the rapid location of fault roots, significantly improving the efficiency of the integration and compilation of the vehicle's underlying software.

[0075] In summary, the embodiments of this application have at least the following beneficial effects: (1) Significantly improves the efficiency of vehicle underlying software integration and compilation. This application builds a fully automated continuous integration platform for vehicle underlying software based on Python. Relying on the Jenkins server and MDGB server, it constructs an independent and controllable compilation and integration system. It can monitor source code repository submission behavior, automatically locate the source code SVN path according to the integration library component information, and automatically complete code inspection, dynamic testing, integration compilation and generate software integration packages. It replaces the cumbersome process of manual file registration, manual compilation and manual archiving, solves the problems of time-consuming and error-prone manual operation, effectively shortens the development cycle from source code submission to integration package output, and adapts to the rapid iteration development needs of vehicle manufacturers' underlying software.

[0076] (3) Achieve standardized and traceable R&D management of underlying software and enhance R&D collaboration capabilities. The vehicle underlying software continuous integration platform of this application supports software iteration history traceability based on the time dimension, which can fully record the evolution and change details of software versions, realize the software version can be checked and the root cause of the problem can be located; at the same time, it unifies the storage and distribution path of software packages, which facilitates R&D personnel to carry out subsequent testing, version control and iteration traceability, simplify the R&D collaboration process, reduce communication costs, and realize refined and standardized management of the entire life cycle of vehicle underlying software.

[0077] Figure 6 This is an architecture diagram of the vehicle underlying software compilation system provided in the embodiments of this application.

[0078] like Figure 6 As shown, the vehicle's underlying software compilation system 60 includes a master server 601 and a slave server 602.

[0079] The system includes a master server 601 and at least one slave server 602 mounted on the master server 601. The master server 601 is equipped with an interactive interface. Based on the interactive data of the interactive interface, the target source code of the vehicle's underlying software is determined and the target server is called to execute the vehicle's underlying software compilation method as described in the above embodiment. The target server is one of the slave servers 602.

[0080] Specifically, such as Figure 3 As shown, the main server is a Jenkins server, which has four types of slave servers mounted on it: an MDGB server for PDCU software development and integration, a Tasking (embedded compiler for automotive electronic motor controllers) server for VCU software development and integration, a HIGHTEC (embedded compilation toolchain for battery management systems and vehicle controllers) server for BMS software development and integration, and another HIGHTEC server for MCU software development and integration. This application uses the MDGB slave server for PDCU software development and integration as the target server for executing the compilation task. The main server collects compilation interaction data through its own interactive interface, matches the corresponding vehicle controller hardware, and then calls the MDGB slave server to execute the aforementioned automated compilation process of the vehicle's underlying software.

[0081] According to the vehicle underlying software compilation system proposed in the embodiments of this application, a layered compilation system architecture is constructed by a master server and a mounted slave server. The system obtains interactive data through the interactive interface of the master server, automatically determines the target source code, and schedules the corresponding slave server as the target server to execute the compilation process. This achieves unified scheduling and centralized management of compilation resources, ensuring the orderly, stable, and automated operation of the vehicle underlying software compilation process.

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

[0083] When the processor 702 executes the program, it implements the vehicle-level software compilation method provided in the above embodiments.

[0084] Furthermore, electronic devices also include: Communication interface 703 is used for communication between memory 701 and processor 702.

[0085] The memory 701 is used to store computer programs that can run on the processor 702.

[0086] The memory 701 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0087] If the memory 701, processor 702, and communication interface 703 are implemented independently, then the communication interface 703, memory 701, and processor 702 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 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.

[0088] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0089] The processor 702 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0090] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for compiling the vehicle's underlying software.

[0091] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0092] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0093] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application 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 should be understood by those skilled in the art to which embodiments of this application pertain.

[0094] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0095] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0096] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for compiling low-level software for a vehicle, characterized in that, Includes the following steps: Obtain the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software; The target source code of the vehicle's underlying software is determined based on the compilation requirement text and the target address path, and the target server is called based on the target application hardware of the vehicle's underlying software. The underlying software of the vehicle is compiled based on the target server and the target source code.

2. The method for compiling the underlying software of a vehicle according to claim 1, characterized in that, The process of obtaining the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software includes: Identify the user's first and second interactive actions on the target interactive interface; Based on the first interactive action, input the relevant compilation information on the target interactive interface; The second interactive action triggers a filtering operation to filter the compilation requirement text, target address path, and target application hardware of the vehicle's underlying software based on the compilation-related information.

3. The method for compiling the underlying software of a vehicle according to claim 2, characterized in that, The process of filtering the compilation requirements text and target application hardware of the vehicle's underlying software based on the compilation-related information includes: Extract the project name, hardware name, and software code from the compilation-related information; Based on the project name, the hardware name, and the software code, the database is queried to retrieve the compilation requirements text, target address path, and target application hardware of the vehicle's underlying software.

4. The method for compiling the underlying software of a vehicle according to claim 1, characterized in that, Determining the target source code of the vehicle's underlying software based on the compilation requirement text and the target address path includes: Extract the information of each component from the compilation requirements text; Construct the target compilation script based on the information of each component; The target source code is obtained from the target address path based on the target compilation script.

5. The method for compiling the underlying software of a vehicle according to claim 1, characterized in that, The step of calling the target server based on the target application hardware of the vehicle's underlying software includes: Obtain the mapping table between the identifier of the target application hardware and the target server; The target server is obtained by querying the mapping table using the identifier of the target application hardware as an index.

6. The method for compiling the underlying software of a vehicle according to claim 1, characterized in that, The step of compiling the vehicle's underlying software based on the target server and the target source code includes: Input the target source code into the target server; The target source code is compiled using the target server; The target address path is uploaded based on the compilation result of the target source code.

7. The method for compiling the underlying software of a vehicle according to claim 6, characterized in that, The process of uploading data based on the compilation result of the target source code, including the target address path, includes: Identify the compilation result of the target source code; If the compilation result of the target source code is found to be a compilation failure, the error log content of the target server compilation is obtained and the error log content is uploaded to the target address path; If the compilation result of the target source code is found to be successful, the software package corresponding to the vehicle underlying software compiled by the target server is obtained, and the software package corresponding to the vehicle underlying software is uploaded to the target address path.

8. A vehicle-level low-level software compilation system, characterized in that, include: The master server and at least one slave server mounted under the master server; The master server is equipped with an interactive interface. Based on the interactive data of the interactive interface, the target source code of the vehicle's underlying software is determined and the target server is called to execute the vehicle's underlying software compilation method as described in any one of claims 1-7. The target server is one of the slave servers.

9. An electronic device, characterized in that, include: 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 vehicle-level software compilation method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they implement the vehicle underlying software compilation method according to any one of claims 1-7.

Images