Vehicle machine software version management method, device and equipment and storage medium

Abstract

The invention discloses a vehicle machine software version management method, device and equipment and a storage medium, and relates to the technical field of vehicle wireless communication, and the method comprises the steps: receiving an update instruction, and determining an update operation according to the update instruction, the update operation comprising normal upgrade and version restoration; according to the updating operation, a corresponding updating mode is adopted to update the version of the vehicle-mounted machine part; and after version updating is completed, obtaining an updating start package and an updating target package of the vehicle-mounted machine part, and taking the updating start package and the updating target package as version updating records and storing the version updating records so as to complete version management of the vehicle-mounted machine part. According to the method and the device, the flexibility and the reliability of OTA software updating of the whole vehicle are improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle wireless communication technology, and in particular to a vehicle computer software version management method, device, equipment and storage medium. Background Art

[0002] With the rapid development of automobile intelligence and networking, software plays an increasingly important role in automobiles. The traditional way of upgrading cars requires car owners to go to the store, which is time-consuming and labor-intensive, and it is difficult to respond quickly to software defects and safety issues. Therefore, OTA technology came into being, allowing vehicle software to be upgraded and repaired remotely via wireless networks. At present, vehicle OTA technology allows vehicles to upgrade software via wireless networks, but there are still the following problems: software version management is not flexible enough, and it is difficult to cope with situations where rollback to a specific historical version is required; users are concerned about the reliability and security of OTA upgrades, and are worried about upgrade failures or incompatibility. Summary of the invention

[0003] The main purpose of this application is to provide a vehicle software version management method, device, equipment and storage medium, aiming to solve the technical problem of how to improve the flexibility and reliability of vehicle OTA software updates.

[0004] To achieve the above purpose, the present application proposes a vehicle software version management method, the method comprising:

[0005] receiving an update instruction, and determining an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore;

[0006] According to the update operation, a corresponding update method is used to update the version of the vehicle computer parts;

[0007] After the version update is completed, the update start package and the update target package of the vehicle machine part are obtained, and the update start package and the update target package are stored in the version record directory to complete the version management of the vehicle machine part.

[0008] In one embodiment, the step of updating the version of the vehicle machine parts using a corresponding updating method according to the updating operation includes:

[0009] When the update operation is a normal upgrade, the current version information of the vehicle machine parts is obtained and sent to the OTA cloud, so that the OTA cloud provides feedback based on the current version information;

[0010] Obtain the task information fed back by the OTA cloud;

[0011] When the task information indicates that there is an upgrade task, obtaining the vehicle machine part corresponding to the upgrade task, and upgrading the version of the vehicle machine part;

[0012] When the task information indicates that there is no upgrade task, the version upgrade of the vehicle machine component is stopped.

[0013] In one embodiment, the step of updating the version of the vehicle machine parts using a corresponding updating method according to the updating operation includes:

[0014] When the update operation is version restoration, obtaining a version baseline for the version restoration according to the update instruction;

[0015] Analyze the version baseline to obtain analysis results;

[0016] The version of the vehicle computer parts is restored using a corresponding update method according to the analysis result.

[0017] In one embodiment, the step of analyzing the version baseline to obtain an analysis result includes:

[0018] According to the version baseline, obtain the time node data of the version restoration;

[0019] Match the time node data with the local version directory to obtain a matching result;

[0020] When the matching result is successful, the analysis result is obtained as being consistent with the local version;

[0021] When the matching result is a matching failure, the analysis result is obtained as not being consistent with the local version.

[0022] In one embodiment, the step of restoring the version of the vehicle machine part using the corresponding update method according to the analysis result includes:

[0023] When the analysis result is consistent with the local version, determining the update mode to be a local restoration mode, and using the local restoration mode to restore the version of the vehicle machine parts;

[0024] When the analysis result is not in conformity with the local version, the update mode is determined to be an online restoration mode, and the version of the vehicle machine part is restored by using the online restoration mode.

[0025] In one embodiment, when the analysis result is consistent with the local version, determining the update mode as the local restoration mode, and restoring the version of the vehicle machine part by using the local restoration mode includes:

[0026] When the analysis result is consistent with the local version, determining the update mode as the local restore mode, and generating local task information according to the version baseline;

[0027] Obtaining vehicle computer parts that need to be flashed according to the local task information, and generating a task list according to the vehicle computer parts that need to be flashed;

[0028] The versions of the vehicle machine parts that need to be flashed are restored according to the task list.

[0029] In one embodiment, when the analysis result is inconsistent with the local version, determining that the update method is an online restoration method, and restoring the version of the vehicle machine part by using the online restoration method includes:

[0030] When the analysis result is that the local version is not in compliance, determining that the update mode is an online restoration mode, and initiating an online version restoration application to the OTA cloud according to the version baseline, so that the OTA cloud provides feedback based on the online version restoration application;

[0031] Obtaining online version information of the OTA cloud feedback;

[0032] Obtaining online task information according to the online version information;

[0033] Obtaining vehicle computer parts that need to be flashed according to the online task information, and generating a task list according to the vehicle computer parts that need to be flashed;

[0034] The versions of the vehicle machine parts that need to be flashed are restored according to the task list.

[0035] In addition, to achieve the above purpose, the present application also proposes a vehicle software version management device, the device comprising:

[0036] An instruction analysis module, used for receiving an update instruction and determining an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore;

[0037] A version update module, used to update the version of the vehicle machine parts using a corresponding update method according to the update operation;

[0038] The version management module is used to obtain the update start package and update target package of the vehicle machine part after the version update is completed, and store the update start package and the update target package in the version record directory to complete the version management of the vehicle machine part.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a vehicle software version management device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the vehicle software version management method as described above.

[0040] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the vehicle software version management method described above are implemented.

[0041] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the vehicle software version management method as described above.

[0042] One or more technical solutions proposed in this application have at least the following technical effects:

[0043] By introducing the concept of a version control system, effective management of vehicle parts software versions is achieved, and users are allowed to restore the software version to the corresponding version at any point in time. This solves the problem of insufficient flexibility in OTA software version management, difficulty in coping with situations where rollback to a specific historical version is required, and users' concerns about OTA software upgrade failure or incompatibility. Compared with the existing technology, the flexibility and reliability of vehicle OTA software updates are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0045] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0046] Figure 1 A flowchart of the first embodiment of the vehicle software version management method of the present application is provided;

[0047] Figure 2 A schematic diagram of the overall system architecture of a vehicle computer software version management method provided in an embodiment of the present application;

[0048] Figure 3 A flowchart of the second embodiment of the vehicle software version management method of the present application is provided;

[0049] Figure 4 A timing diagram of a normal upgrade method of a vehicle computer software version management method provided in an embodiment of the present application;

[0050] Figure 5 A flowchart of the third embodiment of the vehicle software version management method of the present application is provided;

[0051] Figure 6 A schematic diagram of version rollback and restoration of a vehicle computer software version management method provided in an embodiment of the present application;

[0052] Figure 7 A schematic diagram of a vehicle software version management method provided in an embodiment of the present application;

[0053] Figure 8 A flowchart diagram of the fourth embodiment of the vehicle software version management method of the present application;

[0054] Fig. 9 A schematic diagram of a local version record structure of a vehicle software version management method provided in an embodiment of the present application;

[0055] Fig.10 A timing diagram of a local restoration method of a vehicle software version management method provided in an embodiment of the present application;

[0056] Fig.11 A timing diagram of an online restoration method of a vehicle computer software version management method provided in an embodiment of the present application;

[0057] Fig.12 This is a schematic diagram of the module structure of the vehicle software version management device according to an embodiment of the present application;

[0058] Fig.13 This is a schematic diagram of the device structure of the hardware operating environment involved in the vehicle computer software version management method in the embodiment of the present application.

[0059] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0060] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0061] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0062] The main solution of the embodiment of the present application is: receiving an update instruction, and determining an update operation according to the update instruction, the update operation including normal upgrade and version restoration; according to the update operation, using a corresponding update method to perform a version update of the vehicle parts; after the version update is completed, obtaining the update start package and the update target package of the vehicle parts, and storing the update start package and the update target package as version update records to complete the version management of the vehicle parts.

[0063] In this embodiment, for ease of description, the following description is made taking the vehicle-side OTA main control program as the execution subject.

[0064] Because software version management in existing technologies is not flexible enough and it is difficult to cope with situations where rollback to a specific historical version is required, users are concerned about the reliability and security of OTA upgrades, and are worried about upgrade failure or incompatibility.

[0065] The present application provides a solution that introduces the concept of a version control system to achieve effective management of vehicle parts software versions and allows users to restore the software version to the version corresponding to any point in time, thereby improving the flexibility and reliability of vehicle OTA software updates.

[0066] It can be seen from the above embodiments that the present application, by introducing the concept of a version control system, achieves effective management of the software versions of vehicle parts and allows users to restore the software version to the version corresponding to any point in time, thereby solving the problems of insufficient flexibility in OTA software version management, difficulty in coping with situations where rollback to a specific historical version is required, and user concerns about OTA software upgrade failure or incompatibility, thereby improving the flexibility and reliability of vehicle OTA software updates.

[0067] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, etc. The following takes the OTA main control program on the vehicle side as an example to illustrate this embodiment and the following embodiments.

[0068] Based on this, the present application embodiment provides a vehicle software version management method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the vehicle software version management method of the present application.

[0069] In this embodiment, the vehicle computer software version management method includes steps S10 to S30:

[0070] Step S10, receiving an update instruction, and determining an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore.

[0071] It should be noted that the update command is a software update command issued by the user to the OTA main control program on the vehicle side through the human-computer interaction interface, including the updated version baseline, updated parts information, etc. The normal upgrade is to upgrade the vehicle parts to the new version specified in the update command, and the version restore is to restore the vehicle parts to the old version specified in the update command.

[0072] Step S20: According to the update operation, a corresponding update method is used to update the version of the vehicle machine parts.

[0073] It should be noted that the update methods include normal upgrade method, local restore method and online restore method. Different update operations correspond to different update methods, so the version of the vehicle computer parts can be updated using the corresponding update method according to the update operation.

[0074] Step S30, after the version update is completed, the update start package and the update target package of the vehicle machine part are obtained, and the update start package and the update target package are stored in the version record directory to complete the version management of the vehicle machine part.

[0075] It should be noted that the update start package is the version file package before the vehicle computer parts software version is updated, the update target package is the version file package after the software version is updated, and the version record directory is the record of the vehicle computer parts software version update, including the update start package, update target package, task information, version upgrade time, current version information, etc. The update start package is named in the src_xxx.zip format, and the update target package is named in the dst_xxx.zip format.

[0076] Each upgrade task contains an update start package and an update target package. The upgrade task is upgraded from the start package to the target package. When the task is downloaded, the start package and the target package will be downloaded to the cache together. After the upgrade is successful, the update start package and the update target package of all ECUs in this upgrade task will be used as version update records and stored in the version record directory. The version record directory of the OTA main control program on the vehicle side will clear the version records of historical time nodes and only retain the version information of 2 time nodes, that is, the two most recent version information of the time node and the current time node. The number of retained time nodes can be adjusted appropriately according to the storage space of the system ROM. The version record directory of the OTA cloud will retain the version information of all time nodes of all parts of the vehicle computer.

[0077] In addition, it should be noted that ECU (Electronic Control Unit) refers to an ECU in an automobile or other automated system that can use the UCM (Unified Change Management) method to manage and track changes in the system. This method is often used in the development of software systems to ensure that changes are properly identified, organized and controlled, thereby coordinating development work, reducing confusion and errors, and improving production efficiency. Version record directory.

[0078] This embodiment provides a vehicle software version management method. By introducing the concept of a version control system, effective management of the software versions of vehicle parts is achieved, and users are allowed to restore the software version to the version corresponding to any point in time. This solves the problem that OTA software version management is not flexible enough to cope with situations where rollback to a specific historical version is required, as well as users' concerns about OTA software upgrade failure or incompatibility. This improves the flexibility and reliability of vehicle OTA software updates.

[0079] For example, to help understand the vehicle software version management method of the first embodiment, please refer to Figure 2 , Figure 2 A schematic diagram of the overall system architecture of a vehicle software version management method is provided, wherein the overall architecture includes: OTA cloud and cloud version server, UC, DPC, OtaService, UPS, OTA-UE, IVI SocketServer, IVI MCU and GW.

[0080] OTA cloud and cloud version server: unified management of vehicles, parts, upgrade tasks, and software versions;

[0081] UC (Automotive OTA Master Control Program): responsible for OTA upgrades of all vehicle parts, including storage of version update information, vehicle parts information query, task detection, downloading, upgrading, result reporting, etc.;

[0082] DPC (diagnostic flash module): For parts upgraded via CAN or Doip protocol, this module is responsible for information collection, version flashing, etc.

[0083] OtaService (smart component flashing module): Some smart components such as IVI and TBOX do not support Doip upgrades. This module can be used to complete information collection and version flashing;

[0084] Ups (MQTT server process): provides MQTT message communication mechanism between modules;

[0085] OTA-UE (user interaction module): responsible for the display of the upgrade process, including version prompts, upgrade task prompts, upgrade progress prompts, and upgrade result display;

[0086] IVI SocketServer (VHAL): The communication channel provided by the IVI car service is responsible for forwarding DPC message packets to the MCU;

[0087] IVI MCU: The microcontroller program on IVI is responsible for forwarding messages to GW (gateway) and for communication between GW and DPC;

[0088] GW (Gateway): Responsible for transferring CAN messages to designated parts.

[0089] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 , step S20 includes steps S201 to S204:

[0090] Step S201, when the update operation is a normal upgrade, obtain the current version information of the vehicle machine parts and send it to the OTA cloud, so that the OTA cloud provides feedback based on the current version information.

[0091] When the update operation is a normal upgrade, the current version information of the vehicle parts is obtained. The current version information of the parts is queried by the OTA main control program on the vehicle side. For parts of CAN upgrade or Doip upgrade type, the DPC sends out the query command after receiving the MQTT message from the OTA main control program on the vehicle side. The smart parts are sent by OtaService. After receiving the response, DPC and OtaService send the part information back to the OTA main control program on the vehicle side. The OTA main control program on the vehicle side writes the version information of all parts of the vehicle into the cache and sends it to the OTA cloud.

[0092] It should be noted that MQTT (Message Queuing Telemetry Transport) is a lightweight message transmission protocol that is widely used for communication between devices in the Internet of Things. The OTA cloud is responsible for unified management of vehicles, parts, upgrade tasks, and software versions.

[0093] In addition, it should be noted that CAN upgrade usually refers to the process of updating the firmware of the vehicle's electronic control unit (ECU) through the CAN bus. The DoIP (Diagnostic Communication over Internet Protocol) protocol is an automotive diagnostic communication protocol based on an IP network, allowing diagnostic operations to be performed through Ethernet. TBOX (Telematics BOX) is a vehicle-mounted wireless terminal, and IVI (In-Vehicle Infotainment) is an in-vehicle infotainment system.

[0094] Step S202, obtaining the task information fed back by the OTA cloud.

[0095] The OTA cloud obtains the corresponding vehicle parts information based on the received current version information, and searches whether the corresponding vehicle parts have a new version of the software that can be upgraded. If so, it generates task information containing the version upgrade information of the vehicle parts. If not, it generates task information that no upgrade task exists and returns the information to the OTA main control program on the vehicle side.

[0096] Step S203, when the task information indicates that there is an upgrade task, the vehicle machine parts corresponding to the upgrade task are obtained, and the versions of the vehicle machine parts are upgraded.

[0097] When the task information indicates that there is an upgrade task, the vehicle computer part version upgrade information in the upgrade task is obtained, and the software version of the vehicle computer part is upgraded to the corresponding new version.

[0098] Before upgrading the software version of the vehicle computer parts, in theory, there will be steps such as vehicle computer environment preparation, upgrade prerequisite comparison, and part version verification before upgrading. Since these functions are not closely related to this application, they will not be repeated in this embodiment.

[0099] Step S204, when the task information indicates that there is no upgrade task, stop upgrading the version of the vehicle machine component.

[0100] When the task information indicates that there is no upgrade task, it means that the software version of the vehicle computer part that needs to be upgraded in the update instruction is already the latest version, and there is no corresponding upgradeable version, so the upgrade of the version of the vehicle computer part is stopped.

[0101] The timing diagram of updating the software version using the normal upgrade method is as follows: Figure 4 As shown, including:

[0102] Detect new version; obtain part cache version information; return part version information; query new version; new version information; download new version; transfer file and return download progress; return download progress in real time; download completed; start upgrade; keep vehicle power On; return command result; enter OTA mode; initiate part flash command (can upgrade multiple parts repeatedly); part flash progress; part flash completed; part flash successful; record the upgraded part version to cache; report upgrade result; notify upgrade result; exit OTA mode.

[0103] This embodiment provides a vehicle computer software version management method, when the update operation is a normal upgrade, the current version information of the vehicle computer parts is obtained and sent to the OTA cloud, so that the OTA cloud provides feedback based on the current version information; the task information fed back by the OTA cloud is obtained; when the task information indicates that there is an upgrade task, the vehicle computer parts corresponding to the upgrade task are obtained, and the versions of the vehicle computer parts are upgraded; when the task information indicates that there is no upgrade task, the version upgrade of the vehicle computer parts is stopped, thereby improving the reliability of the normal upgrade of the OTA software version.

[0104] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 5 , step S20 also includes steps S201' to S203':

[0105] Step S201': when the update operation is version restoration, obtaining a version baseline for the version restoration according to the update instruction.

[0106] It should be noted that the version baseline is the timeline corresponding to the upgrade record of the vehicle computer parts software version. For example, the version baseline of the current version of the software is time 3, the version baseline of the previous version is time 2, and the version baseline of the previous two versions is time 1.

[0107] Step S202': analyzing the version baseline to obtain an analysis result.

[0108] The obtained version baseline is matched with the time node in the version record directory to obtain the target historical version that needs to be traced back in the update instruction.

[0109] In a feasible implementation, step S202' includes steps A21 to A24:

[0110] Step A21, obtaining the time node data of the version restoration according to the version baseline.

[0111] According to the version baseline, the time node data of the software version that needs to be traced back for this version restoration is obtained, for example, time node 1, time node 2, etc.

[0112] Step A22, matching the time node data with the local version directory to obtain a matching result.

[0113] It should be noted that the local version directory is the version record directory of the car-side OTA main control program, which only retains the two version information most recent to the current time node.

[0114] The obtained time node data is matched with the time node in the local version directory to obtain a matching result.

[0115] Step A23, when the matching result is successful, the analysis result is obtained to be consistent with the local version.

[0116] When the matching result is successful, it means that the software version information that needs to be backtracked for this version restoration is stored in the local version directory, and the analysis result is consistent with the local version.

[0117] Step A24, when the matching result is a matching failure, the analysis result is obtained as not being in conformity with the local version.

[0118] When the matching result is a matching failure, it means that the software version information that needs to be backtracked for this version restoration is not stored in the local version directory, and the analysis result is that it does not match the local version.

[0119] By analyzing the version baseline and obtaining the analysis results, the accuracy of determining which update method to use for version restoration is improved.

[0120] Step S203 ′: restore the version of the vehicle machine parts by adopting a corresponding updating method according to the analysis result.

[0121] It should be noted that the version restoration update methods include local restoration method and online restoration method, and both of these update methods include version backward restoration and version forward restoration.

[0122] Version rollback restoration is a restoration method that restores the current version to a time node earlier than the current version time node. For example, Figure 6 , assuming that the current vehicle machine version is located at the baseline at time 3, each baseline corresponds to the upgrade record stored in the baseline of that version, srcx is the starting package of the corresponding part, and dtsx is the target package corresponding to the current baseline version. If the user wants to restore to the baseline version at time 1, then the vehicle-side OTA master control program needs to restore the content of the baseline upgrade at time 2 and the content of the baseline upgrade at time 3, so the vehicle-side OTA master control program needs to distribute the following upgrade packages to the corresponding ECUs of the vehicle for upgrade in sequence: src5, src4, src3. After this operation, the baseline version of the vehicle parts is restored to the baseline version corresponding to time 1.

[0123] Version forward restoration is a restoration method that restores the current version to a time node later than the current version time node. For example, Figure 7, assuming that the current vehicle machine version is located at the baseline at time 1, each baseline corresponds to the upgrade record stored in the baseline of that version, srcx is the starting package of the corresponding part, and dtsx is the target package corresponding to the current baseline version. If the user wants to restore to the baseline version at time 3, then the OTA master control program on the vehicle side needs to restore the content of the baseline upgrade at time 2 and the content of the baseline upgrade at time 3, so the OTA master control program on the vehicle side needs to distribute the following upgrade packages to the corresponding ECUs of the vehicle for upgrade in sequence: dts3, dts4, dts5. After this operation, the baseline version of the vehicle parts is restored to the baseline version corresponding to time 3.

[0124] This embodiment provides a method for managing vehicle computer software versions. When the update operation is version restoration, a version baseline for the version restoration is obtained according to the update instruction; the version baseline is analyzed to obtain an analysis result; and according to the analysis result, the version of the vehicle computer parts is restored using a corresponding update method, thereby improving the flexibility of software version management.

[0125] Based on the third embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the third embodiment can be referred to the above introduction, and will not be described in detail later. Figure 8 Step S203' includes steps B31-B32:

[0126] Step B31, when the analysis result is consistent with the local version, determine that the update method is the local restoration method, and use the local restoration method to restore the version of the vehicle machine parts.

[0127] When the analysis result is consistent with the local version, the local restore method is used, and the version is restored backward or forward according to the time node data.

[0128] In a feasible implementation manner, step B31 includes steps C10 to C30:

[0129] Step C10, when the analysis result is consistent with the local version, determine that the update mode is the local restore mode, and generate local task information according to the version baseline.

[0130] It should be noted that the local task information is the system task information generated when the version is restored using the local restore method, including the vehicle computer parts information that needs to be restored.

[0131] When the analysis result is consistent with the local version, the local restoration method is used. The time node data in the version baseline is matched with the version information in the local version record to obtain the software version information that needs to be traced back for this version restoration. Based on the software version information, the restoration method is determined to be version backward restoration or version forward restoration, and local task information is generated.

[0132] The local version record structure is as follows Fig. 9 The first-level subdirectory is the time of version upgrade. This directory mainly includes task information, part start package and part target package. Parallel to the first-level subdirectory is version_info, which is equivalent to a pointer, indicating which baseline version the system is currently in, that is, the current version information.

[0133] The task information describes the task of this upgrade, including task information, part information of this upgrade and task description. taskid, that is, task information is the information corresponding to the task id of the platform database. The part information of this upgrade includes part id, part starting package version number, part target package version number and other information. The task description is the content information updated in this upgrade. src_xxx.zip indicates the starting package of a part, that is, the update starting package, and dst_xxx.zip indicates the target package of a part, that is, the update target package.

[0134] Step C20, obtaining the vehicle computer parts that need to be flashed according to the local task information, and generating a task list according to the vehicle computer parts that need to be flashed.

[0135] It should be noted that the task list is the instruction information for the car-side OTA main control program to perform version restoration operations, including the version information of this version restoration.

[0136] According to the local task information, the vehicle computer parts that need to have their software versions replaced for this version restoration, that is, the vehicle computer parts that need to be flashed, are obtained, and a task list is generated.

[0137] Step C30, restoring the version of the vehicle machine parts that need to be flashed according to the task list.

[0138] According to the instruction information in the task list, the software version of the vehicle computer parts that need to be flashed will be restored to the historical version required by the user.

[0139] The timing diagram of restoration using local restoration is as follows: Fig.10 As shown, including:

[0140] Initiate version restore; confirm whether the corresponding version baseline is stored locally; return yes; generate local upgrade task information; return upgrade task; keep the vehicle power on; return command result; enter OTA mode; initiate part flash command (can be repeated to upgrade multiple parts); part flash progress; part flash completed; part flash successful; exit OTA mode.

[0141] The software version of the vehicle computer parts is restored by local restoration, thereby improving the flexibility of software version management.

[0142] Step B32, when the analysis result is not in compliance with the local version, determining that the update method is an online restoration method, and using the online restoration method to restore the version of the vehicle machine part.

[0143] When the analysis result is inconsistent with the local version, the online restore method is used, and the version is rolled back or forward restored according to the time node data.

[0144] In a feasible implementation manner, step B32 includes steps C01 to C05:

[0145] Step C01, when the analysis result is not consistent with the local version, determine that the update method is an online restoration method, and initiate an online version restoration application to the OTA cloud according to the version baseline, so that the OTA cloud provides feedback based on the online version restoration application.

[0146] It should be noted that the online version restoration application is an information query application sent by the OTA main control program on the vehicle side to the OTA cloud when the online restoration method is adopted, including the time node data of the version that needs to be backtracked.

[0147] When the analysis result is that it does not match the local version, it means that the software version information that needs to be backtracked for this version restoration is not stored in the local version directory. In this case, the version restoration is performed using the online restoration method. According to the time node data in the version baseline, an online version restoration application is initiated to the OTA cloud. The OTA cloud queries the software version information corresponding to the time node of the version that needs to be backtracked based on the online version restoration application, and feeds back to the OTA main control program on the vehicle side.

[0148] Step C02, obtaining the online version information fed back by the OTA cloud.

[0149] It should be noted that the online version information is the software version information corresponding to the time node of the version that needs to be traced back.

[0150] Step C03, obtaining online task information according to the online version information.

[0151] It should be noted that the online task information is the system task information generated when the version is restored using the online restoration method, including the vehicle computer parts information that needs to be restored.

[0152] Step C04, obtaining the vehicle computer parts that need to be flashed according to the online task information, and generating a task list according to the vehicle computer parts that need to be flashed.

[0153] It should be noted that the task list is the instruction information for the car-side OTA main control program to perform version restoration operations, including the version information of this version restoration.

[0154] According to the online task information, the vehicle computer parts that need to have their software versions replaced for this version restoration, that is, the vehicle computer parts that need to be flashed, are obtained, and a task list is generated.

[0155] Step C05, restoring the versions of the vehicle machine parts that need to be flashed according to the task list.

[0156] According to the instruction information in the task list, the software version of the vehicle computer parts that need to be flashed will be restored to the historical version required by the user.

[0157] The timing diagram of restoration using online restoration is as follows: Fig.11 As shown, including:

[0158] Initiate version restoration; confirm whether the corresponding version baseline is stored locally; return no; apply for version restoration; version restoration task information; download tasks and upgrade package files; transfer files and return download progress; return download progress in real time; download complete; keep the vehicle power On; return command results; enter OTA mode; initiate part flashing command (can be repeated to upgrade multiple parts); part flashing progress; part flashing completed; part flashing successful; exit OTA mode.

[0159] The software versions of vehicle computer parts are restored through online restoration, thereby improving the flexibility of software version management.

[0160] This embodiment provides a method for managing vehicle computer software versions. When the analysis result is consistent with the local version, the update method is determined to be a local restoration method, and the local restoration method is used to restore the version of the vehicle computer parts. When the analysis result is inconsistent with the local version, the update method is determined to be an online restoration method, and the online restoration method is used to restore the version of the vehicle computer parts, thereby restoring the software version of the vehicle computer parts to a specific time node and improving the flexibility of software version management.

[0161] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the vehicle software version management method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0162] This application also provides a vehicle software version management device, please refer to Fig.12 , the vehicle software version management device includes:

[0163] The instruction analysis module 10 is used to receive an update instruction and determine an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore.

[0164] The version update module 20 is used to update the version of the vehicle machine parts using a corresponding update method according to the update operation.

[0165] The version management module 30 is used to obtain the update start package and the update target package of the vehicle machine part after the version update is completed, and store the update start package and the update target package in the version record directory to complete the version management of the vehicle machine part.

[0166] The vehicle software version management device provided by the present application adopts the vehicle software version management method in the above embodiment, which can solve the technical problem of how to improve the flexibility and reliability of vehicle OTA software updates. Compared with the prior art, the beneficial effects of the vehicle software version management device provided by the present application are the same as the beneficial effects of the vehicle software version management method provided by the above embodiment, and the other technical features in the vehicle software version management device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0167] In one embodiment, the version update module 20 is also used to obtain the current version information of the vehicle parts and send it to the OTA cloud when the update operation is a normal upgrade, so that the OTA cloud can provide feedback based on the current version information; obtain the task information fed back by the OTA cloud; when the task information indicates that there is an upgrade task, obtain the vehicle parts corresponding to the upgrade task and upgrade the version of the vehicle parts; when the task information indicates that there is no upgrade task, stop upgrading the version of the vehicle parts.

[0168] In one embodiment, the version update module 20 is also used to obtain the version baseline of the version restoration according to the update instruction when the update operation is version restoration; analyze the version baseline to obtain an analysis result; and restore the version of the vehicle parts using a corresponding update method according to the analysis result; in one embodiment, the version update module 20 is also used to obtain the time node data of the version restoration according to the version baseline; match the time node data with the local version directory to obtain a matching result; when the matching result is a successful match, the analysis result is obtained to be compliant with the local version; when the matching result is a failed match, the analysis result is obtained to be inconsistent with the local version.

[0169] In one embodiment, the version update module 20 is also used to determine that the update method is a local restoration method when the analysis result is consistent with the local version, and use the local restoration method to restore the version of the vehicle machine parts; when the analysis result is not consistent with the local version, determine that the update method is an online restoration method, and use the online restoration method to restore the version of the vehicle machine parts.

[0170] In one embodiment, the version update module 20 is also used to determine that the update method is a local restoration method when the analysis result is consistent with the local version, and generate local task information according to the version baseline; obtain the vehicle parts that need to be flashed according to the local task information, and generate a task list according to the vehicle parts that need to be flashed; restore the version of the vehicle parts that need to be flashed according to the task list.

[0171] In one embodiment, the version update module 20 is further used to determine that the update method is an online restoration method when the analysis result is not consistent with the local version, and initiate an online version restoration application to the OTA cloud according to the version baseline, so that the OTA cloud provides feedback based on the online version restoration application; obtain the online version information fed back by the OTA cloud; obtain online task information according to the online version information; obtain the vehicle parts that need to be flashed according to the online task information, and generate a task list according to the vehicle parts that need to be flashed; and restore the version of the vehicle parts that need to be flashed according to the task list.

[0172] The present application provides a vehicle-machine software version management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the vehicle-machine software version management method in the above-mentioned embodiment one.

[0173] Reference below Fig.13, which shows a schematic diagram of the structure of a vehicle software version management device suitable for implementing the embodiment of the present application. The vehicle software version management device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.13 The vehicle software version management device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0174] like Fig.13 As shown, the vehicle software version management device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the vehicle software version management device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the vehicle software version management device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a vehicle software version management device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0175] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0176] The vehicle software version management device provided by this application adopts the vehicle software version management method in the above embodiment, which can solve the technical problem of how to improve the flexibility and reliability of vehicle OTA software updates. Compared with the prior art, the beneficial effects of the vehicle software version management device provided by this application are the same as the beneficial effects of the vehicle software version management method provided by the above embodiment, and the other technical features in the vehicle software version management device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0177] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0178] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0179] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the vehicle computer software version management method in the above-mentioned embodiment.

[0180] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0181] The computer-readable storage medium may be included in the vehicle-machine software version management device; or may exist independently without being assembled into the vehicle-machine software version management device.

[0182] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the vehicle-machine software version management device, the vehicle-machine software version management device: receives an update instruction, and determines an update operation according to the update instruction, and the update operation includes normal upgrade and version restoration; according to the update operation, adopts a corresponding update method to perform a version update of the vehicle-machine parts; after the version update is completed, obtains the update start package and the update target package of the vehicle-machine parts, and stores the update start package and the update target package in the version record directory to complete the version management of the vehicle-machine parts.

[0183] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0184] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0185] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0186] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned vehicle software version management method, and can solve the technical problem of how to improve the flexibility and reliability of vehicle OTA software updates. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the vehicle software version management method provided in the above-mentioned embodiment, and will not be repeated here.

[0187] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned vehicle software version management method when executed by a processor.

[0188] The computer program product provided by this application can solve the technical problem of how to improve the flexibility and reliability of vehicle OTA software updates. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the vehicle software version management method provided in the above embodiment, which will not be repeated here.

[0189] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A vehicle computer software version management method, characterized in that: The method comprises: receiving an update instruction, and determining an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore; According to the update operation, a corresponding update method is used to update the version of the vehicle computer parts; After the version update is completed, the update start package and the update target package of the vehicle machine part are obtained, and the update start package and the update target package are stored in the version record directory to complete the version management of the vehicle machine part.

2. The method according to claim 1, characterized in that The step of updating the version of the vehicle machine parts using a corresponding updating method according to the updating operation includes: When the update operation is a normal upgrade, the current version information of the vehicle machine parts is obtained and sent to the OTA cloud, so that the OTA cloud provides feedback based on the current version information; Obtain the task information fed back by the OTA cloud; When the task information indicates that there is an upgrade task, obtaining the vehicle machine part corresponding to the upgrade task, and upgrading the version of the vehicle machine part; When the task information indicates that there is no upgrade task, the version upgrade of the vehicle machine component is stopped.

3. The method according to claim 1, characterized in that The step of updating the version of the vehicle machine parts using a corresponding updating method according to the updating operation includes: When the update operation is version restoration, obtaining a version baseline for the version restoration according to the update instruction; Analyze the version baseline to obtain analysis results; The version of the vehicle computer parts is restored using a corresponding update method according to the analysis result.

4. The method according to claim 3, characterized in that The step of analyzing the version baseline to obtain the analysis result includes: According to the version baseline, obtain the time node data of the version restoration; Match the time node data with the local version directory to obtain a matching result; When the matching result is successful, the analysis result is obtained as being consistent with the local version; When the matching result is a matching failure, the analysis result is obtained as not being consistent with the local version.

5. The method according to claim 3, characterized in that The step of restoring the version of the vehicle machine parts by using the corresponding update method according to the analysis result includes: When the analysis result is consistent with the local version, determining the update mode to be a local restoration mode, and using the local restoration mode to restore the version of the vehicle machine parts; When the analysis result is not in conformity with the local version, the update mode is determined to be an online restoration mode, and the version of the vehicle machine part is restored by using the online restoration mode.

6. The method according to claim 5, characterized in that When the analysis result is consistent with the local version, the step of determining the update mode as the local restoration mode, and restoring the version of the vehicle machine component by using the local restoration mode includes: When the analysis result is consistent with the local version, determining the update mode as the local restore mode, and generating local task information according to the version baseline; Obtaining vehicle computer parts that need to be flashed according to the local task information, and generating a task list according to the vehicle computer parts that need to be flashed; The versions of the vehicle machine parts that need to be flashed are restored according to the task list.

7. The method according to claim 5, characterized in that When the analysis result is that the local version is not consistent, the step of determining that the update method is an online restoration method, and restoring the version of the vehicle machine part by using the online restoration method includes: When the analysis result is that the local version is not in compliance, determining that the update mode is an online restoration mode, and initiating an online version restoration application to the OTA cloud according to the version baseline, so that the OTA cloud provides feedback based on the online version restoration application; Obtaining online version information of the OTA cloud feedback; Obtaining online task information according to the online version information; Obtaining vehicle computer parts that need to be flashed according to the online task information, and generating a task list according to the vehicle computer parts that need to be flashed; The versions of the vehicle machine parts that need to be flashed are restored according to the task list.

8. A vehicle software version management device, characterized in that: The device comprises: An instruction analysis module, used for receiving an update instruction and determining an update operation according to the update instruction, wherein the update operation includes a normal upgrade and a version restore; A version update module, used to update the version of the vehicle machine parts using a corresponding update method according to the update operation; The version management module is used to obtain the update start package and update target package of the vehicle machine part after the version update is completed, and store the update start package and the update target package in the version record directory to complete the version management of the vehicle machine part.

9. A vehicle software version management device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the vehicle software version management method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the vehicle computer software version management method according to any one of claims 1 to 7 are implemented.

Images