Vehicle-mounted software version management method and device, storage medium, electronic equipment and computer program product

Abstract

The embodiment of the invention provides a vehicle-mounted software version management method and device, a storage medium, electronic equipment and a computer program product. The method comprises the steps that at least one whole vehicle software version corresponding to all vehicles under a target vehicle system and a target vehicle set corresponding to the whole vehicle software version are obtained; comparing the whole vehicle software version with a plurality of preset main whole vehicle baseline versions; if the whole vehicle software version is aligned with the target main whole vehicle baseline version, recording the target main whole vehicle baseline version as a to-be-upgraded baseline version of the corresponding target vehicle set; and if the whole vehicle software version is not aligned with each main whole vehicle baseline version, creating the whole vehicle software version as a branch whole vehicle baseline version, and recording the branch whole vehicle baseline version as a to-be-upgraded baseline version of the target vehicle set corresponding to the whole vehicle software version. The corresponding upgrading strategy can be formulated by taking the to-be-upgraded baseline version corresponding to the target vehicle set as the reference, so that the upgrading efficiency of the vehicle-mounted software version is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data processing technology, and in particular to a method, device, storage medium, electronic device and computer program product for managing vehicle software versions. Background Art

[0002] In order to strengthen the collaborative management of software development during the life cycle of the vehicle, ensure that the vehicle status is controllable and the new version of the vehicle software is implemented in a timely manner, the vehicle manufacturer usually formulates the vehicle baseline version management. The vehicle baseline version management is to divide the vehicle controller software version into the vehicle baseline version according to the cycle. When the cycle node is reached, the baseline version is combined according to the currently released controller software versions, and this is used as a benchmark for the integration test and compatibility test of the vehicle. After the test is passed, the vehicle baseline version is released, and the vehicle can upgrade the vehicle software to the vehicle baseline version through OTA (Over-the-Air Technology).

[0003] At present, the on-board software versions of vehicles on the market are scattered, and the on-board software versions of vehicles are not all aligned with the baseline versions of the entire vehicle, which makes it difficult to formulate an upgrade strategy based on the baseline version of the entire vehicle, resulting in low efficiency in upgrading the on-board software versions of vehicles. Summary of the invention

[0004] In view of this, embodiments of the present application provide a method, device, storage medium, electronic device and computer program product for managing vehicle software versions to at least partially solve the above problems.

[0005] According to a first aspect of an embodiment of the present application, a method for managing vehicle software versions is provided, including: obtaining at least one vehicle software version corresponding to all vehicles under a target vehicle series and a target vehicle set corresponding to the vehicle software version; comparing the vehicle software version with a plurality of pre-set main vehicle baseline versions; if the vehicle software version is aligned with the target main vehicle baseline version, recording the target main vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version; if the vehicle software version is not aligned with any of the main vehicle baseline versions, creating a branch vehicle baseline version for the vehicle software version, and recording the branch vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

[0006] According to a second aspect of an embodiment of the present application, a vehicle-mounted software version management device is provided, comprising: an acquisition module, used to acquire at least one vehicle software version corresponding to all vehicles under a target vehicle series and a target vehicle set corresponding to the vehicle software version; a comparison module, used to compare the vehicle software version with a plurality of pre-set main vehicle baseline versions; a first upgrade module, used to record the target main vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version if the vehicle software version is aligned with the target main vehicle baseline version; and a second upgrade module, used to create a branch vehicle baseline version for the vehicle software version if the vehicle software version is not aligned with any of the main vehicle baseline versions, and record the branch vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

[0007] According to a third aspect of an embodiment of the present application, a computer storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described in the first aspect is implemented.

[0008] According to the fourth aspect of an embodiment of the present application, there is provided an electronic device, including a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform an operation corresponding to the method described in the first aspect.

[0009] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, comprising computer instructions, which instruct a computing device to perform operations corresponding to the method described in the first aspect.

[0010] The embodiments of the present application provide a vehicle-mounted software version management method, device, storage medium, electronic device and computer program product, wherein the vehicle-mounted software version management method includes: obtaining at least one vehicle software version corresponding to all vehicles under a target vehicle series and a target vehicle set corresponding to the vehicle software version; comparing the vehicle software version with a plurality of pre-set main vehicle baseline versions; if the vehicle software version is aligned with the target main vehicle baseline version, recording the target main vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version; if the vehicle software version is not aligned with any of the main vehicle baseline versions, creating a branch vehicle baseline version for the vehicle software version, and recording the branch vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version. Through the embodiments of the present application, all vehicles under the same vehicle series can be divided into multiple target vehicle sets, and the main vehicle baseline version or branch vehicle baseline version corresponding to each target vehicle set can be used as the baseline version to be upgraded. Therefore, when upgrading the on-board software version of the target vehicle series, the corresponding upgrade strategy can be directly formulated based on the baseline version to be upgraded corresponding to the target vehicle set, which is convenient and efficient; and each upgrade strategy can be applied in batches to all vehicles in the corresponding target vehicle set, thereby improving the efficiency of the vehicle-mounted software version upgrade. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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, the drawings described below are only some embodiments recorded in the embodiments of the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0012] Figure 1 A flowchart of a method for managing vehicle software versions according to an exemplary embodiment of the present application;

[0013] Figures 2A to 2C A schematic diagram for explaining the process of a vehicle software version management method according to an exemplary embodiment of the present application;

[0014] Figure 3 is a structural block diagram of a vehicle-mounted software version management device according to an exemplary embodiment of the present application;

[0015] Figure 4 It is a schematic structural diagram of an electronic device according to an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0016] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the embodiments of the present application should fall within the scope of protection of the embodiments of the present application.

[0017] Reference Figure 1 , shows a flowchart of a method for managing vehicle software versions according to an exemplary embodiment of the present application. As shown in the figure, this embodiment mainly includes the following steps:

[0018] S102: Obtain at least one vehicle software version corresponding to all vehicles in the target vehicle series and a target vehicle set corresponding to the vehicle software version.

[0019] For example, the target vehicle series can be any vehicle series on the market, and this embodiment does not limit this. All vehicles under the target vehicle series can correspond to one or more vehicle software versions, for example, Figure 2A , all vehicles under the target vehicle series may correspond to multiple vehicle software versions, namely, market vehicle ECU software version combination 1, market vehicle ECU software version combination 2, market vehicle ECU software version combination 3, market vehicle ECU software version combination 4, etc. Each vehicle software version corresponds to a target vehicle set, and the target vehicle set may include the number of vehicles, the proportion of the number of vehicles, the version information of the historical vehicle software versions of the vehicles, etc., which is not limited in this embodiment.

[0020] In an optional implementation, at least one vehicle software version corresponding to a vehicle in a target vehicle series and a target vehicle set corresponding to the vehicle software version are obtained, including: obtaining the latest vehicle software version of all vehicles in the target vehicle series; classifying the same latest vehicle software versions for the latest vehicle software versions of all vehicles in the target vehicle series to obtain at least one vehicle software version; and grouping all vehicles in the target vehicle series based on the vehicle software version to obtain a target vehicle set corresponding to the vehicle software version.

[0021] For example, the latest vehicle software versions of all vehicles in the target vehicle series are counted. The latest vehicle software version may include the ECU software version of the vehicle. The latest vehicle software versions of all vehicles are classified and the same latest vehicle software versions are grouped into one category to obtain one or more vehicle software versions, for example Figure 2AThe market vehicle ECU software version combination 1, market vehicle ECU software version combination 2, market vehicle ECU software version combination 3, market vehicle ECU software version combination 4, etc. Then, according to the obtained vehicle software version, all vehicles under the target vehicle series are grouped to obtain the target vehicle set corresponding to the vehicle software version, for example Figure 2A The target vehicle set may include the number of vehicles, the proportion of vehicles, the version information of the historical vehicle software version, the version status of the vehicle software version, etc., which is not limited in this embodiment.

[0022] In this implementation, for the latest vehicle software versions of all vehicles in the target vehicle series, the same latest vehicle software versions are classified to obtain at least one vehicle software version; based on the vehicle software version, all vehicles in the target vehicle series are grouped to obtain a target vehicle set corresponding to the vehicle software version, and by grouping and classifying the latest vehicle software versions of all vehicles in the target vehicle series and the corresponding vehicles, it is convenient to formulate subsequent batch upgrade strategies.

[0023] S104: Compare the vehicle software version with a plurality of pre-set master vehicle baseline versions respectively.

[0024] For example, the pre-set multiple master vehicle baseline versions can be vehicle baseline versions obtained by synchronizing the vehicle engineering baselines regularly released by the vehicle manufacturer. The vehicle baseline version is used to manage the ECU software version part number and related attached attributes of the vehicle under the target vehicle series. Each iteration of the vehicle baseline version represents a change maintenance. Figure 2A , the multiple main vehicle baseline versions may include vehicle baseline version A, vehicle baseline version B, vehicle baseline version C and vehicle baseline version G. Each vehicle software version is compared with the multiple pre-set main vehicle baseline versions one by one to obtain a comparison result. If the comparison result is that a certain vehicle software version is consistent with any of the multiple pre-set main vehicle baseline versions, it means that the vehicle software version is aligned with the consistent main vehicle baseline version (i.e., the target main vehicle baseline version). For example Figure 2A In the comparison, the market vehicle ECU software version combination 1 is aligned with the vehicle baseline version A, the market vehicle ECU software version combination 3 is aligned with the vehicle baseline version B, and the market vehicle ECU software version combination 4 is aligned with the vehicle baseline version C. If the comparison result shows that a certain vehicle software version is inconsistent with all the main vehicle baseline versions in multiple main vehicle baseline versions, it means that the vehicle software version is not aligned with the main vehicle baseline version. For example Figure 2A In the example, the baseline version status corresponding to the market vehicle ECU software version combination 2 is not aligned. Here, the comparison result can be used as the version status (i.e. Figure 2A The baseline version status in the software version is saved in the target vehicle set corresponding to the vehicle software version.

[0025] S106. If the vehicle software version is aligned with the target main vehicle baseline version, the target main vehicle baseline version is recorded as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

[0026] For example, if a vehicle software version is aligned with the target main vehicle baseline version, for example Figure 2A In the example, the market vehicle ECU software version combination 1 is aligned with the vehicle baseline version A, the market vehicle ECU software version combination 3 is aligned with the vehicle baseline version B, and the market vehicle ECU software version combination 4 is aligned with the vehicle baseline version C. Then the target main vehicle baseline version is recorded as the baseline version to be upgraded of the target vehicle set corresponding to the vehicle software version, that is, the vehicle baseline version A is the baseline version to be upgraded of the target vehicle set corresponding to the market vehicle ECU software version combination 1, the vehicle baseline version B is the baseline version to be upgraded of the target vehicle set corresponding to the market vehicle ECU software version combination 3, and the vehicle baseline version C is the baseline version to be upgraded of the target vehicle set corresponding to the market vehicle ECU software version combination 4, so that the corresponding upgrade strategy can be formulated based on the baseline version to be upgraded in the future to perform batch software upgrades on the vehicles in the target vehicle set.

[0027] S108. If the vehicle software version is not aligned with the main vehicle baseline versions, the vehicle software version is created as a branch vehicle baseline version, and the branch vehicle baseline version is recorded as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

[0028] For example, if a vehicle software version is not aligned with the baseline versions of all main vehicles, for example Figure 2A If the market vehicle ECU software version combination 2 is in the ECU software version list, the vehicle software version can be created as a branch vehicle baseline version, for example Figure 2A The branch baseline version X in the , and the branch vehicle baseline version is recorded as the baseline version to be upgraded of the target vehicle set corresponding to the vehicle software version, so that the baseline version to be upgraded can be used as the benchmark in the future, for example Figure 2A In the process, taking the branch baseline version X as the benchmark and the vehicle baseline version G (main vehicle baseline version) as the target, a corresponding upgrade strategy is formulated to perform batch software upgrades on the vehicles in the target vehicle collection corresponding to the branch vehicle baseline version.

[0029] Reference Figure 2B, vehicle engineering baselines released regularly by vehicle manufacturers, such as engineering baseline 1, engineering baseline 2, and engineering baseline 3. By synchronizing the vehicle engineering baselines, multiple corresponding main vehicle baseline versions can be obtained, such as vehicle baseline version 1, vehicle baseline version 2, and vehicle baseline version 3. Since the vehicle software versions of some vehicles are not aligned with the main vehicle baseline version, the unaligned vehicle software versions can be created as branch vehicle baseline versions, that is, between two adjacent main vehicle baseline versions, branch vehicle baseline versions can be created, such as branch baseline versions 1-1, 1-2, and 1-3 between vehicle baseline version 1 and vehicle baseline version 2, and branch baseline versions 2-1 and 2-2 between vehicle baseline version 2 and vehicle baseline version 3. The branch vehicle baseline version can be upgraded to the next main vehicle baseline version through the OTA upgrade strategy. For example, the branch baseline version 1-1, branch baseline version 1-2, and branch baseline version 1-3 between vehicle baseline version 1 and vehicle baseline version 2 can all be upgraded to vehicle baseline version 2, and the branch baseline version 2-1 and branch baseline version 2-2 between vehicle baseline version 2 and vehicle baseline version 3 can all be upgraded to vehicle baseline version 3. Furthermore, the branch vehicle baseline version can be upgraded across baselines through the OTA upgrade strategy. For example, the branch baseline version 1-1, branch baseline version 1-2, and branch baseline version 1-3 between vehicle baseline version 1 and vehicle baseline version 2 can all be upgraded to vehicle baseline version 3.

[0030] Through this embodiment, all vehicles under the same vehicle series can be divided into multiple target vehicle sets, and the main vehicle baseline version or branch vehicle baseline version corresponding to each target vehicle set can be used as the baseline version to be upgraded. Therefore, when upgrading the vehicle-mounted software version for the target vehicle series, the corresponding upgrade strategy can be directly formulated based on the baseline version to be upgraded corresponding to the target vehicle set, thereby improving the efficiency of specifying the upgrade strategy and realizing statistical analysis and vehicle baseline version management of scattered vehicle software versions; and each upgrade strategy can be applied in batches to all vehicles in the corresponding target vehicle set, thereby improving the efficiency of upgrading the vehicle-mounted software version.

[0031] In an optional implementation, after obtaining the latest vehicle software version of all vehicles under the target vehicle series, the method also includes: comparing the latest vehicle software version of each vehicle under the target vehicle series with the previous historical vehicle software version; if the comparison is inconsistent, determining the software change content based on the latest vehicle software version and the previous historical vehicle software version; determining the change reason corresponding to the software change content based on the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, the change reason including the first upgrade method or the second upgrade method.

[0032] Exemplarily, the method of this embodiment can be applied to the cloud, and the latest vehicle software version corresponding to the vehicle can be obtained from the vehicle. For example, the OTA application on the vehicle side can request the ECU software module signal collection list from the cloud regularly (such as every 24 hours); the OTA system on the cloud side sends the vehicle ECU software module signal collection list according to the vehicle model configuration; after receiving the ECU software module list, the OTA application on the vehicle side starts to collect the local ECU software module part numbers and reports them to the OTA system on the cloud; the OTA system on the cloud side receives all the ECU software version part numbers reported by the vehicle side, that is, obtains the latest vehicle software version corresponding to the vehicle. Here, the ECU software part number is used to represent the vehicle ECU module software version information, which can be used as the corresponding ECU software version mark.

[0033] Afterwards, all ECU software part numbers reported by the vehicle end this time are compared with all ECU software part numbers reported last time (i.e., the last historical vehicle software version): if the content is consistent, the result of this report can be ignored; if there is any change, all ECU software part numbers reported this time are saved, that is, the latest vehicle software version is saved, and the software change content of the latest vehicle software version compared to the last historical vehicle software version is calculated. Furthermore, the first acquisition time of the latest vehicle software version and the second acquisition time of the last historical vehicle software version can be determined, and the upgrade record between the first acquisition time and the second acquisition time can be queried. The upgrade record may include OTA upgrade tasks and upgrade content; according to the upgrade record, it can be determined that the change reason corresponding to the software change content is the first upgrade method or the second upgrade method. The first upgrade method can be OTA upgrade, and the second upgrade method can be offline flashing. The last historical vehicle software version can be the main vehicle baseline version.

[0034] In this implementation method, the latest vehicle software version of each vehicle under the target vehicle series is compared with the previous historical vehicle software version; if the comparison is inconsistent, the software change content is determined based on the latest vehicle software version and the previous historical vehicle software version; based on the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, the change reason corresponding to the software change content is determined, thereby realizing the identification of the change reason of the vehicle software version, which is convenient for the subsequent formulation of different upgrade strategies for different change reasons.

[0035] In an optional implementation, the change reason corresponding to the software change content is determined based on the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, including: obtaining the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version; if the upgrade record includes the first upgrade method and the corresponding upgrade content, comparing the upgrade content and the software change content, if the comparison is consistent, determining that the change reason corresponding to the software change content is the first upgrade method; if the comparison is inconsistent, or the upgrade record is empty, determining that the change reason corresponding to the software change content is the second upgrade method.

[0036] Exemplarily, after determining the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, query the upgrade record between the first acquisition time and the second acquisition time; if the upgrade record includes the first upgrade method and the corresponding upgrade content, that is, the upgrade record includes the OTA upgrade task and the corresponding upgrade content, then compare whether the upgrade content and the software change content are consistent. If the comparison is consistent, determine that the change reason corresponding to the software change content is the first upgrade method, that is, OTA upgrade; if the comparison is inconsistent, determine that the change reason corresponding to the software change content is the second upgrade method, that is, offline flashing. In addition, if the upgrade record is empty, it means that the vehicle was not OTA upgraded between the first acquisition time and the second acquisition time, then determine that the change reason corresponding to the software change content is the second upgrade method, that is, offline flashing.

[0037] In this implementation method, the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version is obtained; if the upgrade record includes the first upgrade method and the corresponding upgrade content, the upgrade content and the software change content are compared. If the comparison is consistent, the change reason corresponding to the software change content is determined to be the first upgrade method; if the comparison is inconsistent, or the upgrade record is empty, the change reason corresponding to the software change content is determined to be the second upgrade method, thereby realizing the identification of the change reason of the vehicle software version of the vehicle, thereby quickly screening out abnormal scenarios where the vehicle software version cannot be aligned with the main vehicle baseline version due to offline flashing (including after-sales replacement of vehicle controllers or abnormal flashing), which is convenient for subsequent upgrade strategy formulation.

[0038] In an optional implementation, the method of this embodiment also includes: obtaining version information of all historical vehicle software versions of the target vehicle under the target vehicle series, the version information including software change content, change time, change reason and version status, the version status is used to indicate the alignment of the historical vehicle software version with the pre-set main vehicle baseline version; determining the version information of the latest vehicle software version of the target vehicle; generating vehicle software version statistics of the target vehicle based on the version information of all historical vehicle software versions of the target vehicle and the version information of the latest vehicle software version.

[0039] For example, the target vehicle may be any vehicle in the target vehicle series. For the target vehicle, the version information of all historical vehicle software versions of the target vehicle is obtained, referring to Figure 2C , all historical vehicle software versions of the target vehicle may include ECU software version change history record 1, ECU software version change history record 2 and ECU software version change history record 3. The version information of each historical vehicle software version may include software change content, change time, change reason and version status. The version status is used to indicate the alignment of the historical vehicle software version with the preset main vehicle baseline version, for example Figure 2C The baseline status in the table includes aligned and unaligned. For example, ECU software version change history record 1 is aligned with vehicle baseline version 1, while ECU software version change history record 2 and ECU software version change history record 3 are not aligned. For unaligned historical vehicle software versions, the difference between the historical vehicle software version and the last aligned main vehicle baseline version can be obtained, and the unaligned historical vehicle software version can be created as a branch vehicle baseline version, for example Figure 2C Branch baseline version 1-1 in. Further, the version information of the latest vehicle software version of the target vehicle can also be determined, for example, the latest vehicle software version is ECU software version change history record 4, ECU software version change history record 4 is aligned with vehicle baseline version 2, and the vehicle software version statistics of the target vehicle are generated based on the version information of all historical vehicle software versions of the target vehicle and the version information of the latest vehicle software version. The vehicle software version statistics of the target vehicle can be displayed in any way, for example Figure 2C shown.

[0040] In this implementation, the corresponding vehicle software version statistics can be generated for the target vehicle. By collecting statistics on the change history of the vehicle software version of a single vehicle, an efficient strategy for aligning the vehicle baseline version of the single vehicle can be formulated.

[0041] In an optional implementation, the method of this embodiment also includes: generating vehicle baseline version statistics for the target vehicle series based on at least one vehicle software version under the target vehicle series, the target vehicle set corresponding to the vehicle software version, and the baseline version to be upgraded of the target vehicle set, wherein the target vehicle set corresponding to the vehicle software version includes the number of vehicles and the proportion of the number of vehicles corresponding to the vehicle software version.

[0042] Exemplarily, at least one vehicle software version under the target vehicle series, a target vehicle set corresponding to the vehicle software version, and a baseline version to be upgraded of the target vehicle set can be obtained, wherein the target vehicle set corresponding to the vehicle software version includes the number of vehicles and the proportion of the number of vehicles corresponding to the vehicle software version, and the statistical results of the vehicle baseline version of the target vehicle series are generated and displayed, for example Figure 2A Furthermore, the vehicle baseline version statistics may also include the version status of the vehicle software version, etc., which is not limited in this embodiment.

[0043] This implementation method generates statistics on the whole vehicle baseline version of the target vehicle series based on at least one whole vehicle software version under the target vehicle series, the target vehicle set corresponding to the whole vehicle software version, and the baseline version to be upgraded of the target vehicle set. It can quickly count the whole vehicle software versions and whole vehicle baseline versions of all vehicles in the market, efficiently support upgrade operation decisions, and improve the efficiency of formulating upgrade strategies for the scattered vehicle software versions in the market.

[0044] Reference Figure 3 , shows a structural block diagram of a vehicle-mounted software version management device according to an exemplary embodiment of the present application.

[0045] The vehicle-mounted software version management device of this embodiment includes an acquisition module 302 , a comparison module 304 , a first upgrade module 306 and a second upgrade module 308 .

[0046] Among them, the acquisition module 302 is used to obtain at least one vehicle software version corresponding to all vehicles under the target vehicle series and the target vehicle set corresponding to the vehicle software version; the comparison module 304 is used to compare the vehicle software version with multiple pre-set main vehicle baseline versions respectively; the first upgrade module 306 is used to record the target main vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version if the vehicle software version is aligned with the target main vehicle baseline version; the second upgrade module 308 is used to create the vehicle software version as a branch vehicle baseline version if the vehicle software version is not aligned with each main vehicle baseline version, and record the branch vehicle baseline version as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

[0047] In an optional implementation, the acquisition module 302 is also used to: obtain the latest vehicle software version of all vehicles in the target vehicle series; classify the same latest vehicle software version for the latest vehicle software version of all vehicles in the target vehicle series to obtain at least one vehicle software version; based on the vehicle software version, group all vehicles in the target vehicle series to obtain a target vehicle set corresponding to the vehicle software version.

[0048] In an optional implementation, the device of this embodiment also includes an identification module, which is used to: compare the latest vehicle software version of each vehicle under the target vehicle series with the previous historical vehicle software version; if the comparison is inconsistent, determine the software change content based on the latest vehicle software version and the previous historical vehicle software version; determine the change reason corresponding to the software change content based on the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, and the change reason includes the first upgrade method or the second upgrade method.

[0049] In an optional implementation, the identification module is also used to: obtain the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version; if the upgrade record includes the first upgrade method and the corresponding upgrade content, then compare the upgrade content and the software change content. If the comparison is consistent, then determine that the change reason corresponding to the software change content is the first upgrade method; if the comparison is inconsistent, or the upgrade record is empty, then determine that the change reason corresponding to the software change content is the second upgrade method.

[0050] In an optional implementation, the device of this embodiment also includes a statistical module, which is used to: obtain version information of all historical vehicle software versions of the target vehicle under the target vehicle series, the version information including software change content, change time, change reason and version status, the version status is used to indicate the alignment of the historical vehicle software version with the pre-set main vehicle baseline version; determine the version information of the latest vehicle software version of the target vehicle; generate vehicle software version statistics of the target vehicle based on the version information of all historical vehicle software versions of the target vehicle and the version information of the latest vehicle software version.

[0051] In an optional implementation, the statistical module is also used to generate statistical results of the whole vehicle baseline version of the target vehicle series based on at least one whole vehicle software version under the target vehicle series, the target vehicle set corresponding to the whole vehicle software version, and the baseline version to be upgraded of the target vehicle set. The target vehicle set corresponding to the whole vehicle software version includes the number of vehicles corresponding to the whole vehicle software version and the proportion of the number of vehicles.

[0052] The vehicle software version management device of this embodiment is used to implement the corresponding vehicle software version management method in the aforementioned multiple method embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here. In addition, the functional implementation of each module in the vehicle software version management device of this embodiment can refer to the description of the corresponding parts in the aforementioned method embodiments, which will not be repeated here.

[0053] Reference Figure 4 , shows a schematic diagram of the structure of an electronic device according to an exemplary embodiment of the present application. The specific embodiment of the present invention does not limit the specific implementation of the electronic device.

[0054] like Figure 4 As shown, the electronic device may include: a processor (processor) 401, a memory (memory) 403, a communication bus (communication bus) 404, and a communication interface (Communications Interface) 405.

[0055] Wherein: the processor 401 , the memory 403 and the communication interface 405 communicate with each other via the communication bus 404 .

[0056] The communication interface 405 is used to communicate with other electronic devices or servers.

[0057] The processor 401 is used to execute the program 402, and specifically can execute the steps of any one of the vehicle software version management methods in the above embodiments.

[0058] Specifically, the program 402 may include program codes, which include computer operation instructions.

[0059] The processor 401 may be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs; or may be processors of different types, such as one or more CPUs and one or more ASICs.

[0060] The memory 403 is used to store the program 402. The memory 403 may include a high-speed RAM memory, and may also include a non-volatile memory, such as at least one disk memory.

[0061] The program 402 can be specifically used to enable the processor 401 to execute to implement the steps of any vehicle software version management method described in the embodiment. The specific implementation of each step in the program 402 can refer to the corresponding description of the steps and units executed by any vehicle software version management method in the above steps, and will not be repeated here. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described devices and modules can refer to the corresponding process description in the above-mentioned method embodiment.

[0062] An embodiment of the present application also provides a computer storage medium on which a computer program is stored. When the program is executed by a processor, the vehicle-mounted software version management method described in any one of the above-mentioned multiple method embodiments is implemented.

[0063] An embodiment of the present application also provides a computer program product, including computer instructions, which instruct a computing device to execute operations corresponding to the vehicle software version management method described in any one of the above-mentioned multiple method embodiments.

[0064] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0065] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded through a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an AS IC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown here, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown here.

[0066] Those of ordinary skill in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present application.

[0067] The above implementation methods are only used to illustrate the embodiments of the present application, and are not limitations on the embodiments of the present application. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the spirit and scope of the embodiments of the present application. Therefore, all equivalent technical solutions also belong to the scope of the embodiments of the present application. The scope of patent protection of the embodiments of the present application should be limited by the claims.

Claims

1. A vehicle software version management method, characterized in that: include: Obtain at least one vehicle software version corresponding to all vehicles in the target vehicle series and a target vehicle set corresponding to the vehicle software version; Comparing the vehicle software version with a plurality of pre-set master vehicle baseline versions respectively; If the vehicle software version is aligned with the target main vehicle baseline version, the target main vehicle baseline version is recorded as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version; If the vehicle software version is not aligned with the main vehicle baseline versions, the vehicle software version is created as a branch vehicle baseline version, and the branch vehicle baseline version is recorded as the baseline version to be upgraded for the target vehicle set corresponding to the vehicle software version.

2. The vehicle software version management method according to claim 1, characterized in that: The obtaining of at least one vehicle software version corresponding to a vehicle under a target vehicle series and a target vehicle set corresponding to the vehicle software version includes: Obtain the latest vehicle software version for all vehicles in the target vehicle series; For the latest vehicle software versions of all vehicles under the target vehicle series, classify the same latest vehicle software versions to obtain at least one vehicle software version; Based on the vehicle software version, all vehicles under the target vehicle series are grouped to obtain a target vehicle set corresponding to the vehicle software version.

3. The vehicle software version management method according to claim 2, characterized in that: After obtaining the latest vehicle software version of all vehicles in the target vehicle series, the method further includes: Compare the latest vehicle software version of each vehicle under the target vehicle series with the previous historical vehicle software version; If the comparison is inconsistent, the software change content is determined according to the latest vehicle software version and the previous historical vehicle software version; According to the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, the change reason corresponding to the software change content is determined, and the change reason includes the first upgrade method or the second upgrade method.

4. The vehicle software version management method according to claim 3, characterized in that: The determining, according to the upgrade record between the first acquisition time of the latest vehicle software version and the second acquisition time of the previous historical vehicle software version, the change reason corresponding to the software change content includes: Obtaining an upgrade record between a first acquisition time of the latest vehicle software version and a second acquisition time of the previous historical vehicle software version; If the upgrade record includes a first upgrade method and corresponding upgrade content, compare the upgrade content with the software change content, and if the comparison is consistent, determine that the change reason corresponding to the software change content is the first upgrade method; If the comparison is inconsistent, or the upgrade record is empty, it is determined that the change reason corresponding to the software change content is the second upgrade method.

5. The vehicle software version management method according to claim 4, characterized in that: The method further comprises: Obtaining version information of all historical vehicle software versions of the target vehicle under the target vehicle series, wherein the version information includes software change content, change time, change reason, and version status, wherein the version status is used to indicate whether the historical vehicle software version is aligned with the preset main vehicle baseline version; Determine the version information of the latest vehicle software version of the target vehicle; The vehicle software version statistics of the target vehicle are generated based on the version information of all historical vehicle software versions of the target vehicle and the version information of the latest vehicle software version.

6. The vehicle software version management method according to claim 1, characterized in that: The method further comprises: According to at least one vehicle software version under the target vehicle series, the target vehicle set corresponding to the vehicle software version and the baseline version to be upgraded of the target vehicle set, the vehicle baseline version statistics of the target vehicle series are generated. The target vehicle set corresponding to the vehicle software version includes the number of vehicles corresponding to the vehicle software version and the proportion of the number of vehicles.

7. A vehicle-mounted software version management device, characterized in that: include: An acquisition module, used to acquire at least one vehicle software version corresponding to all vehicles in a target vehicle series and a target vehicle set corresponding to the vehicle software version; A comparison module, used for comparing the vehicle software version with a plurality of pre-set master vehicle baseline versions respectively; A first upgrade module is used for recording the target main vehicle baseline version as the to-be-upgraded baseline version of the target vehicle set corresponding to the vehicle software version if the vehicle software version is aligned with the target main vehicle baseline version; The second upgrade module is used to create the whole vehicle software version as a branch whole vehicle baseline version if the whole vehicle software version is not aligned with the main whole vehicle baseline versions, and record the branch whole vehicle baseline version as the baseline version to be upgraded of the target vehicle set corresponding to the whole vehicle software version.

8. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform an operation corresponding to the method according to any one of claims 1 to 6.

9. A computer storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The method comprises computer instructions, wherein the computer instructions instruct a computing device to execute operations corresponding to the method according to any one of claims 1 to 6.

Images