WO2022252381A1 - Procédé et système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots, et support - Google Patents

Procédé et système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots, et support 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)
Chinese (zh)
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/fr

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

La présente demande appartient au domaine technique de la conduite autonome. Un procédé et un système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots sont divulgués, ainsi qu'un support. Le procédé comprend : un processus de téléversement et de stockage de codes logiciels ; un processus de compilation et d'intégration en continu des codes logiciels ; un processus de stockage de fichiers binaires ; un processus de stockage de paquetages de fichiers de déploiement de version déclarative ; un processus de groupement uniforme et de publication de nouvelles versions de logiciel ; et un processus de groupement et de mise à niveau automatique des nouvelles versions de logiciel par lots. Lorsque des véhicules dans des groupes correspondants sont dans un état démarré, une pluralité d'unités de gestion de conteneurs côté véhicule téléchargent automatiquement, selon de nouveaux paquetages de fichiers de déploiement de version déclarative, des fichiers binaires correspondants à partir d'une bibliothèque de stockage de fichiers binaires et exécutent les fichiers binaires correspondants sous la forme de conteneurs, de manière à accomplir la mise à niveau par lots de versions de logiciel correspondantes sur tous les véhicules dans les groupes correspondants. Au moyen du procédé de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots de la présente invention, l'efficacité de publication de versions de logiciel est améliorée, et la complexité de publication et de mise à niveau des versions de logiciel est réduite.
PCT/CN2021/109539 2021-06-02 2021-07-30 Procédé et système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots, et support WO2022252381A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=84240142

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/109539 WO2022252381A1 (fr) 2021-06-02 2021-07-30 Procédé et système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots, et support

Country Status (2)

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

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 (fr) Procédé de libération et de gestion de règles commerciales, dispositif électronique et support d'informations lisible
CN110990019A (zh) 一种Java类分析方法、装置、存储介质及电子设备
US8332356B2 (en) NFS agent upgrade
Nikolov Research firmware update over the air from the cloud
CN111966366A (zh) 一种多cpu架构的集群部署的方法和设备
CN112214388A (zh) 内存监控方法、装置、设备及计算机可读存储介质
WO2022252381A1 (fr) Procédé et système de gestion pour la mise à niveau à distance de versions de logiciel côté véhicule par lots, et support
CN104699503A (zh) 一种替换安卓系统中函数的执行逻辑的方法及装置
US20240078103A1 (en) Generating and distributing customized embedded operating systems
CN113448686A (zh) 一种资源部署方法、装置、电子设备及存储介质
CN111158743B (zh) 大数据运维管理平台
CN114237632A (zh) 一种混合云自动化运维发布系统及其操作方法
CN113434180B (zh) 应用的数据处理方法、装置、服务器和存储介质
CN114546588A (zh) 任务的部署方法、装置、存储介质及电子装置
US10540151B1 (en) Graphical customization of a firmware-provided user interface (UI)
CN112565416B (zh) 基于云原生的大规模边缘安卓设备纳管系统及其纳管方法
CN114064083A (zh) 通过在配置中心自定义模板部署云原生应用的方法及应用
US10394619B2 (en) Signature-based service manager with dependency checking
CN113448793A (zh) 一种兼容多操作系统的系统监控方法及装置
CN113515293B (zh) 一种管理DevOps工具链的方法和系统
US11550566B2 (en) Automatically integrating software components into a control framework in a distributed computing environment
CN115421847A (zh) 支持多引擎的研发运维平台和cicd流水线的管理方法及设备

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