Software upgrading path determination method, electronic equipment, vehicle and program product

Abstract

The invention provides a method for determining a software upgrading path, electronic equipment, a vehicle and a program product, and is applied to the technical field of software upgrade.The method for determining the software upgrading path comprises the steps that an initial upgrading path is obtained, the initial upgrading path comprises a plurality of baseline versions, the baseline versions are officially released whole vehicle versions, and the baseline versions are stored in the initial upgrading path; the plurality of baseline versions are sorted according to a release time sequence, the whole vehicle version comprises a part version corresponding to at least one part, and the part version is used for upgrading software of the corresponding part; an operation bridge is determined from the initial upgrading path according to the initial version, the target version and the upgrading span, the operation bridge comprises the initial version, the target version and an intermediate version, and the intermediate version comprises a baseline version in the initial upgrading path, the release time of the baseline version is after the initial version, and the baseline version and the initial version are spaced by integral multiple upgrading span; the initial version is an initial version or a current version; and determining a target upgrading path according to the current version and the operation bridge.

Description

Technical Field

[0001] The present application relates to the technical field of software upgrade, and in particular to a method for determining a software upgrade path, an electronic device, a vehicle, and a program product. Background Art

[0002] With the development of the Internet of Vehicles, Over-The-Air technology (OTA) upgrades (i.e. remote upgrades) have become the "standard" for new energy vehicles. The frequent use of new vehicles has improved the user experience and also increased users' expectations for software upgrades. Therefore, it is very important to ensure the stability of software functions. Among them, there are many parts in a car, and the number of parts that support OTA may reach more than 50. As the number of OTAs increases and the frequency increases, the cars on the market will stay on various versions.

[0003] When a new version is updated using the software upgrade method in the prior art, in order to ensure the stability of the upgrade, it is necessary to verify the success rate of upgrading all versions on the market to the target version, which will lead to huge testing pressure and after-sales pressure. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a method for determining a software upgrade path, an electronic device, a vehicle, and a program product, so as to solve the technical problem that the software upgrade method in the prior art will cause huge testing pressure and after-sales pressure.

[0005] In a first aspect, an embodiment of the present application provides a method for determining a software upgrade path, comprising: obtaining an initial upgrade path, wherein the initial upgrade path includes multiple baseline versions, the baseline version is a formally released vehicle version, the multiple baseline versions are sorted in order of release time, the vehicle version includes a part version corresponding to at least one part, and the part version is used to upgrade the software of the corresponding part; determining an operation bridge from the initial upgrade path according to a starting version, a target version, and an upgrade span, wherein the operation bridge includes the starting version, the target version, and an intermediate version, the intermediate version includes a baseline version in the initial upgrade path whose release time is after the starting version and is separated from the starting version by an integer multiple of the upgrade span, the starting version being the initial version or the current version; determining a target upgrade path according to the current version and the operation bridge.

[0006] In the above scheme, the operation bridge can be determined from the initial upgrade path based on the upgrade span, and then the target upgrade path can be determined based on the current version and the above operation bridge, so that the software upgrade can be performed based on the above target upgrade path. Compared with the software upgrade method in the prior art, the method for determining the software upgrade path provided in the embodiment of the present application clarifies and narrows the scope of each new version test by limiting the upgrade span, thereby greatly reducing the testing cost and after-sales cost.

[0007] In an optional implementation, the operation bridge is determined from the initial upgrade path according to the starting version, the target version and the upgrade span, including: determining the starting version and the intermediate version in the initial upgrade path as the baseline version in the operation bridge; if the intermediate version includes the target version, then determining the intermediate version that is the same as the target version as the target version; otherwise, determining the target version in the initial upgrade path as the baseline version in the operation bridge. In the above scheme, two schemes for determining the operation bridge are proposed, namely a fixed operation bridge and a dynamic operation bridge, so as to adapt to the upgrade requirements of different scenarios.

[0008] In an optional embodiment, when the starting version is the initial version, the target upgrade path is determined based on the current version and the operation bridge, including: if the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline version included in the target upgrade path. In the above scheme, a scheme of fixing the operation bridge is proposed, that is, the starting version included in the operation bridge is the initial version; because the target upgrade paths corresponding to different vehicles determined by this scheme have the same baseline version, the cost of operation management can be reduced, and it is convenient to monitor the upgrade results and troubleshoot problems.

[0009] In an optional implementation, when the starting version is the current version, determining the target upgrade path based on the current version and the operation bridge includes: determining the baseline version included in the operation bridge as the baseline version included in the target upgrade path. In the above scheme, a dynamic operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the current version; since the number of baseline versions included in the target upgrade path determined by this scheme is small, the number of vehicle upgrades can be reduced, thereby improving user experience.

[0010] In an optional implementation, the obtaining of the initial upgrade path includes: obtaining the multiple baseline versions; sorting the multiple baseline versions in the order of their official release time to obtain the initial upgrade path; or obtaining the latest baseline version; and adding the latest baseline version to the initial upgrade path based on the release time corresponding to the latest baseline version to obtain a new initial upgrade path. In the above scheme, the initial upgrade path can be obtained by sorting the baseline versions in time in advance, so as to determine the operation bridge according to the above initial upgrade path.

[0011] In an optional implementation, the initial upgrade path also includes at least one technology bridge, one technology bridge corresponds to a baseline version, and upgrading to the baseline version requires first upgrading to the technology bridge corresponding to it, and the technology bridge includes at least one dependent version, and one dependent version corresponds to a part version in the baseline version corresponding to the technology bridge; the operation bridge is determined from the initial upgrade path according to the starting version, the target version, and the upgrade span, including: determining the starting version and the intermediate version in the initial upgrade path as the baseline version in the operation bridge; if the intermediate version includes the target version, the intermediate version identical to the target version is determined as the target version; otherwise, the target version in the initial upgrade path is determined as the baseline version in the operation bridge; the technology bridge corresponding to the starting version and the technology bridge corresponding to the baseline version whose release time is between the starting version and the target version are determined as the technology bridge in the operation bridge. In the above scheme, since the software upgrade has a chip for the underlying software version or the internal chip version, the concept of the technology bridge is introduced, and the upgrade to the technology bridge is first upgraded and then upgraded to the corresponding baseline version, so as to ensure the normal progress of the software upgrade. In addition, two solutions for determining the operation bridge, a fixed operation bridge and a dynamic operation bridge, are proposed to adapt to the upgrade requirements of different scenarios.

[0012] In an optional embodiment, when the starting version is the initial version, the target upgrade path is determined based on the current version and the operation bridge, including: if the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline version included in the target upgrade path; the technology bridge corresponding to the baseline version whose release time is between the current version and the target version is determined as the technology bridge in the target upgrade path. In the above scheme, a scheme of fixing the operation bridge is proposed, that is, the starting version included in the operation bridge is the initial version; because the target upgrade paths corresponding to different vehicles determined by this scheme have the same baseline version, the cost of operation management can be reduced, and the monitoring of upgrade results and troubleshooting can be facilitated.

[0013] In an optional implementation, when the starting version is the current version, determining the target upgrade path based on the current version and the operation bridge includes: determining the baseline version included in the operation bridge as the baseline version included in the target upgrade path; determining the technology bridge corresponding to the baseline version with a release time between the current version and the target version as the technology bridge in the target upgrade path. In the above scheme, a dynamic operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the current version; since the number of baseline versions included in the target upgrade path determined by this scheme is small, the number of vehicle upgrades can be reduced, thereby improving user experience.

[0014] In an optional implementation, the obtaining of the initial upgrade path includes: receiving multiple component versions and multiple dependency versions, and associating each dependency version with the corresponding component version to obtain the baseline version and the technology bridge corresponding to the baseline version; sorting the multiple baseline versions in the order of their official release time and adding the technology bridge to obtain the initial upgrade path; or, receiving the latest component version and the latest dependency version, and associating each latest dependency version with the corresponding latest component version to obtain the latest baseline version and the latest technology bridge corresponding to the latest baseline version; based on the release time corresponding to the latest baseline version, adding the latest baseline version and the latest technology bridge to the initial upgrade path to obtain a new initial upgrade path. In the above scheme, since the software upgrade involves the underlying software version or the internal chip version of the chip, the concept of the technology bridge is introduced, and the upgrade to the technology bridge is first performed and then to the corresponding baseline version, thereby ensuring the normal progress of the software upgrade.

[0015] In a second aspect, an embodiment of the present application provides an electronic device, comprising: a processor and a memory; the memory stores computer program instructions that can be executed by the processor, and the processor calls the computer program instructions to execute the method for determining the software upgrade path as described in the first aspect.

[0016] In a third aspect, an embodiment of the present application provides a vehicle, comprising the electronic device described in the second aspect.

[0017] In a fourth aspect, an embodiment of the present application provides a computer program product, wherein the computer program product includes instructions, and when the instructions are executed by a computer, the computer implements the method for determining a software upgrade path as described in the first aspect.

[0018] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer program instructions. When the computer program instructions are executed by a computer, the computer executes the method for determining a software upgrade path as described in the first aspect.

[0019] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the following specifically cites the embodiments of the present application and describes them in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0021] Figure 1 A flowchart of a method for determining a software upgrade path provided in an embodiment of the present application;

[0022] Figure 2 A schematic diagram of an initial upgrade path provided by an embodiment of the present application;

[0023] Figure 3 A schematic diagram of an operating bridge under a fixed operating bridge solution provided in an embodiment of the present application;

[0024] Figure 4 A schematic diagram of a target upgrade path under a fixed operation bridge solution provided in an embodiment of the present application;

[0025] Figure 5 A schematic diagram of an operation bridge under a dynamic operation bridge solution provided in an embodiment of the present application;

[0026] Figure 6A schematic diagram of a target upgrade path under a dynamic operation bridge solution provided in an embodiment of the present application;

[0027] Figure 7 A structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The method for determining the software upgrade path disclosed in the embodiment of the present application can be applied to, but is not limited to, vehicles such as battery vehicles, motor vehicles, ships, and spacecraft, wherein the spacecraft may include aircraft, rockets, space shuttles, and spacecrafts. For the convenience of explanation, the following embodiments are described by taking the method for determining the software upgrade path disclosed in the embodiment of the present application as applied to a motor vehicle as an example. The motor vehicle may be a fuel vehicle, a gas vehicle, or a new energy vehicle, and the new energy vehicle may be a pure electric vehicle, a hybrid vehicle, or an extended-range vehicle.

[0029] In the embodiments of the present application, two concepts, namely, an operation bridge and a technology bridge, are involved. The two concepts, namely, a technology bridge and an operation bridge, are introduced below.

[0030] In order to improve testing and operational efficiency, the maximum span of each vehicle upgrade will be limited (assuming the span is X). If the upgrade of a low-version vehicle to the target version exceeds the maximum span, the process versions must be divided into intervals of X and upgraded in sequence. These process versions are called operational bridges. Since software upgrades are dependent on the underlying software version or internal chip version, you must first upgrade to a dependent version before you can continue to upgrade to the target version. This dependent version is called a technical bridge. The following will describe the technical solution in the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. Please refer to Figure 1 , Figure 1 A flowchart of a method for determining a software upgrade path provided in an embodiment of the present application, the method for determining a software upgrade path may specifically include the following steps:

[0031] Step S101: Obtain an initial upgrade path, wherein the initial upgrade path includes multiple baseline versions, the baseline version is a formally released vehicle version, the multiple baseline versions are sorted in order of release time, the vehicle version includes a part version corresponding to at least one part, and the part version is used to upgrade the software of the corresponding part.

[0032] Step S102: Determine the operation bridge from the initial upgrade path according to the starting version, the target version and the upgrade span, wherein the operation bridge includes the starting version, the target version and the intermediate version, the intermediate version includes a baseline version in the initial upgrade path whose release time is after the starting version and is separated from the starting version by an integer multiple of the upgrade span, and the starting version is the initial version or the current version.

[0033] Step S103: Determine the target upgrade path according to the current version and the operation bridge.

[0034] Specifically, a vehicle may include many parts, some of which support OTA, so the software of these parts that support OTA (i.e., upgradeable parts) can be upgraded. Under an upgrade version, an upgradeable part may correspond to one or more part versions, where the above part version refers to the software version of a single upgradeable part, which is used to upgrade the software of the corresponding part.

[0035] Aggregating the corresponding part versions of all upgradeable parts of the vehicle under an upgraded version can obtain the corresponding vehicle version of the vehicle, that is, the vehicle version includes the part version corresponding to at least one part. After a vehicle version is developed, it can be tested; by iterating the above vehicle versions, a vehicle version that has been fully tested and has stable functions and can be released to users in batches can be obtained. The vehicle version that can be officially released is the baseline version corresponding to the vehicle under an upgraded version.

[0036] In the above step S101, the initial upgrade path may include multiple baseline versions, and the above multiple baseline versions are sorted in the order of release time. As an implementation, the multiple baseline versions included in the initial upgrade path are sorted in the order of release time from early to late; as another implementation, the multiple baseline versions included in the initial upgrade path are sorted in the order of release time from late to early.

[0037] It should be noted that the embodiments of the present application do not specifically limit the specific implementation method of obtaining the initial upgrade path, and those skilled in the art may make appropriate adjustments according to actual conditions. For example, the initial upgrade path sent by an external device may be received; or multiple baseline versions may be obtained and the initial upgrade path may be determined based on the multiple baseline versions; or the initial upgrade path may be read from a local or cloud storage, etc.

[0038] In the above step S102, the starting version is the initial version or the current version. The initial version may be a baseline version in a predetermined initial upgrade path, indicating that the initial version may be upgraded first before further upgrades. For example, the initial version may be the first baseline version in the initial upgrade path; or the initial version may be the third baseline version in the initial upgrade path; or the initial version may be the tenth baseline version in the initial upgrade path, etc. The current version is the current software version of the vehicle, indicating that further upgrades may be performed starting from the current version.

[0039] The upgrade span can be a pre-determined step length for the upgrade, and software testing and software upgrade work can be carried out within the upgrade span. For example, assuming the upgrade span is 2, the upgrade can be performed every two baseline versions, such as: first upgrade using the first baseline version in the initial upgrade path, then upgrade using the third baseline version in the initial upgrade path, then upgrade using the fifth baseline version in the initial upgrade path...; at this time, when a new baseline version is added, it is only necessary to test the stability between the baseline version and the last baseline version, and to test the stability between the baseline version and the second last baseline version.

[0040] It is understandable that the maximum upgrade span can be determined by the project team members (including project, testing, after-sales, operation, and software integration personnel) by comprehensively considering the resources of all parties. As an implementation method, the upgrade span in the above step S102 is the above maximum upgrade span; as another implementation method, the upgrade span in the above step S102 can be less than the above maximum upgrade span and greater than 1.

[0041] The target version refers to the software version that the vehicle currently needs to upgrade to. Intermediate versions include baseline versions in the initial upgrade path that are released after the start version and are separated from the start version by an integer multiple of the upgrade span. For example, assuming the upgrade span is 2 and the start version is the first baseline version in the initial upgrade path, the intermediate versions may include the third baseline version, the fifth baseline version, the seventh baseline version, etc. in the initial upgrade path.

[0042] The operation bridge may include the above-mentioned starting version, the above-mentioned target version and the above-mentioned intermediate version. It should be noted that the embodiment of the present application does not specifically limit the specific implementation method of determining the above-mentioned operation bridge, and those skilled in the art may make appropriate adjustments according to actual conditions. For example, the starting version and the target version in the initial upgrade path may be determined first, and then the intermediate version between the starting version and the target version may be determined; or, the starting version in the initial upgrade path may be determined first, and then the intermediate version whose release time is after the starting version may be determined, and finally the target version may be reached.

[0043] When the starting version included in the operation bridge is the initial version, a fixed operation bridge is used. For example, an initial version V1 is determined, and the upgrade span X is used as the step length. From the initial version, the baseline version V1, baseline version V1+X, baseline version V1+2X... are determined as the baseline versions in the operation bridge.

[0044] When the starting version included in the operation bridge is the current version, a dynamic operation bridge is used. For example, the vehicle's current version V2 is used as the starting version, and the upgrade span X is used as the step length. From the current version, the baseline version V2+X, baseline version V2+2X, etc. are incremented and determined as the baseline versions in the operation bridge.

[0045] In the above step S103, the target upgrade path includes the baseline version that the vehicle must go through in order to upgrade from the current version to the target version; based on the above target upgrade path, the vehicle software can be upgraded in advance.

[0046] In the above scheme, the operation bridge can be determined from the initial upgrade path based on the upgrade span, and then the target upgrade path can be determined based on the current version and the above operation bridge, so that the software upgrade can be performed based on the above target upgrade path. Compared with the software upgrade method in the prior art, the method for determining the software upgrade path provided in the embodiment of the present application clarifies and narrows the scope of each new version test by limiting the upgrade span, thereby greatly reducing the testing cost and after-sales cost.

[0047] Further, based on the above embodiment, the above step S102 may specifically include the following steps:

[0048] Step 1) determines the starting version and the intermediate versions in the initial upgrade path as the baseline versions in the operation bridge.

[0049] Step 2), if the intermediate version includes the target version, the intermediate version that is the same as the target version is determined as the target version; otherwise, the target version in the initial upgrade path is determined as the baseline version in the operation bridge.

[0050] In the above step 2), if the intermediate version includes the target version, it means that the target version can be included by incrementing from the starting version with the upgrade span as the step length, so the intermediate version that is the same as the target version can be directly determined as the target version. If the intermediate version does not include the target version, it means that the target version can only be included by incrementing from the starting version with the upgrade span as the step length, but not the target version, so the target version in the initial upgrade path also needs to be determined as the baseline version in the operation bridge.

[0051] In the above scheme, two schemes for determining the operation bridge, a fixed operation bridge and a dynamic operation bridge, are proposed, so as to adapt to the upgrade demands of different scenarios.

[0052] Further, based on the above embodiment, when the starting version is an initial version, the above step S103 may specifically include the following steps:

[0053] If the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline versions included in the target upgrade path.

[0054] In the above scheme, a fixed operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the initial version; since the target upgrade paths corresponding to different vehicles determined by this scheme have the same baseline version, the cost of operation management can be reduced, and it is convenient to monitor the upgrade results and troubleshoot problems.

[0055] Further, based on the above embodiment, when the starting version is the current version, the above step S103 may specifically include the following steps:

[0056] Identify the baseline version included in the Operational Bridge as the baseline version included in the target upgrade path.

[0057] In the above scheme, a dynamic operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the current version; since the number of baseline versions included in the target upgrade path determined by this scheme is small, the number of vehicle upgrades can be reduced, thereby improving user experience.

[0058] Further, based on the above embodiment, as an implementation mode, when the initial upgrade path cannot be obtained or information related to the initial upgrade path (for example, one or more information such as the upgrade span and the baseline version) changes, a new initial upgrade path may be generated based on multiple baseline versions in the above step S101, that is, the above step S101 may specifically include the following steps:

[0059] Step 1), obtain multiple baseline versions.

[0060] Step 2), sort multiple baseline versions according to the time sequence of their official release to obtain the initial upgrade path.

[0061] Specifically, in the above step 1), as an implementation method, the part production engineer (PDE) can upload the part version in the vehicle software platform (VSP), and create the vehicle version in the VSP based on the part version. Then, the software integrator can mark the officially released vehicle version under each baseline; by querying all officially released vehicle versions in the VSP, multiple baseline versions can be obtained.

[0062] As another implementation, when only the latest baseline version is added and the information related to the initial upgrade path is not changed, the old initial upgrade path may be updated based on the latest baseline version in step S101, that is, step S101 may specifically include the following steps:

[0063] Step 1), obtain the latest baseline version.

[0064] Step 2), based on the release time corresponding to the latest baseline version, add the latest baseline version to the initial upgrade path to obtain a new initial upgrade path.

[0065] In the above solution, the baseline versions may be sorted in time in advance to obtain an initial upgrade path, and the operation bridge may be determined according to the initial upgrade path.

[0066] Further, based on the above embodiment, the initial upgrade path may further include at least one technology bridge. A technology bridge corresponds to a baseline version, and upgrading to the baseline version requires first upgrading to the corresponding technology bridge, and the technology bridge includes at least one dependent version, and a dependent version corresponds to a component version in the baseline version corresponding to the technology bridge.

[0067] When a vehicle requests an upgrade, it can be upgraded according to the baseline version and technology bridge in the above target upgrade path. That is, in addition to the target version, the baseline version and technology bridge between the current vehicle version and the target version must be upgraded, and they must be upgraded in order until the target version is reached.

[0068] In this embodiment, the above step S102 may specifically include the following steps:

[0069] Step 1) determines the starting version and the intermediate versions in the initial upgrade path as the baseline versions in the operation bridge.

[0070] Step 2), if the intermediate version includes the target version, the intermediate version that is the same as the target version is determined as the target version; otherwise, the target version in the initial upgrade path is determined as the baseline version in the operation bridge.

[0071] Step 3), the technical bridge corresponding to the starting version and the technical bridge corresponding to the baseline version whose release time is between the starting version and the target version are determined as the technical bridges in the operation bridge.

[0072] Specifically, in the above step 3), since the technology bridge is the version that must be upgraded first during the software upgrade process, the technology bridge corresponding to the starting version and the technology bridge corresponding to the baseline version whose release time is between the starting version and the target version need to be determined as the technology bridges in the operation bridge.

[0073] In the above solution, since software upgrades may affect the underlying software version or internal chip version, the concept of technology bridge is introduced. First, upgrade to the technology bridge and then upgrade to the corresponding baseline version to ensure the normal progress of software upgrade. In addition, two solutions for determining the operation bridge, fixed operation bridge and dynamic operation bridge, are proposed to adapt to the upgrade requirements of different scenarios.

[0074] Further, based on the above embodiment, when the starting version is an initial version, the above step S103 may specifically include the following steps:

[0075] Step 1), if the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline versions included in the target upgrade path.

[0076] Step 2) The technology bridge corresponding to the baseline version whose release time is between the current version and the target version is determined as the technology bridge in the target upgrade path.

[0077] In the above scheme, a fixed operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the initial version; since the target upgrade paths corresponding to different vehicles determined by this scheme have the same baseline version, the cost of operation management can be reduced, and it is convenient to monitor the upgrade results and troubleshoot problems.

[0078] Further, based on the above embodiment, when the starting version is the current version, the above step S102 may specifically include the following steps:

[0079] Step 1) determines the baseline version included in the operation bridge as the baseline version included in the target upgrade path.

[0080] Step 2) The technology bridge corresponding to the baseline version whose release time is between the current version and the target version is determined as the technology bridge in the target upgrade path.

[0081] In the above scheme, a dynamic operation bridge scheme is proposed, that is, the starting version included in the operation bridge is the current version; since the number of baseline versions included in the target upgrade path determined by this scheme is small, the number of vehicle upgrades can be reduced, thereby improving user experience.

[0082] Further, based on the above embodiment, as an implementation mode, when the initial upgrade path cannot be obtained or information related to the initial upgrade path (for example, one or more information such as upgrade span, baseline version, technology bridge, etc.) changes, a new initial upgrade path can be generated based on multiple baseline versions and technology bridges in the above step S101, that is, the above step S101 can specifically include the following steps:

[0083] Step 1), receiving multiple component versions and multiple dependent versions, and associating each dependent version with the corresponding component version to obtain a baseline version and a technology bridge corresponding to the baseline version.

[0084] Step 2), sort multiple baseline versions according to the time sequence of official release and add technology bridges to obtain the initial upgrade path.

[0085] Specifically, in the above step 1), as an implementation method, a part production engineer (PDE) can upload the part version and dependent version in the vehicle software management platform (VSP), and associate each dependent version with the corresponding part version; then, the whole vehicle version and technology bridge can be created in the VSP based on the above part version and dependent version.

[0086] Among them, since the same part version can be configured with multiple different dependency versions, the following rules can be referred to when creating a technology bridge: Rule 1, if the same part version is configured with multiple different dependency versions, any of the above multiple dependency versions can be used as the dependency version corresponding to the part version in the technology bridge; Rule 2, if multiple part versions are respectively configured with multiple different dependency versions, the technology bridge includes the above multiple different dependency versions.

[0087] Finally, the software integrator can mark the officially released vehicle version under each baseline; by querying all officially released vehicle versions and their corresponding technology bridges in the VSP, multiple baseline versions and the technology bridges corresponding to the baseline versions can be obtained.

[0088] As another implementation, when only the latest baseline version is added and the information related to the initial upgrade path is not changed, the above step S101 may update the old initial upgrade path based on the latest baseline version and the latest technology bridge, that is, the above step S101 may specifically include the following steps:

[0089] Step 1), receiving the latest component version and the latest dependency version, and associating each latest dependency version with the corresponding latest component version, to obtain the latest baseline version and the latest technology bridge corresponding to the latest baseline version.

[0090] Step 2), based on the release time corresponding to the latest baseline version, the latest baseline version and the latest technology bridge are added to the initial upgrade path to obtain a new initial upgrade path.

[0091] In the above solution, since the software upgrade involves the underlying software version or the internal chip version of the chip, the concept of technology bridge is introduced. The upgrade is first to the technology bridge and then to the corresponding baseline version, thereby ensuring the normal progress of the software upgrade.

[0092] The following example introduces the method for determining the software upgrade path provided in the embodiment of the present application.

[0093] The existing part Airbag Control Unit (ACU), its corresponding PDE uploaded the part version 603011210DF corresponding to the ACU, and configured the corresponding dependent versions 603011210AB and 603011210BC.

[0094] Create vehicle version V2.1.0CB, select the part version 603011210DF corresponding to ACU, and then configure the technology bridge corresponding to the vehicle version; find that vehicle version V2.1.0BA contains one of the dependent versions 603011210AB, so configure vehicle version V2.1.0BA as the technology bridge of vehicle version V2.1.0CB.

[0095] The currently released vehicle versions (i.e. baseline versions) are found to include V1.5.0AG, V1.6.0BD, V1.7.0BG, V2.0.0BR, V2.1.0CB, and V2.2.0CF, so the following can be generated: Figure 2 Initial upgrade path shown.

[0096] At this time, a vehicle needs to be upgraded. The current version of the vehicle is V1.5.0AG and the target version is V2.1.0CB. If the fixed operation bridge solution is adopted: the upgrade span X = 2, the initial version is V1.6.0BD, then the operation bridge is as follows Figure 3 As shown in the blue part; the target upgrade path corresponding to the current vehicle is V1.5.0AG, V1.6.0BD, V2.0.0BR, V2.1.0BA, V2.1.0CB, such as Figure 4 shown.

[0097] If the dynamic operation bridge solution is adopted: the upgrade span X = 2, and the current version is V1.5.0AG, then the operation bridge is as follows Figure 5 As shown in the blue part; the target upgrade path corresponding to the current vehicle is V1.5.0AG, V1.7.0BG, V2.1.0BA, V2.1.0CB, such as Figure 6 shown.

[0098] Please refer to Figure 7 , Figure 7 The structural block diagram of an electronic device provided in an embodiment of the present application, the electronic device 700 includes: at least one processor 701, at least one communication interface 702, at least one memory 703 and at least one communication bus 704. Among them, the communication bus 704 is used to realize the direct connection and communication of these components, the communication interface 702 is used to communicate signaling or data with other node devices, and the memory 703 stores machine-readable instructions executable by the processor 701. When the electronic device 700 is running, the processor 701 communicates with the memory 703 through the communication bus 704, and the machine-readable instructions are called by the processor 701 to execute the above-mentioned method for determining the software upgrade path.

[0099] For example, the processor 701 of the embodiment of the present application reads a computer program from the memory 703 through the communication bus 704 and executes the computer program to implement the following method: obtaining an initial upgrade path, wherein the initial upgrade path includes multiple baseline versions, the baseline version is a formally released vehicle version, the multiple baseline versions are sorted in order of release time, the vehicle version includes a part version corresponding to at least one part, and the part version is used to upgrade the software of the corresponding part; determining an operation bridge from the initial upgrade path according to the starting version, the target version and the upgrade span, wherein the operation bridge includes the starting version, the target version and the intermediate version, the intermediate version includes a baseline version in the initial upgrade path whose release time is after the starting version and is separated from the starting version by an integer multiple of the upgrade span, the starting version is the initial version or the current version; determining the target upgrade path according to the current version and the operation bridge.

[0100] Among them, the processor 701 includes one or more, which can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 701 can be a general-purpose processor, including a central processing unit (CPU), a micro control unit (MCU), a network processor (NP) or other conventional processors; it can also be a dedicated processor, including a neural network processor (NPU), a graphics processor (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. In addition, when there are multiple processors 701, some of them can be general-purpose processors and the other part can be dedicated processors.

[0101] The memory 703 includes one or more, which may be, but not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc.

[0102] Understandably, Figure 7 The structure shown is for illustration only. The electronic device 700 may also include Figure 7 More or fewer components as shown, or with Figure 7 Different configurations are shown. Figure 7Each component shown in can be implemented by hardware, software or a combination thereof. In the embodiment of the present application, the electronic device 700 can be, but not limited to, a physical device such as a desktop computer, a laptop computer, a smart phone, a smart wearable device, a vehicle-mounted device, etc., and can also be a virtual device such as a virtual machine. In addition, the electronic device 700 is not necessarily a single device, but can also be a combination of multiple devices, such as a server cluster, etc.

[0103] The method in the present application can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by 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 on a computer, the process or function described in the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, a core network device, an OAM or other programmable device.

[0104] The computer program or instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-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 computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center 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.

[0105] An embodiment of the present application also provides a vehicle, comprising the electronic device of the aforementioned embodiment.

[0106] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer program instructions. When the computer program instructions are executed by a computer, the computer executes the method for determining a software upgrade path described in the aforementioned method embodiment.

[0107] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0108] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0109] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0110] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM) random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0111] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0112] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for determining a software upgrade path, characterized in that: include: Obtaining an initial upgrade path, wherein the initial upgrade path includes multiple baseline versions, the baseline version is a formally released vehicle version, the multiple baseline versions are sorted in order of release time, the vehicle version includes a part version corresponding to at least one part, and the part version is used to upgrade software of the corresponding part; Determine an operation bridge from the initial upgrade path according to a starting version, a target version, and an upgrade span, wherein the operation bridge includes the starting version, the target version, and an intermediate version, the intermediate version includes a baseline version in the initial upgrade path whose release time is after the starting version and is separated from the starting version by an integral multiple of the upgrade span, and the starting version is the initial version or the current version; A target upgrade path is determined according to the current version and the operation bridge.

2. The method for determining a software upgrade path according to claim 1, characterized in that: The step of determining the operation bridge from the initial upgrade path according to the starting version, the target version, and the upgrade span includes: Determine the starting version and the intermediate version in the initial upgrade path as baseline versions in the operation bridge; If the intermediate version includes the target version, the intermediate version that is the same as the target version is determined as the target version; otherwise, the target version in the initial upgrade path is determined as the baseline version in the operation bridge.

3. The method for determining a software upgrade path according to claim 2, characterized in that: When the starting version is the initial version, determining a target upgrade path according to the current version and the operation bridge includes: If the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline versions included in the target upgrade path.

4. The method for determining a software upgrade path according to claim 2, wherein: When the starting version is the current version, determining a target upgrade path according to the current version and the operation bridge includes: The baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path.

5. The method for determining a software upgrade path according to any one of claims 1 to 4, characterized in that: The obtaining of the initial upgrade path includes: Obtaining the multiple baseline versions; Sorting the multiple baseline versions in the order of their official release time to obtain the initial upgrade path; or, Get the latest baseline version; Based on the release time corresponding to the latest baseline version, the latest baseline version is added to the initial upgrade path to obtain a new initial upgrade path.

6. The method for determining a software upgrade path according to claim 1, characterized in that: The initial upgrade path further includes at least one technology bridge, one technology bridge corresponds to a baseline version, and upgrading to the baseline version requires first upgrading to the corresponding technology bridge, and the technology bridge includes at least one dependent version, one dependent version corresponds to a component version in the baseline version corresponding to the technology bridge; The step of determining the operation bridge from the initial upgrade path according to the starting version, the target version, and the upgrade span includes: Determine the starting version and the intermediate version in the initial upgrade path as baseline versions in the operation bridge; If the intermediate version includes the target version, the intermediate version that is the same as the target version is determined as the target version; otherwise, the target version in the initial upgrade path is determined as the baseline version in the operation bridge; The technical bridge corresponding to the starting version and the technical bridge corresponding to the baseline version whose release time is between the starting version and the target version are determined as technical bridges in the operation bridge.

7. The method for determining a software upgrade path according to claim 6, characterized in that: When the starting version is the initial version, determining a target upgrade path according to the current version and the operation bridge includes: If the release time corresponding to the current version is not later than the release time corresponding to the initial version, the baseline version included in the operation bridge is determined as the baseline version included in the target upgrade path; otherwise, the current version and the baseline version in the operation bridge whose release time is later than the release time corresponding to the current version are determined as the baseline versions included in the target upgrade path; A technology bridge corresponding to a baseline version whose release time is between the current version and the target version is determined as a technology bridge in the target upgrade path.

8. The method for determining a software upgrade path according to claim 6, characterized in that: When the starting version is the current version, determining a target upgrade path according to the current version and the operation bridge includes: Determining the baseline version included in the operation bridge as the baseline version included in the target upgrade path; A technology bridge corresponding to a baseline version whose release time is between the current version and the target version is determined as a technology bridge in the target upgrade path.

9. The method for determining a software upgrade path according to any one of claims 6 to 8, characterized in that: The obtaining of the initial upgrade path includes: Receiving multiple component versions and multiple dependent versions, and associating each dependent version with a corresponding component version to obtain the baseline version and the technology bridge corresponding to the baseline version; Sorting multiple baseline versions in the order of their official release time and adding the technology bridge to obtain the initial upgrade path; or, Receiving the latest component version and the latest dependency version, and associating each latest dependency version with the corresponding latest component version, to obtain the latest baseline version and the latest technology bridge corresponding to the latest baseline version; Based on the release time corresponding to the latest baseline version, the latest baseline version and the latest technology bridge are added to the initial upgrade path to obtain a new initial upgrade path.

10. An electronic device, characterized in that: include: Processor and memory; The memory stores computer program instructions executable by the processor, and the processor can execute the method according to any one of claims 1 to 9 by calling the computer program instructions.

11. A vehicle, characterized in that: Comprising the electronic device as claimed in claim 10.

12. A computer program product, characterized in that The computer program product includes instructions, which, when executed by a computer, enable the computer to implement the method for determining a software upgrade path according to any one of claims 1 to 9.

Images