WO2022252381A1 - 车端软件版本远程批量升级管理方法、***及介质 - Google Patents

车端软件版本远程批量升级管理方法、***及介质 Download PDF

Info

Publication number
WO2022252381A1
WO2022252381A1 PCT/CN2021/109539 CN2021109539W WO2022252381A1 WO 2022252381 A1 WO2022252381 A1 WO 2022252381A1 CN 2021109539 W CN2021109539 W CN 2021109539W WO 2022252381 A1 WO2022252381 A1 WO 2022252381A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
version
software
declarative
deployment file
Prior art date
Application number
PCT/CN2021/109539
Other languages
English (en)
French (fr)
Inventor
杨桂芳
杨川
董维山
傅雷
丁磊
Original Assignee
魔门塔(苏州)科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 魔门塔(苏州)科技有限公司 filed Critical 魔门塔(苏州)科技有限公司
Publication of WO2022252381A1 publication Critical patent/WO2022252381A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management

Definitions

  • 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.
  • this application proposes a management method, system and medium for remote batch upgrade of software versions at the vehicle end.
  • a method for remote batch upgrade management of vehicle-end software versions 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
  • 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
  • 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.
  • the new declarative version deployment file package 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.
  • 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.
  • a remote batch upgrade management system for vehicle-end software versions 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
  • a computer-readable storage medium 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the code storage library stores the software codes distributed and uploaded by programmers.
  • the code repository may be a centralized code repository, and each programmer's local terminal is pre-installed with a distributed version control system.
  • a code repository may be one or more computer devices with storage capabilities.
  • 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.
  • the distributed version control system may be an open source distributed version control system, specifically git.
  • the code repository can be a git repository.
  • 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.
  • 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.
  • each group of vehicles grouped by function can perform data collection, automatic driving algorithm verification, automatic driving trial operation, etc.
  • 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.
  • 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.
  • 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.
  • the pre-configured compiling rules can realize the standardization check on the writing of software codes.
  • 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.
  • the continuous integration build service can return the software code to the corresponding programmer and ask him to rewrite it.
  • compile and integrate the codes that meet the pre-configured compilation rules among the continuously uploaded software codes 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the startup of the corresponding software needs to start or stop other car-end software as a prerequisite.
  • 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.
  • 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.
  • the method for remote batch upgrade management of vehicle-end software versions of the present application further includes: S203, a binary file storage process.
  • the binary file storage library stores the binary file.
  • 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.
  • the declarative version deployment file repository stores the declarative version deployment file package.
  • 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.
  • the multiple declarative version deployment file repositories may be multiple independent physical storage media, or multiple branches within one physical storage medium.
  • the declarative version deployment file repository can be a git repository.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • each vehicle 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.
  • the independent clusters may be implemented with one or more servers on the respective vehicles.
  • 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.
  • 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.
  • the vehicle-side container management unit may be the lightweight version k3s of the cluster management tool Kubernetes.
  • the independent cluster managed by the vehicle-end container management unit can be an independent k3s cluster.
  • 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.
  • 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-installe
  • 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
  • a computer-readable storage medium 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.
  • 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.
  • 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.
  • 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.
  • the processor and storage medium may reside as discrete components in the user terminal.
  • the disclosed device may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components can be combined or integrated. to another system, or some features may be ignored, or not implemented.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本申请公开了一种车端软件版本远程批量升级管理方法、***和介质，属于自动驾驶技术领域。该方法包括：软件代码上传存储过程；软件代码持续编译集成过程；二进制文件存储过程；声明式版本部署文件包存储过程；软件新版本统一分组发布过程；以及软件新版本分组自动批量升级过程，由多个车端容器管理单元，在相应分组的车辆处于启动状态时，根据新的声明式版本部署文件包，自动从二进制文件存储库下载并以容器的形式运行相应的二进制文件，以完成相应软件版本在相应分组的所有车辆上的批量升级。本申请的车端软件版本远程批量升级管理方法，提高了软件版本发布效率，降低了软件版本发布和升级的复杂度。

Description

车端软件版本远程批量升级管理方法、***及介质 技术领域
本申请涉及自动驾驶技术领域，尤其涉及一种车端软件版本远程批量升级管理方法、***及介质。
背景技术
在对车端软件进行升级的现有技术中，以与物联网OTA(Over-the-air Technology的缩写，译为“空中下载技术”，指借助移动网络或WIFI网络进行下载的技术)升级一致的方式为主。附图1示出了现有技术中对车端软件进行升级的典型方式。如图1所示，车端应用程序的新版本开发成功之后，将新版本编译成全量版本包或OTA差分包，并上传到版本仓库，同时同步到OTA服务器上。车辆上运行的OTA代理程序接收到新版本升级消息后，显示相应的应用程序有新版本，这时可以通过人工在具体的车辆上进行操作来完成相应应用软件的升级。整个升级过程类似于目前手机上应用程序的升级。
然而，随着自动驾驶技术的演进，特别是在自动驾驶技术研发过程中，需要很多车辆批量参与。对不同车进行频繁的版本升级，若采用上述现有技术，则人工操作的工作量极大，且需要多人同时对多台车辆进行相同软件的升级时，人员的协调成为很大的问题，极大的降低了工作效率。
发明内容
针对现有技术无法高效应用于批量车远程升级的技术问题，本申请提出一种车端软件版本远程批量升级管理方法、***及介质。
在本申请的一个技术方案中，提供一种车端软件版本远程批量升级管理方法，包括：软件代码上传存储过程，由代码存储库，存储编程人员分布式上传的软件代码；软件代码持续编译集成过程，由持续集成构建服务，对持续上传的软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对二进制文件进行描述的声明式版本部署文件包；二进制文件存储过程，由二进制文件存储库，存储二进制文件；声明式版本部署文件包存储过程，由声明式版本部署文件存储库，存储声明式版本部署文件包；软件新版本统一分组发布过程，由统一发布平台，当实时自动监听到或在统一发布平台上人工选择需升级的车端软件版本后检查到，在声明式版本部署文件存储库中存储有，与上一监听结果相比或人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包 时，从声明式版本部署文件存储库拉取新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆；以及软件新版本分组自动批量升级过程，由多个车端容器管理单元，其分别预先安装在各个车辆中，在相应分组的车辆处于启动状态时，根据新的声明式版本部署文件包，自动从二进制文件存储库下载并以容器的形式运行相应的二进制文件，以完成相应软件版本在相应分组的所有车辆上的批量升级。
在本申请的另一个技术方案中，提供一种车端软件版本远程批量升级管理***，包括：代码存储库，存储编程人员分布式上传的软件代码；持续集成构建服务，对持续上传的软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对二进制文件进行描述的声明式版本部署文件包；二进制文件存储库，存储二进制文件；声明式版本部署文件存储库，存储声明式版本部署文件包；统一发布平台，当实时自动监听到或在统一发布平台上人工选择需升级的车端软件版本后检查到，在声明式版本部署文件存储库中存储有，与上一监听结果相比或人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包时，从声明式版本部署文件存储库拉取新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆；以及多个车端容器管理单元，其分别预先安装在各个车辆中，在相应分组的车辆处于启动状态时，根据新的声明式版本部署文件包，自动从二进制文件存储库下载并以容器的形式运行相应的二进制文件，以完成相应软件版本在相应分组的所有车辆上的批量升级。
在本申请的另一个技术方案中，提供一种计算机可读存储介质，其存储有计算机指令，计算机指令***作以执行上述技术方案中的车端软件版本远程批量升级管理方法。
通过采用上述技术方案，本申请能够达到如下技术效果：不需要在车端进行人工介入就可以完成相应分组车辆的软件版本远程自动升级，提高了软件版本发布效率；通过基于对容器进行管理的技术思想，降低了软件版本发布和升级的复杂度。
附图说明
为了更清楚地说明本申请具体实施方式或现有技术中的技术方案，下面将对本申请具体实施方式或现有技术描述中所需要使用的附图进行简要说明。显然，下面说明的附图针对的是本申请的一些具体实施方式，对于本领域技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图，直接毫无疑义地确定与具体实施方式的等价替换或变形所对应的其他附图。
图1示出了现有技术中对车端软件进行升级的典型方式的示意图；
图2示出了本申请的车端软件版本远程批量升级管理方法的一个具体实施方式的流程示意图；
图3示出了本申请的车端软件版本远程批量升级管理***的一个具体实施方式的示意图。
通过上述附图，已经清楚明确地示出了本申请的一些具体实施方式，针对这些具体实施方式，后文将有更加详细的文字说明。这些附图和文字说明的目的，并不是要以任何方式限制本申请发明构思所涵盖的保护范围，而是要通过一些特定的具体实施方式，使本领域技术人员能够更方便地理解本申请的发明思想。
具体实施方式
为使本领域技术人员更加方便地理解本申请的技术方案，将结合附图，对本申请技术方案的一些具体实施方式进行清楚、完整地说明。显然，所描述的具体实施方式只是本申请技术方案的一部分具体实施方式，而不是全部的具体实施方式。基于本申请中已经描述的具体实施方式，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都属于本申请保护的范围。
应该说明的是，本申请中提及的术语“第一”、“第二”、“第三”“第四”等(如果有)，若干处理过程的数字和/或字母标号，是用于区别类似的对象，而不必然理解成用于描述特定的顺序或先后次序。应该理解，这些数字在适当情况下可以互换，以便这里描述的本申请的技术方案，比如能够以除了图示或描述的那样以外的顺序进行实施。另外，术语“包括”和“具有”以及他们的任何变形，并非意指仅覆盖排他性的包含，例如，包含了一系列步骤的方法，或包含了若干单元、模块的产品或设备，并不必然理解成仅限于列明的那些步骤、单元、模块，而是还可以包括没有列明的或对于这些方法、产品或设备本身理应固有的其它步骤、单元、模块。
另外，下面对本发明技术方案的不同部分进行详细说明的多个具体实施方式、多个实施例、多个实例等，在不相互排斥的情况下，可以相互结合成为本发明的一个完整的技术方案。对于在某一具体实施方式、实施例、实例等中已经描述过的相同或相似的概念、过程等，可能在其他具体实施方式、实施例、实例等中不再赘述。
下面，结合附图，对本申请的一些具体实施方式、实施例、实例等进行详细说明。
图2示出了本申请的车端软件版本远程批量升级管理方法的一个具体实施方式的流程示意图。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法包括：S201，软件代码上传存储过程，由代码存储库，存储编程人员分布式上传的软件代码。
在S201表示的软件代码上传存储过程中，由代码存储库，存储编程人员分布式上传的软件代码。
在本实施方式中，通过将分布在不同位置的编程人员所编写的软件代码统一上传并存储在统一的代码存储库中，进行相应的统一管理，能够有效、高速地进行从很小到很大的软件 开发项目，提高不同位置编程人员的协同工作能力。
在本实施方式的一个实施例中，代码存储库可以是集中式的代码存储库，并且，每一编程人员的本地终端上均预先安装有分布式版本控制***。作为一个实例，代码存储库可以是具有存储功能的一台或多台计算机设备。
在该实施例中，通过采用集中式的代码存储库，能够便于后续对全部编程人员的编程结果，即软件代码，进行统一管控。
作为一个实例，分布在不同位置的编程人员，在自己的本地终端将自己负责编写的相应软件的软件代码编写完成之后，通过自己的本地终端上预先安装的分布式版本控制***，将编写完成的软件代码上传到集中式的代码存储库，由该代码存储库进行存储。
作为一个实例，分布式版本控制***可以是开源的分布式版本控制***，具体可以是git。相应的，代码存储库可以是git存储库。
作为本实施方式的一个实施例，编程人员可以被分成多个组，一组编程人员针对实现一种功能的车辆分组中车辆的软件的编程和升级任务进行工作。从而，该组编程人员所编写的代码可以作为相应功能分组的车辆所用软件的一部分。
作为一个实例，按功能进行分组后的各组车辆，可以分别进行数据采集、自动驾驶算法验证、自动驾驶试运行等。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法包括：S202，软件代码持续编译集成过程。
在S202表示的软件代码持续编译集成过程中，由持续集成构建服务，对持续上传的软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对二进制文件进行描述的声明式版本部署文件包。
这样，针对不同的软件代码，能够按相应的自动化执行流程进行编译和集成，从而能够自动生成车端可运行的不同版本的二进制文件，以及对二进制文件进行描述的声明式版本部署文件包。
作为本实施方式的一个实施例，持续集成构建服务，针对多个车辆分组当中的各个分组分别对应的编程人员上传的软件代码，被各自预先配置相应的编译规则。
作为本实施方式的一个实施例，预先配置的编译规则，可以实现对软件代码的编写规范性的检查。作为一个实例，编写规范性可以包括：编写的格式是否满足要求，以及代码的大小与其要实现的功能相比是否经济，等。这样，当软件代码的编写不规范，比如，格式不符合要求，或代码的大小不够经济时，持续集成构建服务可以将该软件代码退回相应的编程人员，要求其重新编写。
作为本实施方式的一个实施例，对持续上传的软件代码当中满足预先配置的编译规则的代码进行编译和集成，具体可以将针对同一软件的代码编译成该软件对应的车辆可运行的数据格式，并将编译后的结果集成在该软件的新版本的二进制文件中。
作为本实施方式的一个实施例，声明式版本部署文件包可以描述相应车端软件的启动命令、计算资源占用下限值和上限值、基于健康检查结果所需执行的操作、副本数量、和/或与其他车端软件的启动先后顺序。
作为一个实例，计算资源占用下限值，是为了确保相应的车端软件的新版本能够正常运行，必须被分配的内存和/或CPU占用量。计算资源占用上限值，应能确保相应的车端软件的新版本在运行时所占用的内存和/或CPU，不得影响相应车辆正常驾驶所必须运行的软件和功能组件的正常运行。
作为一个实例，健康检查结果所需执行的操作可以包括：在相应车端软件的相应版本的安装过程中，若检查到相应的容器在持续预定时间段后仍不能正常响应，则将相应的容器强制停止运行后再次重启；以及在相应车端软件的相应版本的运行过程中，若检查到相应的容器不能正常响应，则将相应的容器强制停止运行后再次重启。
这样，通过在声明式版本部署文件包中设置基于健康检查结果所需执行的操作，能够实现对相应车端软件的全生命周期管理。
作为本实施方式的一个实施例，为相应车端软件建立的副本数量为1个。这样，能够确保相应的车端软件不论因何原因崩溃时，一定还有一个健康的副本还在运行，从而确保相应车端软件运行的稳健性。
作为本实施方式的一个实施例，相应软件的启动需要以其他车端软件的启动或停止为前提，这时，声明式版本部署文件包中配置与其他车端软件的启动先后顺序，能够确保相应软件在启动时已经具备了启动的条件。比如，图像分析的软件，启动之前，需要确保控制车辆上安装的摄像头进行拍摄的软件已经启动。
作为一个实例，声明式版本部署文件包可以是采用轻量级Kubernetes的包管理工具helm生成和管理的声明式部署包helm chart。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法还包括：S203，二进制文件存储过程。
在S203表示的二进制文件存储过程中，由二进制文件存储库，存储二进制文件。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法还包括：S204，声明式版本部署文件包存储过程。
在S204表示的声明式版本部署文件包存储过程中，由声明式版本部署文件存储库，存储声明式版本部署文件包。
在本实施方式的一个实施例中，声明式版本部署文件存储库可以是多个，多个声明式版本部署文件存储库当中的每一个，可以分别专用于存储一种功能的车辆分组中车辆的软件对应的软件代码所生成的声明式版本部署文件包。从而，各个声明式版本部署文件存储库中存储的相应的声明式版本部署文件包，可以分别一一对应地专用于多个车辆分组当中的各个分组。
这样，在后续操作时，仅根据声明式版本部署文件包的存储位置是在哪一个声明式版本部署文件存储库，就能够判断相应的声明式版本部署文件包需要发布给哪一组车辆。
在本实施方式的一个实施例中，多个声明式版本部署文件存储库可以是多个独立的物理存储介质，或者是一个物理存储介质内的多个分支。
作为一个实例，声明式版本部署文件存储库可以是git存储库。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法还包括：S205，软件新版本统一分组发布过程。
在S205表示的软件新版本统一分组发布过程中，由统一发布平台，当实时自动监听到或在统一发布平台上人工选择需升级的车端软件版本后检查到，在声明式版本部署文件存储库中存储有，与上一监听结果相比或人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包时，从声明式版本部署文件存储库拉取新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆。
在本实施方式中，若由统一发布平台实时自动监听是否有新的声明式版本部署文件包，进而进行发布的，属于监听式自动发布；若由人工在统一发布平台上选择需升级的车端软件版本后进行发布的，属于主动发布。
在本实施方式的一个实施例中，在进行主动发布的情况下，统一发布平台管理人员可以在统一发布平台上点选需要升级的软件版本，从而统一发布平台可以将从相应的声明式版本部署文件存储库检查到并拉取的声明式版本部署文件包，发布给该软件版本所服务的相应分组的所有车辆。
在本实施方式的一个实施例中，若需要发布软件新版本的相应分组车辆中的一台或多台车辆处于未启动状态，则将统一发布平台拉取的相应声明式版本部署文件包缓存在统一发布平台上。这样，在相应车辆启动后即能够开始相应软件的自动升级。
作为一个实例，在声明式版本部署文件存储库为git存储库的情况下，统一发布平台对声明式版本部署文件存储库的自动监听和通信，可以以GitOps的形式完成。
在图2所示的实施方式中，本申请的车端软件版本远程批量升级管理方法还包括：S206，软件新版本分组自动批量升级过程。
在S206表示的软件新版本分组自动批量升级过程中，由多个车端容器管理单元，其分别 预先安装在各个车辆中，在相应分组的车辆处于启动状态时，根据新的声明式版本部署文件包，自动从二进制文件存储库下载并以容器的形式运行相应的二进制文件，以完成相应软件版本在相应分组的所有车辆上的批量升级。
在本实施方式的一个实施例中，车端容器管理单元可以是控制软件。车端容器管理单元可以将下载的用于软件版本升级的二进制文件，以容器的形式进行运行，从而完成该软件版本在相应车辆上的升级。
因为车端容器管理单元能够将相应的二进制文件以容器的形式运行，并且考虑到容器所具有的能够整体迁移、便于建立副本等特性，所以能够降低车端软件版本发布和升级的复杂度。
在本实施方式的一个实施例中，在车端容器管理单元的管理下，每辆车可以表现为一个车端容器管理单元管理下的独立集群。作为一个实例，该独立集群可以利用相应车辆上的一个或多个服务器来实现。
在本实施方式的一个实施例中，统一发布平台可以对所有车端容器管理单元管理下的独立集群进行分组管理，进而使相同功能的车辆被分在所述车辆分组的同一分组中。
在本实施方式的一个实施例中，统一发布平台与车端容器管理单元管理下的独立集群之间的通信，可以采用双向证书认证。这样，能够确保双方之间通信的安全性，防止车辆自动驾驶过程中被第三方恶意劫持。
作为一个实例，车端容器管理单元可以是集群管理工具Kubernetes的轻量级版本k3s。相应的，车端容器管理单元管理下的独立集群可以是独立的k3s集群。
图3示出了本申请的车端软件版本远程批量升级管理***的一个具体实施方式的示意图。
在该具体实施方式中，包括：代码存储库301，存储编程人员分布式上传的软件代码；持续集成构建服务302，对持续上传的软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对二进制文件进行描述的声明式版本部署文件包；二进制文件存储库303，存储二进制文件；声明式版本部署文件存储库304，存储声明式版本部署文件包；统一发布平台305，当实时自动监听到或在统一发布平台上人工选择需升级的车端软件版本后检查到，在声明式版本部署文件存储库中存储有，与上一监听结果相比或人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包时，从声明式版本部署文件存储库拉取新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆；以及多个车端容器管理单元306，其分别预先安装在各个车辆中，在相应分组的车辆处于启动状态时，根据新的声明式版本部署文件包，自动从二进制文件存储库下载并以容器的形式运行相应的二进制文件，以完成相应软件版本在相应分组的所有车辆上的批量升级。
在该具体实施方式中，代码存储库301、持续集成构建服务器302、二进制文件存储库 303、声明式版本部署文件存储库304、统一发布平台305、多个车端容器管理单元306，可以具体执行图2所示的车端软件版本远程批量升级管理方法的软件代码上传存储过程201、软件代码持续编译集成过程202；二进制文件存储过程203、声明式版本部署文件包存储过程204、软件新版本统一分组发布过程205、软件新版本分组自动批量升级过程206的上述具体实施方式、实施例、实例等描述的相应过程，能够达到图2所示的车端软件版本远程批量升级管理方法的上述具体实施方式、实施例、实例等描述的相应过程所达到的相应技术效果。
在本申请的一个具体实施方式中，提供了一种计算机可读存储介质，其存储有计算机指令，其中计算机指令***作以执行任一上述实施方式、实施例、实例等描述的车端软件版本远程批量升级管理方法。其中，该存储介质存储的计算机指令，可以直接存储在硬件中、存储在由处理器执行的软件模块中、或者存储在两者的组合中。
软件模块可驻留在RAM存储器、快闪存储器、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可装卸盘、CD-ROM或可用于存储计算机指令的任何其它形式的存储介质中。通常，存储介质可以在处理器的控制下，使处理器可从存储介质读取信息和向存储介质写入信息。
处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)、现场可编程门阵列(英文：Field Programmable Gate Array，简称：FPGA)或其它可编程逻辑装置、离散门或晶体管逻辑、离散硬件组件或其任何组合等。通用处理器可以是微处理器，但在替代方案中，处理器可以是任何常规处理器、控制器、微控制器或状态机。处理器还可实施为计算装置的组合，例如DSP与微处理器的组合、多个微处理器、结合DSP核心的一个或一个以上微处理器或任何其它此类配置。在替代方案中，存储介质与处理器可以是一体的。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替代方案中，处理器和存储介质可作为离散组件驻留在用户终端中。
在本申请所提供的实施方式中，应该理解到，所公开的装置，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本申请的技术方案的目的。
以上仅为本申请的实施例，并非因此限制本申请的专利保护范围，凡是利用本申请说明 书及附图内容所作的等效结构变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

  1. 一种车端软件版本远程批量升级管理方法，其特征在于，包括：
    软件代码上传存储过程，由代码存储库，存储编程人员分布式上传的软件代码；
    软件代码持续编译集成过程，由持续集成构建服务，对持续上传的所述软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对所述二进制文件进行描述的声明式版本部署文件包；
    二进制文件存储过程，由二进制文件存储库，存储所述二进制文件；
    声明式版本部署文件包存储过程，由声明式版本部署文件存储库，存储所述声明式版本部署文件包；
    软件新版本统一分组发布过程，由统一发布平台，当实时自动监听到或在所述统一发布平台上人工选择需升级的车端软件版本后检查到，在所述声明式版本部署文件存储库中存储有，与上一监听结果相比或所述人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包时，从所述声明式版本部署文件存储库拉取所述新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆；以及
    软件新版本分组自动批量升级过程，由多个车端容器管理单元，其分别预先安装在各个所述车辆中，在所述相应分组的车辆处于启动状态时，根据所述新的声明式版本部署文件包，自动从所述二进制文件存储库下载并以容器的形式运行相应的所述二进制文件，以完成相应软件版本在所述相应分组的所有车辆上的批量升级。
  2. 根据权利要求1所述的车端软件版本远程批量升级管理方法，其特征在于，所述声明式版本部署文件存储库为多个，各个所述声明式版本部署文件存储库中存储的相应的所述声明式版本部署文件包，分别一一对应地专用于所述多个车辆分组当中的各个分组。
  3. 根据权利要求1所述的车端软件版本远程批量升级管理方法，其特征在于，所述声明式版本部署文件包描述相应车端软件的启动命令、计算资源占用下限值和上限值、基于健康检查结果所需执行的操作、副本数量、和/或与其他车端软件的启动先后顺序。
  4. 根据权利要求3所述的车端软件版本远程批量升级管理方法，其特征在于，所述基于健康检查结果所需执行的操作包括：
    在相应车端软件的相应版本的安装过程中，若检查到相应的容器在持续预定时间段后仍不能正常响应，则将相应的容器强制停止运行后再次重启；以及
    在相应车端软件的相应版本的运行过程中，若检查到相应的容器不能正常响应，则将相应的容器强制停止运行后再次重启。
  5. 根据权利要求3所述的车端软件版本远程批量升级管理方法，其特征在于，为所述相应车端软件建立的所述副本数量为1个。
  6. 根据权利要求1所述的车端软件版本远程批量升级管理方法，其特征在于，所述持续集成构建服务，针对所述多个车辆分组当中的各个分组分别对应的编程人员上传的所述软件代码，被各自预先配置相应的所述编译规则。
  7. 根据权利要求1所述的车端软件版本远程批量升级管理方法，其特征在于，在所述统一发布平台上，对所述多个车端容器管理单元进行分组管理，进而使相同功能的车辆被分在所述车辆分组的同一分组中。
  8. 根据权利要求1所述的车端软件版本远程批量升级管理方法，其特征在于，所述统一发布平台与所述车端容器管理单元之间的通信采用双向证书认证。
  9. 一种车端软件版本远程批量升级管理***，其特征在于，包括：
    代码存储库，存储编程人员分布式上传的软件代码；
    持续集成构建服务，对持续上传的所述软件代码当中满足预先配置的编译规则的代码进行编译和集成，生成车端可运行的不同版本的二进制文件，以及对所述二进制文件进行描述的声明式版本部署文件包；
    二进制文件存储库，存储所述二进制文件；
    声明式版本部署文件存储库，存储所述声明式版本部署文件包；
    统一发布平台，当实时自动监听到或在所述统一发布平台上人工选择需升级的车端软件版本后检查到，在所述声明式版本部署文件存储库中存储有，与上一监听结果相比或所述人工选择需升级的车端软件版本所对应的新的声明式版本部署文件包时，从所述声明式版本部署文件存储库拉取所述新的声明式版本部署文件包，并将其发布给多个车辆分组当中相应分组的所有车辆；以及
    多个车端容器管理单元，其分别预先安装在各个所述车辆中，在所述相应分组的车辆处于启动状态时，根据所述新的声明式版本部署文件包，自动从所述二进制文件存储库下载并以容器的形式运行相应的所述二进制文件，以完成相应软件版本在所述相应分组的所有车辆上的批量升级。
  10. 一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机指令，所述计算机指令***作以执行权利要求1-8中任一项所述的车端软件版本远程批量升级管理方法。
PCT/CN2021/109539 2021-06-02 2021-07-30 车端软件版本远程批量升级管理方法、***及介质 WO2022252381A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110613727.7A CN115437659A (zh) 2021-06-02 2021-06-02 车端软件版本远程批量升级管理方法、***及介质
CN202110613727.7 2021-06-02

Publications (1)

Publication Number Publication Date
WO2022252381A1 true WO2022252381A1 (zh) 2022-12-08

Family

ID=84240142

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/109539 WO2022252381A1 (zh) 2021-06-02 2021-07-30 车端软件版本远程批量升级管理方法、***及介质

Country Status (2)

Country Link
CN (1) CN115437659A (zh)
WO (1) WO2022252381A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116707819A (zh) * 2023-06-01 2023-09-05 红石阳光（北京）科技股份有限公司 一种车辆ota升级安全机制的构建方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327125A (zh) * 2013-07-15 2013-09-25 厦门金龙联合汽车工业有限公司 一种代码远程升级***及其文件传输方法
CN108279919A (zh) * 2018-01-22 2018-07-13 成都雅骏新能源汽车科技股份有限公司 一种新能源电动汽车远程程序升级方法
CN110489143A (zh) * 2019-07-18 2019-11-22 南京依维柯汽车有限公司 新能源汽车上的fota固件远程升级***及其方法
CN111343064A (zh) * 2020-02-29 2020-06-26 东风汽车集团有限公司 汽车控制***软件升级***及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103327125A (zh) * 2013-07-15 2013-09-25 厦门金龙联合汽车工业有限公司 一种代码远程升级***及其文件传输方法
CN108279919A (zh) * 2018-01-22 2018-07-13 成都雅骏新能源汽车科技股份有限公司 一种新能源电动汽车远程程序升级方法
CN110489143A (zh) * 2019-07-18 2019-11-22 南京依维柯汽车有限公司 新能源汽车上的fota固件远程升级***及其方法
CN111343064A (zh) * 2020-02-29 2020-06-26 东风汽车集团有限公司 汽车控制***软件升级***及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116707819A (zh) * 2023-06-01 2023-09-05 红石阳光（北京）科技股份有限公司 一种车辆ota升级安全机制的构建方法
CN116707819B (zh) * 2023-06-01 2024-03-15 红石阳光（北京）科技股份有限公司 一种车辆ota升级安全机制的构建方法

Also Published As

Publication number Publication date
CN115437659A (zh) 2022-12-06

Similar Documents

Publication Publication Date Title
US20200159604A1 (en) Self-healing learning system for one or more controllers
US9823915B1 (en) Software container format
CN107733985B (zh) 一种云计算***功能组件部署方法及装置
WO2020015191A1 (zh) 业务规则的发布管理方法、电子装置及可读存储介质
CN110990019A (zh) 一种Java类分析方法、装置、存储介质及电子设备
CN108829425B (zh) 一种针对国产操作***上的应用软件在线升级管控方法
Nikolov Research firmware update over the air from the cloud
CN111966366A (zh) 一种多cpu架构的集群部署的方法和设备
CN112214388A (zh) 内存监控方法、装置、设备及计算机可读存储介质
WO2022252381A1 (zh) 车端软件版本远程批量升级管理方法、***及介质
CN104699503A (zh) 一种替换安卓***中函数的执行逻辑的方法及装置
US20240078103A1 (en) Generating and distributing customized embedded operating systems
CN113448686A (zh) 一种资源部署方法、装置、电子设备及存储介质
CN111158743B (zh) 大数据运维管理平台
CN113434180B (zh) 应用的数据处理方法、装置、服务器和存储介质
CN114546588A (zh) 任务的部署方法、装置、存储介质及电子装置
US10540151B1 (en) Graphical customization of a firmware-provided user interface (UI)
CN112565416B (zh) 基于云原生的大规模边缘安卓设备纳管***及其纳管方法
CN114064083A (zh) 通过在配置中心自定义模板部署云原生应用的方法及应用
WO2018037292A1 (en) Non-process identifier based service manager
CN113448793A (zh) 一种兼容多操作***的***监控方法及装置
CN113515293B (zh) 一种管理DevOps工具链的方法和***
CN115421847A (zh) 支持多引擎的研发运维平台和cicd流水线的管理方法及设备
US11425203B2 (en) Commissioning a virtualized network function
US11550566B2 (en) Automatically integrating software components into a control framework in a distributed computing environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21943737

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21943737

Country of ref document: EP

Kind code of ref document: A1