WO2022252381A1

WO2022252381A1 - Management method and system for remotely upgrading vehicle-end software versions in batches, and medium

Info

Publication number: WO2022252381A1
Application number: PCT/CN2021/109539
Authority: WO
Inventors: 杨桂芳; 杨川; 董维山; 傅雷; 丁磊
Original assignee: 魔门塔(苏州)科技有限公司
Priority date: 2021-06-02
Filing date: 2021-07-30
Publication date: 2022-12-08
Also published as: CN115437659A

Abstract

The present application belongs to the technical field of autonomous driving. Disclosed are a management method and system for remotely upgrading vehicle-end software versions in batches, and a medium. The method comprises: a process of uploading and storing software codes; a process of continuously compiling and integrating the software codes; a process of storing binary files; a process of storing declarative version deployment file packages; a process of uniformly grouping and issuing new software versions; and a process of grouping and automatically upgrading the new software versions in batches. When vehicles in corresponding groups are in a started state, a plurality of vehicle-end container management units automatically download, according to new declarative version deployment file packages, corresponding binary files from a binary file storage library and run the corresponding binary files in the form of containers, so as to complete the batch upgrading of corresponding software versions on all the vehicles in the corresponding groups. By means of the management method for remotely upgrading vehicle-end software versions in batches of the present application, the issuing efficiency of software versions is improved, and the complexity of issuing and upgrading the software versions is reduced.

Description

Method, system and medium for remote batch upgrade management of car-end software version

technical field

The present application relates to the technical field of automatic driving, and in particular to a method, system and medium for remote batch upgrade management of vehicle-end software versions.

Background technique

In the existing technology of upgrading the car-end software, it is consistent with the upgrading of the Internet of Things OTA (abbreviation of Over-the-air Technology, translated as "over-the-air technology", referring to the technology of downloading with the help of mobile network or WIFI network) way is dominant. Accompanying drawing 1 has shown the typical way of upgrading the vehicle end software in the prior art. As shown in Figure 1, after the new version of the car-end application is successfully developed, the new version is compiled into a full version package or an OTA differential package, and uploaded to the version warehouse and synchronized to the OTA server. After the OTA agent program running on the vehicle receives the new version upgrade message, it shows that the corresponding application program has a new version. At this time, the corresponding application software can be upgraded by manually operating on the specific vehicle. The entire upgrade process is similar to the upgrade of the application program on the current mobile phone.

However, with the evolution of autonomous driving technology, especially in the process of research and development of autonomous driving technology, many vehicles need to participate in batches. For frequent version upgrades of different vehicles, if the above-mentioned prior art is used, the workload of manual operation will be huge, and when multiple people are required to upgrade the same software on multiple vehicles at the same time, the coordination of personnel will become a big problem. Greatly reduced work efficiency.

Contents of the invention

In view of the technical problem that the existing technology cannot be efficiently applied to the remote upgrade of batch vehicles, this application proposes a management method, system and medium for remote batch upgrade of software versions at the vehicle end.

In one technical solution of the present application, a method for remote batch upgrade management of vehicle-end software versions is provided, including: software code upload and storage process, the code storage library stores the software code distributed and uploaded by programmers; software code is continuously compiled and integrated In the process, the continuous integration build service compiles and integrates the code that meets the pre-configured compilation rules among the continuously uploaded software codes, generates binary files of different versions that can be run on the vehicle end, and a declarative version that describes the binary files Deployment file package; binary file storage process, which stores binary files in binary file repository; declarative version deployment file package storage process, uses declarative version deployment file repository to store declarative version deployment file package; new software versions are grouped uniformly During the release process, when the unified release platform automatically monitors in real time or manually selects the vehicle-end software version to be upgraded on the unified release platform, it is detected and stored in the declarative version deployment file repository, which is the same as the previous monitoring result. When comparing or manually selecting the new declarative version deployment file package corresponding to the vehicle-side software version to be upgraded, the new declarative version deployment file package is pulled from the declarative version deployment file repository and released to multiple All the vehicles of the corresponding group in the vehicle group; and the automatic batch upgrade process of the new version of the software group. There are multiple vehicle-end container management units, which are pre-installed in each vehicle. When the vehicles of the corresponding group are in the starting state, The declarative version deployment file package automatically downloads from the binary file repository and runs the corresponding binary file in the form of a container to complete the batch upgrade of the corresponding software version on all vehicles in the corresponding group.

In another technical solution of the present application, a remote batch upgrade management system for vehicle-end software versions is provided, including: a code storage library, which stores software codes distributed and uploaded by programmers; continuous integration and construction services, for continuously uploaded software codes The code that meets the pre-configured compilation rules is compiled and integrated to generate different versions of binary files that can run on the vehicle, as well as a declarative version deployment file package that describes the binary files; binary file repository, storing binary files; statement The version deployment file repository stores the declarative version deployment file package; the unified release platform, when it is automatically monitored in real time or manually selected on the unified release platform after checking the software version of the vehicle to be upgraded, it is stored in the declarative version deployment file Stored in the library, compared with the last monitoring result or manually selecting the new declarative version deployment file package corresponding to the car-end software version to be upgraded, the new declarative version is pulled from the declarative version deployment file repository Deploy the file package, and issue it to all the vehicles of the corresponding group in the multiple vehicle groups; and multiple vehicle-end container management units, which are respectively pre-installed in each vehicle, and when the vehicles of the corresponding group are in the starting state, according to the new The declarative version deployment file package of , automatically downloads from the binary file repository and runs the corresponding binary file in the form of a container, so as to complete the batch upgrade of the corresponding software version on all vehicles in the corresponding group.

In another technical solution of the present application, a computer-readable storage medium is provided, which stores computer instructions, and the computer instructions are operated to execute the method for remote batch upgrade management of vehicle end software versions in the above technical solution.

By adopting the above technical solution, the present application can achieve the following technical effects: the software version of the corresponding grouped vehicles can be remotely and automatically upgraded without manual intervention at the vehicle end, which improves the efficiency of software version release; through the technology based on container management Thought, which reduces the complexity of software version release and upgrade.

Description of drawings

In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly describe the drawings that need to be used in the description of the specific embodiments of the present application or the prior art. Obviously, the drawings described below are aimed at some specific implementations of the present application, and those skilled in the art can directly and unambiguously determine the specific implementation methods according to these drawings without any creative work. Other drawings corresponding to the equivalent replacement or deformation of the embodiment.

Fig. 1 shows a schematic diagram of a typical way of upgrading the vehicle end software in the prior art;

Fig. 2 shows the schematic flow chart of a specific embodiment of the remote batch upgrade management method of the vehicle end software version of the present application;

Fig. 3 shows a schematic diagram of a specific embodiment of the management system for remote batch upgrade of vehicle-end software versions of the present application.

Through the above-mentioned drawings, some specific implementations of the present application have been clearly and clearly shown. For these specific implementations, more detailed text descriptions will be given later. The purpose of these drawings and text descriptions is not to limit the scope of protection covered by the inventive concept of the application in any way, but to enable those skilled in the art to more easily understand the scope of the application through some specific implementation methods. Invent ideas.

Detailed ways

In order to make it easier for those skilled in the art to understand the technical solution of the present application, some specific implementations of the technical solution of the present application will be clearly and completely described in conjunction with the accompanying drawings. Apparently, the described specific implementations are only some specific implementations of the technical solutions of the present application, rather than all specific implementations. Based on the specific implementation manners described in this application, all other implementation manners obtained by those skilled in the art without making creative efforts fall within the scope of protection of this application.

It should be noted that the terms "first", "second", "third", "fourth" and so on (if any) mentioned in this application, and the number and/or letter designations of several processing processes are used for Distinguishing similar objects is not necessarily to be understood as describing a particular order or sequence. It should be understood that these numbers can be interchanged under appropriate circumstances, so that the technical solutions of the present application described here can, for example, be implemented in an order other than those shown or described. In addition, the terms "comprising" and "having" and any variations thereof are not intended to cover only exclusive inclusion, for example, a method comprising a series of steps, or a product or device comprising several units, modules, and not necessarily It is understood to be limited to those steps, units, and modules listed, but may also include other steps, units, and modules that are not listed or should be inherent to the methods, products, or devices themselves.

In addition, the multiple specific implementation modes, multiple embodiments, multiple examples, etc. that are described in detail below for different parts of the technical solution of the present invention can be combined with each other to form a complete technical solution of the present invention under the condition that they are not mutually exclusive. . For the same or similar concepts, processes, etc. that have been described in a specific implementation manner, embodiment, example, etc., they may not be repeated in other specific implementation manners, embodiments, examples, etc.

Below, some specific implementations, embodiments, examples, etc. of the present application will be described in detail in conjunction with the accompanying drawings.

FIG. 2 shows a schematic flow chart of a specific embodiment of the method for remote batch upgrade management of vehicle-side software versions of the present application.

In the embodiment shown in FIG. 2 , the remote batch upgrade management method of the vehicle end software version of the present application includes: S201, a software code upload and storage process, and the code repository stores the software code distributed and uploaded by programmers.

In the process of uploading and storing software codes represented by S201, the code storage library stores the software codes distributed and uploaded by programmers.

In this embodiment, by uploading and storing the software codes written by programmers distributed in different locations in a unified code repository, and performing corresponding unified management, it is possible to efficiently and quickly implement the process from small to large To improve the collaborative work ability of programmers in different positions.

In an example of this embodiment, the code repository may be a centralized code repository, and each programmer's local terminal is pre-installed with a distributed version control system. As an example, a code repository may be one or more computer devices with storage capabilities.

In this embodiment, by adopting a centralized code storage library, it is possible to facilitate subsequent unified management and control of the programming results of all programmers, that is, software codes.

As an example, programmers distributed in different locations, after writing the software code of the corresponding software that they are responsible for writing in their own local terminals, use the pre-installed distributed version control system on their local terminals to write the completed code. Software code is uploaded to a centralized code repository where it is stored.

As an example, the distributed version control system may be an open source distributed version control system, specifically git. Correspondingly, the code repository can be a git repository.

As an example of this embodiment, programmers can be divided into multiple groups, and a group of programmers works on the task of programming and upgrading the software of the vehicles in the vehicle group that realizes one function. Thus, the code written by the group of programmers can be used as part of the software used by the vehicle of the corresponding function group.

As an example, each group of vehicles grouped by function can perform data collection, automatic driving algorithm verification, automatic driving trial operation, etc.

In the embodiment shown in FIG. 2 , the management method for remote batch upgrade of vehicle-end software versions of the present application includes: S202 , a process of continuous compilation and integration of software codes.

During the continuous compilation and integration process of the software code represented by S202, the continuous integration construction service compiles and integrates the codes that meet the pre-configured compilation rules among the continuously uploaded software codes, and generates binary files of different versions that can be run by the vehicle. and a declarative release deployment package that describes the binary.

In this way, different software codes can be compiled and integrated according to the corresponding automated execution process, so that different versions of binary files that can be run on the vehicle end can be automatically generated, as well as a declarative version deployment file package that describes the binary files.

As an example of this embodiment, the continuous integration construction service is pre-configured with corresponding compilation rules for the software codes uploaded by the programmers corresponding to each of the multiple vehicle groups.

As an example of this embodiment, the pre-configured compiling rules can realize the standardization check on the writing of software codes. As an example, writing specification can include whether the written format meets the requirements, and whether the size of the code is economical compared to the functions it is intended to achieve, etc. In this way, when the software code is written irregularly, for example, the format does not meet the requirements, or the size of the code is not economical, the continuous integration build service can return the software code to the corresponding programmer and ask him to rewrite it.

As an example of this embodiment, compile and integrate the codes that meet the pre-configured compilation rules among the continuously uploaded software codes. Specifically, the code for the same software can be compiled into a data format that the vehicle corresponding to the software can run. And integrate the compiled result in the binary file of the new version of the software.

As an example of this embodiment, the declarative version deployment file package can describe the startup command of the corresponding car-end software, the lower limit and upper limit of computing resource usage, the operations to be performed based on the health check results, the number of copies, and /or the startup sequence with other car-end software.

As an example, the lower limit of computing resource occupancy is the amount of memory and/or CPU occupancy that must be allocated to ensure that the new version of the corresponding vehicle end software can run normally. The upper limit of computing resource occupation should ensure that the memory and/or CPU occupied by the new version of the corresponding vehicle-end software during operation must not affect the normal operation of the software and functional components that must be operated for the normal driving of the corresponding vehicle.

As an example, the operations required for the health check result may include: during the installation process of the corresponding version of the corresponding vehicle-side software, if it is detected that the corresponding container still cannot respond normally after a predetermined period of time, the corresponding container Restart after forcibly stopping the operation; and during the operation of the corresponding version of the corresponding car-end software, if it is detected that the corresponding container cannot respond normally, the corresponding container is forcibly stopped and then restarted.

In this way, by setting the operations that need to be performed based on the health check results in the declarative version deployment file package, the full life cycle management of the corresponding vehicle end software can be realized.

As an example of this embodiment, the number of copies established for the corresponding vehicle end software is one. In this way, it can be ensured that when the corresponding car-end software crashes for any reason, there must still be a healthy copy still running, thereby ensuring the robustness of the corresponding car-end software.

As an example of this embodiment, the startup of the corresponding software needs to start or stop other car-end software as a prerequisite. At this time, the configuration in the declarative version deployment file package and the startup sequence of other car-end software can ensure The software already has the conditions to start when it is started. For example, before starting the image analysis software, it is necessary to ensure that the software that controls the camera installed on the vehicle to take pictures has been started.

As an example, the declarative version deployment file package may be a declarative deployment package helm chart generated and managed by the lightweight Kubernetes package management tool helm.

In the embodiment shown in FIG. 2 , the method for remote batch upgrade management of vehicle-end software versions of the present application further includes: S203, a binary file storage process.

In the binary file storage process represented by S203, the binary file storage library stores the binary file.

In the embodiment shown in FIG. 2 , the method for remote batch upgrade management of vehicle-side software versions of the present application further includes: S204 , a declarative version deployment file package storage process.

In the declarative version deployment file package storage process represented by S204, the declarative version deployment file repository stores the declarative version deployment file package.

In an example of this embodiment, there may be multiple declarative version deployment file repositories, and each of the multiple declarative version deployment file repositories may be dedicated to storing the information of a vehicle in a vehicle group of a function. The declarative version deployment file package generated by the corresponding software code of the software. Therefore, the corresponding declarative version deployment file packages stored in each declarative version deployment file repository can be dedicated to each of the multiple vehicle groups in a one-to-one correspondence.

In this way, in subsequent operations, only according to which declarative version deployment file repository the declarative version deployment file package is stored in, it can be determined which group of vehicles the corresponding declarative version deployment file package needs to be released to.

In an example of this embodiment, the multiple declarative version deployment file repositories may be multiple independent physical storage media, or multiple branches within one physical storage medium.

As an example, the declarative version deployment file repository can be a git repository.

In the embodiment shown in FIG. 2 , the management method for remote batch upgrade of vehicle-end software versions of the present application further includes: S205 , a unified group release process of new software versions.

During the unified group release process of the new software version represented by S205, when the unified release platform automatically monitors in real time or manually selects the vehicle-side software version to be upgraded on the unified release platform, it is detected, and the declarative version is deployed in the file repository. Compared with the last monitoring result or manually selecting the new declarative version deployment file package corresponding to the car-end software version to be upgraded, the new declarative version deployment file is pulled from the declarative version deployment file repository. file package and publish it to all vehicles in the corresponding group of multiple vehicle groups.

In this embodiment, if the unified release platform automatically monitors whether there is a new declarative version deployment file package in real time, and then releases it, it belongs to the monitoring type automatic release; if the vehicle terminal to be upgraded is manually selected on the unified release platform If the software is released after the software version, it is an active release.

In an example of this embodiment, in the case of active release, the unified release platform manager can click on the software version that needs to be upgraded on the unified release platform, so that the unified release platform can deploy from the corresponding declarative version The file repository checks and pulls the declarative version deployment file package, and releases it to all vehicles of the corresponding group that the software version serves.

In one embodiment of this embodiment, if one or more vehicles in the corresponding group of vehicles that need to release a new version of the software are in an unstarted state, the corresponding declarative version deployment file package pulled by the unified release platform is cached in Unified publishing platform. In this way, the automatic update of the corresponding software can be started immediately after the corresponding vehicle is started.

As an example, when the declarative version deployment file repository is a git repository, the automatic monitoring and communication of the declarative version deployment file repository by the unified publishing platform can be completed in the form of GitOps.

In the embodiment shown in FIG. 2 , the remote batch upgrade management method of the vehicle end software version of the present application further includes: S206 , a group automatic batch upgrade process of new software versions.

In the automatic batch upgrade process of software new version groups represented by S206, a plurality of vehicle-end container management units, which are pre-installed in each vehicle, deploy files according to the new declarative version when the vehicles in the corresponding group are in the startup state package, automatically download from the binary file repository and run the corresponding binary file in the form of a container, so as to complete the batch upgrade of the corresponding software version on all vehicles in the corresponding group.

In an example of this embodiment, the container management unit at the vehicle end may be control software. The container management unit at the vehicle end can run the downloaded binary file for upgrading the software version in the form of a container, so as to complete the upgrading of the software version on the corresponding vehicle.

Because the vehicle-end container management unit can run the corresponding binary files in the form of containers, and considering the characteristics of containers that can be migrated as a whole and facilitate the creation of copies, it can reduce the complexity of vehicle-side software version release and upgrade.

In an example of this embodiment, under the management of the vehicle-side container management unit, each vehicle may be represented as an independent cluster under the management of a vehicle-side container management unit. As an example, the independent clusters may be implemented with one or more servers on the respective vehicles.

In one embodiment of this embodiment, the unified publishing platform can perform group management on all independent clusters managed by the container management units at the vehicle end, so that vehicles with the same function are classified into the same group of the vehicle groups.

In one example of this embodiment, the communication between the unified publishing platform and the independent cluster managed by the container management unit at the vehicle end may adopt two-way certificate authentication. In this way, the security of the communication between the two parties can be ensured, and the vehicle can be prevented from being maliciously hijacked by a third party during the automatic driving process.

As an example, the vehicle-side container management unit may be the lightweight version k3s of the cluster management tool Kubernetes. Correspondingly, the independent cluster managed by the vehicle-end container management unit can be an independent k3s cluster.

In this specific embodiment, it includes: a code storage library 301, which stores software codes distributed and uploaded by programmers; a continuous integration construction service 302, which compiles and integrates the codes that meet the pre-configured compilation rules among the continuously uploaded software codes, Generate binary files of different versions that can run on the vehicle, and a declarative version deployment file package that describes the binary files; binary file repository 303 stores binary files; declarative version deployment file repository 304 stores declarative version deployment File package; the unified release platform 305, when it is automatically monitored in real time or checked after manually selecting the vehicle-side software version that needs to be upgraded on the unified release platform, it is stored in the declarative version deployment file repository, which is related to the last monitoring result When comparing or manually selecting the new declarative version deployment file package corresponding to the vehicle-side software version to be upgraded, the new declarative version deployment file package is pulled from the declarative version deployment file repository and released to multiple All the vehicles of the corresponding group in the vehicle group; and a plurality of vehicle-end container management units 306, which are pre-installed in each vehicle, and when the vehicles of the corresponding group are in the starting state, deploy the file package according to the new declarative version, automatically from The binary file repository downloads and runs the corresponding binary file in the form of a container, so as to complete the batch upgrade of the corresponding software version on all vehicles in the corresponding group.

In this specific implementation, the code repository 301, the continuous integration build server 302, the binary file repository 303, the declarative version deployment file repository 304, the unified release platform 305, and the multiple vehicle-side container management units 306 can specifically execute The software code upload storage process 201, the software code continuous compilation and integration process 202, the binary file storage process 203, the declarative version deployment file package storage process 204, and the unified software version The corresponding processes described in the above-mentioned specific implementation modes, embodiments, examples, etc. of the group release process 205 and the group automatic batch upgrade process 206 of the new software version can achieve the above-mentioned specific implementation of the remote batch upgrade management method for the vehicle-end software version shown in FIG. 2 The corresponding technical effects achieved by the corresponding processes described in the methods, embodiments, examples, etc.

In a specific embodiment of the present application, a computer-readable storage medium is provided, which stores computer instructions, wherein the computer instructions are operated to execute any of the vehicle-end software versions described in the above-mentioned embodiments, embodiments, examples, etc. Remote batch upgrade management method. Wherein, the computer instructions stored in the storage medium may be directly stored in hardware, stored in a software module executed by a processor, or stored in a combination of both.

A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium that can be used for storing computer instructions. Generally, a storage medium may be under the control of a processor such that the processor can read information from, and write information to, the storage medium.

The processor can be a central processing unit (English: Central Processing Unit, referred to as: CPU), and can also be other general-purpose processors, digital signal processors (English: Digital Signal Processor, referred to as: DSP), application-specific integrated circuits (English: Application Specific Integrated Circuit, referred to as: ASIC), field programmable gate array (English: Field Programmable Gate Array, referred to as: FPGA) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components or any combination thereof. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In the alternative, the storage medium and processor may be integral. The processor and storage medium can reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and storage medium may reside as discrete components in the user terminal.

In the implementation manners provided in this application, it should be understood that the disclosed device may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

A unit described as a separate component may or may not be physically separated, and a component displayed as a unit may or may not be a physical unit, that is, it may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to realize the purpose of the technical solution of the present application.

The above are only the embodiments of the present application, and are not intended to limit the scope of patent protection of the present application. All equivalent structural transformations made by using the description of the application and the contents of the accompanying drawings, or directly or indirectly used in other related technical fields, are all the same. included in the scope of patent protection of the present application.

Claims

A remote batch upgrade management method for vehicle-end software versions, characterized in that it includes:

Software code upload storage process, the code repository stores the software code distributed and uploaded by programmers;

In the process of continuous compilation and integration of software codes, the continuous integration construction service compiles and integrates the codes that meet the pre-configured compilation rules among the continuously uploaded software codes, generates binary files of different versions that can run on the vehicle, and compiles and integrates the codes of all A declarative version deployment package described by the binary file;

The binary file storage process stores the binary file by the binary file repository;

The declarative version deployment file package storage process stores the declarative version deployment file package in the declarative version deployment file repository;

The unified group release process of the new software version, when the unified release platform automatically monitors in real time or manually selects the vehicle-end software version that needs to be upgraded on the unified release platform, it is detected, and in the declarative version deployment file repository When there is a new declarative version deployment file package stored, compared with the last monitoring result or the manually selected car-side software version to be upgraded, the new declarative version deployment file package is pulled from the declarative version deployment file repository. The declarative version of the deployment package and publish it to all vehicles in the corresponding group of multiple vehicle groups; and

The automatic batch upgrade process of the new version of the software group consists of a plurality of vehicle-end container management units, which are pre-installed in each of the vehicles, and when the vehicles of the corresponding group are in the startup state, they are deployed according to the new declarative version The file package is automatically downloaded from the binary file repository and runs the corresponding binary file in the form of a container, so as to complete the batch upgrade of the corresponding software version on all the vehicles of the corresponding group.
The method for remote batch upgrade management of vehicle-end software versions according to claim 1, characterized in that there are multiple declarative version deployment file repositories, and the corresponding all stored in each of the declarative version deployment file repositories The declarative version deployment file package is dedicated to each of the multiple vehicle groups in a one-to-one correspondence.
According to claim 1, the remote batch upgrade management method of vehicle-end software version is characterized in that, the declarative version deployment file package describes the start-up command of the corresponding vehicle-end software, the lower limit and upper limit of computing resource occupation, based on The operation required for the health check result, the number of copies, and/or the startup sequence with other car-end software.
According to claim 3, the method for remote batch upgrade management of vehicle-end software versions is characterized in that the operations to be performed based on the results of the health check include:

During the installation process of the corresponding version of the corresponding vehicle-side software, if it is detected that the corresponding container still cannot respond normally after a predetermined period of time, the corresponding container will be forced to stop running and then restarted; and

During the operation of the corresponding version of the corresponding car-end software, if it is detected that the corresponding container cannot respond normally, the corresponding container will be forced to stop running and then restarted again.
The remote batch upgrade management method for vehicle-end software versions according to claim 3, characterized in that the number of copies established for the corresponding vehicle-end software is one.
The method for remote batch upgrade management of vehicle-end software versions according to claim 1, characterized in that, the continuous integration construction service is aimed at the software codes uploaded by the programmers corresponding to each group in the plurality of vehicle groups , are respectively pre-configured with corresponding compilation rules.
The method for remote batch upgrade management of vehicle-end software versions according to claim 1, characterized in that, on the unified publishing platform, the plurality of vehicle-end container management units are grouped and managed, so that vehicles with the same function are in the same group as the vehicle group.
The method for remote batch upgrade management of vehicle-end software versions according to claim 1, wherein the communication between the unified release platform and the vehicle-end container management unit adopts two-way certificate authentication.
A remote batch upgrade management system for vehicle software versions, characterized in that it includes:

Code repository, which stores software code distributed and uploaded by programmers;

Continuous integration and construction services, compiling and integrating the codes that meet the pre-configured compilation rules among the continuously uploaded software codes, generating binary files of different versions that can be run on the vehicle end, and declarative expressions describing the binary files Version deployment file package;

a binary file repository for storing said binary files;

A declarative version deployment file repository, storing the declarative version deployment file package;

The unified release platform, when it is automatically monitored in real time or checked after manually selecting the vehicle-end software version to be upgraded on the unified release platform, it is stored in the declarative version deployment file repository. When comparing or manually selecting the new declarative version deployment file package corresponding to the vehicle-end software version to be upgraded, pulling the new declarative version deployment file package from the declarative version deployment file repository, and publish it to all vehicles in the corresponding group of vehicle groups; and

A plurality of vehicle-end container management units, which are respectively pre-installed in each of the vehicles, and when the vehicles of the corresponding group are in the startup state, deploy the file package according to the new declarative version, and automatically store the binary file from the binary file The library downloads and runs the corresponding binary file in the form of a container, so as to complete the batch upgrade of the corresponding software version on all the vehicles of the corresponding group.
A computer-readable storage medium, characterized in that the storage medium stores computer instructions, and the computer instructions are operated to perform the remote batch upgrade management method of the vehicle end software version described in any one of claims 1-8 .