Upgrading method and system based on whole vehicle software package, vehicle and program product

Abstract

The invention relates to the technical field of automobiles, and provides an upgrading method and system based on a whole vehicle software package, a vehicle and a program product. The upgrading method based on the whole vehicle software package comprises the steps that the whole vehicle software package is obtained, the whole vehicle software package comprises a dependency configuration file and multiple pieces of upgrading software, and the dependency configuration file comprises the incidence relation between the upgrading software and configuration parameters in associated software; determining whether the hardware number of the target vehicle part exists in a dependency configuration file; if yes, according to the incidence relation, target upgrading software is determined through the hardware number of the target vehicle part; and performing software upgrading on the electronic control unit of the target vehicle part through the target upgrading software. The problem that the unique upgrade software cannot be determined through the hardware number is avoided, the reuse rate of the upgrade software is improved, and the management cost of the whole vehicle software package is reduced.

Description

Technical Field

[0001] The present disclosure relates to the field of automobile technology, and in particular to an upgrade method based on a whole vehicle software package, a whole vehicle software package generation method, an upgrade system based on a whole vehicle software package, a whole vehicle software package generation system, a vehicle, and a computer program product. Background Art

[0002] The vehicle software package is used to maintain the software configuration of various ECUs (Electronic Control Units) in the vehicle. The precise pairing of software and ECU is the key link to realize the flashing of the vehicle software package. Usually, the software can be flashed on the ECU if the hardware number supported by the software matches the hardware number of the vehicle part controlled by the ECU. However, multiple vehicle parts with the same hardware number may have different configuration parameters, such as battery voltages of 400V and 800V respectively. If the ECUs that control these vehicle parts need to be flashed with different software, even if the remaining ECU software in multiple vehicles with these vehicle parts can be reused, in order to overcome the pairing problem between ECU and software, the relevant technology will package multiple vehicle software packages according to the number of configuration parameters. This method undoubtedly reduces the reuse rate of the vehicle software package and increases the difficulty of maintenance. Summary of the invention

[0003] The present disclosure provides an upgrade method based on a whole-vehicle software package, a whole-vehicle software package generation method, an upgrade system based on a whole-vehicle software package, a whole-vehicle software package generation system, a vehicle, and a computer program product.

[0004] According to one aspect of the present disclosure, there is provided an upgrade method based on a whole vehicle software package, for upgrading an electronic control unit of a target vehicle part, comprising: obtaining a whole vehicle software package, the whole vehicle software package comprising a dependency configuration file and a plurality of upgrade software, the dependency configuration file comprising an association relationship between each upgrade software and a configuration parameter in the associated software, the associated software being two or more upgrade software containing the same hardware number, the configuration parameter being a configuration parameter of a vehicle part having the same hardware number in the associated software; determining whether the hardware number of the target vehicle part exists in the dependency configuration file; if the hardware number of the target vehicle part exists in the dependency configuration file, determining the target upgrade software of the target vehicle part through the hardware number of the target vehicle part according to the association relationship in the dependency configuration file; and performing a software upgrade on the electronic control unit of the target vehicle part through the target upgrade software, the electronic control unit being used to control the target vehicle part.

[0005] According to the technical solution of this embodiment, by matching the actual configuration parameters of the target vehicle parts with the dependent configuration files, the target upgrade software can be matched for the target vehicle parts from the dimension of the configuration parameters, thereby avoiding the problem of being unable to determine the unique upgrade software through the hardware number, improving the reuse rate of the upgrade software and reducing the management cost of the entire vehicle software package.

[0006] In some embodiments, the configuration parameters include first-type configuration parameters and second-type configuration parameters, the first-type configuration parameters characterizing categories of vehicle parts, and the second-type configuration parameters characterizing specifications of vehicle parts in the first-type configuration parameters.

[0007] In some embodiments, according to the association relationship in the dependency configuration file, the target upgrade software of the target vehicle part is determined by the hardware number of the target vehicle part, including: obtaining the first type actual configuration parameters and the second type actual configuration parameters of the target vehicle part; searching for the upgrade software that has an association relationship with the hardware number of the target vehicle part in the dependency configuration file; determining whether the first type configuration parameters of the upgrade software are the same as the first type actual configuration parameters; if the first type configuration parameters of the upgrade software are the same as the first type actual configuration parameters, determining whether the second type configuration parameters of the upgrade software are the same as the second type actual configuration parameters; and if the second type configuration parameters of the upgrade software are the same as the second type actual configuration parameters, determining that the upgrade software is the target upgrade software.

[0008] According to the technical solution of this embodiment, the dependent configuration file is compared with the actual configuration parameters of the target vehicle parts, overcoming the one-to-many problem between the hardware number and the upgrade software, and achieving the effect of accurately matching the target vehicle parts with the target upgrade software.

[0009] In some embodiments, after obtaining the whole vehicle software package, it also includes: according to the hardware number of the target vehicle part, searching for the archived configuration parameters of the target vehicle part from the data maintenance terminal, the configuration parameters in the whole vehicle software package are the archived configuration parameters, and the data maintenance terminal is used to record the archived configuration parameters; and when the actual configuration parameters of the target vehicle part are the same as the archived configuration parameters of the target vehicle part, the whole vehicle software package is verified to be qualified.

[0010] According to the technical solution of this embodiment, by judging the consistency between the actual configuration parameters and the archived configuration parameters, the compatibility of the vehicle software package with the target vehicle parts is ensured, avoiding the problem of flashing failure caused by inconsistency between the archived configuration parameters and the actual configuration parameters.

[0011] In some embodiments, performing a software upgrade on the electronic control unit of the target vehicle part through the target upgrade software includes: obtaining the current software version of the electronic control unit of the target vehicle part; determining whether a dependent version of the target upgrade software is the same as the current software version, the dependent version being a condition for the electronic control unit to run the target upgrade software; if the dependent version is the same as the current software version, verifying that the target upgrade software is qualified; and performing a software upgrade on the electronic control unit of the target vehicle part through the verified qualified target upgrade software.

[0012] According to the technical solution of this embodiment, by comparing the current software version of the electronic control unit with the dependent version of the target upgrade software, the compatibility of the software environment of the electronic control unit and the target upgrade software is ensured, avoiding the problem of failure in flashing the target upgrade software.

[0013] According to another aspect of the present disclosure, a method for generating a whole vehicle software package is provided, comprising: obtaining a plurality of upgrade software, wherein the upgrade software comprises a hardware number of a vehicle part; determining associated software among the plurality of upgrade software, wherein the associated software comprises two or more upgrade software comprising the same hardware number; generating a dependency configuration file according to configuration parameters of the associated software, wherein the configuration parameters are configuration parameters of the vehicle part having the same hardware number in the associated software, and the dependency configuration file comprises an association relationship between each upgrade software and the configuration parameters in the associated software; and packaging the plurality of upgrade software with the dependency configuration file to generate a whole vehicle software package.

[0014] According to the technical solution of the present embodiment, by adding a solution of dependent configuration files in the whole vehicle software package, it is feasible to integrate the upgrade software corresponding to the same hardware number and different configuration parameters into the same whole vehicle software package, thereby avoiding the problem of being unable to determine the unique upgrade software by the hardware number, improving the reuse rate of the upgrade software and reducing the management cost of the whole vehicle software package.

[0015] In some embodiments, generating a dependency configuration file based on the configuration parameters of the associated software includes: determining the configuration parameters of each upgrade software in the associated software; associating the configuration parameters with the software identifier of the upgrade software having the configuration parameters to generate dependency data; and generating the dependency configuration file based on the dependency data.

[0016] In some implementations, packaging the multiple upgrade software with the dependency configuration file includes: verifying the dependency configuration file, and packaging the multiple upgrade software with the dependency configuration file that passes the verification.

[0017] In some embodiments, the dependency configuration file is verified, including: determining whether the non-associated software has the same hardware number as the remaining upgrade software, the non-associated software being the upgrade software that does not belong to the associated software among the multiple upgrade software; and failing the verification of the dependency configuration file if the software has the same hardware number; or passing the verification of the dependency configuration file if the software does not have the same hardware number.

[0018] In some embodiments, verifying the dependency configuration file includes: determining whether first type configuration parameters of each upgrade software in the associated software are the same, the configuration parameters including the first type configuration parameters and the second type configuration parameters, the first type configuration parameters representing the category of the vehicle part, and the second type configuration parameters representing the specifications of the vehicle part in the first type configuration parameters; in a case where the first type configuration parameters are the same, the verification of the dependency configuration file fails; or in a case where the first type configuration parameters are different, determining whether the second type configuration parameters of each upgrade software in the associated software are the same; and in a case where the second type configuration parameters are different, the verification of the dependency configuration file passes; or in a case where the second type configuration parameters are the same, the verification of the dependency configuration file fails.

[0019] According to the technical solution of this embodiment, the integrity and availability of the dependent configuration file are guaranteed through the above-mentioned two verification mechanisms for the dependent configuration file, thereby avoiding the flashing failure caused by problems with the dependent configuration file.

[0020] According to another aspect of the present disclosure, there is provided an upgrade system based on a whole vehicle software package, comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following process: obtaining a whole vehicle software package, wherein the whole vehicle software package comprises a dependency configuration file and a plurality of upgrade software, wherein the dependency configuration file comprises an association relationship between each upgrade software and a configuration parameter in associated software, wherein the associated software comprises two or more upgrade software comprising the same hardware number, and the configuration parameter is a configuration parameter of a vehicle part having the same hardware number in the associated software; determining whether the hardware number of the target vehicle part exists in the dependency configuration file; if the hardware number of the target vehicle part exists in the dependency configuration file, determining the target upgrade software of the target vehicle part through the hardware number of the target vehicle part according to the association relationship in the dependency configuration file; and performing a software upgrade on an electronic control unit of the target vehicle part through the target upgrade software, wherein the electronic control unit is used to control the target vehicle part.

[0021] According to another aspect of the present disclosure, a whole vehicle software package generation system is provided, including a processor and a memory, the memory storing a computer program, when the computer program is executed by the processor, the processor performs the following process: obtaining multiple upgrade software, the upgrade software including the hardware number of a vehicle part; determining associated software among the multiple upgrade software, the associated software being two or more upgrade software including the same hardware number; generating a dependency configuration file according to configuration parameters of the associated software, the configuration parameters being the configuration parameters of the vehicle part having the same hardware number in the associated software, the dependency configuration file including the association relationship between each upgrade software and the configuration parameters in the associated software; and packaging the multiple upgrade software with the dependency configuration file to generate a whole vehicle software package.

[0022] According to yet another aspect of the present disclosure, a vehicle is provided, the vehicle comprising an upgrade system based on a whole vehicle software package and a whole vehicle software generation system as described above.

[0023] According to another aspect of the present disclosure, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, it is used to implement at least the method as described in any one of the above embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] 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.

[0025] Figure 1 It is a schematic diagram of the pairing method of the software and ECU when the vehicle software package is flashed.

[0026] Figure 2 It is a schematic diagram of an application scenario of the method for generating a whole vehicle software package according to an embodiment of the present disclosure.

[0027] Figure 3 It is an interactive schematic flow chart of the entire process of generating and upgrading the vehicle software package according to an embodiment of the present disclosure.

[0028] Figure 4 It is a schematic diagram of the dependency configuration file structure according to an embodiment of the present disclosure.

[0029] Figure 5 It is a schematic flowchart of the whole vehicle software package generation process according to an embodiment of the present disclosure.

[0030] Figure 6 It is a flow chart of a method for generating a whole vehicle software package according to an embodiment of the present disclosure.

[0031] Figure 7 It is a schematic flowchart of the upgrade process based on the whole vehicle software package according to an embodiment of the present disclosure.

[0032] Figure 8 It is a schematic diagram of the pairing method of the software and the ECU when the vehicle software package is flashed according to an embodiment of the present disclosure.

[0033] Fig. 9 It is a flow chart of an upgrade method based on a whole vehicle software package according to an embodiment of the present disclosure.

[0034] Fig.10 is a schematic diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0035] 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.

[0036] 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.

[0037] The precise matching between the upgrade software and the vehicle ECU (Electronic Control Unit) is the key link in flashing the whole vehicle software package. Usually, in the process of generating the whole vehicle software package, the hardware number of the vehicle parts that the upgrade software can support will be determined; then, in the process of flashing the software package, the supported hardware number and the hardware number of the vehicle part controlled by the ECU are matched to complete the pairing of the software and the ECU. However, some types of vehicle parts have multiple specifications. These vehicle parts of the same type but different specifications share the same hardware number, and the ECUs of these vehicle parts need to be flashed with different upgrade software according to their specifications. If they are integrated in the same whole vehicle software package, the matching of the software and the ECU cannot be achieved through the hardware number. If the whole vehicle software package is not built separately, the reuse rate of the remaining reusable ECU upgrade software in the vehicle is reduced, and the maintenance cost is increased.

[0038] Figure 1 This is a schematic diagram of the pairing method between software and ECU when flashing the vehicle software package. Figure 1, which intuitively shows the problems that arise when matching only by hardware number. Assume that the BBM (Battery Balance Management) in the vehicle software package corresponds to software 1 and software 2, and the configuration parameters applicable to software 1 are 400V batteries and the supported hardware number is A; the configuration parameters applicable to software 2 are 800V batteries and the supported hardware number is also A. When the vehicle software package containing software 1 and software 2 is sent to a vehicle equipped with a battery with hardware number A, if the software and ECU are matched only by the hardware number, the BBM of the 800V battery in the vehicle will be matched to software 1 and software 2 at the same time, and the flashing process will fail because it cannot match the only upgrade software for BBM.

[0039] Figure 2 It is a schematic diagram of an application scenario of the method for generating a whole vehicle software package according to an embodiment of the present disclosure.

[0040] refer to Figure 2 The vehicle software package generation method is executed by the VSP (Vehicle Service Platform) built on the cloud 100. The VSP generates a vehicle software package including a dependent configuration file by executing the vehicle software package generation method, and synchronizes the vehicle software package to the vehicle 110 through the network or other means. If the hardware number of a vehicle part controlled by an ECU in the vehicle 110 falls into the dependent configuration file, then according to the first type actual configuration parameter and the second type actual configuration parameter of the ECU, the target upgrade software adapted to its actual configuration parameter is located in the dependent configuration file, and then the ECU is upgraded using the target upgrade software. In this way, the problem of low reuse rate caused by generating multiple vehicle software packages when multiple vehicle parts of the same category share the same hardware number but have different specifications is avoided, and the maintenance cost of the vehicle software package is reduced.

[0041] ECU: An electronic control unit for a vehicle part that controls the vehicle part by running software that is appropriate for the vehicle part (including category and specification).

[0042] The vehicle parts involved in the present disclosure are automobile parts that can be monitored by the ECU and receive ECU adjustment functions.

[0043] Hardware number: A number used to identify vehicle parts. Vehicle parts of the same category but different specifications share the same hardware number.

[0044] Upgrade software: contains supported hardware numbers and configuration parameters of applicable vehicle parts. Supported hardware numbers are the hardware numbers of vehicle parts that can be controlled by the applicable ECU, and configuration parameters contain the categories and specifications of applicable vehicle parts. The upgrade software and its supported hardware numbers and configuration parameters are used to upgrade the corresponding ECUs, so as to repair the original problems of the ECU, add new functions to the ECU, or improve its performance.

[0045] Vehicle software package: includes at least one upgrade software and dependent configuration files for each ECU in the corresponding vehicle model, which is used to perform software upgrades for each ECU in the vehicle belonging to the model.

[0046] Dependency configuration file: records the associated software of the vehicle software package, as well as the relationship between the software identifiers of each upgrade software in the associated software and the configuration parameters of the controlled vehicle parts, including at least the software ID (Identification), the supported hardware number, and the correspondence between the first type of configuration parameters and the second type of configuration parameters of the applicable vehicle parts.

[0047] Associated software: two or more upgrade software with the same hardware number in the vehicle software package.

[0048] Configuration parameters: include first-type configuration parameters and second-type configuration parameters. The first-type configuration parameters represent the categories of vehicle parts (such as batteries, wheels), and the second-type configuration parameters represent the specifications of vehicle parts (such as battery voltage, wheel size).

[0049] VSP: It is the executive body of the vehicle software package generation method, used to generate upgrade software for various ECUs in corresponding vehicle models, and to generate dependent configuration files based on the hardware number and configuration parameters of these upgrade software.

[0050] Data maintenance terminal: used to maintain the ECU-related information uploaded by the vehicle, including the hardware number and configuration parameters of the vehicle parts controlled by the ECU; and provide data support for VSP to generate the vehicle software package.

[0051] Figure 3 It is an interactive schematic flow chart of the whole process of generating and upgrading the vehicle software package according to the embodiment of the present disclosure. Figure 3 , six steps from step 201 to step 206 are the process of generating the vehicle software package, and ten steps from step 208 to step 217 are the upgrade process based on the vehicle software package. In the process of generating the vehicle software package and using the vehicle software package to upgrade each ECU of the vehicle, the vehicle side, VSP and data maintenance side are mainly involved. Through the data interaction between these three, it is feasible to merge the ECU upgrade software of the same model with different specifications into the same vehicle software package, thereby improving the reuse rate of various upgrade software and reducing maintenance costs.

[0052] In step 201, the vehicle end sends relevant information of all ECUs in the vehicle to the data maintenance end, and the relevant information includes at least the hardware number and configuration parameters of the vehicle parts controlled by the ECU. The configuration parameters include the first type configuration parameters and the second type configuration parameters of the vehicle parts controlled by the ECU. For example, the first type configuration parameter corresponding to the ECU that controls the wheel is the wheel, and the second type configuration parameter is the wheel size (for example, R1); or, the first type configuration parameter corresponding to the ECU that controls the battery is the battery, and the second type configuration parameter is the battery voltage (for example, 400V). The specifications corresponding to the ECUs that control the same category of vehicle parts in the same vehicle model may be different, so the first type configuration parameters of different vehicles of the same vehicle model are the same, and the second type configuration parameters are different. In order to fully understand the possible categories or specifications of each ECU in each vehicle model, the relevant information of the ECU will be obtained from the vehicle end of each vehicle.

[0053] In step 202, the data maintenance terminal synchronizes the relevant information of all ECUs of the vehicle model required by the VSP to the VSP. The relevant information of the ECU includes at least the hardware number of the vehicle part controlled by the ECU and its archived configuration parameters.

[0054] In step 203, the VSP generates upgrade software suitable for various ECUs based on the data synchronized by the data maintenance end and the upgrade requirements; and determines the associated software that supports the same hardware number in multiple upgrade software. Based on what has been described above, there are some categories of vehicle parts that have different specifications but share the same hardware number; due to the different specifications of vehicle parts, the upgrade software of the ECU that controls these vehicle parts is usually different. Therefore, it is necessary to find two or more upgrade software that support the same hardware number among all the generated upgrade software, and treat the two or more upgrade software that support the same hardware number as a group of associated software. There can be multiple groups of associated software in multiple upgrade software of the same vehicle model. The associated software is the basis for the generation of the dependency configuration file, which limits the scope of the upgrade software recorded in the dependency configuration file.

[0055] In step 204, the VSP generates a dependency configuration file based on the associated software. Specifically, for any group of associated software, the software ID of each upgrade software in the associated software, the configuration parameters supported by the upgrade software, and the supported hardware number are extracted; then, a corresponding relationship between these information is established to form dependency data about the upgrade software. Through the aforementioned method, each upgrade software in the associated software and each group of associated software are traversed to obtain multiple dependency data, and finally these dependency data are integrated into a dependency configuration file. Through the dependency configuration file, an association is established for the upgrade software, the hardware number, and the configuration parameters, providing data support for packaging multiple upgrade software supporting the same hardware number in the same software package.

[0056] Figure 4 Schematic diagram of the dependency configuration file structure according to an embodiment of the present disclosure. Figure 4 The dependency configuration file is composed of multiple dependency data, each dependency data records the relationship between the upgrade software, the supported hardware number, the first type configuration parameters, and the second type configuration parameters. For example, software i is suitable for controlling vehicle parts of category m and specification n with hardware number X. Category m can be, for example, wheels, and specification n can be, for example, size R1. Vehicle parts of different categories in different vehicles have different specifications, which are not listed here one by one. The number of upgrade software with the same hardware number in different vehicles is different, so the number of dependency data in the dependency configuration file is also different. In addition, when VSP generates the upgrade software and determines the dependency configuration file, the hardware number and configuration parameters involved are the hardware number and archived configuration parameters provided by the data maintenance end.

[0057] In step 205, the VSP verifies the dependency configuration file.

[0058] One of the contents of the verification is: whether the non-associated software of the vehicle model has the same hardware number as the other upgrade software. Non-associated software refers to the upgrade software that is not associated software among the multiple upgrade software of the vehicle model. In other words, if a certain upgrade software supports the same hardware number as the other upgrade software, but the upgrade software is not recorded in the dependency configuration file, then it means that the dependency configuration file formed does not record all the associated software, and the recorded content is not comprehensive enough. If the vehicle performs a software upgrade on the corresponding ECU, the flashing will fail because the dependency data of the upgrade software cannot be found. Therefore, in order to ensure the feasibility of the vehicle software package, the dependency configuration file should include the dependency data of the associated software to avoid the problem of one ECU corresponding to multiple upgrade software when the vehicle is flashing the software package.

[0059] The second content of the inspection is: it is also necessary to ensure that the first type configuration parameters of two or more upgrade software with the same hardware number in the dependent configuration file are the same and the second type configuration parameters are different. For example, both software 1 and software 2 support vehicle parts with hardware number A, but the first type configuration parameter of the vehicle parts with hardware number A supported by software 1 is the wheel, and the first type configuration parameter of the vehicle parts with hardware number A supported by software 2 is the battery. Obviously, the categories of vehicle parts corresponding to software 1 and software 2 are different, but the supported hardware numbers overlap in vehicle parts of different categories, indicating that there is a problem with the hardware number supported by the upgrade software or the dependent configuration file during the configuration process. For another example, the first type configuration parameters of the vehicle parts with hardware number A corresponding to software 1 and software 2 are both wheels, and the second type configuration parameters corresponding to the two are both R1, which means that the upgrade software is redundant when it is generated; or, the dependent configuration information is wrong during the generation process. In short, if any of the above two situations occurs, the verification of the dependent configuration file will not pass; it needs to be fed back to manual verification, and steps 203 to 205 are re-executed until the verification passes.

[0060] If the verification is passed, step 206 is executed, and the VSP generates a vehicle software package including a dependent configuration file. The vehicle software package includes multiple upgrade software for various ECUs in the vehicle model, and the dependent configuration file.

[0061] The above two verification mechanisms for dependent configuration files ensure the integrity and availability of the dependent configuration files, thus avoiding the problem of software flashing failure due to errors in the dependent configuration files.

[0062] In step 207, the VSP sends the vehicle software package to the vehicle side. The vehicle model corresponding to the vehicle side should be the vehicle model adapted by the vehicle software package, and all ECUs in the vehicle side can find the corresponding upgrade software in the vehicle software package.

[0063] After the vehicle side determines the hardware numbers of the vehicle parts that can be supported by each ECU of its own vehicle, it executes step 208 to determine whether these hardware numbers all exist in the vehicle software package. This step is a verification of the compatibility of the vehicle software package with the vehicle by the vehicle side. If all the hardware numbers corresponding to the vehicle exist in the vehicle software package, it proves that the vehicle software package sent by the VSP is compatible with the vehicle corresponding to the vehicle side. The vehicle side is a system in the vehicle used to control ECU upgrades, including a vehicle gateway that interacts with the VSP or the data maintenance side.

[0064] In step 209, when the hardware numbers of all vehicle parts exist in the vehicle software package, the vehicle end determines all the hardware numbers recorded in the dependency configuration file, and then sends a read request including the vehicle unique identifier and all the hardware numbers recorded in the dependency configuration file to the data maintenance end to obtain the archived configuration parameters about these hardware numbers recorded by the data maintenance end.

[0065] In step 210, the data maintenance end responds to the read request and feeds back the archive configuration parameters corresponding to the hardware number in step 209 to the vehicle end.

[0066] In step 211, the vehicle side obtains the actual configuration parameters of the hardware number in the vehicle according to the hardware number recorded in the dependency configuration file. Then, step 212 is executed to determine whether the actual configuration parameters are consistent with the archived configuration parameters fed back by the data maintenance side. Specifically, since the VSP cannot predict the specific vehicle that may be upgraded using this vehicle software package when building the upgrade software and dependency configuration file for each ECU of the vehicle model, it is necessary to obtain the configuration information of the corresponding ECU at the data maintenance side. After the vehicle sends the configuration information of its own ECU to the data maintenance side (i.e., step 201), the vehicle parts may be replaced, for example, the battery of the vehicle is changed from 400V to 800V, and it may not be synchronized to the data maintenance side in time. Therefore, the vehicle side needs to actively verify whether the actual configuration parameters of the vehicle parts are consistent with the archived configuration parameters at the time of flashing the software package. If they are consistent, it proves that the dependency configuration file is valid for the vehicle; otherwise, it proves that the dependency configuration file is set based on the original ECU of the vehicle side and is not applicable to the current state of the vehicle, and the verification fails.

[0067] If the vehicle-side verification of the whole vehicle software package passes, step 213 is executed, and the vehicle-side determines whether the hardware number of the target vehicle part exists in the dependent configuration file. If the hardware number of the target vehicle part exists in the dependent configuration file, it proves that there are at least two upgrade software in the whole vehicle software package that can support the hardware number of the target vehicle part, and it is necessary to use the actual configuration parameters of the target vehicle part to compare with the configuration parameters supported by each upgrade software; screen out the upgrade software with the same configuration parameters as the actual configuration parameters as the target upgrade software. On the contrary, if the hardware number of the target vehicle part does not exist in the dependent configuration file, it proves that only the only upgrade software in the whole vehicle software package can support the hardware number, then the upgrade software is directly used as the target upgrade software to upgrade the ECU that controls the target vehicle part, and there will be no matching problem between the ECU and the upgrade software.

[0068] By verifying whether the actual configuration parameters of each vehicle part are consistent with the archived configuration parameters on the data maintenance end, the validity of the dependent configuration files generated based on the archived configuration parameters is guaranteed, avoiding the problem of incompatibility due to vehicle part replacement.

[0069] If the hardware number of the target vehicle part exists in the dependency configuration file, step 214 is executed to determine the target upgrade software of the ECU that controls the target vehicle part according to the dependency configuration file and the actual configuration parameters of the target vehicle part. Specifically, if the hardware number of the target vehicle part exists in the dependency configuration file, it proves that there are at least two upgrade software in the vehicle software package that can support the ECU that controls the target vehicle part. In order to determine the upgrade software that is truly compatible with the ECU, it is necessary to first retrieve the first type of actual configuration parameters and the second type of actual configuration parameters of the target vehicle part; then traverse the dependency data corresponding to the hardware number in the dependency configuration file, find the dependency data with the first type of actual configuration parameters as the first configuration parameters and the second type of actual configuration parameters as the second configuration parameters, and locate the target upgrade software in the vehicle software package according to the software ID of the dependency data. The control logic of the target upgrade software is compatible with the category and specification of the target vehicle part, and can be used to upgrade the ECU that controls the target vehicle part to repair the problem of the ECU, increase the function of the ECU, or upgrade its version.

[0070] In step 215, the vehicle side obtains the current software version of the ECU that controls the target vehicle parts in the vehicle. Then, the vehicle side executes step 216 to determine whether the current software version is the same as the dependent version of the target upgrade software. The dependent version indicates the operating environment on which the target upgrade software depends. In steps 215 to 216, the vehicle side verifies the flashing environment of the determined target upgrade software to ensure that the current operating environment of the ECU can support the flashing of the target upgrade software. For example, the target upgrade software is used to repair certain problems of the 3.0 version running by the corresponding ECU, so the software currently running by the ECU should be version 3.0; on the contrary, if the software running by the ECU is version 1.0 or version 2.0, it is obvious that the target upgrade software cannot find the object to be repaired in the current software version, and it is not feasible to flash it, so the verification fails and the software of the ECU is not flashed.

[0071] However, if the current software version of the ECU is the same as the dependent version of the target upgrade software, the vehicle side executes step 217 to upgrade the ECU using the target upgrade software. When software is flashed to each ECU in the vehicle, steps 213 to 217 need to be executed.

[0072] By judging whether the current software version of the ECU is the same as the dependent version of the target upgrade software, the feasibility of ECU flashing is guaranteed and the problem of flashing failure is overcome.

[0073] Based on the foregoing, it can be seen that in the process of generating the vehicle software package, VSP is the execution subject of the software package generation method. Figure 5 is a schematic flow chart of the vehicle software package generation process according to the embodiment of the present disclosure, and the following is combined with Figure 5 Steps 203 to 207 performed by the VSP are described in more detail to illustrate the generation and verification process of the dependency configuration file.

[0074] VSP will configure upgrade software for each ECU in any vehicle model and the iteration requirements of each ECU under different configuration parameters according to the vulnerability issues, new functions and version iterations of each ECU software in any vehicle model maintained. Usually, the software versions of multiple upgrade software belonging to the same vehicle software package are consistent. When generating the upgrade software, the ECU type of the current vehicle model and the archived configuration parameters of each ECU are obtained from the data maintenance end. Each upgrade software contains software ID, supported hardware number, upgrade program, applicable configuration parameters, etc.

[0075] After generating the upgrade software corresponding to each ECU, the associated software in the multiple upgrade software is determined. Specifically, according to the hardware number supported by the upgrade software, the upgrade software supporting the same hardware number is confirmed as the associated software, and each upgrade software can support one or more hardware numbers. In other words, when two or more upgrade softwares support the same hardware number in the multiple upgrade softwares of the vehicle model, when the vehicle performs the whole vehicle software package flashing, the ECUs involving these same hardware numbers will correspond to multiple upgrade softwares, which will not be successfully flashed due to the difficulty in selection. Therefore, it is necessary to provide a multi-dimensional matching mechanism for multiple upgrade softwares supporting the same hardware number. In this method, the configuration parameters are used as another matching condition between the upgrade software and the ECU. The prerequisite for realizing this matching mechanism is to find multiple groups of associated softwares that share the same hardware number in multiple upgrade softwares, and each group of associated softwares contains more than two upgrade softwares that support the same hardware number. Among them, the number of upgrade softwares in each group of associated softwares is not fixed, and the number of groups of associated softwares is not fixed. They are all set according to the actual situation and are not limited here.

[0076] Furthermore, after the associated software is determined, dependency data is generated according to the software ID of each upgrade software in the associated software, the same hardware number supported, the first type configuration parameters and the second type configuration parameters corresponding to the upgrade software. Each upgrade software in the associated software will form such a dependency data, and multiple dependency data of each group of associated software are listed in a dependency data table to form a dependency configuration file. For example, there are dependency data "software 1-hardware number A-battery-voltage 400V" and "software 2-hardware number A-battery-voltage 800V" in the dependency configuration file. Then, when the vehicle's ECU corresponds to a battery with hardware number A and voltage 800V, through layer-by-layer matching, software 2 can be located as its upgrade software, avoiding the disadvantage of matching only by hardware number.

[0077] Furthermore, after the dependent configuration file is determined, it is necessary to verify it in order to ensure its accuracy. First, determine whether the non-associated software has the same hardware number as the rest of the upgrade software. The non-associated software is the upgrade software that does not belong to the associated software among multiple upgrade software; and in the case of having the same hardware number, the verification of the dependent configuration file fails; or, in the case of not having the same hardware number, the verification of the dependent configuration file passes. The main function of the dependent configuration file is to record the relationship between each upgrade software and the corresponding configuration parameters in the associated software, and solve the problem that one hardware number corresponds to more than two upgrade software that cannot be matched. If the dependent configuration file cannot cover the dependency data of all associated software, then the dependent configuration file cannot guarantee the feasibility of the vehicle software package. If the verification of the dependent configuration file fails, feedback should be given to manually supplement it. On the contrary, the dependent configuration file passes the verification under this verification condition.

[0078] Further, in the dependency configuration file, it is determined whether the first type configuration parameters and the second type configuration parameters of two or more upgrade software supporting the same hardware number exist. If the first type configuration parameters or the second type configuration parameters of any upgrade software are empty, the dependency data cannot play a pairing role in the matching process between the ECU and the software, and the verification of the dependency configuration file fails. Further, in the dependency configuration file, if the first type configuration parameters and the second type configuration parameters of two or more upgrade software with the same hardware number exist, it is determined whether the first type configuration parameters of the two or more upgrade software with the same hardware number are the same. For example, the first type configuration parameters of the upgrade software with the same hardware number are all wheels, or all batteries. If the first type configuration parameters of the upgrade software with the same hardware number are different, then the upgrade software corresponding to the ECU of different categories of vehicle parts does not have the meaning of comparing the second type configuration parameters; and, usually different categories of vehicle parts should have different hardware numbers, so the dependency configuration file needs to be verified, and the verification fails at this time.

[0079] Furthermore, if the first type configuration parameters of two or more upgrade software with the same hardware number are the same, then it is necessary to verify whether the second type configuration parameters of these upgrade software are the same. For example, the first type configuration parameters of the upgrade software with the same hardware number are all batteries, and the second type configuration parameters are 400V and 800V respectively. Then, when an ECU for controlling a battery with a voltage of 400V and the same hardware number appears, the only upgrade software can be selected for it through the second type configuration parameters. On the contrary, if on the basis of the above, the second type configuration parameters are all 400V, then these upgrade software have no difference in configuration parameters and hardware numbers, and it is necessary to manually verify whether these upgrade software are redundant, or whether at least one of the hardware number and configuration parameters is statistically incorrect, and the verification fails at this time.

[0080] By verifying the dependent configuration files, their integrity, availability and accuracy are guaranteed, providing support for writing multiple upgrade software corresponding to the same hardware number into the same vehicle software package, thereby improving the reuse rate of the upgrade software.

[0081] If the aforementioned multiple checks are passed, then the dependent configuration file is qualified, and a vehicle software package containing the dependent configuration file and multiple upgrade software can be generated. When the software package is sent to the vehicle for flashing, if the unique upgrade software cannot be determined by the hardware number, the unique upgrade software can be matched from the dependent configuration file based on the hardware number and configuration parameters, overcoming the one-to-many matching problem, making it feasible to package upgrade software that supports the same hardware number but different configuration parameters into the same software package, improving the reuse rate of the upgrade software and reducing the management cost of the vehicle software package.

[0082] In order to implement the aforementioned solution, the present disclosure proposes a method for generating a whole vehicle software package. Figure 6 is a flow chart of a method for generating a vehicle software package according to an embodiment of the present disclosure. Figure 6 The whole vehicle software package generation method M600 includes: step S610, obtaining multiple upgrade software, the upgrade software includes the hardware number of the vehicle part; step S620, determining the associated software among the multiple upgrade software, the associated software is two or more upgrade software including the same hardware number; step S630, generating a dependent configuration file according to the configuration parameters of the associated software, the configuration parameters are the configuration parameters of the vehicle parts with the same hardware number in the associated software, and the dependent configuration file includes the association relationship between each upgrade software and the configuration parameters in the associated software; and step S640, packaging the multiple upgrade software with the dependent configuration file to generate a whole vehicle software package.

[0083] The specific methods and principles for implementing each step in the vehicle software package generation method M600 can be found in the previous text and will not be repeated here.

[0084] In the upgrade process based on the vehicle software package, the vehicle side is the executor of the software package upgrade method. Figure 7 is a schematic flow chart of the upgrade process based on the vehicle software package according to the embodiment of the present disclosure, and the following is combined with Figure 7 Steps 701 to 712 describe steps 208 to 216 executed by the vehicle side in more detail to illustrate the process of verifying and matching the dependency configuration file on the vehicle side.

[0085] The vehicle side includes a vehicle gateway. In step 701, the vehicle software package is obtained from the VSP through the vehicle gateway. In step 702, it is determined whether the hardware numbers corresponding to all ECUs in the vehicle exist in the vehicle software package. This step 702 is the first verification of the vehicle software package. If the hardware number corresponding to a certain ECU in the vehicle is not reflected in any vehicle software package, it proves that the vehicle software package is not suitable for this vehicle; or the vehicle model is not compatible with the vehicle software package, then the vehicle ECU cannot be upgraded using the software package to avoid safety problems due to mismatch.

[0086] If all the hardware numbers in the vehicle exist in the vehicle software package, then step 703 is executed to find the hardware number in the vehicle that exists in the dependent configuration file, and a read request is sent to the data maintenance end, the read request includes the aforementioned hardware number and the vehicle unique identifier. Then, step 704 is executed to obtain the archived configuration parameters of the vehicle parts corresponding to the hardware number in the read request at the data maintenance end.

[0087] Furthermore, for any hardware number recorded in the dependency configuration file, step 705 is executed to determine whether the archived configuration parameters of the vehicle part with the hardware number on the data maintenance end and the actual configuration parameters of the vehicle part with the hardware number in the vehicle are the same. If they are different, it proves that the vehicle part configuration parameters maintained by the data maintenance end are not updated with the replacement of the vehicle parts, then the dependency configuration file obtained based on the archived configuration parameters cannot be used as the matching basis between the ECU and the upgrade software in the vehicle, and the verification of the whole vehicle software package fails. On the contrary, if the archived configuration parameters and the actual configuration parameters of the vehicle parts are the same, it proves that the verification of the whole vehicle software package on the vehicle end has passed.

[0088] By comparing the archived configuration parameters with the actual configuration parameters, the compatibility of the dependent configuration files with the vehicle is ensured.

[0089] Furthermore, if the archived configuration parameters are the same as the actual configuration parameters of the vehicle parts, when the software matching is performed on the ECU controlling the target vehicle parts, step 706 is executed to determine whether the hardware number of the target vehicle parts exists in the dependent configuration file. If it exists in the dependent configuration file, step 707 is executed to determine multiple upgrade software supporting the hardware number of the target vehicle parts in the dependent configuration file; then, step 708 is executed to determine whether the first type configuration parameters of the multiple upgrade software are the same as the first type actual configuration parameters of the target vehicle parts; if they are the same, step 709 is executed to determine the upgrade software whose second type configuration parameters are the same as the second type actual configuration parameters of the target vehicle parts in the multiple upgrade software. Step 711 is executed to determine the target upgrade software; specifically, the upgrade software whose second type configuration parameters obtained through step 709 are the same as the second type actual configuration parameters is used as the target upgrade software. If the first type configuration parameter is different from the first actual type configuration parameter, or the second type configuration parameter is different from the second type actual configuration parameter, it is proved that the corresponding upgrade software is not suitable for the ECU controlling the target vehicle parts. Alternatively, when the hardware number of the target vehicle part does not exist in the dependent configuration file, step 710 is executed to search for the upgrade software corresponding to the hardware number in the vehicle software package; then step 711 is executed to determine the target upgrade software; at this time, the upgrade software obtained through step 710 should be unique, and the upgrade software is used as the target upgrade software. By comparing the actual configuration parameters of the target vehicle part with the dependent configuration file, the ECU of the target vehicle part is controlled to accurately match the target upgrade software.

[0090] Further, step 712 is executed to determine whether the dependent version of the target upgrade software is the same as the current software version of the ECU that controls the target vehicle parts. If they are not the same, it proves that the current software version cannot provide an operating environment for the target upgrade software; otherwise, step 713 is executed to upgrade the ECU version using the target upgrade software, so that the ECU runs the target upgrade software and controls the target vehicle parts in the manner of the target upgrade software. By comparing the consistency of the dependent version of the target upgrade software and the current software version of the ECU, a guarantee is provided for the successful flashing of the target upgrade software.

[0091] Figure 8 Schematic diagram of the pairing method of the software and ECU when flashing the vehicle software package according to the embodiment of the present disclosure. Figure 8As shown, assuming that the actual configuration parameters of the battery in the vehicle are 800V batteries and the hardware number is A, then when selecting the upgrade software for the BBM that controls the battery, first find software 1 and software 2 whose supported hardware numbers include A in the dependency configuration file. Then, compare whether the first type configuration parameters of software 1 and software 2 are consistent with the categories of the actual configuration parameters of the vehicle battery. If all three are batteries, it indicates that the first type configuration parameters are the same as the first type actual configuration parameters. Further, search for the second type configuration parameters that are the same as the second type actual configuration parameters of the vehicle battery, 800V, in software 1 and software 2. Obviously, the second type configuration parameters of software 2 are also 800V, then find the upgrade software with "2" as the software ID in the upgrade software, and use the upgrade software 2 as the first upgrade and software to flash the vehicle BBM software.

[0092] When performing software upgrades on the ECU, if the unique upgrade software cannot be determined for the ECU through the hardware number, the unique upgrade software can be matched from the dependent configuration file based on the actual configuration parameters, making it feasible to package upgrade software with the same hardware number but different configuration parameters into the same software package, thereby improving the reuse rate of the upgrade software and reducing the management cost of the vehicle software package.

[0093] Fig. 9 is a flow chart of an upgrade method based on a vehicle software package according to an embodiment of the present disclosure, such as Fig. 9 As shown, in order to realize the above scheme, the present disclosure proposes a vehicle software package upgrade method M900, including: step S910, obtaining a vehicle software package, the vehicle software package includes a dependent configuration file and multiple upgrade software, the dependent configuration file includes the association relationship between each upgrade software and the configuration parameter in the associated software, the associated software is two or more upgrade software containing the same hardware number, and the configuration parameter is the configuration parameter of the vehicle part with the same hardware number in the associated software; step S920, determining whether the hardware number of the target vehicle part exists in the dependent configuration file; step S930, in the case where the hardware number of the target vehicle part exists in the dependent configuration file, according to the association relationship in the dependent configuration file, the target upgrade software of the target vehicle part is determined by the hardware number of the target vehicle part. And step S940, performing software upgrade on the electronic control unit of the target vehicle part through the target upgrade software, the electronic control unit is used to control the target vehicle part.

[0094] The specific methods and principles for implementing each step in the upgrade method M900 based on the vehicle software package can be found in the previous text and will not be repeated here.

[0095] Fig.10 Schematic diagram of an electronic device according to an embodiment of the present disclosure. Fig.10As shown, the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnected buses and bridges, depending on the specific application and overall design constraints of the hardware. The bus 1100 connects various circuits including one or more processors 1200, memory 1300 and / or hardware modules together. The bus 1100 can also connect various other circuits such as peripherals, voltage regulators, power management circuits, external antennas, etc. The bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can 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.

[0096] The processor 1200 may call the computer program in the memory 1300 to execute the methods of the above embodiments of the present disclosure. It should be understood that the corresponding modules that execute one or several steps of the above methods may be one or more modules specifically configured to execute the corresponding steps.

[0097] The electronic device 1000 can be used as a whole vehicle software package generation system, and can also be used as an upgrade system based on the whole vehicle software package.

[0098] When the electronic device 1000 is used as a vehicle software package generation system, the processor 1200 can execute the following process by calling the computer program in the memory 1300: obtaining multiple upgrade software, the upgrade software including the hardware number of the vehicle part; determining the associated software among the multiple upgrade software, the associated software being two or more upgrade software including the same hardware number; generating a dependency configuration file based on the configuration parameters of the associated software, the configuration parameters being the configuration parameters of the vehicle parts with the same hardware number in the associated software, the dependency configuration file including the association relationship between each upgrade software and the configuration parameters in the associated software; and packaging the multiple upgrade software with the dependency configuration file to generate a vehicle software package.

[0099] In some embodiments, the specific execution steps of the processor 1200 when generating a dependency configuration file are: determining the configuration parameters of each upgrade software in the associated software; associating the configuration parameters with the software identifier of the upgrade software having the configuration parameters to generate dependency data; and, generating a dependency configuration file based on the dependency data.

[0100] In some implementations, the specific execution steps of the processor 1200 when packaging the multiple upgrade software with the dependency configuration file are: verifying the dependency configuration file, and packaging the multiple upgrade software with the dependency configuration file that passes the verification.

[0101] In some embodiments, when the processor 1200 verifies the dependent configuration file, the specific execution steps are: determining whether the non-associated software has the same hardware number as the remaining upgrade software, the non-associated software being the upgrade software that does not belong to the associated software among the multiple upgrade software; and, in the case of having the same hardware number, the verification of the dependent configuration file fails; or, in the case of not having the same hardware number, the verification of the dependent configuration file passes.

[0102] In some embodiments, when the processor 1200 verifies the dependent configuration file, the specific execution steps are: determining whether the first type configuration parameters of each upgrade software in the associated software are the same, the configuration parameters include the first type configuration parameters and the second type configuration parameters, the first type configuration parameters represent the category of the vehicle parts, and the second type configuration parameters represent the specifications of the vehicle parts in the first type configuration parameters; if the first type configuration parameters are the same, the verification of the dependent configuration file fails; or if the first type configuration parameters are different, determining whether the second type configuration parameters of each upgrade software in the associated software are the same; and if the second type configuration parameters are different, the verification of the dependent configuration file passes; or if the second type configuration parameters are the same, the verification of the dependent configuration file fails. The specific methods and principles for implementing each step executed by the electronic device 1000 as a whole vehicle software package generation system can be referred to the previous text and will not be repeated.

[0103] When the electronic device 1000 is used as an upgrade system based on a whole vehicle software package, the processor 1200 can also perform the following process by calling the computer program in the memory 1300: obtaining the whole vehicle software package, the whole vehicle software package includes a dependent configuration file and multiple upgrade software, the dependent configuration file includes the association relationship between each upgrade software and the configuration parameters in the associated software, the associated software is two or more upgrade software containing the same hardware number, and the configuration parameters are the configuration parameters of the vehicle parts with the same hardware number in the associated software; determining whether the hardware number of the target vehicle part exists in the dependent configuration file; when the hardware number of the target vehicle part exists in the dependent configuration file, determining the target upgrade software of the target vehicle part through the hardware number of the target vehicle part according to the association relationship in the dependent configuration file; and, performing software upgrade on the electronic control unit of the target vehicle part through the target upgrade software, the electronic control unit being used to control the target vehicle part.

[0104] In some embodiments, the configuration parameters include first-type configuration parameters and second-type configuration parameters, the first-type configuration parameters characterizing categories of vehicle parts, and the second-type configuration parameters characterizing specifications of the vehicle parts in the first-type configuration parameters.

[0105] In some embodiments, when the processor 1200 determines the target upgrade software of the target vehicle part, the specific execution steps are: obtaining the first type actual configuration parameters and the second type actual configuration parameters of the target vehicle part; searching for the upgrade software that has an association with the hardware number of the target vehicle part in the dependency configuration file; determining whether the first type configuration parameters of the upgrade software are the same as the first type actual configuration parameters; if the first type configuration parameters of the upgrade software are the same as the first type actual configuration parameters, determining whether the second type configuration parameters and the second type actual configuration parameters of the upgrade software are the same; and, if the second type configuration parameters and the second type actual configuration parameters of the upgrade software are the same, determining that the upgrade software is the target upgrade software.

[0106] In some embodiments, after obtaining the whole vehicle software package, the processor 1200 is also used to: search for the archived configuration parameters of the target vehicle parts from the data maintenance terminal according to the hardware number of the target vehicle parts, the configuration parameters in the whole vehicle software package are the archived configuration parameters, and the data maintenance terminal is used to record the archived configuration parameters; and, when the actual configuration parameters of the target vehicle parts are the same as the archived configuration parameters of the target vehicle parts, the verification of the whole vehicle software package is qualified.

[0107] In some embodiments, when the processor 1200 performs a software upgrade on the electronic control unit of a target vehicle part through the target upgrade software, the specific execution steps are: obtaining the current software version of the electronic control unit of the target vehicle part; determining whether the dependent version of the target upgrade software is the same as the current software version, the dependent version is a condition for the electronic control unit to run the target upgrade software; when the dependent version is the same as the current software version, verifying that the target upgrade software is qualified; and, performing a software upgrade on the electronic control unit of the target vehicle part through the verified qualified target upgrade software.

[0108] The specific methods and principles for implementing each step executed by the electronic device 1000 as an upgrade system based on the vehicle software package can be found in the previous text and will not be described in detail. The present disclosure also provides a readable storage medium, in which execution instructions are stored, and when the execution instructions are executed by a processor, they are used to implement the above method. "Readable storage medium" can be any device that can contain, store, communicate, propagate or transmit programs 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.

[0109] The present disclosure also provides a computer program product, and 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. A computer-readable storage medium can be used as an implementation of a computer program product, that is, the present disclosure also provides a computer-readable storage medium, which includes a computer program, and when the computer program is executed by a processor, any of the above methods is implemented.

[0110] 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.

[0111] 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.

[0112] The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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. An upgrade method based on a vehicle software package, used to upgrade the electronic control unit of a target vehicle part, characterized in that: include: Acquire a vehicle software package, the vehicle software package including a dependent configuration file and a plurality of upgrade software, the dependent configuration file including an association relationship between each upgrade software and a configuration parameter in the associated software, the associated software being two or more upgrade software including the same hardware number, and the configuration parameter being a configuration parameter of a vehicle part having the same hardware number in the associated software; determining whether the hardware number of the target vehicle part exists in the dependency configuration file; In the case where the hardware number of the target vehicle part exists in the dependency configuration file, determining the target upgrade software of the target vehicle part by the hardware number of the target vehicle part according to the association relationship in the dependency configuration file; as well as, The electronic control unit of the target vehicle part is software upgraded by the target upgrade software, and the electronic control unit is used to control the target vehicle part.

2. The upgrade method based on the vehicle software package according to claim 1 is characterized in that: The configuration parameters include first-type configuration parameters and second-type configuration parameters, the first-type configuration parameters characterizing the categories of vehicle parts, and the second-type configuration parameters characterizing the specifications of the vehicle parts in the first-type configuration parameters.

3. The upgrade method based on the vehicle software package according to claim 2 is characterized in that: Determining the target upgrade software of the target vehicle part by the hardware number of the target vehicle part according to the association relationship in the dependency configuration file includes: Acquire a first type of actual configuration parameter and a second type of actual configuration parameter of the target vehicle part; In the dependency configuration file, searching for upgrade software associated with the hardware number of the target vehicle part; Determining whether the first type of configuration parameters of the upgrade software are the same as the first type of actual configuration parameters; In the case where the first type configuration parameters of the upgrade software are the same as the first type actual configuration parameters, determining whether the second type configuration parameters of the upgrade software are the same as the second type actual configuration parameters; and, In a case where the second type configuration parameter of the upgrade software and the second type actual configuration parameter are the same, the upgrade software is determined to be the target upgrade software.

4. The upgrade method based on the vehicle software package according to any one of claims 1 to 3, characterized in that: After obtaining the vehicle software package, it also includes: According to the hardware number of the target vehicle part, searching for the archived configuration parameters of the target vehicle part from the data maintenance terminal, the configuration parameters in the vehicle software package are archived configuration parameters, and the data maintenance terminal is used to record the archived configuration parameters; and, When the actual configuration parameters of the target vehicle parts are the same as the archived configuration parameters of the target vehicle parts, the verification of the whole vehicle software package is qualified.

5. The upgrade method based on the vehicle software package according to any one of claims 1 to 3, characterized in that: Performing software upgrade on the electronic control unit of the target vehicle part by using the target upgrade software includes: Obtaining a current software version of an electronic control unit of the target vehicle part; Determine whether a dependent version of the target upgrade software is the same as the current software version, the dependent version being a condition for the electronic control unit to run the target upgrade software; In the case where the dependent version is the same as the current software version, the target upgrade software is verified to be qualified; and The electronic control unit of the target vehicle part is software upgraded by verifying qualified target upgrade software.

6. A method for generating a vehicle software package, characterized in that: include: Acquire a plurality of upgrade software, wherein the upgrade software includes a hardware number of a vehicle part; Determine associated software among the plurality of upgrade software, wherein the associated software is two or more upgrade software including the same hardware number; Generate a dependency configuration file according to the configuration parameters of the associated software, wherein the configuration parameters are configuration parameters of the vehicle parts having the same hardware number in the associated software, and the dependency configuration file includes associations between each upgrade software and the configuration parameters in the associated software; as well as, The multiple upgrade software are packaged with the dependent configuration files to generate a vehicle software package.

7. The method for generating a vehicle software package according to claim 6, characterized in that: Generate a dependency configuration file according to the configuration parameters of the associated software, including: Determining configuration parameters of each upgrade software in the associated software; Associating the configuration parameter with the software identifier of the upgrade software having the configuration parameter to generate dependency data; and, The dependency configuration file is generated according to the dependency data.

8. The method for generating a vehicle software package according to claim 6, characterized in that: Packaging the multiple upgrade software with the dependent configuration files includes: The dependency configuration file is verified, and the plurality of upgrade software are packaged with the dependency configuration file that passes the verification.

9. The method for generating a vehicle software package according to claim 8, characterized in that: Verifying the dependency configuration file includes: determining whether the non-associated software has the same hardware number as the remaining upgrade software, the non-associated software being the upgrade software that does not belong to the associated software among the plurality of upgrade software; and, In the case of having the same hardware number, the verification of the dependent configuration file fails; or, in the case of not having the same hardware number, the verification of the dependent configuration file passes.

10. The method for generating a vehicle software package according to claim 9, characterized in that: Verifying the dependency configuration file includes: Determining whether first-type configuration parameters of each upgraded software in the associated software are the same, the configuration parameters comprising the first-type configuration parameters and the second-type configuration parameters, the first-type configuration parameters representing the category of the vehicle parts, and the second-type configuration parameters representing the specifications of the vehicle parts in the first-type configuration parameters; If the first type configuration parameters are the same, the verification of the dependent configuration file fails; or if the first type configuration parameters are different, determining whether the second type configuration parameters of each upgraded software in the associated software are the same; and, When the second-type configuration parameters are different, the verification of the dependent configuration file passes; or, when the second-type configuration parameters are the same, the verification of the dependent configuration file fails.

11. An upgrade system based on a vehicle software package, characterized in that: The invention comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following process: Acquire a vehicle software package, the vehicle software package including a dependent configuration file and a plurality of upgrade software, the dependent configuration file including an association relationship between each upgrade software and a configuration parameter in the associated software, the associated software being two or more upgrade software including the same hardware number, and the configuration parameter being a configuration parameter of a vehicle part having the same hardware number in the associated software; determining whether the hardware number of the target vehicle part exists in the dependency configuration file; In the case where the hardware number of the target vehicle part exists in the dependency configuration file, determining the target upgrade software of the target vehicle part by the hardware number of the target vehicle part according to the association relationship in the dependency configuration file; as well as, The electronic control unit of the target vehicle part is software upgraded by the target upgrade software, and the electronic control unit is used to control the target vehicle part.

12. A vehicle software package generation system, characterized in that: The invention comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following process: Acquire a plurality of upgrade software, wherein the upgrade software includes a hardware number of a vehicle part; Determine associated software among the plurality of upgrade software, wherein the associated software is two or more upgrade software including the same hardware number; Generate a dependency configuration file according to the configuration parameters of the associated software, wherein the configuration parameters are configuration parameters of the vehicle parts having the same hardware number in the associated software, and the dependency configuration file includes associations between each upgrade software and the configuration parameters in the associated software; as well as, The multiple upgrade software are packaged with the dependent configuration files to generate a vehicle software package.

13. A vehicle, characterized in that: The vehicle includes the whole-vehicle software package-based upgrade system as claimed in claim 11 or the whole-vehicle software package generation system as claimed in claim 12.

14. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, is used to implement at least the upgrade method based on the whole vehicle software package as claimed in any one of claims 1 to 5 or the whole vehicle software package generation method as claimed in any one of claims 6 to 10.

Images