Software upgrading method and system, vehicle, server and computer program product

Abstract

The invention provides a software upgrading method, a software upgrading system, a vehicle, a server and a computer program product. The software upgrading method comprises the following steps: determining a plurality of intermediate version numbers through which software needs to be upgraded from a current version number to a target version number; determining a relay version number and a dependency version number in the plurality of intermediate version numbers; determining a software upgrading path according to the determined version sequence of the relay version number and the dependency version number; and upgrading the software from the current version number to the target version number according to the software upgrading path.

Description

Technical Field

[0001] The present disclosure relates to the field of software, and in particular to a software upgrade method, a software upgrade system, a vehicle, a server, and a computer program product. Background Art

[0002] Software needs to be upgraded for reasons such as function upgrades, bug fixes, or error corrections. During the software upgrade process, a large number of software versions will appear. If the upgrade is not performed in a timely manner, it may take multiple versions of software to upgrade from the current version of the software to the latest version of the software. At this time, it is easy to fail to upgrade successfully. If the multiple versions of the software are upgraded one by one, it will take a lot of upgrade time. Especially during the vehicle software upgrade process, if the upgrade fails, maintenance personnel need to upgrade remotely or the vehicle needs to be driven to a maintenance point. Summary of the invention

[0003] The present disclosure provides a software upgrade method, a software upgrade system, a vehicle, a server, and a computer program product.

[0004] According to one aspect of the present disclosure, a software upgrade method is provided, comprising: determining a plurality of intermediate version numbers that the software needs to go through to upgrade from a current version number to a target version number; determining a relay version number and a dependent version number from the plurality of intermediate version numbers, wherein the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process, the relay version number is configured before the software upgrade, the relay version number is used to limit the number of versions crossed during each software upgrade process, the dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number; determining a software upgrade path according to the determined version sequence of the relay version number and the dependent version number; and upgrading the software from the current version number to the target version number according to the software upgrade path.

[0005] According to the technical solution disclosed in the present invention, the relay version number and the dependent version number are determined during the software upgrade process, and then the software upgrade path is determined based on the relay version number and the dependent version number. This can avoid the problem of the software failing to upgrade successfully, and can also avoid the problem of upgrading the software of each intermediate version number one by one.

[0006] According to the software upgrade method of at least one embodiment of the present disclosure, determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: selecting M intermediate version numbers from the multiple intermediate version numbers as the M relay version numbers, M≥1.

[0007] According to the software upgrade method of at least one embodiment of the present disclosure, starting from the current version number, M intermediate version numbers are selected from the intermediate version numbers based on an interval value N as the M relay version numbers, wherein the interval value N is the number of versions allowed to be crossed during each software upgrade process, 1≤N≤5.

[0008] According to the software upgrade method of at least one embodiment of the present disclosure, based on the M relay version numbers, the current version to the target version is divided into M+1 upgrade intervals, each upgrade interval includes N intermediate version numbers, where 1≤N≤5.

[0009] According to the software upgrade method of at least one embodiment of the present disclosure, when M=1, the current version number to the target version number is divided into two upgrade intervals, wherein the first upgrade interval is an upgrade interval formed by the current version number and the relay version number, and the second upgrade interval is an upgrade interval formed by the relay version number and the target version number.

[0010] According to the software upgrade method of at least one embodiment of the present disclosure, when M≥2, the current version number to the target version number is divided into M+1 upgrade intervals, wherein the first upgrade interval is the upgrade interval formed by the current version number and the first relay version number, the last upgrade interval is the upgrade interval formed by the last relay version number and the target version number, and the intermediate upgrade interval between the first upgrade interval and the last upgrade interval is the upgrade interval formed by adjacent relay version numbers.

[0011] According to a software upgrade method of at least one embodiment of the present disclosure, determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: determining whether the dependent version number is included in each upgrade interval in the M+1 upgrade intervals.

[0012] According to the software upgrade method of at least one embodiment of the present disclosure, when a dependent version number is determined among the multiple intermediate version numbers, a software upgrade path is generated according to the determined version sequence of the relay version number and the dependent version number; when the dependent version number is not determined among the multiple intermediate version numbers, the software upgrade path is generated according to the determined version sequence of the relay version number.

[0013] According to another aspect of the present disclosure, a software upgrade system is provided, the software upgrade system includes a processor and a memory, the memory stores a computer program, when the computer program is executed by the processor, the processor performs the following process: determining a plurality of intermediate version numbers that the software needs to go through to upgrade from a current version number to a target version number; determining a relay version number and a dependent version number among the plurality of intermediate version numbers, wherein the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process, the relay version number is configured before the software upgrade, the relay version number is used to limit the number of versions crossed during each software upgrade process, the dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number; and determining a software upgrade path according to the determined version sequence of the relay version number and the dependent version number, the software upgrade path being used to upgrade the software from the current version number to the target version number.

[0014] According to yet another aspect of the present disclosure, a vehicle is provided, comprising the software upgrade system as described above.

[0015] According to yet another aspect of the present disclosure, a server is provided, comprising the software upgrade system as described above.

[0016] According to another aspect of the present disclosure, a computer program product is provided, characterized in that the computer program product comprises a computer program, and when the computer program is executed by a processor, it is used to implement at least any one of the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings illustrate exemplary embodiments of the present disclosure and together with the description serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0018] Figure 1 It is a schematic flowchart of an upgrade path generation method according to an embodiment of the present disclosure.

[0019] Figure 2 is a schematic diagram illustrating software versions according to an embodiment of the present disclosure.

[0020] Figure 3 is a schematic diagram illustrating software versions according to another embodiment of the present disclosure.

[0021] Figure 4 It is a schematic flowchart of an upgrade path generation method according to an embodiment of the present disclosure.

[0022] Figure 5 It is a schematic flowchart of an upgrade path generation method according to an embodiment of the present disclosure.

[0023] Figure 6 is a schematic diagram illustrating software versions according to another embodiment of the present disclosure.

[0024] Figure 7 It is an interactive schematic diagram of an upgrade method according to an embodiment of the present disclosure.

[0025] Figure 8 It is a schematic block diagram of the structure of an upgrade path generation system according to an embodiment of the present disclosure.

[0026] Fig. 9 is a schematic block diagram of an upgrading system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] The present disclosure is further described in detail below in conjunction with the accompanying drawings and examples. It is understood that the specific examples described herein are only used to explain the relevant content, rather than to limit the present disclosure. It should also be noted that, for ease of description, only the parts related to the present disclosure are shown in the accompanying drawings.

[0028] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure can be combined with each other. The technical solution of the present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0029] During the use of software, software development companies will release many software versions over time to upgrade functions, fix vulnerabilities, etc. During the use of software, if the user does not upgrade the software in time, there may be many versions between the current version of the software and the latest version of the software. If they are upgraded one by one, it will take a lot of time. If too many versions are skipped during the upgrade process, it will become difficult to troubleshoot the problem after the upgrade problem occurs. Therefore, in order to be able to stably upgrade the current version of the software to the latest version of the software, and to facilitate troubleshooting when problems arise, the inventors of the present disclosure have proposed the following technical solutions after in-depth research.

[0030] For vehicle software, if the user does not upgrade the vehicle software in time, there may be a gap of multiple versions between the current version of the software and the latest version of the software. In this case, the user usually cannot upgrade by himself, and can only upgrade through the staff of the car company, or the user upgrades the vehicle software one by one until it is upgraded to the latest version of the software. In order to save the time cost and manpower cost of vehicle upgrades, the present disclosure uses the dependent version and the relay version together, so that the user can upgrade the software by himself, and during the upgrade process, the staff of the car company can easily find and solve the problem.

[0031] In order to facilitate understanding of the contents of the embodiments of the present disclosure, some technical terms used in the embodiments of the present disclosure are described below.

[0032] Intermediate versions and intermediate version numbers: Intermediate versions refer to the software versions between the current version and the latest version (or target version), and the intermediate version numbers are the version numbers of these software versions.

[0033] Relay version and relay version number: Relay version is one or some versions in the intermediate version, which can also be called "operation bridge" version. The version number of the relay version software is the relay version number. The relay version number can be used to limit the number of software versions that the upgrade spans. For example, in order to test the success rate of software upgrade, some software in the intermediate version is set as relay version software. After the development of a certain latest version of software is completed, the software tester needs to test the software. Based on the considerations of testing cost and testers, the upgrade success rate of the software before the latest software directly upgraded to the latest software will be tested during the testing process. For example, if the version number of the latest software is n, the tester will test the upgrade success rate of version numbers n-x to n, and will not test the software with a version number lower than nx. Accordingly, the software with a version number lower than nx cannot be directly upgraded to the latest software. In this way, the relay version can be set according to the test situation. During the upgrade process, you must upgrade to the software with the relay version number before you can upgrade to the software after it.

[0034] Dependent version and dependent version number: Dependent version can also be called "technical bridge" version. Dependent version can be a software version that cannot be crossed during the software upgrade process due to various reasons. The software version number of the dependent version is the dependent version number. For example, a software version that upgrades the hardware and configuration of the running software can be used as a dependent version. For example, if a piece of hardware is replaced and the configuration of the hardware is upgraded in a certain upgraded software version, then the software version can be a dependent version. For example, due to compatibility issues, the changes between software versions are very large, resulting in serious incompatibility issues between the new and old versions. For example, a certain version changes the data format, etc. During the software upgrade process, you must first upgrade to the dependent version before you can upgrade to the software version after the dependent version.

[0035] According to an embodiment of the present disclosure, a software upgrade method is provided. In the software upgrade method, the software needs to be upgraded from a current version number to a target version number, and there are multiple intermediate version numbers between the current version number and the target version number. The current version number refers to the starting software version number in the cross-version software upgrade process. The target version number can be, for example, the latest version number. Figure 1 FIG. 1 is a flow chart showing a software upgrade method according to an embodiment of the present disclosure. Figure 1As shown, the method may include steps S110 to S140.

[0036] In step S110, multiple intermediate version numbers that the software needs to go through to upgrade from the current version number to the target version number are determined. Each version of the software can be stored in a software server or a software management platform. By obtaining the current version number being used by the device, multiple intermediate version numbers between the current version number and the target version number are obtained. Each version of the software can be stored in a server or a software management platform. In the process of obtaining the intermediate version number between the current version number and the target version number of the software, it can be obtained by querying the server or the software management platform.

[0037] In step S120, a relay version number and a dependent version number are determined from a plurality of intermediate version numbers. In the present disclosure, the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process. During the software upgrade process, if the intermediate version number includes the relay version number, it is necessary to first upgrade to the relay version number before continuing the upgrade. If the dependent version number is included, it is also necessary to first upgrade to the dependent version number before continuing the upgrade. The relay version number is configured before the software is upgraded. The relay version number is used to limit the number of versions crossed during each software upgrade. The dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number.

[0038] like Figure 2 As shown, it is a schematic diagram of various software version numbers in the process of upgrading the software from software version number 1.3 (current version number) to software version number 1.9 (target version number). Figure 2 The content shown is only exemplary and does not constitute a limitation of the present disclosure. All intermediate version numbers between the current version number 1.3 and the target version number 1.9 are obtained. Figure 2 In the example of , these intermediate version numbers include intermediate version number 1.4, intermediate version number 1.5, intermediate version number 1.6, intermediate version number 1.7, and intermediate version number 1.8. The relay version number and the dependent version number are determined in these intermediate version numbers. Figure 2 In the example, the relay version number is configured before the software is upgraded. For example, M intermediate version numbers are selected from multiple intermediate version numbers as M relay version numbers, M ≥ 1. Figure 2In the embodiment, two relay version numbers are set in the intermediate version numbers from the current version number 1.3 to the target version number 1.9, namely, the intermediate version number 1.5 and the intermediate version number 1.7 as the relay version numbers. Further, in the present disclosure, the relay version number can be set based on the interval value. As an example, M intermediate version numbers are selected from the intermediate version numbers based on the interval value N as M relay version numbers, where the interval value N is the number of versions allowed to be crossed during each software upgrade, 1≤N≤5. For adjacent relay version numbers, the value of the interval value N can be the same or different.

[0039] Since the dependent version number is a version number that cannot be crossed during the software development process, the dependent version number can be directly confirmed from multiple intermediate version numbers. According to a preferred embodiment of the present disclosure, in the process of determining the relay version number and the dependent version number from multiple intermediate version numbers, the relay version number can be determined first, and then the dependent version number can be determined. As an example, it can be determined whether the dependent version number exists between adjacent relay version numbers.

[0040] Based on M relay version numbers, the current version to the target version is divided into M+1 upgrade intervals, each of which includes N intermediate version numbers, where 1≤N≤5. In the case of M=1, the current version number to the target version number is divided into 2 upgrade intervals, where the first upgrade interval is the upgrade interval formed by the current version number and the relay version number, and the second upgrade interval is the upgrade interval formed by the relay version number and the target version number. In the case of M≥2, the current version number to the target version number is divided into M+1 upgrade intervals, where the first upgrade interval is the upgrade interval formed by the current version number and the first relay version number, the last upgrade interval is the upgrade interval formed by the last relay version number and the target version number, and the intermediate upgrade interval between the first upgrade interval and the last upgrade interval is the upgrade interval formed by adjacent relay version numbers. In the M+1 upgrade intervals, determine whether the dependent version number is included in each upgrade interval.

[0041] The technical solution disclosed in the present invention avoids upgrading one by one according to the intermediate version numbers between the current version number and the target version number during the cross-version software upgrade process, which can save upgrade time, etc. The technical solution disclosed in the present invention also avoids upgrading directly from the current software to the latest software, in which case it is easy to fail to upgrade. For example, if the vehicle software upgrade fails, the vehicle maintenance personnel may need to intervene, which brings great manpower costs.

[0042] After the software development is completed, the tester selects the relay version number based on the relay interval value to test the software upgrade, which greatly reduces the testing pressure. During the software upgrade process, the user determines the relay version number software according to the relay interval value during the test, and then determines the upgrade path for the upgrade, which can ensure the upgrade success rate and avoid the situation where the upgrade fails. By setting the relay version number, during the software testing process, the tester does not need to test the success rate of upgrading any software before the latest software to the latest software. It only needs to set the relay version number, divide the software version by the relay version number, and perform interval testing. In this way, the testing pressure is greatly reduced and the success rate of subsequent software upgrades is guaranteed.

[0043] In step S130, a software upgrade path is generated according to the determined version order of the relay version number and the dependent version number. The determined relay version number and the dependent version number can be sorted according to the upgrade order, and the sorted version numbers are used as the upgrade order of the software version number, so as to obtain the software upgrade path. In the present disclosure, the intermediate version number includes the relay version number, but for the dependent version number, there may be a case where it is not included. Therefore, according to a further scheme of the present disclosure. In the case where the dependent version number is determined among multiple intermediate version numbers, the software upgrade path is generated according to the determined version order of the relay version number and the dependent version number. In the case where the dependent version number is not determined among multiple intermediate version numbers, the software upgrade path is generated according to the determined version order of the relay version number.

[0044] In step S140, the software can be upgraded from the current version number to the target version number according to the software upgrade path. During the upgrade process, the relay version number and the dependent version number in the software upgrade path are version numbers that cannot be crossed during the upgrade process, that is, according to the upgrade sequence, the software must first be upgraded to the relay version number or the dependent version number before the subsequent upgrade can be continued. This will be described in detail below.

[0045] According to this embodiment of the present disclosure, the method of upgrading one by one according to the intermediate version number during the software upgrade process can be avoided, saving upgrade time, etc. In addition, when the software upgrade fails, the failure cause can be easily found, thereby saving software maintenance costs, etc. This will be described in detail below.

[0046] The technical solution of the present disclosure will be described in detail below with specific examples. The specific examples of the present disclosure are only for illustrative purposes rather than limiting purposes, so that those skilled in the art can better understand the technical ideas of the present disclosure. It should be understood that the technical solution of the present disclosure can also be applied to software upgrades in other scenarios.

[0047] As an example, the technical solution of the present disclosure may be applied to remote upgrade (FOTA) of vehicle software. Figure 3 FIG. 2 shows a flow chart of a method for upgrading vehicle software according to this embodiment. Figure 3 As shown, the upgrade path generation method may include steps S310 to S350. The vehicle software herein may be the whole vehicle software or software for a certain component.

[0048] In step S310, the current version number of the vehicle software is determined. In this step, in the process of determining the current version number of the vehicle software, the server can determine the current version number of the software being used by the vehicle from the previously received vehicle information, or request the vehicle to send the current version number of the software being used.

[0049] In step S320, multiple intermediate version numbers that the vehicle software needs to go through to upgrade from the current version number to the target version number are determined. The current version number refers to the starting version number in the cross-version software upgrade process, and the target version number refers to the target version number of the target software to be upgraded to in the cross-version software upgrade process, such as the version number of the latest software. Each version of the software can be stored in a server or a software management platform. In the process of determining the intermediate version number, all intermediate version numbers upgraded from the current version number to the target version number can be queried.

[0050] like Figure 2 As shown, the vehicle software needs to be upgraded from software version number 1.3 to software version number 1.9 as an example. All intermediate version numbers between the current version number 1.3 and the target version number 1.9 are obtained, including software version number 1.4, software version number 1.5, software version number 1.6, software version number 1.7, and software version number 1.8.

[0051] In step S330, a relay version number and a dependent version number are determined from the multiple intermediate version numbers. As described above, the relay version number can be the intermediate version numbers confirmed as relay version numbers according to the relay interval value, and the dependent version number is the version number that cannot be upgraded during the software development process.

[0052] According to a preferred embodiment of the present disclosure, the relay version number may be determined first, and then the dependent version number may be determined. Figure 4 A schematic flow chart of this embodiment is shown.

[0053] In step S331, the relay interval value N is determined. In the present disclosure, the value of N can be 1 to 5, and the value range of N can be determined according to the software testing situation. Preferably, N=1 or N=2. The relay interval value N is the number of intermediate version numbers between adjacent relay version numbers (including between the current version number and the first relay version number, and between the last relay version number and the target version number). The software testing situation can be a test conducted by the tester on whether the software upgrade can be successfully performed before the software is released. For example, when the value of N is 1, the tester has completed the software testing when the relay interval value is 1, and confirmed that in this case, the software can be successfully upgraded.

[0054] In step S332, the relay version number of the vehicle software is determined. M relay version numbers are determined in the intermediate version software, where M≥1. The number of M depends on the relay interval value N and the number of intermediate version numbers from the current version number to the target version number. In the present disclosure, the relay version number can be determined based on the relay interval value N and the current version number. If N=1, a relay version number is set for every other version number starting from the current version number until the number of version numbers between the last relay version number and the target version number is less than N. Figure 2 The figure shows the case where N is 1, that is, there is a software version number 1.4 between the first relay version number 1.5 and the current version number 1.3, an intermediate version number 1.6 between the relay version number 1.5 and the relay version number 1.7, and an intermediate version number 1.8 between the last relay version number 1.7 and the target version number 1.9. If N is 2, there will be two intermediate version numbers. Figure 5 As shown, there are two intermediate version numbers 1.4 and 1.5 between the current version number 1.3 and the relay version number 1.6, and there are two intermediate version numbers 1.7 and 1.8 between the relay version number 1.6 and the target version number 1.9. It should be understood by those skilled in the art that when there are more or fewer intermediate version numbers between the current version number and the target version number, the principle is the same as described above and will not be repeated here.

[0055] In step S333, the dependent version number is determined. After the M relay version numbers are determined, the M relay version numbers can divide the version numbers between the current version number and the target version number into M+1 intervals. Figure 2 As shown, the software versions between the current version number 1.3 and the target version number 1.9 are divided into three intervals: the first interval between the current version number 1.3 and the relay version number 1.5, the second interval between the relay version number 1.5 and the relay version number 1.7, and the third interval between the relay version number 1.7 and the target version number 1.9. Figure 5The version number is divided into two intervals: the first interval between the current version number 1.3 and the relay version number 1.6, and the second interval between the relay version number 1.6 and the target version number 1.9.

[0056] The dependent version number means that the software after the dependent version number needs to rely on the software with the dependent version number for upgrading. In other words, during the upgrading process of the software after the dependent version number, the software of the later version needs to be upgraded on the basis of the software of the dependent version number, otherwise the software of the later version will not be upgraded normally or there may be software problems after the upgrade.

[0057] As an example, in Figure 2 In the embodiment of the present invention, there is a dependency version number 1.4. In the process of upgrading the software from version number 1.3 to version number 1.5, the software must first be upgraded from version number 1.3 to version number 1.4, and then upgraded from version number 1.4 to version number 1.5, instead of directly upgrading from version number 1.3 to version number 1.5. Figure 5 In the embodiment of, there are two dependent versions 1.5 and 1.7. The software upgrade from software of version number 1.3 to software of version number 1.6 is described as an example. If it is desired to upgrade from software of version number 1.3 to software of version number 1.6, it is necessary to first upgrade from software of version number 1.3 to software of version number 1.5, and then upgrade from software of version number 1.5 to software of version number 1.6, or if it is desired to upgrade from software of version number 1.4 to software of version number 1.6, it is necessary to upgrade from software of version number 1.4 to software of version number 1.5, and then upgrade from software of version number 1.5 to software of version number 1.6. The software upgrade between software of version number 1.6 and software of version number 1.9 is described as an example. If it is desired to upgrade from software of version number 1.6 to software of version number 1.7, it is necessary to first upgrade from software of version number 1.6 to software of version number 1.7, and then upgrade from software of version number 1.7 to software of version number 1.9.

[0058] As described above, M relay version numbers can be divided into M+1 intervals between the current version number and the target version number. Therefore, it can be determined whether there is a dependent version number in each of the M+1 intervals. In an interval where a dependent version number exists, in the process of upgrading from the first version number of the interval to the last version number of the interval, it is necessary to first upgrade from the first version number of the interval to the dependent version number, and then upgrade from the dependent version number to the last version number of the interval. In an interval where there is no dependent version number, it is possible to upgrade directly from the first version number of the interval to the last version number of the interval. Figure 2Take the implementation example as an example to illustrate: in the first interval of software version number 1.3 to software version number 1.5, since there is a dependent version number 1.4, it is necessary to first upgrade from the zone head version number 1.3 to the dependent version number 1.4, and then upgrade from the dependent version number 1.4 to the zone end version number 1.5. In the second interval of software version number 1.5 to software version number 1.7 and the third interval of software version number 1.7 to software version number 1.9, since there is no dependent version, for the second interval, it is possible to directly upgrade from the zone head version number 1.5 to the zone end version number 1.7, and for the third interval, it is possible to directly upgrade from the zone head version number 1.7 to the zone end version number 1.9. Figure 5 Take the embodiment of as an example to illustrate: in the first interval of software version number 1.3 to software version number 1.6, due to the existence of dependent version number 1.5, it is necessary to first upgrade from the first version number 1.3 to the dependent version number 1.5, and then upgrade from the dependent version number 1.5 to the last version number 1.6. Of course, if there is no dependent version in the first interval, you can directly upgrade from the first version number 1.3 to the last version number 1.6. Similarly, in the second interval of software version number 1.6 to software version number 1.9, due to the existence of dependent version number 1.7, it is necessary to first upgrade from the first version number 1.6 to the dependent version number 1.7, and then upgrade from the dependent version number 1.7 to the last version number 1.9. Of course, if there is no dependent version in the first interval, you can directly upgrade from the first version number 1.6 to the last version number 1.9.

[0059] In step S340 , an upgrade path for the vehicle software is generated according to the determined version sequence of the relay version number and the dependent version number.

[0060] The version order of the trunk version number and the dependent version number refers to the order of the two in the upgraded version of the vehicle software. Figure 2 and Figure 5 For example, the version sequence is 1.3→1.4→1.5→1.6→1.7→1.8→1.9. Figure 2 In the embodiment, the dependency version number 1.4 and the relay version numbers 1.5 and 1.7 are included. Since the dependency version number and the relay version number are not crossable, after determining the dependency version number and the relay version number, Figure 2 The upgrade path of the embodiment is 1.3→1.4→1.5→1.7→1.9. According to this upgrade path, the upgrade from version number 1.3 to version number 1.9 can be achieved. Figure 5 The example includes dependency version numbers 1.5 and 1.7 and trunk version number 1.6, so Figure 5 The upgrade path of the embodiment is 1.3→1.5→1.6→1.7→1.9.

[0061] In step S350, the software is upgraded according to the determined software upgrade path, and the software is upgraded from the current version number to the target version number.

[0062] Figure 6 A further embodiment of the software method of the present disclosure is provided, comprising steps S610 to S660.

[0063] In step S610, a plurality of intermediate version numbers that need to be passed through in order to upgrade the current version number of the software to the target version number are obtained. In step S620, it is determined whether the number of intermediate version numbers between the current version number and the target version number is greater than the relay interval value N. In the case where the number of intermediate version numbers between the current version number and the target version number is greater than the relay interval value N, step S630 is executed, and the relay version number is determined in step S630. In the case where the number of intermediate version numbers between the current version number and the target version number is less than or equal to the relay interval value N, step S640 is executed, and the dependent version number is determined in step S640. In step S650, the software upgrade path is determined according to the determined relay version number and the dependent version number. According to the technical solution of this embodiment, the presence or absence of the relay version number and the presence or absence of the dependent version number are all possible. In the process of determining the upgrade path, it is only necessary to form the software upgrade path according to the version order of the determined version number. In step S660, according to the determined software upgrade path, the software is upgraded from the current version number to the target version number.

[0064] by Figure 5 For example, suppose you need to upgrade from software version 1.3 to software version 1.5, because there is only one intermediate version 1.4 between the two, which is less than the relay interval value N (=2), then you do not need to set the relay version number, and you can directly confirm whether the software version 1.4 is a dependent version. Therefore, according to the technical solution of the present disclosure, even if the span of software upgrade is relatively small (such as one intermediate version number), it is not necessary to upgrade one by one during the software upgrade process.

[0065] According to a further embodiment of the present disclosure, before determining the M relay version numbers, the method further includes: sorting the software version numbers according to the version sequence from the current version number to the target version number. Figure 2 and Figure 5 In the embodiment, during the upgrade from version number 1.3 to 1.9, sorting is performed to obtain the version order of 1.3→1.6→1.5→1.6→1.7→1.8→1.9.

[0066] For the version numbers after sorting, the relay version number is determined from multiple intermediate version numbers according to the current version number and the relay interval value N. Then, in the process of determining the dependent version number between the current version number and the target version number, the dependent version is searched between the current version number and the first relay version number, between adjacent relay version numbers, and between the last relay version number and the target version number.

[0067] In an embodiment of the present disclosure, the upgrade path can be quickly determined for each vehicle according to the current version number of different vehicles. According to a further embodiment of the present disclosure, a method for upgrading vehicle software is provided, and the vehicle software can be the whole vehicle software or the software of a certain component. Figure 7 A schematic interactive diagram showing a method for upgrading vehicle software according to an embodiment.

[0068] In step S701, the server or software management platform obtains the current version number of the vehicle software. The server or software management platform can obtain the current version number of the vehicle software in real time, or it can use the software version number of the last successful upgrade of the vehicle stored in the server or software management platform as the current version number. Figure 7 n vehicles are shown in the figure, that is, according to the upgrade method disclosed in the present invention, different vehicles can be upgraded separately for different current version numbers. For example, during the software upgrade of vehicle 1, the current version number of vehicle 1 can be determined, and during the software upgrade of vehicle n, the current version number of vehicle n can be determined.

[0069] In step S702, the server or software management platform determines the intermediate version number between the current version number and the target version number (the version number to be upgraded) according to the obtained current version number. In step S703, it is determined whether the number of intermediate version numbers is greater than the relay interval value N, wherein the relay interval value N may be a value related to software testing, and may refer to the above description.

[0070] When the number of intermediate version numbers is greater than N, step S704 is executed to determine the version number, wherein the version number is determined according to the current version number and the relay interval value N. Then step S705 is executed. When the number of intermediate version numbers is less than or equal to N, step S705 is executed. In step S705, the dependent version number in the intermediate version number is determined. The specific description of steps S702-S706 can refer to the above content.

[0071] In the vehicle software upgrade method, after the server or software management platform determines the upgrade path, the software of the corresponding version number (including software of the relay version number, software of the dependent version number, and software of the target version number) is sent to the vehicle according to the upgrade path in step S707. In step S708, the vehicle performs a corresponding upgrade after receiving the software. The software of each version number is sent in the order determined by the upgrade path, and can be sent continuously during the software upgrade process. In addition, according to the generated upgrade path, information such as upgrade instructions can also be sent to the vehicle, and the vehicle user can view the upgrade instructions through the vehicle display terminal. After the vehicle software is upgraded to the software of the target version number, the software of the target version number is run and the upgrade result can be fed back to the server or software management platform in step S710.

[0072] According to a further embodiment of the present disclosure, a software upgrade system is also provided. The software upgrade system includes a processor and a memory, the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following process: determining multiple intermediate version numbers that the software needs to go through to upgrade from the current version number to the target version number; determining a relay version number and a dependent version number among the multiple intermediate version numbers, wherein the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process, the relay version number is configured before the software upgrade, the relay version number is used to limit the number of versions crossed during each software upgrade process, the dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number; and generating a software upgrade path according to the determined version sequence of the relay version number and the dependent version number, the software upgrade path is used to upgrade the software from the current version number to the target version number.

[0073] In addition, determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: selecting M intermediate version numbers from the multiple intermediate version numbers as M relay version numbers, where M≥1. Starting from the current version number, selecting M intermediate version numbers from the intermediate version numbers based on the interval value N as M relay version numbers, where the interval value N is the number of versions allowed to be crossed during each software upgrade, and 1≤N≤5. Based on the M relay version numbers, the current version to the target version is divided into M+1 upgrade intervals, and each upgrade interval includes N intermediate version numbers, where 1≤N≤5.

[0074] When M=1, the current version number to the target version number is divided into 2 upgrade intervals, of which the first upgrade interval is the upgrade interval formed by the current version number and the relay version number, and the second upgrade interval is the upgrade interval formed by the relay version number and the target version number. When M≥2, the current version number to the target version number is divided into M+1 upgrade intervals, of which the first upgrade interval is the upgrade interval formed by the current version number and the first relay version number, the last upgrade interval is the upgrade interval formed by the last relay version number and the target version number, and the intermediate upgrade interval between the first upgrade interval and the last upgrade interval is the upgrade interval formed by adjacent relay version numbers.

[0075] Determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: determining whether the dependent version number is included in each upgrade interval in the M+1 upgrade intervals. When the dependent version number is determined from the multiple intermediate version numbers, a software upgrade path is generated according to the determined version sequence of the relay version number and the dependent version number; when the dependent version number is not determined from the multiple intermediate version numbers, a software upgrade path is generated according to the determined version sequence of the relay version number.

[0076] Figure 8 The structural schematic block diagram of the software upgrade system is shown. The hardware structure of the software upgrade system 800 of the present disclosure can be implemented using a bus architecture. The bus architecture may include any number of interconnected buses and bridges, depending on the specific application and overall design constraints of the hardware. The bus 810 connects various circuits including one or more processors 820, memory 830 and / or hardware modules together. The bus 810 may also connect various other circuits 840 such as peripherals, voltage regulators, power management circuits, external antennas, etc. The bus 810 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 810 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one connecting line is used in the figure, but it does not mean that there is only one bus or one type of bus. The memory 830 stores a computer program, and the processor 820 executes the computer program. In addition, the software upgrade system 800 may further include an intermediate version number determination module 802 , a relay version determination module 804 , a dependent version determination module 806 , an upgrade path determination module 808 and an upgrade control module 809 .

[0077] The intermediate version number determination module 802 is used to determine the intermediate version number between the current version number and the target version number of the vehicle software. The relay version number determination module 804 is used to determine the relay version number in the intermediate version number. The dependent version number determination module 806 is used to determine the dependent version number in the intermediate version number. The upgrade path generation module 808 is used to generate a software upgrade path according to the determined version sequence of the relay version number and the dependent version number. The upgrade control module 809 is used to generate the software according to the determined software upgrade path, and upgrade from the current version number to the target version number.

[0078] The relay version determination module 804 may also select M intermediate version numbers from the multiple intermediate version numbers as the M relay version numbers, where M≥1. Specifically, starting from the current version number, M intermediate version numbers are selected from the intermediate version numbers based on the interval value N as the M relay version numbers, where the interval value N is the number of versions allowed to be crossed during each software upgrade, where 1≤N≤5.

[0079] The dependent version determination module 806 can also determine whether there are dependent version numbers in the upgrade space divided by the relay version number. Based on M relay version numbers, the current version to the target version is divided into M+1 upgrade intervals, and each upgrade interval includes N intermediate version numbers, where 1≤N≤5. In the M+1 upgrade intervals, it is determined whether the dependent version number is included in each upgrade interval. In the case where the dependent version number is determined among multiple intermediate version numbers, a software upgrade path is generated based on the version order of the determined relay version number and the dependent version number. In the case where the dependent version number is not determined among multiple intermediate version numbers, a software upgrade path is generated based on the version order of the determined relay version number.

[0080] According to a further embodiment of the present disclosure, a vehicle is also provided, and the vehicle may include the above-mentioned software upgrade system. Fig. 9 As shown, the upgrade system 900 may include a communication module, which may be wirelessly connected to a server such as a cloud server or a software management platform. The communication module may receive upgrade software from the server or software management platform. After the upgrade software is stored in the memory, it may be called by the processor to implement the upgrade, and the upgrade process and upgrade results may be displayed on the vehicle display terminal.

[0081] The present disclosure also provides a server, which may include the above-mentioned software upgrade system.

[0082] The present disclosure also provides a readable storage medium, in which a computer program is stored, and the computer program is used to implement the above method when executed by a processor. "Readable storage medium" can be any device that can contain, store, communicate, propagate or transmit a program for use in an instruction execution system, device or equipment or in combination with these instruction execution systems, devices or equipment. More specific examples of readable storage media include the following: an electrical connection portion (electronic device) with one or more wirings, a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and editable read-only memory (EPROM or flash memory), an optical fiber device, and a portable read-only memory (CDROM), etc.

[0083] The present disclosure also provides a computer program product. The method of the present disclosure can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed, the process or function of the present disclosure is executed in whole or in part.

[0084] The computer program or instructions may be stored in a readable storage medium or transmitted from one readable storage medium to another readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The readable storage medium may be any available medium that can be accessed or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid state drive. The computer readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0085] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, systems, and computer program products according to the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0087] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0088] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0089] In the description of this specification, the description with reference to the terms "one embodiment / method", "some embodiments / methods", "example", "specific example", or "some examples" etc. means that the specific features, structures, or characteristics described in conjunction with the embodiment / method or example are included in at least one embodiment / method or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment / method or example. Moreover, the specific features, structures, or characteristics described may be combined in any one or more embodiments / methods or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments / methods or examples described in this specification and features of different embodiments / methods or examples, unless they are contradictory.

[0090] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of the present disclosure, "plurality" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0091] Those skilled in the art should understand that the above embodiments are only for the purpose of clearly illustrating the present disclosure, and are not intended to limit the scope of the present disclosure. For those skilled in the art, other changes or modifications may be made based on the above disclosure, and these changes or modifications are still within the scope of the present disclosure.

Claims

1. A software upgrade method, characterized in that: include: Determine the number of intermediate versions that the software needs to go through to upgrade from the current version number to the target version number; Determine a relay version number and a dependent version number from the multiple intermediate version numbers, wherein the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process, the relay version number is configured before the software upgrade, the relay version number is used to limit the number of versions crossed during each software upgrade process, the dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number; Determine a software upgrade path according to the determined version sequence of the relay version number and the dependent version number; and According to the software upgrade path, the software is upgraded from the current version number to the target version number.

2. The software upgrade method according to claim 1, characterized in that: Determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: selecting M intermediate version numbers from the multiple intermediate version numbers as the M relay version numbers, M≥1.

3. The software upgrade method according to claim 2, characterized in that: Starting from the current version number, M intermediate version numbers are selected from the intermediate version numbers based on an interval value N as the M relay version numbers, wherein the interval value N is the number of versions allowed to be crossed during each software upgrade process, 1≤N≤5.

4. The software upgrade method according to claim 2, characterized in that: Based on the M relay version numbers, the current version to the target version is divided into M+1 upgrade intervals, each upgrade interval includes N intermediate version numbers, where 1≤N≤5.

5. The software upgrade method according to claim 4, characterized in that: When M=1, the current version number to the target version number is divided into two upgrade intervals, wherein the first upgrade interval is the upgrade interval formed by the current version number and the relay version number, and the second upgrade interval is the upgrade interval formed by the relay version number and the target version number.

6. The software upgrade method according to claim 4, characterized in that: When M≥2, the current version number to the target version number is divided into M+1 upgrade intervals, where the first upgrade interval is the upgrade interval formed by the current version number and the first relay version number, the last upgrade interval is the upgrade interval formed by the last relay version number and the target version number, and the middle upgrade interval between the first upgrade interval and the last upgrade interval is the upgrade interval formed by adjacent relay version numbers.

7. The software upgrade method according to claim 4, characterized in that: Determining the relay version number and the dependent version number from the multiple intermediate version numbers includes: determining in the M+1 upgrade intervals whether each upgrade interval includes the dependent version number.

8. The software upgrade method according to any one of claims 1 to 7, characterized in that: When a dependent version number is determined among the multiple intermediate version numbers, a software upgrade path is generated according to the determined version sequence of the relay version number and the dependent version number; When no dependent version number is determined among the plurality of intermediate version numbers, a software upgrade path is generated according to the determined version sequence of the relay version numbers.

9. A software upgrade system, characterized in that: The software upgrade system includes a processor and a memory, wherein the memory stores a computer program. When the computer program is executed by the processor, the processor performs the following process: Determine the number of intermediate versions that the software needs to go through to upgrade from the current version number to the target version number; Determine a relay version number and a dependent version number from the multiple intermediate version numbers, wherein the relay version number and the dependent version number are both version numbers that cannot be crossed during the software upgrade process, the relay version number is configured before the software upgrade, the relay version number is used to limit the number of versions crossed during each software upgrade process, the dependent version number is configured during the software development process, and the software upgrade after the dependent version number depends on the dependent version number; as well as According to the determined version sequence of the relay version number and the dependent version number, a software upgrade path is determined, where the software upgrade path is used to upgrade the software from the current version number to the target version number.

10. A vehicle, characterized in that: Comprising the software upgrade system as claimed in claim 9.

11. A server, characterized in that: Comprising the software upgrade system as claimed in claim 9.

12. A computer program product, characterized in that The computer program product comprises a computer program, which is used to implement at least the method according to any one of claims 1 to 8 when being executed by a processor.

Images