Engineering method for automation software integration of automobile industry safety

Abstract

The invention discloses an engineering method for automatic software integration of automobile industry safety, which comprises the following steps of: defining a protocol of a construction system, and realizing integration and collaboration of upstream and downstream modules; building an infrastructure of the construction system; the software submodule issues target platform characteristics of the software package; configuring a target hardware equipment system mirror image; the software submodule warehouse adapts to a construction system; and continuously integrating and releasing the system mirror image file and delivering to the user. According to the method, a two-mechanism mode is adopted for integration, so that the risk of code security leakage is reduced, and the integration efficiency is not reduced; upstream and downstream of a global integration assembly line are opened by adopting a publishing and subscribing mechanism, a highly automatic integration mode is realized, and the development efficiency is improved; and continuously optimizing the efficiency of the global integrated assembly line by introducing a hybrid integration mode and assisting with a reinforcement learning algorithm.

Description

Technical Field

[0001] The present invention relates to software integration technology, and in particular to an engineering method for safe automated software integration in the automotive industry. Background Art

[0002] The automotive industry has a large number of software modules and components, which require the collaborative development of many internal and external teams. The security of software source code and the efficiency of integrated engineering are great challenges.

[0003] Automotive systems are becoming increasingly complex, usually including multiple target hardware platforms of different models to cope with different purposes, such as ECU (Electronic Control Unit) electronic control units for centralized control of vehicle areas, and HPC (High Performance Computing) high-performance computers for autonomous driving. These terminal devices have their own operating systems and development tool chains. The introduction of virtualization technology even allows multiple operating systems to run simultaneously on a hardware terminal, greatly increasing the difficulty of software integration.

[0004] As OTA becomes the direction of industry development, the launch of vehicles is no longer the end of software integration, but the starting point of continuous iteration. With the increase of models and new functions on the market, the development and operation teams will bear more and more pressure, and software integration automation engineering has become the only solution to the problem.

[0005] There are two main integration methods: source code integration and binary integration. When integrating for a specific target platform, source code integration is extremely convenient in terms of engineering, such as unified tool chain, centralized configuration, and convenient problem tracing. However, the disadvantages of source code integration are also obvious, that is, the risk of code leakage is high, and all downstream modules can access the upstream source code, exposing a larger scope of leakage risk. Binary integration is the opposite. While it has better information security, it must make greater efforts in integration management, which poses greater challenges to R&D management. Summary of the invention

[0006] In order to solve the deficiencies in the prior art, the object of the present invention is to provide an engineering method for safe automated software integration in the automotive industry.

[0007] To achieve the purpose of the present invention, the technical solution adopted by the present invention is: An engineering method for safe automated software integration in the automotive industry, comprising the steps of: (1) Define the specifications for building the system and realize the integration and collaboration of upstream and downstream modules; (2) Build the infrastructure for the build system; (3) Target platform characteristics of software submodule release packages; (4) Configure the target hardware device system image; (5) Software submodule repository adaptation build system; (6) Continuously integrate and publish system image files and deliver them to users.

[0008] Furthermore, in step (1), the automated software integration system includes target hardware device system image software and upstream software sub-module software. The target hardware device system image software defines a series of integration elements to form output product requirements for the upstream software sub-module software, and connects the upstream and downstream pipelines by standardizing the definition of the integration elements.

[0009] Furthermore, in step (1), the integration elements include: target hardware device, operating system, development tool chain, dependent modules, and customized configuration; Target hardware device, including device model and hardware features; Operating system: the operating system of the target hardware device runtime environment. The same hardware device supports multiple operating systems including virtualization technology. Development tool chain, a series of compilation and debugging tool software that supports the target hardware device operating system running in the development environment; Dependency module, a list of dependencies on upstream software submodule packages, and alignment of dependency modules with target hardware device operating systems and development tool chains; Customized configuration defines the features supported by the upstream and downstream software, and builds a customized software package containing specified features based on specific needs.

[0010] Furthermore, in step (2), the infrastructure includes source code repository, integrated pipeline environment, artifact library, integrated scheduler, command line tool, build pipeline configuration, and undertake automated build work; The source code warehouse is a warehouse for storing product source code and is the source of input for the integration pipeline; Integrated pipeline environment is a general term for a series of operating environments and management service applications that compile, reorganize, test and package the input source code and binary machine products, and execute pipeline operations in sequence; Product warehouse, a warehouse for storing products produced after the assembly line completes operation; Integrated scheduler for coordinating scheduling services across upstream and downstream module warehouse pipelines; Command line tool to help maintain build system configuration files, abstracting common functionality for all modules to use.

[0011] Furthermore, in step (3), the software submodule publishes its own target platform characteristics to the build system. When building the system, the published characteristics are used to implement customized construction, and the downstream modules publish their own characteristics based on these characteristics.

[0012] Further, in step (4), in the target hardware device system image integrated code repository, a configuration file is generated using a command line tool according to the requirements of a specific product project and a defined build system specification; After completing the definition of the target hardware device system image configuration file, use the command line tool to subscribe to the new version release message of the dependent module according to the relevant content of the dependent project in the configuration file, and request the upstream module to release the corresponding software version.

[0013] Furthermore, in step (5), the format of the system configuration file is the same as the format of the target hardware device system image integration, and the maintenance and update methods are divided into: self-maintenance and update, upstream dependent module releases a new version, and downstream module requests the target platform version.

[0014] Furthermore, in step (6), the system construction methods include continuous construction, periodic construction, and hybrid mode; Continuous build: For any module in any link of the global integrated build pipeline, submitting code to the source code repository triggers the module's own build pipeline; Regular builds execute build tasks at fixed time intervals; The hybrid mode refers to the use of continuous integration in the main body of the global integrated construction pipeline, regular construction of aggregation modules that are widely dependent on basic modules and have many dependent modules, and the introduction of reinforcement learning for continuous optimization.

[0015] The beneficial effects of the present invention are that, compared with the prior art, the present invention adopts a two-mechanism integration method to reduce the risk of code security leakage without reducing the efficiency of integration; the present invention adopts a publish-subscribe mechanism to connect the upstream and downstream of the global integration pipeline, realizing a highly automated integration mode to accelerate development efficiency; the present invention introduces a hybrid integration method and uses a reinforcement learning algorithm to continuously optimize the efficiency of the global integration pipeline. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a schematic diagram of the engineering method for safe automated software integration in the automotive industry according to the present invention. DETAILED DESCRIPTION

[0017] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of this application.

[0018] like Figure 1 As shown, the engineering method for safe automated software integration in the automotive industry of the present invention comprises the following steps: (1) Define the specifications for building the system to achieve integration and collaboration between upstream and downstream modules; The automation software integration system is mainly divided into two types: target hardware device system image software and upstream software submodule software. The former defines a series of integration elements to form the demand for the latter's output products, and these integration elements are defined in a standardized way to connect the upstream and downstream pipelines. These integration elements include: Target hardware device, mainly device model, hardware features, etc., such as CPU architecture x86_64 / arm64 / arm32, etc.

[0019] Operating system: the operating system of the target hardware device runtime environment. The same hardware device may support multiple operating systems including virtualization technology, such as Linux / QNX.

[0020] Development tool chain is a series of compilation and debugging tool software that runs in the development environment and supports the operating system of a specific target hardware device, such as GNU / QNXSDP.

[0021] Dependency module, a list of dependencies on upstream software submodule packages. Dependency modules need to align with the target hardware device operating system and development tool chain.

[0022] Customized configuration defines the features supported by the upstream and downstream software respectively, and builds a software package containing the specified features based on specific needs. When the feature needs are supported by the downstream software features, the downstream also needs to customize and build a software package that meets the needs.

[0023] Define standard expressions for the above integration elements to facilitate the formation of a maintainable database later.

[0024] (2) Build the infrastructure for the build system; The infrastructure includes source code repository, integrated pipeline environment, product library, integrated scheduler, command line tools, etc., which help build pipeline configuration and undertake actual automated construction work.

[0025] The source code repository is a warehouse that stores product source code and is also the source of input for the integration pipeline.

[0026] The integrated pipeline environment is a general term for a series of operating environments and management service applications that compile, reorganize, test and package input source code, binary products, etc. in a sequential manner. The pipeline operation is usually triggered by the upstream artifact library under specific events, such as the remote repository where the source code is submitted.

[0027] The product library is a warehouse that stores the products produced after the pipeline completes the operation. The scope of products includes compiled code, installation packages, container images, system images, configuration files, and documents.

[0028] The integrated scheduler is used to coordinate the scheduling services of the upstream and downstream module warehouse pipelines. When the downstream warehouse registers its list of dependent modules to the integrated scheduler to form a subscription relationship, after its upstream module releases a new version, the integrated scheduler can trigger the downstream module pipeline to integrate the new upstream version. At the same time, the downstream module can also request the upstream to release the required version of the product package through the integrated scheduler.

[0029] A command line tool that helps maintain build system configuration files and abstracts common functions for all modules. For example, using build configuration files to download dependent packages and initialize the environment required for building.

[0030] (3) Target platform characteristics of software submodule release packages; The software submodule publishes the features of its target platform to the build system, so that the published features can be used when configuring the build system in subsequent steps to achieve customized builds. Downstream modules can also publish their own features based on these features.

[0031] The following are the elements of a feature release in JSON format: { "repository": "https: / / git.example.com / subcomponent1", "features": [ { "name": "FEATURE1", "packages": [ { "name": "linux-aarch64-rp4", "values": [ { "value": "OFF", "deps": [] }, { "value": "ON", "deps": [ { "repository": "https: / / git.example.com / subcomponent2", "name": "FEATURE2", "value": "ON" } ] } ], "default": "OFF" } ] } ] } Table 1 is a description of the characteristic elements.

[0032] Table 1 1 2 3 4 5 illustrate repository The address of the submodule code repository, which can be used to identify the uniqueness of the submodule. features Submodule feature list name Feature Name packages List of target platform packages supported by the feature name The specification defines the package type name. For example, gnu9.4-x86_64-linux-aarch64-rp4 means that the target platform system architecture is arm64, the operating system is Linux, and the model is rp4 (RaspberryPi 4) hardware device. values List of feature values ​​supported by the current target platform value Characteristic Value Definition deps Features of upstream modules that the feature value directly depends on repository The address of the upstream module's code repository, which can be used to identify the uniqueness of the submodule. name The name of the upstream module feature that depends on. value Depends on the value of an upstream module feature. (4) Configure the target hardware device system image; In the target hardware device system image integrated code repository, use the command line tool to generate configuration files based on the requirements of the specific product project and the build system specifications defined in step 1. If there are multiple projects, you can use different directories to store multiple sets of configuration files.

[0033] After completing the definition of the target hardware device system image configuration file, you can use the command line tool to subscribe to the new version release message of the dependent module according to the relevant content of the dependent project in the configuration file, and request the upstream module to release the corresponding software version.

[0034] The following is a sample JSON configuration file: { "name": "project1", "cli_version": ">=1.0.0", "repository": "https: / / git.example.com / sysimage", "packages": [ { "name": "gnu9.4-x86_64-linux-aarch64-rp4", "features": [ { "name": "FEATURE1", "value": "ON" } ], "deps": [ { "name": "gnu9.4-x86_64-linux-aarch64-rp4", "repository": "https: / / git.example.com / subcomponent1", "version": "SUBCOMPONENT1-V1.0.0" } ] } ] } Table 2 is a description of the configuration properties.

[0035] Table 2 Level 1 Level 2 Level 3 illustrate name Configuration name, you can use the abbreviation of the project. cli_version A compatible version of the command line tools software, since the configuration files are maintained and used by the command line tools. repository The address of the device system image integration code repository, using a unique identifier. packages List of target platform packages supported by the integrated repository name The specification defines the package type name. For example, gnu9.4-x86_64-linux-aarch64-rp4 means that the target platform system architecture is arm64, the operating system is Linux, and the model is rp4 (Raspberry Pi 4) hardware device, which is cross-compiled in the x86_64 development environment using the GNU9.4 version of the tool chain. features The integrated warehouse schedule software package target platform supports feature parameter lists. name Feature parameter name value Characteristic parameter value deps List of underlying direct dependent submodule packages. name Dependency submodule package type name. For example, gnu9.4-x86_64-linux-aarch64-rp4 means that the target platform system architecture is arm64, the operating system is Linux, and the model is rp4 (Raspberry Pi 4) hardware device, which is cross-compiled in the x86_64 development environment using the GNU9.4 version of the tool chain. repository The address of the submodule code repository, which can be used to identify the uniqueness of the submodule. version The version of the submodule software package. If there is no software version that meets the target, no specific software version is specified. It will be automatically updated by the integration pipeline or manually updated later. (5) Software submodule repository adaptation build system; The software submodule builds system configuration files based on maintenance and updates to meet the needs of itself and upstream and downstream. The format of building system configuration files is the same as the format of system image integration of the target hardware device. The maintenance and update methods are mainly divided into: Self-maintenance and update, edit and maintain build configuration files from scratch according to the preset target platform.

[0036] When an upstream dependent module releases a new version, if a build configuration file already exists and has subscribed to upstream messages, respond to the new version message sent by the upstream, update the configuration file and submit it.

[0037] The downstream module requests the target platform version. When the downstream module does not find the appropriate software version of the dependent module, it will initiate a version request to the upstream. After receiving the request, the current software submodule will align with the existing configuration file. If the target platform software package already exists, it will be ignored. If it is missing, it will be supplemented. It should be noted that the downstream module does not have the deep information of the upstream module's dependent project, such as the dependent module information. Therefore, the current software module needs to complete this part of the information for the newly added target platform software package.

[0038] (6) Continuously integrate and release system image files; After the infrastructure is built and the initial configuration of each software repository is completed, the target device system image can be continuously integrated and released through the build system and delivered to the user. There are two typical build methods: Continuous building: For any module in any link of the global integrated building pipeline, submitting code to the source code repository triggers the module's own building pipeline. When the module is successfully built, the new version is released and passed to the downstream through the integrated scheduler. The downstream receives the subscribed new version message and triggers its own building pipeline, and so on until the terminal target hardware device system image of the global building pipeline.

[0039] Regular builds are executed at certain time intervals. For example, daily builds usually start after work hours, such as 1 a.m. The build starts from the upstream module of the global integration pipeline and estimates the build time. Then the downstream starts its own build based on the upstream start time plus the build time, until the terminal target hardware device system image of the global build pipeline is reached.

[0040] The two building methods have their own advantages and disadvantages. The advantage of continuous building is that the latest version can be built as early as possible, and even if there are problems, they can be exposed as early as possible. In addition, due to the adoption of the subscription mechanism, the pipeline organization is simple and flexible, but there may be a large number of inefficient builds, wasting a lot of infrastructure resources. A typical scenario is that the basic module is submitted and released multiple times in a day, causing a build peak. Regular builds can smooth out such fluctuations and relieve resource pressure. However, regular builds require precise planning, and their characteristic is aversion to change. For example, if the build time exceeds the estimated new version, the downstream build window will be missed. In addition, pipeline problems will be discovered later than continuous builds.

[0041] Based on the above considerations, a hybrid mode is adopted to balance efficiency and resource utilization, while introducing reinforcement learning for continuous optimization. The hybrid mode specifically refers to the use of continuous integration for the main body of the global integrated construction pipeline, but regular construction is used for aggregation modules that are widely dependent on basic modules and have many dependent modules. Quasi-static data such as configuration file information and dynamic data such as pipeline construction tasks are collected, and the integration method and regular integration cycles are adjusted using reinforcement learning algorithms to shorten the time spent on discovering errors and failures and the time spent on pipeline success.

[0042] The beneficial effects of the present invention are that, compared with the prior art, the present invention adopts a two-mechanism integration method to reduce the risk of code security leakage without reducing the efficiency of integration; the present invention adopts a publish-subscribe mechanism to connect the upstream and downstream of the global integration pipeline, realizing a highly automated integration mode to accelerate development efficiency; the present invention introduces a hybrid integration method and uses a reinforcement learning algorithm to continuously optimize the efficiency of the global integration pipeline.

[0043] The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the drawings in the specification. However, those skilled in the art should understand that the above implementation examples are only preferred implementation schemes of the present invention, and the detailed description is only to help readers better understand the spirit of the present invention, but not to limit the scope of protection of the present invention. On the contrary, any improvements or modifications based on the inventive spirit of the present invention should fall within the scope of protection of the present invention.

Claims

1. An engineering method for safe automated software integration in the automotive industry, characterized in that: Includes steps: (1) Define the specifications for building the system and realize the integration and collaboration of upstream and downstream modules; (2) Build the infrastructure for the build system; (3) Target platform characteristics of software submodule release packages; (4) Configure the target hardware device system image; (5) Software submodule repository adaptation build system; (6) Continuously integrate and publish system image files and deliver them to users.

2. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (1), the automated software integration system includes the target hardware device system image software and the upstream software sub-module software. The target hardware device system image software defines a series of integration elements to form the output product requirements for the upstream software sub-module software, and connects the upstream and downstream pipelines by standardizing the definition of the integration elements.

3. The engineering method for safe automated software integration in the automotive industry according to claim 2, characterized in that: In step (1), the integration elements include: target hardware device, operating system, development tool chain, dependent modules, and customized configuration; Target hardware device, including device model and hardware features; Operating system: the operating system of the target hardware device runtime environment. The same hardware device supports multiple operating systems including virtualization technology. Development tool chain, a series of compilation and debugging tool software that supports the target hardware device operating system running in the development environment; Dependency module, a list of dependencies on upstream software submodule packages, and alignment of dependency modules with target hardware device operating systems and development tool chains; Customized configuration defines the features supported by the upstream and downstream software, and builds a customized software package containing specified features based on specific needs.

4. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (2), the infrastructure includes source code repository, integrated pipeline environment, artifact library, integrated scheduler, command line tools, build pipeline configuration, and undertake automated build work; The source code warehouse is a warehouse for storing product source code and is the source of input for the integration pipeline; Integrated pipeline environment is a general term for a series of operating environments and management service applications that compile, reorganize, test and package the input source code and binary machine products, and execute pipeline operations in sequence; Product warehouse, a warehouse for storing products produced after the assembly line completes operation; Integrated scheduler for coordinating scheduling services across upstream and downstream module warehouse pipelines; Command line tool to help maintain build system configuration files, abstracting common functionality for all modules to use.

5. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (3), the software submodule publishes its own target platform features to the build system. When building the system, the published features are used to implement customized builds, and the downstream modules publish their own features based on these features.

6. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (4), in the target hardware device system image integrated code repository, a configuration file is generated using a command line tool according to the requirements of the specific product project and the defined build system specification; After completing the definition of the target hardware device system image configuration file, use the command line tool to subscribe to the new version release message of the dependent module according to the relevant content of the dependent project in the configuration file, and request the upstream module to release the corresponding software version.

7. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (5), the format of the system configuration file is the same as the format of the target hardware device system image integration. The maintenance and update methods are divided into: self-maintenance and update, upstream dependent module releases a new version, and downstream modules request the target platform version.

8. The engineering method for safe automated software integration in the automotive industry according to claim 1, characterized in that: In step (6), the system construction methods include continuous construction, periodic construction, and mixed mode; Continuous build: For any module in the global integrated build pipeline, submitting code to the source code repository triggers the module's own build pipeline. Regular builds execute build tasks at fixed time intervals; The hybrid mode refers to the use of continuous integration in the main body of the global integrated construction pipeline, regular construction of aggregation modules that are widely dependent on basic modules and have many dependent modules, and the introduction of reinforcement learning for continuous optimization.

Images