Software integration method and system of vehicle, vehicle and computer readable storage medium

Abstract

The embodiment of the invention provides a software integration method and system of a vehicle, the vehicle and a computer readable storage medium. The method comprises the steps that at least one piece of software release plan information of an auxiliary driving function is determined; determining a development task associated with the software release plan information; determining a plurality of function development stages of the function software based on the development task; determining a target integration strategy corresponding to the function development stage from an integration strategy set, the integration strategy set comprises a first integration strategy used for integrating source codes in a function development stage, a second integration strategy used for integrating binary files in the function development stage, and a third integration strategy used for performing hybrid integration on the source codes and the binary files in the function development stage; and according to the target integration strategy, integrating the development objects in the function development stage to obtain a target integration product. The technical problem that the software integration efficiency of the vehicle is low is solved.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of vehicle data processing, and more specifically, to a vehicle software integration method, system, vehicle, and computer-readable storage medium. Background Art

[0002] At present, in the vehicle's assisted driving system, software products are an important part of intelligent vehicles, and their continuous integration efficiency is related to various aspects such as system development, function iteration efficiency and quality assurance.

[0003] During the software product integration process, code security is a particular concern for project managers. Existing software product integration methods, to ensure code security, focus solely on integrating binary products. While this approach can reduce the risk of code leaks, it compromises software iteration efficiency, resulting in low vehicle software integration efficiency.

[0004] There is currently no good solution to the above problems. Summary of the Invention

[0005] Embodiments of the present application provide a vehicle software integration method, system, vehicle, and computer-readable storage medium to at least solve the technical problem of low vehicle software integration efficiency.

[0006] According to one aspect of an embodiment of the present application, a vehicle software integration method is provided, wherein the vehicle has an assisted driving function, and the method may include: determining at least one software release plan information of the assisted driving function, wherein the software release plan information is used to represent the release rules of the functional software to be developed in the assisted driving function; determining a development task associated with the software release plan information, wherein the development task is created through software requirement information, and the software requirement information is used to describe the software release plan information required for developing the functional software; based on the development task, determining multiple functional development stages of the functional software; determining a target integration strategy corresponding to the functional development stage from an integration strategy set, wherein the integration strategy set includes Including: a first integration strategy for integrating source code in the function development stage, a second integration strategy for integrating binary files in the function development stage, and a third integration strategy for mixed integration of source code and binary files in the function development stage, where the binary files are converted from the source code; according to the target integration strategy, the development objects in the function development stage are integrated to obtain the target integrated product, wherein, when the target integration strategy is the first integration strategy, the development object is the source code, when the target integration strategy is the second integration strategy, the development object is the binary file, and when the target integration strategy is the third integration strategy, the development object is the source code and the binary file.

[0007] Furthermore, a target integration strategy corresponding to the function development stage is determined from the integration strategy set, including: in response to the function development stage being the mid-function development stage, determining a first target integration strategy corresponding to the mid-function development stage from the integration strategy set, wherein the first target integration strategy is one of the following: the first integration strategy, the second integration strategy, and the third integration strategy; in response to the function development stage being the function verification stage, determining a second target integration strategy corresponding to the function verification stage from the integration strategy set, wherein the second target integration strategy is the second integration strategy; in response to the function development stage being the function release stage, determining a third target integration strategy corresponding to the function release stage from the integration strategy set, wherein the third target integration strategy is the second integration strategy.

[0008] Furthermore, based on the development task, multiple functional development stages of the functional software are determined, including: based on the development task, a development branch is determined; the stage of developing the source code of the functional software in the development branch is determined as the functional development stage; the binary file of the functional software is built through the source code in the first warehouse branch, the binary file is uploaded to the second warehouse branch, the stage of verifying the binary file in the second warehouse branch is determined as the functional verification stage, and the stage of releasing the binary file in the second warehouse branch is determined as the functional release stage.

[0009] Furthermore, the method also includes: before the target time node, merging the source code of the functional software into the first warehouse branch; after the target time node and before the release time node of the functional software, prohibiting the merging of the source code of the functional software into the first warehouse branch.

[0010] Furthermore, the method also includes: submitting the hash code of the functional software to the warehouse corresponding to the first target strategy set; integrating the development objects in the functional development stage according to the target integration strategy to obtain the target integrated product, including: integrating the development objects in the functional development stage according to the target integration strategy using the hash code to obtain the target integrated product.

[0011] Furthermore, determining the development tasks associated with the software release plan information includes: determining the target association relationship associated with the software release plan information, wherein the target association relationship is used to represent the relationship between the software release plan information and the software requirement information, and the relationship between the software release plan information and the development tasks, and the software release plan information corresponds to the version of the functional software; according to the target association relationship, determining the development tasks associated with the software release plan information.

[0012] Furthermore, before determining the target association relationship associated with the software release plan information, the method also includes: determining project requirement information of the functional software, wherein the project requirement information is used to represent the schedule requirements of the project to which the functional software belongs; splitting the project requirement information to obtain functional requirement information of the functional software, and establishing a first association relationship between the project requirement information and the functional requirement information, wherein the functional requirement information is used to represent the functions that the functional software needs to have; splitting the functional requirement information to obtain software requirement information, and establishing a second association relationship between the functional requirement information and the software requirement information, wherein the software requirement information is used to describe the version of the software release plan information required for developing the functional software; creating a development task based on the software requirement information, and establishing a target association relationship between the development task, the software requirement information and the software release plan information; generating traceability information of the functional software using the target association relationship, the second association relationship and the first association relationship, wherein the traceability information is used to trace the functional software after development.

[0013] According to one aspect of an embodiment of the present application, a software integration system for a vehicle is provided, wherein the vehicle has an assisted driving function. The system may include: a document management system for determining at least one piece of software release plan information for the assisted driving function, wherein the software release plan information is used to represent release rules for functional software to be developed in the assisted driving function; a requirement management system for determining development tasks associated with the software release plan information, wherein the development tasks are created using software requirement information, and the software requirement information is used to describe software release plan information required for developing the functional software; a code management system for determining multiple functional development stages of the functional software based on the development tasks; determining the code developed in the functional development stage, and determining, from an integration strategy set, a target integration strategy corresponding to the functional development stage. Among them, the integration strategy set includes: a first integration strategy for integrating source code in the function development stage, a second integration strategy for integrating binary files in the function development stage, and a third integration strategy for mixed integration of source code and binary files in the function development stage, where the binary files are converted from the source code; a continuous integration system for integrating development objects in the function development stage according to the target integration strategy to obtain target integrated products, where, when the target integration strategy is the first integration strategy, the development object is source code, when the target integration strategy is the second integration strategy, the development object is binary file, and when the target integration strategy is the third integration strategy, the development object is source code and binary file; a product management system for receiving target integrated products.

[0014] According to another aspect of an embodiment of the present application, a vehicle is further provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the method of each embodiment of the present application is executed when the program is running.

[0015] According to another aspect of an embodiment of the present application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present application.

[0016] According to another aspect of the embodiments of the present application, a computer program product is further provided, including a computer program, which implements the methods in various embodiments of the present application when executed by a processor.

[0017] According to another aspect of an embodiment of the present application, a computer program product is further provided, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0018] According to another aspect of the embodiments of the present application, a computer program is further provided, which implements the methods in various embodiments of the present application when executed by a processor.

[0019] In an embodiment of the present application, a vehicle having an assisted driving function is used, including: determining at least one piece of software release plan information for the assisted driving function, wherein the software release plan information is used to represent release rules for functional software to be developed in the assisted driving function; determining a development task associated with the software release plan information, wherein the development task is created using software requirement information, and the software requirement information is used to describe software release plan information required for developing the functional software; determining multiple functional development stages of the functional software based on the development task; determining target integration strategies corresponding to the functional development stages from an integration strategy set, wherein the integration strategy set includes: a first integration strategy for integrating source code in the functional development stage, a second integration strategy for integrating binary files in the functional development stage, and a third integration strategy for hybrid integration of source code and binary files in the functional development stage, wherein the binary files are converted from the source code; and integrating development objects in the functional development stage according to the target integration strategy to obtain a target integrated product, wherein when the target integration strategy is the first integration strategy, the development object is the source code, when the target integration strategy is the second integration strategy, the development object is the binary file, and when the target integration strategy is the third integration strategy, the development object is the source code and the binary file. That is to say, the embodiment of the present application can determine the different functional development stages of the assisted driving function based on the development tasks associated with the software release plan information, and through the integration strategy, in the different functional development stages of the assisted driving function, it can support both continuous integration of source code and binary file integration, and mixed integration of source code and binary files, output traceable software products, and realize safe and rapid iteration of assisted driving function software products, avoiding only supporting binary integration, thereby solving the technical problem of low efficiency of vehicle software integration and achieving the technical effect of improving the efficiency of vehicle software integration. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0021] Figure 1 is a flowchart of a vehicle software integration method according to an embodiment of the present application;

[0022] Figure 2 is a schematic diagram of a vehicle software integration system according to an embodiment of the present invention;

[0023] Figure 3 is a schematic diagram of a continuous integration process of functional software according to an embodiment of the present invention;

[0024] Figure 4is a schematic diagram of a branching strategy according to an embodiment of the present invention;

[0025] Figure 5 2 is a schematic diagram of a vehicle software integration device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] According to an embodiment of the present application, an embodiment of a vehicle software integration method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0029] In this embodiment, a software integration method for a vehicle is provided, where the vehicle has an assisted driving function. Figure 1 FIG is a flow chart of a vehicle software integration method according to an embodiment of the present application. Figure 1 As shown, the process includes the following steps:

[0030] The step S102 is to determine at least one software release plan information of the driving assistance function.

[0031] In the technical solution provided in the above step S102 of the present application, the software release plan information is used to indicate the release rules of the functional software to be developed in the assisted driving function.

[0032] In this embodiment, the vehicle has an assisted driving system, which may be an Advanced Driver Assistance Systems Level 2 (ADAS L2), which allows the vehicle to automatically control acceleration, braking, and steering under driving conditions, allowing the driver to keep their hands on the steering wheel and be ready to take over control of the vehicle at any time. Optionally, the assisted driving system of this embodiment may include functional software, which is also known as functional modules, and may include but is not limited to the vehicle's perception fusion module, speed planning module, control module, Road Experience Management (REM) module, data return module, etc., without specific limitation herein.

[0033] In this embodiment, the above-mentioned assisted driving function has functional software to be developed, and the functional software to be developed can be driving functional software to be developed, for example, a software product to be developed for the above-mentioned functional module, that is, software to be released, and has at least one software release information. Optionally, this embodiment can determine at least one software release plan information of the assisted driving function in the document management system. The software release plan information is used to represent the release rules of the functional software to be developed in the assisted driving function, for example, a software version release plan (Release plan), which can be called a version release plan, and its number can be multiple, which can be used to clarify the functional requirements that need to be implemented by each version of the functional software, thereby ensuring that the functional requirements ultimately implemented by the functional software are associated with the software version release plan. Among them, each version of the functional software corresponds to a corresponding Release Plan, and the Release Plan has a release version number.

[0034] Optionally, the software integration method of this embodiment can achieve traceability of software products, and can start building a traceability relationship for functional software at the beginning of determining at least one software release plan information for the assisted driving function. Optionally, the software release plan information of this embodiment must meet the project's schedule requirements (or requirements), and the software release plan information plans out which requirements need to be implemented and which problems need to be fixed for each version of the functional software. Then, a traceability relationship can be established between the corresponding requirements and the problems fixed and the software release plan information, and this traceability relationship can be used to represent a traceability link.

[0035] Optionally, this embodiment can determine the release time nodes of the functional software and the functions that the functional software needs to achieve when released at each release time node based on the progress requirements of the project to which the functional software belongs. The release time node is used to release the corresponding version of the functional software. Based on the above progress requirements, release time nodes, and the functions that need to be achieved, software release plan information is formulated. Optionally, this software release plan information can be stored in a document management system.

[0036] It should be noted that the software release plan information of this embodiment can correspond to a large version of functional software, which will undergo multiple iterations. Therefore, the actual Release Plan may include multiple small versions. Optionally, based on the actual progress of the above project, the software version release plan information may include E0, E1, E2, E3, E4, and OTA large versions, wherein each large version can undergo multiple iterations and evolve into multiple small versions during the iteration process. For example, the large version E0 can evolve into multiple small versions E0V1, E0V2, etc.

[0037] Step S104: determining the development tasks associated with the software release plan information.

[0038] In the technical solution provided in the above step S104 of the present application, after determining at least one software release plan information of the assisted driving function, the development task associated with the software release plan information can be determined, wherein the development task is created through the software requirement information, and the software requirement information is used to describe the software release plan information required to develop the functional software.

[0039] In this embodiment, the software release plan information is associated with a development task, and the development task associated with the software release plan information can be determined. For example, in a demand management system, the development task associated with the software release plan information can be determined. The development task, also known as the software development task, can be a corresponding development task created based on the software requirement information. The software requirement information can be used to describe which version of the software release plan information is required to develop the functional software. That is, the software requirement information corresponds to the software release plan information. For example, the software requirement information can indicate in which version of the Release Plan the functional software is released. Based on this, an association relationship can be established between the Release Plan and the specific implementation of the software function to ensure consistency between the software requirements, development tasks, and software release plan information of the functional software.

[0040] Optionally, this embodiment may establish an association relationship between the software release plan information and the software requirements and development tasks of the functional software, so that the functional software can be subsequently traced based on the association relationship.

[0041] Optionally, the software release plan information of this embodiment can also be associated with problem repair, which can be used to repair problems that need to be repaired in the functional software. Optionally, developers can quickly locate and repair problems in the functional software based on the integrated log.

[0042] Step S106: determining multiple functional development stages of the functional software based on the development task.

[0043] In the technical solution provided in the above step S106 of the present application, after the development tasks associated with the software release plan information are determined, multiple functional development stages of the functional software can be determined based on the development tasks.

[0044] In this embodiment, the functional software development phase can be used to represent the stage of the functional software in the development process. In each functional development phase, while ensuring the code security of the functional software, the development process needs to be standardized. Based on this, different functional development phases can integrate different requirements.

[0045] This embodiment can determine multiple functional development stages of the functional software based on the development task, such as the software development process stage, the software qualification verification stage, the software version release stage, etc. Among them, the software development process stage is used for software development stage integration, which can achieve rapid iteration of software functions; the software qualification verification stage can be used for software function qualification verification; and the software version release stage can be used for the final version release of the functional software.

[0046] Optionally, this embodiment determines multiple functional development stages of the functional software in the code management system based on the above development tasks.

[0047] Step S108: Determine the target integration strategy corresponding to the function development stage from the integration strategy set.

[0048] In the technical solution provided in the above step S108 of the present application, after determining multiple functional development stages of the functional software based on the development task, the target integration strategy corresponding to the functional development stage can be determined from the integration strategy set. The integration strategy set includes: a first integration strategy for integrating the source code of the functional development stage, a second integration strategy for integrating the binary files of the functional development stage, and a third integration strategy for mixed integration of the source code and binary files of the functional development stage, where the binary files are converted from the source code.

[0049] In this embodiment, the integration strategy set includes different integration strategies, which can be used to represent the rules for integrating development objects in the functional development stage. Optionally, the integration strategy set can include a first integration strategy, a second integration strategy, and a third integration strategy, wherein the first integration strategy can be used to represent the rules for continuous integration of source code in the functional development stage, that is, source code integration rules, the second integration strategy can be used to represent the rules for integrating binary files in the functional development stage, that is, binary file integration rules, and the third integration strategy can be used to represent the rules for mixed integration of source code and binary files in the functional development stage, that is, source code and binary file mixed integration rules. Among them, source code, also known as source code, is the development basis of functional software and is the application code written by programmers, which is written in a high-level programming language; after the source code is translated into machine instructions by a compiler, the resulting executable file or library file can be directly executed on a computer, and the executable file or library file can be a binary file.

[0050] Optionally, this embodiment can support source code integration, binary file integration, and mixed source code and binary file integration by setting an integration strategy set in the continuous integration system, thereby adapting to the integration requirements of different functional development stages. Based on this, from the above integration strategy set, a target integration strategy corresponding to the functional development stage is determined. This target integration strategy can be any one of the first integration strategy, the second integration strategy, and the third integration strategy mentioned above, to achieve on-demand and flexible integration of functional software in different functional development stages, and ensure the code security of the functional software, thereby avoiding the problem of only supporting binary integration, which reduces integration flexibility and development iteration efficiency.

[0051] Step S110 : Integrate the development objects in the functional development phase according to the target integration strategy to obtain the target integrated product.

[0052] In the technical solution provided in step S110 above, after determining the target integration strategy corresponding to the functional development stage from the integration strategy set, the development objects in the functional development stage can be integrated according to the target integration strategy to obtain the target integrated artifact. Specifically, when the target integration strategy is the first integration strategy, the development object is source code; when the target integration strategy is the second integration strategy, the development object is a binary file; and when the target integration strategy is the third integration strategy, the development object is both source code and binary files.

[0053] In this embodiment, development objects in the functional development phase can be automatically integrated according to the integration rules corresponding to the target integration strategy. The integration tasks for this automated integration can be built on nodes. That is, the integration build environment corresponding to the integration tasks can be uniformly deployed on the nodes, thereby ensuring a consistent build environment. On the nodes, development objects in the functional development phase can be automatically integrated according to the integration rules corresponding to the target integration strategy to obtain the target integrated artifact. A node can also be referred to as an integration node, and development objects can include source code and / or binary files.

[0054] In this embodiment, different target integration strategies can correspond to different development objects. Optionally, when the target integration strategy is the first integration strategy described above, the development object to be integrated can be source code; when the target integration strategy is the second integration strategy described above, the development object can be a binary file; and when the target integration strategy is the third integration strategy described above, the development object can be a mixture of source code and binary files. After determining the target integration strategy, the development objects in the functional development phase can be integrated according to the target integration strategy to obtain the target integration artifact, which is the final deployable software artifact.

[0055] Optionally, after each target integrated artifact is uploaded to a designated storage location, the node can automatically clean up the data and delete local information related to the build process to ensure the security of the functional software code and reduce the risk of code leakage. The designated storage location can be the designated path of each artifact warehouse in the artifact management system.

[0056] This embodiment realizes the automated integration of development objects of functional software in the functional development stage through the target integration strategy, and can also achieve the purpose of interactive and flexible integration, while ensuring the security of source code compilation integration, binary file integration, and hybrid integration. It can also meet the traceability requirements of software integration by releasing the relationship between plan information and development tasks through software, thereby improving the software integration efficiency of the vehicle.

[0057] It should be noted that the vehicle in this embodiment can interact with roadside equipment and terminal devices. Optionally, the vehicle can send an information subscription request to the roadside equipment. The message subscription request may include specific types of information that the vehicle needs to receive, such as road conditions, traffic signal status, and forward obstacle warnings. The roadside equipment can respond to the information subscription request and send roadside perception information to the vehicle. For example, the roadside equipment will filter out roadside perception information that meets the vehicle's needs based on its own perception capabilities and stored information, and send it to the vehicle at a certain frequency. In addition to communicating with the roadside equipment, the vehicle can also receive driving scene switching instructions transmitted by the terminal device over the network. For example, the driving scene switching instruction can be used to switch the vehicle to energy-saving mode, sports mode, automatic driving mode, etc., so that the vehicle can adapt to the new driving scene.

[0058] Through the above steps S102 to S110, the vehicle has an assisted driving function, and the different functional development stages of the assisted driving function can be determined based on the development tasks associated with the software release plan information. Moreover, through the integration strategy, in the different functional development stages of the assisted driving function, it can support continuous integration of source code and binary file integration, as well as mixed integration of source code and binary files, output traceable software products, realize safe and rapid iteration of assisted driving function software products, avoid supporting only binary integration, thereby solving the technical problem of low efficiency of vehicle software integration, and achieving the technical effect of improving the software integration efficiency of the vehicle.

[0059] The above method of this application is further introduced below.

[0060] In this embodiment, when determining the target integration strategy corresponding to the function development stage from the integration strategy set, the integration strategy matching the type of the function development stage can be determined from the integration strategy set based on the type of the function development stage. This will be further described below.

[0061] As an optional implementation manner, step S108, determining the target integration strategy corresponding to the function development stage from the integration strategy set, includes: in response to the function development stage being the function development mid-stage, determining the first target integration strategy corresponding to the function development mid-stage from the integration strategy set, wherein the first target integration strategy is one of the following: the first integration strategy, the second integration strategy and the third integration strategy; in response to the function development stage being the function verification stage, determining the second target integration strategy corresponding to the function verification stage from the integration strategy set, wherein the second target integration strategy is the second integration strategy; in response to the function development stage being the function release stage, determining the third target integration strategy corresponding to the function release stage from the integration strategy set, wherein the third target integration strategy is the second integration strategy.

[0062] In this embodiment, the different functional development stages of the functional software may include a function development stage, a function verification stage, and a function release stage. The function development stage may be the aforementioned stage in the software development process, corresponding to the integration of the software development stages, the function verification stage may be the aforementioned software qualification verification stage, and the function release stage may be the aforementioned version release stage.

[0063] In response to the function development stage being the aforementioned function development mid-stage, a first target integration strategy corresponding to the function development mid-stage may be determined from the integration strategy set. The first target integration strategy may be one of the following: a first integration strategy, a second integration strategy, and a third integration strategy. The first integration strategy is a rule for integrating source code in the function development stage, the second integration strategy is a rule for integrating binary files in the function development stage, and the third integration strategy is a rule for mixed integration of source code and binary files in the function development stage.

[0064] Optionally, the above-mentioned first target integration strategy of this embodiment can be an on-demand build task (MonkeyBuild), which can be a random or informal build task. Optionally, the first target integration strategy can also be a daily build task (Daily Build). Among them, Monkey Build can be used to test the stability of functional software under different conditions, and Daily Build refers to the build task of functional software that is automatically performed every day, which is used to realize the regular integration of functional software in a specified branch, and can be used for daily testing. For example, it can be used to check whether the latest changes in the code base can be successfully compiled, and potential integration problems can be discovered early. Based on this, this embodiment adopts Monkey Build / Daily Build in the stage of functional development, which can realize on-demand flexible integration of functional software, support source code integration, binary file integration, and support mixed integration of source code and binary files, thereby realizing rapid iteration of functional software.

[0065] In response to the function development stage being the function verification stage, a second target integration strategy corresponding to the function verification stage can be determined from the integration strategy set. The second target integration strategy can be the above-mentioned second integration strategy, which is a rule for integrating binary files in the function development stage.

[0066] Optionally, the above-mentioned second target integration strategy of this embodiment can be an engineering build task (EngineeringBuild). The Engineering Build can be a build task performed during the development process of the functional software for the purpose of functional testing, system integration or performance verification. It can be used in the later stage of the development phase when the functional software has undergone preliminary testing and is ready for more in-depth technical verification. Based on this, the Engineering Build of this embodiment supports binary file integration, and the latest submission results of the functional software can be pulled for integration on a scheduled or on-demand basis through the Engineering Build, and the target integrated product obtained can be used for qualification verification of the functional software.

[0067] In response to the function development stage being the function release stage, a third target integration strategy corresponding to the function release stage can be determined from the integration strategy set. The third target integration strategy can be the above-mentioned second integration strategy, which is a rule for integrating binary files in the function development stage.

[0068] Optionally, the third target integration strategy of this embodiment can be a release build task (ReleaseBuild). The Release Build can be used for the final build task before the functional software is ready for formal release, including the necessary functions and performance optimization of the functional software, and can include complete testing and verification, so as to ensure that the functional software can run stably in the user environment. Based on this, the Release Build of this embodiment supports binary file integration, and the submission results corresponding to the functional software can be pulled on demand through the Release Build for integration. The obtained target integrated product can be used for the final version release of the functional software for software release and deployment.

[0069] Optionally, after the Monkey Build, Daily Build, Engineering Build, and Release Build tasks are triggered, the development objects can be compiled and built within the integration node. The completed target integration artifacts can then be uploaded to the artifact management system. After uploading the target integration artifacts to the artifact management system, the integration node can automatically purge the relevant build data. Once the data purge is complete, the entire build task is concluded, thus reducing the risk of code leakage throughout the entire build process.

[0070] To meet the integration requirements of functional software at different stages of development, this embodiment implements integrated pipelines for MonkeyBuild / Daily Build, Engineering Build, and Release Build. By using a continuous integration system, the aforementioned Monkey Build / Daily Build can be utilized to achieve flexible, on-demand integration of various functional software for the vehicle. Monkey Build / Daily Build can support source code integration, binary file integration, and mixed integration of source code and binary files, while Engineering Build and Release Build support binary file integration. This avoids supporting only binary integration, thereby resolving the technical issue of low vehicle software integration efficiency and achieving the technical effect of improving vehicle software integration efficiency.

[0071] When implementing multiple functional development phases for functional software based on development tasks, the functional development phases can be determined based on the to-be-developed branches and warehouse branches corresponding to the development tasks. This is further explained below.

[0072] As an optional implementation, step S106 determines multiple functional development stages of the functional software based on the development task, including: determining a development branch based on the development task; determining the stage of developing the source code of the functional software in the development branch as the functional development stage; building the binary file of the functional software through the source code in the first warehouse branch, uploading the binary file to the second warehouse branch, and verifying the binary file in the second warehouse branch as the functional verification stage, and determining the stage of releasing the binary file in the second warehouse branch as the functional release stage.

[0073] This embodiment can adopt a branch management strategy, that is, developers can host the code of the functional software in a code management warehouse, and can implement isolation and version control strategies through branch management (for example, a first warehouse branch and a second warehouse branch). Optionally, this embodiment can determine a development branch based on the development task, and the development branch develops new functions in the functional development phase of the functional software. Optionally, this embodiment can create a development branch based on the created development task (problem fixing), and can pull the above-mentioned development branch from the code warehouse based on the created development task.

[0074] Optionally, the source code of the functional software is developed in the above development branch to achieve the purpose of developing new functions in the development branch. The stage of developing the source code of the functional software in the development branch can be determined as the functional development stage of the functional software.

[0075] As an optional example for the above-mentioned stage of functional development, the above-mentioned Monkey Build / DailyBuild can be used for integration in the stage of functional development, and can achieve rapid iteration of functional software. Monkey Build / Daily Build can create an integrated traceability code repository in the code management repository. The integrated traceability code repository can contain the integrated warehouse address and the corresponding hash code description file. Based on the hash code description file, flexible integration can be achieved, and Type I warehouse integration, Type II warehouse integration, and mixed integration of Type I and Type II warehouses can be supported, wherein the hash code description file can be used for integration traceability; Type I warehouse refers to a source code warehouse, which is used to store the source code of functional software and is the basis for development activities and continuous integration; Type II warehouse can be used to store and manage built binaries, libraries or other artifacts. In the continuous integration process, once the code in the Type I warehouse is verified and built successfully, the generated binary files and other artifacts will be uploaded to the Type II warehouse for testing and deployment. Developers submit and manage code in this warehouse to carry out functional development and merge requests.

[0076] Optionally, the above-mentioned integration traceability code repository file can be modified according to the code modification requirements. After submitting the modified integration traceability code repository file, Monkey Build will be automatically triggered to perform the integration build. If the integration build passes, the target integration artifact obtained can be used for smoke testing; if the integration build fails, the reason for the integration failure can be quickly located based on the integration log (log), so that developers can fix the problem. For example, the integration log will be uploaded to a specified path in the artifact system, and developers can quickly locate and fix software problems based on the integration log.

[0077] Optionally, this embodiment uses Daily Build to achieve regular integration of designated branches of each functional software, that is, to achieve the purpose of scheduled task triggering. This integration task can achieve the purpose of daily detection, thereby realizing early detection of problems, reducing repair costs, and ensuring software stability.

[0078] Optionally, after the source code of the functional software is developed locally corresponding to the development branch, the developed source code can be submitted to the code repository. For example, the source code that meets the process requirements can be merged into the first warehouse branch, and the merge action will automatically trigger the construction of the binary file. Among them, the merge action automatically triggers the construction of the binary file means that in the process of functional software development and continuous integration, when the developer's code is reviewed and approved to be merged into the branch, this merge operation will automatically start a predefined build process. Optionally, the developers of each functional software will submit a merge request to the first warehouse branch for the source code that meets the requirements, and the code reviewer can determine whether to agree to the merge based on the merge request. If the code reviewer agrees to the merge, the source code and the merge action will automatically trigger the binary file build task of the first warehouse branch to obtain the built binary file.

[0079] Optionally, the built binary files will be automatically uploaded or pushed to the corresponding second warehouse branch. This embodiment determines the stage of verifying the binary files in the second warehouse branch as the functional verification stage, and determines the stage of releasing the binary files in the second warehouse branch as the functional release stage. Optionally, in the functional verification stage, the above-mentioned binary files can be functionally verified through Engineering Build; in the functional release stage, the binary files in the above-mentioned second warehouse branch can be released through Release Build.

[0080] As an optional example of the above-mentioned functional verification stage, the above-mentioned Engineering Build can be used to pull the latest submitted binary files (i.e., the latest submission results) on the second-type warehouse branch corresponding to the functional software on a scheduled or on-demand basis for integration, and the obtained target integrated product can be used to verify the qualification of the functional software.

[0081] As an optional example for the aforementioned feature release phase, the Release Build can be used to periodically or on-demand pull the latest tagged binary files (i.e., commit results) from the second repository branch corresponding to each feature software for integration. The resulting target integrated artifact can be used for the final release. The tags can be specific tags assigned to the binary files in the second repository branch according to the Release Plan, and can serve as markers for the final releaseable version of the feature software.

[0082] It should be noted that, in this embodiment, the above-mentioned first warehouse branch can be a Type I warehouse dev branch, which is the dev branch of the Type I warehouse, and can also be called a Type I dev branch, which can refer to the main branch used for source code version management; the above-mentioned second warehouse branch is the warehouse branch to which the binary file is automatically pushed after the binary file is successfully built, which can be a Type II warehouse dev branch, which is the dev branch of the Type II warehouse, and can also be called a Type II dev branch.

[0083] In this embodiment, merging the source code of the functional software into the first warehouse branch is subject to a time limit to ensure the stability and predictability of the release version of the functional software. This is further described below.

[0084] As an optional implementation, the method also includes: before the target time node, merging the source code of the functional software into the first warehouse branch; after the target time node and before the release time node of the functional software, prohibiting the merging of the source code of the functional software into the first warehouse branch.

[0085] In this embodiment, a target time node is specified, which may refer to a code freeze time node. Code freeze is a stage in the software development process, marking the end of function development and the beginning of preparations for entering the final testing or release phase. In this embodiment, before the target time node, the source code of the functional software may be merged into the first warehouse branch, that is, before the target time node, function development may be performed, and source code that complies with the process regulations may submit a merge request to the first warehouse branch. After the target time node and before the release time node of the functional software, it is prohibited to merge the source code of the functional software into the first warehouse branch. This may be that after the target time node, except for urgent problem (bug) fixes, code submissions for new functions will no longer be accepted, and any functional additions or modifications to the code base will no longer be allowed, thereby ensuring that the version of the functional component can reach a stable state before the scheduled release time, avoiding potential problems and risks caused by frequent changes near the release, and thus ensuring the stability and predictability of the release version of the functional software.

[0086] For example, to ensure that the software can be delivered on time, the target time node in the development process can be specified in the software release plan information, such as in the Release Plan. Before the target time point, each functional software can carry out functional development in the branch and submit a merge request for the code that meets the conditions to the corresponding I-type repository dev branch. After the target time point, each functional software can only submit a merge request to the I-type repository dev branch for the code that fixes the functional issues before the target time point to ensure that the final integrated version is consistent with the Release Plan description.

[0087] Optionally, in the development cycle of a Release Plan, before entering the code freeze time node, all functional software is in the functional development state, and Monkey Build can be used to integrate artifacts on demand. Code developers who need to integrate artifacts can submit the hash code of each functional software in the repository corresponding to Monkey Build for artifact integration. The submission action will trigger the integration to start automatically. After the code freeze time node and before the software release time point, Engineering Build will be triggered regularly to pull the latest submission results of the Type II repository dev branch of each functional software for integration and construction. The obtained target integrated artifacts will be uploaded to the specified path in the artifact management system for functional software qualification verification.

[0088] As an optional implementation, the method also includes: submitting the hash code of the functional software to the warehouse corresponding to the first target strategy set; integrating the development objects in the functional development stage according to the target integration strategy to obtain the target integrated product, including: integrating the development objects in the functional development stage according to the target integration strategy using the hash code to obtain the target integrated product.

[0089] In this embodiment, each submission of each functional software in its own repository has a unique hash code, which can provide a traceability basis for subsequent integration. For example, the unique submission hash code and the code repository address can be used for integration traceability.

[0090] Optionally, this embodiment can submit the hash code of the functional software to the repository corresponding to the first target policy set. For example, the hash code of each functional software can be submitted to the repository corresponding to Monkey Build for product integration. This submission action will trigger the automatic start of integration. For example, it can trigger the integration of source code or binary files, achieving real-time or on-demand hybrid integration. Further integration with Engineering Build and Release Build can meet the integration needs of different stages.

[0091] Optionally, Monkey Build / Daily Build creates an integrated traceability code repository in the code management repository. This integrated traceability code repository contains the integrated repository address and a corresponding submission hash code description file. This submission hash code description file can include the aforementioned hash code. Based on this submission hash code description file, Type I repository integration, Type II repository integration, and a hybrid integration of Type I and Type II repositories can be supported, thus achieving flexible integration.

[0092] In this embodiment, there is an association relationship between the software release plan information of each version and the development task, and the development task associated with the software release plan information can be determined.

[0093] As an optional implementation, step S104, determining the development tasks associated with the software release plan information, includes: determining the target association relationship associated with the software release plan information, wherein the target association relationship is used to represent the relationship between the software release plan information and the software requirement information, and the relationship between the software release plan information and the development tasks, and the software release plan information corresponds to the version of the functional software; according to the target association relationship, determining the development tasks associated with the software release plan information.

[0094] In this embodiment, corresponding software release plan information can be formulated for each version of functional software. In order to ensure the consistency between the software release plan information, the development tasks of the functional software, and the software requirement information, a target association relationship can be established in advance between the software release plan information and the specific implementation of the functional software. This target association relationship can be used to represent the relationship between the software release plan information and the software requirement information of the functional software, as well as the relationship between the software release plan information and the development tasks of the functional software. Based on this, when determining the development tasks associated with the software release plan information, the above-mentioned target association relationship associated with the software release plan information can be determined first, and then according to the target association relationship, the above-mentioned development tasks associated with the software release plan information can be determined. Optionally, the problem repair associated with the software release plan information can also be determined.

[0095] As an optional implementation, before determining the target association relationship associated with the software release plan information, the method also includes: determining project requirement information of the functional software, wherein the project requirement information is used to represent the schedule requirements of the project to which the functional software belongs; splitting the project requirement information to obtain functional requirement information of the functional software, and establishing a first association relationship between the project requirement information and the functional requirement information, wherein the functional requirement information is used to represent the functions that the functional software needs to have; splitting the functional requirement information to obtain software requirement information, and establishing a second association relationship between the functional requirement information and the software requirement information, wherein the software requirement information is used to describe the version of the software release plan information required for developing the functional software; creating a development task based on the software requirement information, and establishing a target association relationship between the development task, the software requirement information and the software release plan information; generating traceability information of the functional software using the target association relationship, the second association relationship and the first association relationship, wherein the traceability information is used to trace the functional software after development.

[0096] In this embodiment, before determining the target association relationship associated with the software release plan information, project requirement information for the functional software may also be determined. This project requirement information may be used to represent the schedule requirements (or project requirements) of the project to which the functional software belongs, and may be referred to as project schedule requirements. Optionally, this embodiment stores the project requirement information in a demand management system.

[0097] After determining the project requirement information, the project requirement information can be split to obtain functional requirement information for the functional software. This functional requirement information can be used to represent the functions that the functional software needs to have (i.e., functional requirements), and a first association relationship can be established between the project requirement information and the functional requirement information. Optionally, this embodiment stores the functional requirement information in a demand management system.

[0098] Furthermore, this embodiment can split the functional requirement information to obtain software requirement information. This software requirement information is used to describe the version of the software release plan information required to develop the functional software. For example, the software requirement information is used to clarify in which version of the release plan each requirement of the functional software is implemented. A second association relationship can be established between the functional requirement information and the software requirement information. Optionally, this embodiment stores the software requirement information in a demand management system.

[0099] Furthermore, this embodiment creates a development task based on the software requirement information and establishes the aforementioned target association relationship between the development task, the software requirement information, and the software release plan information. Furthermore, using the aforementioned target association relationship, the second association relationship, and the first association relationship, traceability information for the functional software of this embodiment is generated. This traceability information can be an integrated information description file that can be used to indicate the association and traceability between project requirement information, functional requirement information, and software requirement information. This traceability information is used to trace the functional software after development.

[0100] This embodiment can establish the above-mentioned target association relationship between the software release plan information and the software requirement information and the development tasks of the functional software through the document management system from which the software release plan information comes and the requirement management system from which the development tasks come, and then establish the association traceability between the project requirement information, the functional requirement information and the software requirement information based on the above-mentioned target association relationship, the second association relationship and the first association relationship, thereby achieving the traceability effect of the functional software.

[0101] The embodiment of the present invention further provides a vehicle software integration system. It should be noted that the vehicle software integration system of this embodiment can be used to execute the software integration method of the embodiment of the present invention.

[0102] Figure 2 FIG is a schematic diagram of a vehicle software integration system according to an embodiment of the present invention. Figure 2 As shown, the vehicle software integration system 20 may include: a document management system 21 , a requirement management system 22 , a code management system 23 , a continuous integration system 24 and a product management system 25 .

[0103] The document management system 21 is used to determine at least one piece of software release plan information for the assisted driving function, wherein the software release plan information is used to indicate a release rule for functional software to be developed in the assisted driving function.

[0104] In this embodiment, document management system 21 can be referred to as a version release plan document management system. Based on project requirements, it can determine software release timelines and the functions required to be implemented at each software release timeline. In this embodiment, at least one software release plan for the assisted driving function can be developed and stored in document management system 21. This software release plan information, also known as a version release plan, can be stored.

[0105] In the document management system 21, since the functional software of the assisted driving function needs to comply with the release time nodes of the vehicle development, each version of the functional software needs to be released at each release time node. It is necessary to formulate a corresponding Release Plan for each version and formulate the release version number of the corresponding functional software. Optionally, a large version of the functional software will undergo multiple iterations, so the actual Release Plan will contain multiple small versions. According to the actual progress of the functional software project, the version release plan can include E0, E1, E2, E3, E4, and OTA major versions. Each major version will undergo multiple iterations, and multiple small versions will evolve during the iteration. For example, the major version E0 can evolve into multiple small versions E0V1, E0V2, etc.

[0106] The demand management system 22 is used to determine development tasks associated with software release plan information, wherein the development tasks are created based on software demand information, and the software demand information is used to describe software release plan information required for developing functional software.

[0107] In this embodiment, the requirements management system 22 can be used to split the project requirements information to obtain functional requirements information, establish a first association relationship between the project requirements information and the functional requirements information. The project requirements information can then be split to obtain software requirements information, and then establish a second association relationship between the functional requirements information and the software requirements information. The requirements management system 22 can be used to store the aforementioned project requirements information, functional requirements information, and software requirements information.

[0108] In this embodiment, the functional software may include a perception fusion module, a speed planning module, a control module, a REM module, a data return module, and other functional modules. The requirements management system 22 can determine the associated functional requirements information based on the project requirements information of the functional modules, determine the associated software requirements information based on the functional requirements information, create corresponding development tasks based on the software requirements information, and establish an association between the development tasks and the software requirements information. The software requirements information can specify the release plan version in which the requirements are to be implemented, thereby establishing an association between the release plan and the specific implementation of the software, thereby ensuring consistency among the software requirements information, development tasks, and release plan.

[0109] The code management system 23 is used to determine multiple functional development stages of functional software based on development tasks; determine the codes developed in the functional development stages, and determine the target integration strategies corresponding to the functional development stages from the integration strategy set, wherein the integration strategy set includes: a first integration strategy for integrating the source code of the functional development stage, a second integration strategy for integrating the binary files of the functional development stage, and a third integration strategy for mixed integration of the source code and binary files of the functional development stage, wherein the binary files are converted from the source code.

[0110] In this embodiment, the code management system 23 may include C language code generated by the model and handwritten C code.

[0111] Optionally, the different functional development stages of the functional software may include a functional development stage, a functional verification stage, and a functional release stage. The first integration strategy may be used to represent the rules for continuous integration of source code in the functional development stage, i.e., source code integration rules; the second integration strategy may be used to represent the rules for integration of binary files in the functional development stage, i.e., binary file integration rules; and the third integration strategy may be used to represent the rules for mixed integration of source code and binary files in the functional development stage, i.e., source code and binary file mixed integration rules.

[0112] Optionally, Monkey Build / Daily Build can be used to achieve flexible, on-demand integration of various functional modules during the aforementioned functional development phase, supporting source code integration, binary file integration, and mixed source and binary file integration. In other words, Monkey Build / Daily Build can correspond to the first, second, and third integration strategies described above, thereby enabling rapid software iteration. Monkey Build / Daily Build can create an integrated traceability code repository within the code management repository. This traceability code repository can contain the integration repository address and a corresponding commit hash code description file. Flexible integration can be achieved based on this hash code description file, supporting Type I repository integration, Type II repository integration, and a mix of Type I and Type II repositories. Developers can optionally modify the integrated traceability code repository file as needed, and submitting it will automatically trigger Monkey Build to perform an integrated build. If the integrated build passes, the resulting target integrated artifact can be used for smoke testing. If the build fails, the integration log can be used to quickly locate the cause of the error, facilitating problem resolution by the developer.

[0113] In this embodiment, Engineering Build can be used to support binary file integration during the functional verification phase. That is, Engineering Build corresponds to the second integration strategy described above and can periodically or on-demand pull the latest commits from the dev branch of the Type II repository corresponding to each functional module for integration, with the integrated artifacts used for qualification verification.

[0114] In this embodiment, the Release Build supports binary file integration during the functional verification phase. This corresponds to the second integration strategy described above and can be used to periodically or on-demand pull the latest tagged commits from the dev branch of the Type II repository corresponding to each functional module for integration. The resulting target integrated artifact can then be used for the final release.

[0115] Optionally, developers of functional modules such as the perception fusion module, speed planning module, control module, REM module, and data return module can create development branches based on the created development tasks. For example, they can pull the development branch from the code repository and clone the code to the local development branch for development. After developing the code, the developed code can be pushed to the code management system 23. Optionally, each submission of each functional module in its own repository has a unique submission hash code. This unique submission hash code and the code repository address can be used for integrated traceability.

[0116] Alternatively, developers of each functional module can submit merge requests for code that meets the requirements to the dev branch of the Type I repository. Code reviewers will then decide whether to approve the merge based on the merge request. If the code reviewer approves the merge request, the code and the merge action will automatically trigger a binary build task in the Type II repository. Once the binary is successfully built, it will be automatically pushed to the corresponding dev branch of the Type II repository.

[0117] Optionally, Daily Build is used to trigger integration tasks on a scheduled basis. This integration task can detect problems early, reduce repair costs, and thus ensure the stability of functional module development.

[0118] The continuous integration system 24 is used to integrate the development objects in the functional development stage according to the target integration strategy to obtain the target integrated product. When the target integration strategy is the first integration strategy, the development object is the source code; when the target integration strategy is the second integration strategy, the development object is the binary file; when the target integration strategy is the third integration strategy, the development object is the source code and the binary file.

[0119] In the continuous integration system 24, corresponding continuous integration builds can be performed on nodes according to different triggering tasks. For example, Monkey Build / Daily Build can be used to achieve on-demand flexible integration of various functional modules. It can support source code integration, binary file integration, and mixed integration of source code and binary files, and use Engineering Build and Release Build to achieve binary file integration.

[0120] Optionally, after the Monkey Build integration is triggered, if the integration fails, the continuous integration system 24 can upload the integration log to a specified path in the product management system 25, so that the software problem can be quickly located and repaired based on the integration log.

[0121] Developers of each functional module submit merge requests for code that meets the requirements to the dev branch of the Type I repository. Code reviewers then decide whether to approve the merge based on the submission information. If the code reviewer approves the merge request, the code and the merge action automatically trigger a binary file build task in the Type II repository. Once the binary file is successfully built, it is automatically pushed to the corresponding dev branch of the Type II repository.

[0122] The Daily Build integration task is triggered regularly to perform an integrated build based on the latest commit of the specified module and branch. This integration task can detect problems early, reduce repair costs, and ensure software stability.

[0123] After triggering tasks such as Monkey Build, Daily Build, Engineering Build, and Release Build in the continuous integration system, compilation and build can all be performed on the integration node. After the target integration artifacts are uploaded to the artifact management system, the node automatically clears the relevant build data to reduce the risk of code leakage during the entire build process.

[0124] The product management system 25 is used to receive the target integrated product.

[0125] The work-in-progress management system 25 receives the target integration artifact, wherein a repository corresponding to each continuous integration task can be created and named to be consistent with the continuous integration task naming. For example, the Monkey Build / Daily Build repository directory structure can be set to date-integration task number-artifact name, for example, 2023-04-14-MonkeyBuild001-ProductX. Among them, for frequently built Monkey Build / Daily Build, using the date as a prefix can help the team quickly find the latest build results, and facilitate comparison and problem location of historical builds; the EngineeringBuild / Release Build repository directory structure is set to integration task number-artifact name, for example, EngineeringBuild001-ProductX or ReleaseBuild001-ProductX. The omission of the date prefix means that these builds occur relatively rarely, and more attention is paid to the results of specific build tasks. This naming method can simplify artifact management and make it more direct to find and reference artifacts, especially in situations where formal release or engineering verification is required.

[0126] The vehicle software integration system 20 of this embodiment can determine the related development tasks in the demand management system 22 based on the software release plan information in the document management system 21, and determine the different functional development stages of the assisted driving function in the code management system 23 based on the development tasks. Moreover, through the integration strategy, in the continuous integration system 24, in the different functional development stages of the assisted driving function, it is possible to perform continuous integration of source code, binary file integration, and mixed integration of source code and binary files, and then output traceable software products to the product management system 25, so as to realize safe and rapid iteration of assisted driving function software products, avoid supporting only binary integration, thereby solving the technical problem of low efficiency of vehicle software integration and achieving the technical effect of improving the software integration efficiency of vehicles.

[0127] The above method of this embodiment is further illustrated below with examples specifically for the assisted driving function of a vehicle, by proposing a continuous integration method for functional software with driving functions.

[0128] This embodiment relates to a continuous integration method for various functional software in a vehicle's assisted driving function, which may be a continuous integration method for various functional software in an ADASL level 2 assisted driving function.

[0129] As the pace of vehicle intelligence accelerates, assisted driving systems have become a crucial component of vehicles. As a crucial component of intelligent vehicles, the continuous integration efficiency of functional software in assisted driving systems is crucial to system development, feature iteration efficiency, and quality assurance.

[0130] During the integration of functional software, code security is a particular concern for project managers in practice. Existing integration methods guarantee code security, but only for binary product integration. While this approach can reduce the risk of code leaks, it compromises software iteration efficiency. Furthermore, project managers are concerned about the traceability of functional software, and incorporating traceability into integration management is essential during software integration. Therefore, a continuous integration method and system for functional software that meets both source code and binary file integration requirements while ensuring code security and traceability is crucial for assisted driving software systems.

[0131] However, related technologies integrate functional software through a timed or publish-subscribe mechanism, employing binary integration to ensure code security. While binary integration can ensure code security, in actual development, only binary integration is supported, which reduces the flexibility of functional software integration and the efficiency of development iterations. Furthermore, related intelligent driving software integration and traceability methods use code updates triggered at preset time intervals to enable software integration when trigger conditions are met, and utilize snapshot submissions to achieve traceability of software integration, reducing the flexibility of functional software integration and the efficiency of development iterations.

[0132] In response to the above problems, the continuous integration method of functional software with driving functions in this embodiment can be dedicated to guiding the standardization of the development process of ADAS L2-level assisted driving functional software in various stages of functional software development through a standardized continuous integration process. While ensuring code security, in different functional development stages, it can not only perform source code continuous integration, binary file integration, but also support mixed integration of source code and binary files, output traceable software products, and centrally manage software products, so as to achieve safe and rapid iteration of assisted driving functional software products, simplify the integration process, and reduce the workload of developers, thereby improving the integration efficiency of functional software; this embodiment can meet the requirements of functional software integration at fixed time intervals, as well as flexible and timed integration according to the actual development needs of functional software at different functional development stages; the integrated product can include an integration information description file, which can be used to achieve traceability of functional software.

[0133] The following further introduces the continuous integration method of the functional software with driving functions of this embodiment.

[0134] Figure 3 FIG. 1 is a schematic diagram of a continuous integration process of functional software according to an embodiment of the present invention. Figure 3 As shown, the continuous integration process is implemented through a document management system 31, a requirements management system 32, a code management system 33, a continuous integration system 34, and an artifact management system 35. By using the document management system 31 and the requirements management system 32, a relationship is established between the software version release plan, the software requirements information, and the development tasks of the functional software.

[0135] The implementation method in the document management system 31 is further introduced below.

[0136] The document management system 31 of this embodiment can be called a version release plan document management system. To achieve traceability of functional software, a traceability relationship can be established at the beginning of the software version release plan (Release plan). Optionally, the software version release plan must meet the project schedule requirements of the functional software, that is, to meet the project needs. The requirements and issues that need to be implemented and fixed for each version of the functional software to be released can be planned, and a traceability relationship can be established between the corresponding requirements and fixed issues and the software version release plan.

[0137] Optionally, this embodiment determines the release time nodes of the functional software and the functions that the functional software releases at each release time node. Based on the release time nodes and the functions that need to be realized, the software version release plan is formulated and stored in the document management system 31.

[0138] The document management system 31 can be used to store the above-mentioned software version release plan. Since the functional software of assisted driving needs to comply with the release time nodes of vehicle development, each version of the functional software needs to be released at each release time node. It is necessary to formulate a corresponding software version release plan for each version and formulate the corresponding functional software release version number. Optionally, a large version of software will go through multiple iterations, so the actual software version release plan will include multiple small versions. According to the actual progress of the functional software project, the software version release plan may include several large versions such as Release Plan E0, Release Plan E1, Release Plan E2, Release Plan E3, Release Plan E4, and Release Plan OTA. Each large version will undergo multiple iterations, and multiple small versions will evolve during the iteration. For example, a major version release plan E0 can evolve into multiple minor versions, including release plans E0V1, E0V2, etc.; a major version release plan E1 can evolve into multiple minor versions, including release plans E1V1, E1V2, etc.; a major version release plan E2 can evolve into multiple minor versions, including release plans E2V1, E2V2, etc.; a major version release plan E3 can evolve into multiple minor versions, including release plans E3V1, E3V2, etc.; a major version release plan E4 can evolve into multiple minor versions, including release plans E4V1, E4V2, etc.; a major version release plan OTA can evolve into multiple minor versions, including release plans OTAV1, OTAV2, etc.

[0139] The demand management system 32 of this embodiment is introduced below.

[0140] In the requirements management system 32, a linked traceability system can be established for project requirements information, functional requirements information, and software requirements information / issues. At the same time, a linked relationship is established between development tasks / issue fixes and software requirements information / issues, thereby enabling bidirectional traceability between software requirements information / issues and development tasks / issue fixes. Optionally, this embodiment establishes a linked relationship between development tasks / issue fixes, functional software test cases, and software requirements information, thereby enabling bidirectional traceability between software requirements information, test cases, and development tasks.

[0141] The demand management system 32 of this embodiment can perform the following steps:

[0142] Step S321: Obtain project requirement information.

[0143] Step S322: split the project requirement information to obtain functional requirement information.

[0144] This embodiment can establish an association relationship between project requirement information and function requirement information.

[0145] Step S323: split the functional requirement information to obtain software requirement information / problems.

[0146] This embodiment can establish an association relationship between functional requirement information and software requirement information / issues. The requirement management system 32 can store the above-mentioned project requirement information, functional requirement information, and software requirement information / issues.

[0147] Step S324: Create corresponding development task problem repair according to the software requirement information.

[0148] Each functional module in the requirements management system 32 can determine associated functional requirements based on project requirements, determine associated software requirements / issues based on the functional requirements, create corresponding development task issue fixes based on the software requirements, and establish an association between the development tasks and the software requirements / issues. The software requirements / issues must specify the release plan version in which they are implemented. Based on this, the release plan is associated with the specific implementation of the functional software, ensuring consistency between the software requirements / issues, development tasks / issue fixes, and the release plan.

[0149] The code management system 33 of this embodiment is introduced below.

[0150] The code management system 33 includes C language code generated by the model and handwritten C code, which is used to manage the function development code. The branch management strategy used in this embodiment is that developers host the code in the code management warehouse and use branch management (for example, Type I warehouse dev branch and Type II warehouse dev branch) for isolation and version control. Optionally, the code management system 33 can perform the following steps:

[0151] Step S331: Pull the development branch from the code repository.

[0152] Developers of each functional module create development branches based on the development tasks / problem fixes created, and can pull development branches from the code repository to develop new features in the development branches.

[0153] Step S332: After the local code development is completed, the developed code is submitted to the code repository.

[0154] Step S333, integrate the traceability code repository through on-demand build tasks, submit the integration file / schedule to trigger the daily build task. Monkey Build / Daily Build creates an integrated traceability code repository in the code management repository. The integrated traceability code repository contains the integrated warehouse address and the corresponding submission hash code description file, which is used to achieve flexible integration and support Type I warehouse integration, Type II warehouse integration, and mixed integration of Type I warehouse and Type II warehouse. Developers modify the integrated traceability code repository file as needed, and submission will automatically trigger the Monkey Build integrated build. If the integrated build passes, the software product can be used for smoke testing. If the integrated build fails, the cause of the error can be quickly located based on the integration log, which is convenient for developers to fix the problem.

[0155] Daily Build can be used to trigger integration tasks on a scheduled basis, performing an integration build based on the latest commit results of a specified module and a specified branch. This integration task can help identify problems early, reduce repair costs, and ensure software stability.

[0156] Step S334: The development branch submits a merge request to the dev branch of the Type I repository.

[0157] This can be done by submitting a merge request to the development branch through Monkey Build / Daily Build and to the dev branch of the I-type repository.

[0158] Step S335: The merge request is approved.

[0159] The code reviewer decides whether to approve the merge based on the commit information. If the code reviewer approves the merge request, the source code and the merge action will automatically trigger the binary file build task of the I-type repository.

[0160] After completing the local code development, submit the developed code to the code repository, and merge the source code that meets the process requirements into the dev branch of the I-type repository. The merge action automatically triggers the automatic build.

[0161] Step S336: The built binary file will be automatically uploaded to the corresponding Type II repository dev branch.

[0162] The functional software of the assisted driving system of this embodiment may include multiple functional modules: a perception fusion module, a control module, a speed planning module, a REM module, and a data return module. After the merge request is approved, the corresponding build tasks of the perception fusion module, the control module, and the speed planning module in the continuous integration system 34 can automatically upload the completed binary files to the dev branch of the Type II repository corresponding to each functional module.

[0163] Figure 4FIG. 1 is a schematic diagram of a branching strategy according to an embodiment of the present invention. Figure 4 As shown, the branches include development branches (feature branches) and dev branches, wherein the dev branch includes the dev branch of Type I warehouse and the dev branch of Type II warehouse. The dev branch of Type I warehouse and the dev branch of Type II warehouse are the dev branches of Type I warehouse and Type II warehouse respectively. Each functional module uses the feature branch for development during the functional development stage. When the source code meets the process conditions, the developers of each functional module can submit a merge request for the source code that meets the requirements to the dev branch of Type I warehouse. The code reviewer determines whether to agree to the merge based on the submission information. If the code reviewer agrees to the merge request, the source code and the merge action will automatically trigger the binary file build task of Type I warehouse. After the binary file is successfully built, it will be automatically pushed to the corresponding dev branch of Type II warehouse.

[0164] Optionally, the code can be cloned locally for development in a development branch. After development is complete, the developed code can be pushed to the code management system 33. Each commit of each functional module in its own repository has a unique commit hash code. This unique commit hash code and the code repository address can be used for integrated traceability.

[0165] Optionally, this embodiment specifies a code freeze time node. Before the code freeze time node, feature development is performed, and code that complies with the process regulations can submit merge requests to the dev branch. The merge requests are used to submit merge requests for new features. After the code freeze time node, and before the release time node of the functional software, only merge requests for bug fixes can be submitted to the dev branch. Merge requests for new features are not allowed to be submitted to the dev branch.

[0166] Optionally, to ensure on-time software delivery, the Release Plan needs to specify a code freeze time during development. Before this time, each functional module can develop features in its own branch and submit merge requests for the code that meets the requirements to the corresponding Type I repository dev branch. After the code freeze time, each functional module can only submit merge requests for code that fixes functional issues that occurred before the code freeze to the dev branch, so that the final integrated functional software version is consistent with the Release Plan.

[0167] Optionally, in the development cycle of a Release Plan, before entering the code freeze time node, each functional module is in the functional development state, and Monkey Build can be used to integrate artifacts on demand. Code developers who need to integrate artifacts can submit the hash code of each functional module in the warehouse corresponding to Monkey Build to integrate the artifacts. The submission action will trigger the integration to start automatically. After the time reaches the code freeze time point and before the software release time point, Engineering Build will be triggered regularly to perform an integrated build by pulling the latest submission results of the dev branch of the Type II warehouse corresponding to each functional module. The integrated artifacts are uploaded to the specified path in the artifact management system for software qualification verification.

[0168] The continuous integration system 34 of this embodiment is introduced below.

[0169] This embodiment uses the continuous integration system 34 and Monkey Build / Daily Build to achieve on-demand and flexible integration of various functional modules of the driving function software, and is used to achieve source code integration, binary file integration, and mixed integration of source code and binary files.

[0170] After the Monkey Build task in the continuous integration system 34 is triggered, if the integration fails, the integration log will be uploaded to the specified path in the product management system 35, and developers can quickly locate and fix software problems based on the integration log.

[0171] Optionally, the Monkey Build / Daily Build mentioned above can be used for integration during the software development phase to achieve rapid software iteration.

[0172] The Engineering Build and Release Build in the continuous integration system 34 can be used to implement binary file integration. Optionally, the functional software of the assisted driving system of this embodiment can include: a perception fusion module, a speed planning module, a control module, a REM module, a data return module, etc.

[0173] Optionally, the Engineering Build in this embodiment can be used to pull the latest submission on the dev branch of the Type II repository corresponding to each functional module on a regular / on-demand basis for integration, and the obtained target integrated product can be used for qualification verification.

[0174] The Release Build in this embodiment can be used to pull the latest tagged submissions on the dev branch of the Type II repository corresponding to each functional module on a regular / on-demand basis for integration, and the obtained target integrated product can be used for the final version release.

[0175] In this embodiment, the continuous integration system 34 can perform corresponding continuous integration builds on the integration nodes according to different triggering tasks. In order to meet the integration requirements of different development stages, this embodiment implements the integrated pipelines of Monkey Build / Daily Build, Engineering Build and Release Build. After the Monkey Build, Daily Build, Engineering Build, Release Build and other tasks are triggered, compilation and build can be performed on the above-mentioned integration nodes. This ensures that the integrated build environment is uniformly deployed on the integration node, ensuring a consistent build environment. In addition, after each integrated product is uploaded to the designated storage location, the integration node automatically deletes the local build-related information to ensure code security and reduce the risk of leakage.

[0176] Optionally, each functional module can undergo qualification verification during a Release Plan period, and developers can tag each functional module as specified in the Release Plan to mark the release version. The Release Build is triggered regularly at the software release time point, pulling the latest tagged commit results from the dev branch of the Type II repository corresponding to each functional module for integration and build. The resulting integrated artifact is uploaded to a designated path in the artifact management system 35 for final release.

[0177] Through the product management system 35, the received integrated products corresponding to Monkey Build, Daily Build, Engineering Build and Release Build are centrally managed and controlled. The integrated products contain integration information description files, which can be used for integrated product traceability.

[0178] This embodiment adopts a unified management system for software artifacts. After the integration is completed, the integrated artifacts can be automatically uploaded to the designated path of each artifact repository in the artifact management system. In addition to the software artifacts, the artifacts also contain documentation for integration version tracing. Users with access rights to the artifact management system can download the integrated artifacts.

[0179] Optionally, create a repository corresponding to each continuous integration task in the product management system, and keep the naming consistent with the continuous integration task. The directory structure of the Monkey Build / Daily Build repository is set to date-integration task number-artifact name; the directory structure of the Engineering Build / Release Build repository is set to integration task number-artifact name for product traceability.

[0180] This embodiment implements a method for integrating ADAS L2 driving function software that is traceable from requirements management, software development, product integration, product management, and version release. By using a document management system 31 and a requirements management system 32, a relationship is established between version release plans, software requirements, and software development tasks. Functional development code is managed through a code management system 33. A continuous integration system 34 is used to achieve flexible, on-demand integration of various functional modules of the driving software using Monkey Build / Daily Build, supporting source code integration, binary file integration, and mixed integration of source code and binary files. Binary file integration is achieved using Engineering Build and Release Build. An artifact management system 35 provides centralized management and control of integrated artifacts. Integrated artifacts include integration information description files, which can be used for artifact traceability. This ensures safe and rapid iteration of assisted driving software products, simplifies the integration process, reduces developer workload, and improves functional software integration efficiency. Functional software integration can be performed at fixed intervals while also meeting actual functional software development needs, allowing for flexible and timed integration at different stages of functional development. Integrated artifacts can include integration information description files, which can be used to achieve functional software traceability.

[0181] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0182] According to an embodiment of the present application, an embodiment of a vehicle software integration device is provided, wherein the vehicle has an assisted driving function. It should be noted that the device can be used to execute the above-mentioned vehicle software integration method.

[0183] Figure 5 FIG is a schematic diagram of a vehicle software integration device according to an embodiment of the present invention. Figure 5 As shown, the vehicle software integration device 50 may include: a first determination unit 51 , a second determination unit 52 , a third determination unit 53 , a fourth determination unit 54 and an integration unit 55 .

[0184] The first determining unit 51 is configured to determine at least one piece of software release plan information for the driving assistance function, wherein the software release plan information is used to indicate a release rule for functional software to be developed in the driving assistance function.

[0185] The second determining unit 52 is configured to determine a development task associated with the software release plan information, wherein the development task is created based on the software requirement information, and the software requirement information is used to describe the software release plan information required for developing the functional software.

[0186] The third determining unit 53 is configured to determine multiple functional development stages of the functional software based on the development task.

[0187] The fourth determination unit 54 is used to determine the target integration strategy corresponding to the function development stage from the integration strategy set, wherein the integration strategy set includes: a first integration strategy for integrating the source code of the function development stage, a second integration strategy for integrating the binary files of the function development stage, and a third integration strategy for mixed integration of the source code and binary files of the function development stage, where the binary files are converted from the source code.

[0188] The integration unit 55 is used to integrate the development objects in the function development phase according to the target integration strategy to obtain the target integrated product. When the target integration strategy is the first integration strategy, the development object is the source code; when the target integration strategy is the second integration strategy, the development object is the binary file; when the target integration strategy is the third integration strategy, the development object is the source code and the binary file.

[0189] Optionally, the fourth determination unit 54 includes: a first determination module, used to determine, in response to the function development stage being the function development mid-stage, a first target integration strategy corresponding to the function development mid-stage from the integration strategy set, wherein the first target integration strategy is one of the following: a first integration strategy, a second integration strategy, and a third integration strategy; a second determination module, used to determine, in response to the function development stage being the function verification stage, a second target integration strategy corresponding to the function verification stage from the integration strategy set, wherein the second target integration strategy is the second integration strategy; a third determination module, used to determine, in response to the function development stage being the function release stage, a third target integration strategy corresponding to the function release stage from the integration strategy set, wherein the third target integration strategy is the second integration strategy.

[0190] Optionally, the third determination unit 53 includes: a fourth determination module, used to determine the development branch based on the development task; a fifth determination module, used to determine the stage of developing the source code of the functional software in the development branch as the functional development stage; a sixth determination module, used to build the binary file of the functional software through the source code in the first warehouse branch, upload the binary file to the second warehouse branch, determine the stage of verifying the binary file in the second warehouse branch as the functional verification stage, and determine the stage of releasing the binary file in the second warehouse branch as the functional release stage.

[0191] Optionally, the device also includes: a merging unit, used to merge the source code of the functional software into the first warehouse branch before the target time node; and a prohibiting unit, used to prohibit the merging of the source code of the functional software into the first warehouse branch after the target time node and before the release time node of the functional software.

[0192] Optionally, the device also includes: a submission unit for submitting the hash code of the functional software to the warehouse corresponding to the first target policy set; the integration unit 55 includes: an integration module for integrating the development objects in the functional development stage using the hash code according to the target integration strategy to obtain the target integrated product.

[0193] Optionally, the second determination unit 52 includes: a seventh determination module, used to determine the target association relationship associated with the software release plan information, wherein the target association relationship is used to represent the relationship between the software release plan information and the software requirement information, and the relationship between the software release plan information and the development task, and the software release plan information corresponds to the version of the functional software; an eighth determination module, used to determine the development task associated with the software release plan information according to the target association relationship.

[0194] Optionally, the device also includes: a fifth determination unit, used to determine the project requirement information of the functional software before determining the target association relationship associated with the software release plan information, wherein the project requirement information is used to represent the progress requirements of the project to which the functional software belongs; splitting the project requirement information to obtain functional requirement information of the functional software, and establishing a first association relationship between the project requirement information and the functional requirement information, wherein the functional requirement information is used to represent the functions that the functional software needs to have; splitting the functional requirement information to obtain software requirement information, and establishing a second association relationship between the functional requirement information and the software requirement information, wherein the software requirement information is used to describe the version of the software release plan information required for developing the functional software; creating a development task based on the software requirement information, and establishing a target association relationship between the development task, the software requirement information and the software release plan information; using the target association relationship, the second association relationship and the first association relationship, generating traceability information of the functional software, wherein the traceability information is used to trace the functional software after development.

[0195] In the software integration device of this embodiment, the different functional development stages of the assisted driving function can be determined based on the development tasks associated with the software release plan information. Through the integration strategy, in the different functional development stages of the assisted driving function, it is possible to support both continuous integration of source code and binary file integration, and mixed integration of source code and binary files, output traceable software products, and realize safe and rapid iteration of assisted driving function software products, avoiding supporting only binary integration, thereby solving the technical problem of low efficiency of vehicle software integration and achieving the technical effect of improving the software integration efficiency of the vehicle.

[0196] An embodiment of the present application further provides a vehicle, comprising: a memory storing an executable program; and a processor for running the program, wherein the method of each embodiment of the present application is executed when the program is running.

[0197] An embodiment of the present application further provides a computer-readable storage medium, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present application.

[0198] An embodiment of the present application further provides a computer program product, including a computer program, which implements the methods in various embodiments of the present application when executed by a processor.

[0199] An embodiment of the present application further provides a computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium is used to store a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0200] The embodiments of the present application further provide a computer program, which, when executed by a processor, implements the methods in the above-mentioned embodiments of the present application.

[0201] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0202] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0203] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0204] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0205] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0206] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A vehicle software integration method, characterized in that: The vehicle has assisted driving functions, including: Determining at least one piece of software release plan information of the driving assistance function, wherein the software release plan information is used to indicate a release rule for functional software to be developed in the driving assistance function; Determining a development task associated with the software release plan information, wherein the development task is created by software requirement information, and the software requirement information is used to describe the software release plan information required for developing the functional software; Based on the development task, determining multiple functional development stages of the functional software; Determining a target integration strategy corresponding to the function development stage from an integration strategy set, wherein the integration strategy set includes: a first integration strategy for integrating source code in the function development stage, a second integration strategy for integrating binary files in the function development stage, and a third integration strategy for performing mixed integration of source code and binary files in the function development stage, wherein the binary files are converted from the source code; According to the target integration strategy, the development objects in the function development phase are integrated to obtain a target integrated product, wherein, when the target integration strategy is the first integration strategy, the development object is the source code; when the target integration strategy is the second integration strategy, the development object is the binary file; when the target integration strategy is the third integration strategy, the development object is the source code and the binary file.

2. The method according to claim 1, characterized in that Determining the target integration strategy corresponding to the functional development stage from the integration strategy set includes: In response to the function development stage being the function development mid-stage, determining a first target integration strategy corresponding to the function development mid-stage from the integration strategy set, wherein the first target integration strategy is one of the following: the first integration strategy, the second integration strategy, and the third integration strategy; In response to the function development stage being the function verification stage, determining a second target integration strategy corresponding to the function verification stage from the integration strategy set, wherein the second target integration strategy is the second integration strategy; In response to the function development stage being the function release stage, a third target integration strategy corresponding to the function release stage is determined from the integration strategy set, wherein the third target integration strategy is the second integration strategy.

3. The method according to claim 2, characterized in that Determining multiple functional development stages of the functional software based on the development task includes: Based on the development tasks, determine the development branch; Determining the stage of developing the source code of the functional software in the development branch as the functional development stage; A binary file of the functional software is constructed using the source code in the first warehouse branch, the binary file is uploaded to the second warehouse branch, the stage of verifying the binary file in the second warehouse branch is determined as the functional verification stage, and the stage of releasing the binary file in the second warehouse branch is determined as the functional release stage.

4. The method according to claim 3, characterized in that The method further comprises: Before the target time node, merge the source code of the functional software into the first warehouse branch; After the target time node and before the release time node of the functional software, it is prohibited to merge the source code of the functional software into the first warehouse branch.

5. The method according to claim 2, characterized in that The method further comprises: Submitting the hash code of the functional software to the warehouse corresponding to the first target policy set; Integrating the development objects in the functional development phase according to the target integration strategy to obtain a target integrated product includes: According to the target integration strategy, the development objects in the function development phase are integrated using the hash code to obtain the target integrated product.

6. The method according to claim 1, characterized in that Determining the development task associated with the software release plan information includes: Determining a target association relationship associated with the software release plan information, wherein the target association relationship is used to represent a relationship between the software release plan information and the software requirement information, and a relationship between the software release plan information and the development task, and the software release plan information corresponds to a version of the functional software; According to the target association relationship, the development task associated with the software release plan information is determined.

7. The method according to claim 6, characterized in that Before determining the target association relationship associated with the software release plan information, the method further includes: Determining project requirement information of the functional software, wherein the project requirement information is used to represent the progress requirement of the project to which the functional software belongs; Splitting the project requirement information to obtain functional requirement information of the functional software, and establishing a first association relationship between the project requirement information and the functional requirement information, wherein the functional requirement information is used to indicate the functions that the functional software needs to have; Splitting the functional requirement information to obtain the software requirement information, and establishing a second association relationship between the functional requirement information and the software requirement information, wherein the software requirement information is used to describe the version of the software release plan information required for developing the functional software; Based on the software requirement information, the development task is created, and the target association relationship among the development task, the software requirement information, and the software release plan information is established; The target association relationship, the second association relationship, and the first association relationship are used to generate traceability information of the functional software, wherein the traceability information is used to trace the functional software after development.

8. A vehicle software integration system, characterized in that: The vehicle has assisted driving functions, including: a document management system, configured to determine at least one piece of software release plan information for the driving assistance function, wherein the software release plan information is used to indicate a release rule for functional software to be developed in the driving assistance function; A demand management system for determining a development task associated with the software release plan information, wherein the development task is created using software demand information, and the software demand information is used to describe the software release plan information required for developing the functional software; A code management system is configured to determine, based on the development task, multiple function development stages of the function software; determine the code developed in the function development stage; and determine, from an integration strategy set, a target integration strategy corresponding to the function development stage, wherein the integration strategy set includes: a first integration strategy for integrating source code in the function development stage, a second integration strategy for integrating binary files in the function development stage, and a third integration strategy for hybrid integration of source code and binary files in the function development stage, wherein the binary files are converted from the source code; a continuous integration system, configured to integrate the development objects in the functional development phase according to the target integration strategy to obtain a target integrated artifact, wherein, when the target integration strategy is the first integration strategy, the development object is the source code; when the target integration strategy is the second integration strategy, the development object is the binary file; and when the target integration strategy is the third integration strategy, the development object is both the source code and the binary file; The product management system is used to receive the target integrated product.

9. A vehicle, characterized in that: include: a memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 7 when running.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 7.

Images