OTA upgrade method and system based on data pre-calculation

Abstract

The present invention discloses an OTA upgrade method and system based on data pre-solution, wherein the OTA upgrade method based on data pre-solution includes: obtaining all vehicle status data and OTA software baseline versions in an OTA server; pre-solution of vehicles based on the OTA software baseline version and vehicle status data; constructing a vehicle pool, storing the target vehicle data generated after pre-solution into the vehicle pool; creating and directing the release of OTA upgrade tasks based on the vehicle pool. When the OTA server is idle, the vehicle status data can be pre-solved and stored in the vehicle pool, and the OTA upgrade tasks can be directed based on the vehicle pool, without the need to match the vehicle status data, which can greatly reduce the resource consumption of concurrent data on the server and improve the OTA upgrade efficiency.

Description

Technical Field

[0001] The present invention relates to an OTA upgrade method, and in particular to an OTA upgrade method and system based on data pre-calculation. Background Art

[0002] Over-the-Air Technology (OTA) is a technology that enables remote management of mobile terminal devices and SIM card data through the air interface of mobile communications. OTA technology is also used in the automotive industry to achieve large-scale vehicle upgrades.

[0003] When car manufacturers are currently planning OTA activities, they generally do not perform OTA upgrades on all vehicles, because each vehicle has a different version of its own software, and not all vehicles can be OTA upgraded through this OTA activity. At this stage, car manufacturers are unable to obtain the latest version status of vehicle software in a timely manner, and operators are unable to accurately know which vehicles can undergo this OTA upgrade when creating an OTA marketing activity.

[0004] Furthermore, the current situation is that the OTA market release task is launched without knowing the vehicle status. After the vehicle power-on active detection task is completed, the vehicle task matching is performed through the OTA platform, and the entire process of vehicle detection task and cloud matching task is postponed, resulting in too many vehicles in the market. When performing OTA concurrent business processing, it will be paralyzed due to the performance bottleneck of the server. In the future development of the software-defined car trend, there will be more and more scenarios with high concurrent requests for server resources, which will be imperative from the perspective of saving costs and improving performance. Summary of the invention

[0005] In view of the fact that it is currently impossible to accurately obtain the OTA vehicles that need to be upgraded during OTA upgrades, the present invention provides an OTA upgrade method based on data pre-solution, which stores the vehicle pool after pre-solution of vehicle status data, and directs the release of OTA upgrade tasks based on the vehicle pool to improve the OTA upgrade efficiency.

[0006] To achieve the above object, the embodiments of the present invention adopt the following technical solutions:

[0007] An OTA upgrade method based on data pre-calculation includes the following steps:

[0008] Obtain all vehicle status data and OTA software baseline versions from the OTA server;

[0009] Pre-calculate the vehicle based on the OTA software baseline version and vehicle status data;

[0010] Build a vehicle pool and store the target vehicle data generated after pre-calculation into the vehicle pool;

[0011] Based on the vehicle pool, create and publish OTA upgrade tasks in a targeted manner.

[0012] According to one aspect of the present invention, the OTA software baseline version includes: an OTA software baseline version uniformly released by a vehicle manufacturer, and an existing source software baseline version of the vehicle.

[0013] According to one aspect of the present invention, the vehicle status data includes at least: the vehicle VIN code, the software version information of all controllers of the vehicle, and the existing source software baseline version on the vehicle; the OTA software baseline version uniformly released by the vehicle manufacturer includes the software versions of all controllers to be upgraded in the vehicle, and the source software baseline version includes the software versions of all controllers currently on the vehicle.

[0014] According to one aspect of the present invention, the method of obtaining all vehicle status data in the OTA server is specifically: establishing unique vehicle file information for the vehicle through the vehicle VIN code, obtaining software version information of all controllers of the vehicle through multiple channels, and associating the obtained software version information with the vehicle file information.

[0015] According to one aspect of the present invention, obtaining the software version information of all controllers of the vehicle through multiple channels at least includes: obtaining the software version information of all controllers reported before the vehicle leaves the factory, after each OTA upgrade task is completed, each time it is powered on, and each time after-sales maintenance.

[0016] According to one aspect of the present invention, the pre-calculation of the vehicle based on the OTA software baseline version and the vehicle status data includes:

[0017] Define the matching logic for pre-solving;

[0018] Use the latest released OTA software baseline version as the target OTA software baseline version;

[0019] Match the target OTA software baseline version with the vehicle status data, and pre-solve the vehicle to obtain the target vehicle data.

[0020] According to one aspect of the present invention, the matching logic is:

[0021] Based on the latest released OTA software baseline version, obtain the source software baseline version that can be upgraded;

[0022] According to the upgradeable source software baseline version, match the upgradeable vehicle and output the vehicle VIN code corresponding to the vehicle;

[0023] Based on the output vehicle VIN code, the software version information of all controllers of each vehicle is matched one by one, and the software version information of the upgradeable controller is output;

[0024] Output the target vehicle data including the vehicle VIN code and software version information of the upgradeable controller.

[0025] According to one aspect of the present invention, the creating and directing publishing of OTA upgrade tasks based on a vehicle pool includes:

[0026] Select the target OTA software baseline version and create an OTA upgrade task;

[0027] According to the selected target OTA software baseline version, obtain the pre-solved target vehicle data from the vehicle pool;

[0028] Based on the pre-solved target vehicle data obtained, OTA upgrade tasks are issued in a targeted manner.

[0029] According to one aspect of the present invention, the pre-calculation of the vehicle specifically includes: determining whether the OTA server is idle, and pre-calculating the vehicle when the OTA server is idle.

[0030] An OTA upgrade system based on data pre-calculation, wherein the OTA upgrade system based on data pre-calculation is deployed in an OTA server, comprising:

[0031] A data storage module, used to store all acquired vehicle status data and OTA software baseline versions;

[0032] The pre-calculation module is used to pre-calculate the vehicle based on the OTA software baseline version and vehicle status data;

[0033] The vehicle pool is used to store the target vehicle data generated after pre-calculation;

[0034] The task publishing module is used to create and publish OTA upgrade tasks based on the vehicle pool.

[0035] Advantages of the implementation of the present invention: The OTA upgrade method based on data pre-resolution described in the present invention obtains vehicle status information through multiple channels and at a regular time, and obtains vehicle status information in advance, which is convenient for processing vehicle status information; based on the latest OTA software baseline version released by the OTA server, pre-resolution services are performed on the vehicle at idle time, and the pre-resolved target vehicle data is stored in the vehicle pool, which can greatly reduce the resource consumption of concurrent data of the server and maintain the stability of the OTA server; when it is necessary to release an OTA upgrade task, after creating the OTA upgrade task, the vehicle information that needs to be upgraded can be accurately pulled based on the existing data in the vehicle pool, thereby realizing the targeted release of OTA upgrade tasks and improving the OTA upgrade efficiency; further, technical personnel in this field can also obtain the software version that needs to be upgraded in the existing market through the targeted release of OTA upgrade tasks, carry out technical research and development work in a targeted manner, and realize the pre-processing of the entire market operation work; further, the vehicle status data of each OTA upgrade task is updated in the OTA server, which can not only realize the real-time update of the vehicle status data in the OTA server, but also avoid the problem of repeatedly obtaining the same vehicle status data, further reducing the pressure on the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0037] Figure 1 This is a flow chart of the OTA upgrade method based on data pre-calculation according to the first embodiment of the present invention;

[0038] Figure 2 This is a flow chart of the OTA upgrade method based on data pre-calculation according to the second embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the structure of an OTA upgrade system based on data pre-calculation according to Embodiment 3 of the present invention;

[0040] Figure 4 This is a schematic diagram of the structure of an OTA upgrade device based on data pre-calculation according to Embodiment 4 of the present invention. DETAILED DESCRIPTION

[0041] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] Embodiment 1

[0043] like Figure 1 As shown, an OTA upgrade method based on data pre-calculation includes:

[0044] Step S1: Obtain all vehicle status data and OTA software baseline version in the OTA server;

[0045] The OTA server, which can also be an OTA cloud platform, is used to manage vehicle status data and OTA software baseline versions.

[0046] The OTA software baseline version needs to pass the internal OTA verification process of the car manufacturer, and the software maturity reaches a certain standard before it is officially released. The officially released OTA software baseline version will be uploaded to the OTA server for update and storage; the OTA software baseline version is the major software version, which contains the software version information of all vehicle controllers; generally, the latest released OTA software baseline version will be used as the target OTA software baseline version for the OTA upgrade task.

[0047] Among them, the vehicle status data includes at least the vehicle VIN code and the software version information of all the vehicle controllers. The vehicle VIN code is also known as the vehicle identification number, which is a 17-digit code consisting of letters and numbers, used to uniquely identify a car. It can contain information such as the manufacturer, year, model, engine type, and production plant of the vehicle; all the vehicle controllers include: intelligent domain controllers (power domain, chassis domain, intelligent driving domain, body domain, etc.), traditional controllers (steering power system, streaming media rearview mirror, electronic non-stop toll collection system, pressure and temperature sensor, wiper controller, etc.).

[0048] Unique vehicle file information is established through the vehicle VIN code, and the software version information of all vehicle controllers is obtained through multiple channels. The obtained software version information is associated with the vehicle file information. Specifically, the vehicle VIN code is associated with the software version information of all vehicle controllers. In addition, based on the software version information of all vehicle controllers, the software baseline version of the vehicle can be obtained, and this software baseline version is defined as the existing source software baseline version on the vehicle.

[0049] During the OTA upgrade activity, in addition to obtaining the OTA software baseline version, it is also necessary to obtain the current software version information of all vehicle controllers and obtain the source software baseline version to determine whether the vehicle can perform this OTA upgrade.

[0050] In practical applications, vehicle file information can be obtained through multiple channels, and the software version information of all controllers contained in the vehicle file information can be extracted, as follows:

[0051] Obtain vehicle file information that is flashed and published on the production line before the production line system leaves the factory;

[0052] Obtain vehicle file information reported after each market OTA activity is completed after the vehicle leaves the factory;

[0053] After the vehicle leaves the factory, each time the vehicle is powered on, the vehicle side traverses the vehicle controller software version to obtain the software information, which includes the vehicle file information;

[0054] After the vehicle leaves the factory, the staff reports the vehicle file information to the after-sales system after each after-sales service is completed;

[0055] In addition to the above four methods, the software version information of all vehicle controllers can also be obtained through other legal channels.

[0056] In actual applications, when obtaining vehicle file information through some channels, the amount of data that needs to be processed is large, and real-time acquisition will occupy more server performance. Therefore, you can preset time intervals to obtain vehicle file information regularly, process the vehicle file information, extract the software version information of all controllers contained therein, and obtain the source software baseline version.

[0057] It should be noted that the vehicle status data obtained through multiple channels needs to be uploaded to the OTA server for storage, so that the data can be called directly through the OTA server in the future; in the obtained vehicle status data, the vehicle VIN code is unchanged, so when obtaining the vehicle status data through different channels, it is only necessary to find the software version information of all controllers of the associated original vehicle through the vehicle VIN code, and update the software version information of all original controllers, so that the vehicle status data in the OTA platform corresponds to the latest software version information of all controllers, and the source software baseline version of the vehicle is updated according to the software version information of all controllers; at the same time, it is also necessary to record the data of each update to facilitate tracking and tracing when problems arise.

[0058] Step S2: Pre-calculating the vehicle based on the OTA software baseline version and vehicle status data;

[0059] Step S21: define the matching logic of pre-calculation;

[0060] In this application, pre-solving of the vehicle refers to judging the vehicles that can be OTA upgraded using the target OTA software baseline version based on the latest OTA software baseline version in the existing OTA server, i.e., the target OTA software baseline version, and obtaining the target vehicle data that can be OTA upgraded by matching the vehicle status data with the target OTA software baseline version.

[0061] The specific matching logic is as follows:

[0062] Step S211: based on the latest released OTA software baseline version, obtaining an upgradeable source software baseline version;

[0063] When acquiring vehicle status data, in addition to the vehicle VIN code, the software version information of all vehicle controllers associated with the vehicle VIN code and the source software baseline version are also acquired. The source software baseline version includes the software version information of all vehicle controllers. Therefore, when acquiring vehicle status data, the source software baseline version of the vehicle can be obtained based on the software version information of all vehicle controllers, and the source software baseline version can be uploaded to the OTA server for matching in pre-solution.

[0064] Specifically, the latest released OTA software baseline version and the source software baseline version that can be upgraded are obtained. There is not only one source software baseline version obtained. As long as the source software baseline version can be upgraded to the latest released OTA software baseline version, it can be obtained and pre-solved for vehicles with the software baseline version of the source software baseline version in subsequent steps; when the OTA task is released, the source software baseline version of all vehicles that have been pre-solved and matched successfully can be selected as the source software baseline version of the OTA upgrade task.

[0065] Step S212: matching an upgradeable vehicle according to the upgradeable source software baseline version, and outputting a vehicle VIN code corresponding to the vehicle;

[0066] In step S211, the range of the source software baseline version is obtained, and the obtained vehicle status data includes the existing source software baseline version of the vehicle, so that all vehicles included in the source software baseline version range can be matched and the VIN codes corresponding to these vehicles are output.

[0067] Step S213: Based on the outputted vehicle VIN code, the software version information of all controllers of each vehicle is matched one by one, and the software version information of the upgradeable controller is outputted;

[0068] Through step S212, vehicles that can use the latest released OTA software baseline version for this OTA upgrade are screened. Based on the matching result of step S212, that is, the output vehicle VIN code, the software version information of all controllers of each vehicle is matched, and the software version information of the upgradeable controller is output as the result.

[0069] In actual applications, not all vehicles can upgrade all of their controllers based on the latest released OTA software baseline version. Although the source software baseline version of some vehicles meets the conditions for OTA upgrade, only the software versions of some controllers need to be upgraded, and the remaining software versions may be consistent with the software versions in the latest released OTA software baseline version. Therefore, step S213 is to find the controllers that can be upgraded for each vehicle through matching.

[0070] For example, in a certain OTA upgrade, the relevant data are as follows:

[0071] The source software baseline version is Base_V_2.0.0, wherein the versions of some controllers are VCU: V_0.9.0, TBOX: V_0.9.0, GW: V_0.9.0 (the controllers are VCU, TBOX and GW. In actual situations, the vehicle includes more than three controllers. In this embodiment, only three are selected to briefly explain the matching logic); the source software baseline version of vehicle 5 is Base_V_2.0.0;

[0072] Another source software baseline version that can be used for this OTA upgrade is Base_V_3.0.0, of which some controller versions are VCU:V_1.0.0, TBOX:V_1.0.0, GW:V_1.0.0. The source software baseline versions of Vehicle 1, Vehicle 2, Vehicle 3, and Vehicle 4 given below are all Base_V_2.0.0;

[0073] The latest released software baseline version is Base_V_4.0.0, of which the versions of some controllers are VCU:V_1.0.1, TBOX:V_1.2.0, GW:V_1.3.0;

[0074] Vehicle 1, VIN is 5YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.0, TBOX: V_1.0.0, GW: V_1.0.0;

[0075] Vehicle 2, VIN is 6YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.0.0, GW: V_1.0.0;

[0076] Vehicle 3, VIN is 7YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.2.0, GW: V_1.0.0;

[0077] Vehicle 4, VIN is 8YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.2.0, GW: V_3.0.0;

[0078] Vehicle 5, VIN is 8YJ3E1EA7HL123456, and the versions of some controllers are VCU: V0.9.0, TBOX: V_0.9.0, GW: V_1.0.0;

[0079] According to the vehicle's VIN, the software versions of all the vehicle's controllers are matched one by one. The software versions of the three controllers given by vehicle 1 are not the latest versions compared to the latest released software baseline version Base_V_4.0.0, which means that the three controllers given by vehicle 1 in this upgrade can all be upgraded. Therefore, in addition to the vehicle's VIN code, the output content also includes the controllers that need to be upgraded and the versions of the controllers VCU: V_1.0.0, TBOX: V_1.0.0, GW: V_1.0.0. In subsequent upgrades, OTA upgrades can be accurately implemented based on the output controller software version information;

[0080] Similarly, among the three controllers provided by vehicle 2, compared with the latest released software baseline version Base_V_4.0.0, the controller VCU is already the latest version V_1.0.1, while the controllers TBOX and GW are not the latest versions. Therefore, the output content includes the VIN code of the vehicle, the controller that needs to be upgraded, and the versions of the controllers TBOX: V_1.0.0 and GW: V_1.0.0.

[0081] The result of matching the software version information of all controllers of vehicle 3 includes the VIN code of the vehicle and the controller GW: V_1.0.0 that needs to be upgraded;

[0082] However, when vehicle 4 is matched with the latest software baseline version Base_V_4.0.0, although its controllers VCU and TBOX are the latest versions, the version of the controller GW is V3.0.0, which cannot be upgraded to the controller GW version V1.3.0 in Base_V_4.0.0. In fact, the vehicle can change a certain controller through other non-OTA methods or by replacing parts, but this information is not obtained by the OTA server. At this time, vehicle 4 cannot be matched successfully, that is, the VIN code corresponding to vehicle 4 and the software version information of the upgradeable controller will not be output, and vehicle 4 will not enter the next step;

[0083] The source software baseline version of vehicle 5 is Base_V_2.0.0, and the software versions of its controllers VCU and TBOX are consistent with Base_V_2.0.0. However, it may have upgraded the software version of the controller GW in a non-OTA manner, causing the software version of its controller GW to be consistent with Base_V_3.0.0. In this case, since the software baseline versions Base_V_2.0.0 and Base_V_3.0.0 are both the source software baseline versions selected for this OTA upgrade task, the controllers VCU, TBOX and GW of vehicle 5 can all be upgraded to the software versions of the corresponding controllers in the latest software baseline version Base_V_4.0.0, so vehicle 5 is also considered to be matched successfully.

[0084] Furthermore, if there are multiple source software baseline versions, even if a vehicle corresponding to a certain vehicle VIN code has some controllers whose software versions are within the source software baseline version associated with its vehicle status data and others within the source software baseline version selected for this OTA upgrade task, it can also be upgraded to the target OTA software baseline version, i.e., the match is successful;

[0085] As long as the software version of any controller among all the vehicle's controllers does not exist in the source software baseline version or the target OTA software baseline version, the matching fails.

[0086] Step S214: Output the target vehicle data including the vehicle VIN code and the software version information of the upgradeable controller.

[0087] The software version information of the controllers that need to be upgraded for each vehicle is not consistent. The original vehicle status data contains the software version information of all controllers, which is no longer suitable when output. In order to further speed up the OTA upgrade rate, the target vehicle data is generated by associating the vehicle VIN code with the software version information of the upgradeable (or upgrade-required) controller, and the target vehicle data is used as the final output of the vehicle pre-solution matching.

[0088] Step S22: taking the latest released OTA software baseline version as the target OTA software baseline version;

[0089] After the car manufacturer releases the OTA software baseline version, it is necessary to release an OTA upgrade task based on the OTA software baseline version to implement the OTA upgrade. Therefore, the latest released OTA software baseline version can be used as the target OTA software baseline version, and the OTA upgrade task can be used directly when it is released.

[0090] In actual applications, after the OTA software baseline version is released, the OTA task will not be released and the OTA upgrade will not be performed immediately. A certain amount of time will be reserved before the OTA upgrade task is released. In addition, the OTA server is not always idle. Therefore, the vehicle can be pre-solved before the OTA upgrade task is released and the OTA server is idle, saving server resources and improving the efficiency of OTA upgrades.

[0091] Specifically, by determining whether the OTA server is idle, the vehicle can be pre-solved when the OTA server is idle, which can significantly reduce the performance resource consumption of concurrent data on the server.

[0092] Step S23: Match the target OTA software baseline version with the vehicle status data, and pre-solve the vehicle to obtain the target vehicle data.

[0093] After starting the pre-solution of the vehicle, the vehicle status data is matched with the target OTA software baseline version based on the matching logic, and the target vehicle data containing the vehicle VIN code and the software version information of the upgradeable (or required) controller is output as the final output, which is convenient for subsequent storage in the vehicle pool and for creating an OTA release task to achieve OTA upgrade of the controllers that need to be upgraded in the vehicle instead of all controllers.

[0094] Step S3: construct a vehicle pool and store the pre-solved target vehicle data into the vehicle pool;

[0095] Build a vehicle pool. Based on the released OTA software baseline version, build multiple different vehicle pools. Each vehicle pool stores the target vehicle data corresponding to the vehicle that has been pre-solved by the current OTA software baseline version, so that future OTA upgrade tasks can be directly released after creation. In addition, these pre-solved target vehicle data may have more than one source software baseline version. When storing them in the vehicle pool, they can be classified and stored according to the different software baseline versions of each target vehicle data. When releasing the OTA task, the target vehicle data corresponding to at least one source software baseline version in the vehicle pool should be selected.

[0096] In actual applications, although the latest OTA software baseline version is matched each time, there may be situations where the corresponding OTA upgrade task has not been released for a non-latest OTA software baseline version. If necessary, the OTA upgrade task can be released based on the historical OTA software baseline version in the vehicle pool and its associated target vehicle data. In actual applications, even if all vehicle data are not matched and pre-solved when the OTA upgrade task needs to be released, some priority upgrades can be performed based on the pre-solved target vehicle data stored in the vehicle pool. At the same time, the matched data can be excluded, reducing the amount of data that needs to be re-matched for the OTA upgrade task and improving the efficiency of the release and execution of the OTA upgrade task.

[0097] The OTA upgrade process generally releases OTA upgrade tasks based on the target OTA software baseline version, and cannot screen the target vehicles. After the vehicle obtains the target OTA software baseline version, all its controllers need to determine whether this OTA upgrade can be performed. By building a vehicle pool and pre-solving the vehicle to obtain the target vehicle data, the normal OTA upgrade process is pre-processed.

[0098] Step S4: Based on the vehicle pool, create and publish OTA upgrade tasks in a targeted manner.

[0099] Step S41: Select the OTA software baseline version and create an OTA upgrade task;

[0100] Select the OTA software baseline version. Generally, it is not necessary to select the latest version of the OTA software baseline version, and create an OTA upgrade task based on the selected software baseline version. At this time, the created OTA upgrade task only contains the software versions of all vehicle controllers corresponding to the software baseline version, that is, the target OTA software baseline version, and does not contain other information.

[0101] Step S42: acquiring pre-solved target vehicle data from the vehicle pool according to the selected target OTA software baseline version;

[0102] According to the selected target OTA software baseline version, the pre-solved target vehicle data associated with the target OTA software baseline version is found in the vehicle pool.

[0103] Step S43: Based on the acquired pre-solved target vehicle data, a targeted OTA upgrade task is issued.

[0104] The pre-solved target vehicle data is obtained, and then the VIN code of the vehicle that needs to perform the OTA upgrade task can be obtained. The OTA upgrade task is issued to the target vehicle according to the vehicle VIN code. The target vehicle data contains the software version information of the controller that can be upgraded (or needs to be upgraded). The targeted release task can also upgrade the specific controller.

[0105] The present embodiment discloses an OTA upgrade method based on data pre-resolution, which obtains vehicle status information through multiple channels and at a regular interval, and obtains vehicle status information in advance, which is convenient for processing vehicle status information; based on the latest software baseline version released by the OTA server, pre-resolution services are provided to the vehicle at idle times, and the pre-resolved target vehicle data is stored in the vehicle pool, which can greatly reduce the resource consumption of concurrent data of the server and maintain the stability of the OTA server; when it is necessary to release an OTA upgrade task, it is possible to accurately pull the vehicle information that needs to be upgraded based on the existing data in the vehicle pool after the OTA upgrade task is created, thereby realizing the targeted release of OTA upgrade tasks and improving the OTA upgrade efficiency; further, technical personnel in this field can also obtain the software version that needs to be upgraded in the existing market through the targeted release of OTA upgrade tasks, carry out targeted technical research and development work, and realize the pre-processing of the entire market operation work.

[0106] Embodiment 2

[0107] like Figure 2 As shown, an OTA upgrade method based on data pre-calculation includes:

[0108] Step S1: Obtain all vehicle status data and OTA software baseline version in the OTA server;

[0109] The OTA server, which can also be an OTA cloud platform, is used to manage vehicle status data and OTA software baseline versions.

[0110] The OTA software baseline version needs to pass the internal OTA verification process of the car manufacturer, and the software maturity reaches a certain standard before it is officially released. The officially released OTA software baseline version will be uploaded to the OTA server for update and storage; the OTA software baseline version is the major software version, which contains the software version information of all vehicle controllers; generally, the latest released OTA software baseline version will be used as the target OTA software baseline version for the OTA upgrade task.

[0111] Among them, the vehicle status data includes at least the vehicle VIN code and the software version information of all the vehicle controllers. The vehicle VIN code is also known as the vehicle identification number, which is a 17-digit code consisting of letters and numbers, used to uniquely identify a car. It can contain information such as the manufacturer, year, model, engine type, and production plant of the vehicle; all the vehicle controllers include: intelligent domain controllers (power domain, chassis domain, intelligent driving domain, body domain, etc.), traditional controllers (steering power system, streaming media rearview mirror, electronic non-stop toll collection system, pressure and temperature sensor, wiper controller, etc.).

[0112] Unique vehicle file information is established through the vehicle VIN code, and the software version information of all vehicle controllers is obtained through multiple channels. The obtained software version information is associated with the vehicle file information. Specifically, the vehicle VIN code is associated with the software version information of all vehicle controllers. In addition, based on the software version information of all vehicle controllers, the software baseline version of the vehicle can be obtained, and this software baseline version is defined as the existing source software baseline version on the vehicle.

[0113] During the OTA upgrade activity, in addition to obtaining the OTA software baseline version, it is also necessary to obtain the current software version information of all vehicle controllers and obtain the source software baseline version to determine whether the vehicle can perform this OTA upgrade.

[0114] In practical applications, vehicle file information can be obtained through multiple channels, and the software version information of all controllers contained in the vehicle file information can be extracted, as follows:

[0115] Obtain vehicle file information that is flashed and published on the production line before the production line system leaves the factory;

[0116] Obtain vehicle file information reported after each market OTA activity is completed after the vehicle leaves the factory;

[0117] After the vehicle leaves the factory, each time the vehicle is powered on, the vehicle side traverses the vehicle controller software version to obtain the software information, which includes the vehicle file information;

[0118] After the vehicle leaves the factory, the staff reports the vehicle file information to the after-sales system after each after-sales service is completed;

[0119] In addition to the above four methods, the software version information of all vehicle controllers can also be obtained through other legal channels.

[0120] In actual applications, when obtaining vehicle file information through some channels, the amount of data that needs to be processed is large, and real-time acquisition will occupy more server performance. Therefore, you can preset time intervals to obtain vehicle file information regularly, process the vehicle file information, extract the software version information of all controllers contained therein, and obtain the source software baseline version.

[0121] It should be noted that the vehicle status data obtained through multiple channels needs to be uploaded to the OTA server for storage, so that the data can be called directly through the OTA server in the future; in the obtained vehicle status data, the vehicle VIN code is unchanged, so when obtaining the vehicle status data through different channels, it is only necessary to find the software version information of all controllers of the associated original vehicle through the vehicle VIN code, and update the software version information of all original controllers, so that the vehicle status data in the OTA platform corresponds to the latest software version information of all controllers, and the source software baseline version of the vehicle is updated according to the software version information of all controllers; at the same time, it is also necessary to record the data of each update to facilitate tracking and tracing when problems arise.

[0122] Step S2: Pre-calculating the vehicle based on the OTA software baseline version and vehicle status data;

[0123] Step S21: define the matching logic of pre-calculation;

[0124] In this application, pre-solving of the vehicle refers to judging the vehicles that can be OTA upgraded using the target OTA software baseline version based on the latest OTA software baseline version in the existing OTA server, i.e., the target OTA software baseline version, and obtaining the target vehicle data that can be OTA upgraded by matching the vehicle status data with the target OTA software baseline version.

[0125] The specific matching logic is as follows:

[0126] Step S211: based on the latest released OTA software baseline version, obtaining an upgradeable source software baseline version;

[0127] When acquiring vehicle status data, in addition to the vehicle VIN code, the software version information of all vehicle controllers associated with the vehicle VIN code and the source software baseline version are also acquired. The source software baseline version includes the software version information of all vehicle controllers. Therefore, when acquiring vehicle status data, the source software baseline version of the vehicle can be obtained based on the software version information of all vehicle controllers, and the source software baseline version can be uploaded to the OTA server for matching in pre-solution.

[0128] Specifically, the latest released OTA software baseline version and the source software baseline version that can be upgraded are obtained. There is not only one source software baseline version obtained. As long as the source software baseline version can be upgraded to the latest released OTA software baseline version, it can be obtained and pre-solved for vehicles with the software baseline version of the source software baseline version in subsequent steps; when the OTA task is released, the source software baseline version of all vehicles that have been pre-solved and matched successfully can be selected as the source software baseline version of the OTA upgrade task.

[0129] Step S212: matching an upgradeable vehicle according to the upgradeable source software baseline version, and outputting a vehicle VIN code corresponding to the vehicle;

[0130] In step S211, the range of the source software baseline version is obtained, and the obtained vehicle status data includes the existing source software baseline version of the vehicle, so that all vehicles included in the source software baseline version range can be matched and the VIN codes corresponding to these vehicles are output.

[0131] Step S213: Based on the outputted vehicle VIN code, the software version information of all controllers of each vehicle is matched one by one, and the software version information of the upgradeable controller is outputted;

[0132] Through step S212, vehicles that can use the latest released OTA software baseline version for this OTA upgrade are screened. Based on the matching result of step S212, that is, the output vehicle VIN code, the software version information of all controllers of each vehicle is matched, and the software version information of the upgradeable controller is output as the result.

[0133] In actual applications, not all vehicles can upgrade all of their controllers based on the latest released OTA software baseline version. Although the source software baseline version of some vehicles meets the conditions for OTA upgrade, only the software versions of some controllers need to be upgraded, and the remaining software versions may be consistent with the software versions in the latest released OTA software baseline version. Therefore, step S213 is to find the controllers that can be upgraded for each vehicle through matching.

[0134] For example, in a certain OTA upgrade, the relevant data are as follows:

[0135] The source software baseline version is Base_V_3.0.0, of which the versions of some controllers are Base_V_2.0.0, of which the versions of some controllers are VCU: V_0.9.0, TBOX: V_0.9.0, GW: V_0.9.0 (the controllers are VCU, TBOX and GW. In actual situations, the vehicle contains more than three controllers. In this embodiment, only three are selected to briefly explain the matching logic); the source software baseline version of vehicle 5 is Base_V_2.0.0;

[0136] Another source software baseline version that can be used for this OTA upgrade is Base_V_3.0.0, of which some controller versions are VCU:V_1.0.0, TBOX:V_1.0.0, GW:V_1.0.0. The source software baseline versions of Vehicle 1, Vehicle 2, Vehicle 3, and Vehicle 4 given below are all Base_V_2.0.0;

[0137] The latest released software baseline version is Base_V_4.0.0, of which the versions of some controllers are VCU:V_1.0.1, TBOX:V_1.2.0, GW:V_1.3.0;

[0138] Vehicle 1, VIN is 5YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.0, TBOX: V_1.0.0, GW: V_1.0.0;

[0139] Vehicle 2, VIN is 6YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.0.0, GW: V_1.0.0;

[0140] Vehicle 3, VIN is 7YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.2.0, GW: V_1.0.0;

[0141] Vehicle 4, VIN is 8YJ3E1EA7HL123456, and the versions of some controllers are VCU: V_1.0.1, TBOX: V_1.2.0, GW: V_3.0.0;

[0142] Vehicle 5, VIN is 8YJ3E1EA7HL123456, and the versions of some controllers are VCU: V0.9.0, TBOX: V_0.9.0, GW: V_1.0.0;

[0143] According to the vehicle's VIN, the software versions of all the vehicle's controllers are matched one by one. The software versions of the three controllers given by vehicle 1 are not the latest versions compared to the latest released software baseline version Base_V_4.0.0, which means that the three controllers given by vehicle 1 in this upgrade can all be upgraded. Therefore, in addition to the vehicle's VIN code, the output content also includes the controllers that need to be upgraded and the versions of the controllers VCU: V_1.0.0, TBOX: V_1.0.0, GW: V_1.0.0. In subsequent upgrades, OTA upgrades can be accurately implemented based on the output controller software version information;

[0144] Similarly, among the three controllers provided by vehicle 2, compared with the latest released software baseline version Base_V_4.0.0, the controller VCU is already the latest version V_1.0.1, while the controllers TBOX and GW are not the latest versions. Therefore, the output content includes the VIN code of the vehicle, the controller that needs to be upgraded, and the versions of the controllers TBOX: V_1.0.0 and GW: V_1.0.0.

[0145] The result of matching the software version information of all controllers of vehicle 3 includes the VIN code of the vehicle and the controller GW: V_1.0.0 that needs to be upgraded;

[0146] However, when vehicle 4 is matched with the latest software baseline version Base_V_4.0.0, although its controllers VCU and TBOX are the latest versions, the version of the controller GW is V3.0.0, which cannot be upgraded to the controller GW version V1.3.0 in Base_V_4.0.0. In fact, the vehicle can change a certain controller through other non-OTA methods or by replacing parts, but this information is not obtained by the OTA server. At this time, vehicle 4 cannot be matched successfully, that is, the VIN code corresponding to vehicle 4 and the software version information of the upgradeable controller will not be output, and vehicle 4 will not enter the next step;

[0147] The source software baseline version of vehicle 5 is Base_V_2.0.0, and the software versions of its controllers VCU and TBOX are consistent with Base_V_2.0.0. However, it may have upgraded the software version of the controller GW in a non-OTA manner, causing the software version of its controller GW to be consistent with Base_V_3.0.0. In this case, since the software baseline versions Base_V_2.0.0 and Base_V_3.0.0 are both the source software baseline versions selected for this OTA upgrade task, the controllers VCU, TBOX and GW of vehicle 5 can all be upgraded to the software versions of the corresponding controllers in the latest software baseline version Base_V_4.0.0, so vehicle 5 is also considered to be matched successfully.

[0148] Furthermore, if there are multiple source software baseline versions, even if a vehicle corresponding to a certain vehicle VIN code has some controllers whose software versions are within the source software baseline version associated with its vehicle status data and others within the source software baseline version selected for this OTA upgrade task, it can also be upgraded to the target OTA software baseline version, i.e., the match is successful;

[0149] As long as the software version of any controller among all the vehicle's controllers does not exist in the source software baseline version or the target OTA software baseline version, the matching fails.

[0150] Step S214: Output the target vehicle data including the vehicle VIN code and the software version information of the upgradeable controller.

[0151] The software version information of the controllers that need to be upgraded for each vehicle is not consistent. The original vehicle status data contains the software version information of all controllers, which is no longer suitable when output. In order to further speed up the OTA upgrade rate, the target vehicle data is generated by associating the vehicle VIN code with the software version information of the upgradeable (or upgrade-required) controller, and the target vehicle data is used as the final output of the vehicle pre-solution matching.

[0152] Step S22: taking the latest released OTA software baseline version as the target OTA software baseline version;

[0153] After the car manufacturer releases the OTA software baseline version, it is necessary to release an OTA upgrade task based on the OTA software baseline version to implement the OTA upgrade. Therefore, the latest released OTA software baseline version can be used as the target OTA software baseline version, and the OTA upgrade task can be used directly when it is released.

[0154] In actual applications, after the OTA software baseline version is released, the OTA task will not be released and the OTA upgrade will not be performed immediately. A certain amount of time will be reserved before the OTA upgrade task is released. In addition, the OTA server is not always idle. Therefore, the vehicle can be pre-solved before the OTA upgrade task is released and the OTA server is idle, saving server resources and improving the efficiency of OTA upgrades.

[0155] Specifically, by determining whether the OTA server is idle, the vehicle can be pre-solved when the OTA server is idle, which can significantly reduce the performance resource consumption of concurrent data on the server.

[0156] Step S23: Match the target OTA software baseline version with the vehicle status data, and pre-solve the vehicle to obtain the target vehicle data.

[0157] After starting the pre-solution of the vehicle, the vehicle status data is matched with the target OTA software baseline version based on the matching logic, and the target vehicle data containing the vehicle VIN code and the software version information of the upgradeable (or required) controller is output as the final output, which is convenient for subsequent storage in the vehicle pool and for creating an OTA release task to achieve OTA upgrade of the controllers that need to be upgraded in the vehicle instead of all controllers.

[0158] Step S3: construct a vehicle pool and store the pre-solved target vehicle data into the vehicle pool;

[0159] Build a vehicle pool. Based on the released OTA software baseline version, build multiple different vehicle pools. Each vehicle pool stores the target vehicle data corresponding to the vehicle that has been pre-solved by the current OTA software baseline version, so that future OTA upgrade tasks can be directly released after creation. In addition, these pre-solved target vehicle data may have more than one source software baseline version. When storing them in the vehicle pool, they can be classified and stored according to the different software baseline versions of each target vehicle data. When releasing the OTA task, the target vehicle data corresponding to at least one source software baseline version in the vehicle pool should be selected.

[0160] In actual applications, although the latest OTA software baseline version is matched each time, there may be a situation where the corresponding OTA upgrade task has not been released for a non-latest OTA software baseline version. If necessary, the OTA upgrade task can also be released based on the historical OTA software baseline version in the vehicle pool and its associated target vehicle data.

[0161] In actual applications, even if all vehicle data has not been matched and pre-solved when the OTA upgrade task needs to be released, some vehicle data can be upgraded in priority based on the pre-solved target vehicle data stored in the vehicle pool. At the same time, the matched data can be excluded, reducing the amount of data that needs to be re-matched for the OTA upgrade task and improving the efficiency of the release and execution of the OTA upgrade task.

[0162] The OTA upgrade process generally releases OTA upgrade tasks based on the target OTA software baseline version, and cannot screen the target vehicles. After the vehicle obtains the target OTA software baseline version, all its controllers need to determine whether this OTA upgrade can be performed. By building a vehicle pool and pre-solving the vehicle to obtain the target vehicle data, the normal OTA upgrade process is pre-processed.

[0163] Step S4: Based on the vehicle pool, create and publish OTA upgrade tasks in a targeted manner.

[0164] Step S41: Select the OTA software baseline version and create an OTA upgrade task;

[0165] Select the OTA software baseline version. Generally, it is not necessary to select the latest version of the OTA software baseline version, and create an OTA upgrade task based on the selected software baseline version. At this time, the created OTA upgrade task only contains the software versions of all vehicle controllers corresponding to the software baseline version, that is, the target OTA software baseline version, and does not contain other information.

[0166] Step S42: acquiring pre-solved target vehicle data from the vehicle pool according to the selected target OTA software baseline version;

[0167] According to the selected target OTA software baseline version, the target OTA software baseline version is found in the vehicle pool, and the associated pre-solved target vehicle data is obtained.

[0168] Step S43: Based on the acquired pre-solved target vehicle data, a targeted OTA upgrade task is issued.

[0169] The pre-solved target vehicle data is obtained, and then the VIN code of the vehicle that needs to perform the OTA upgrade task can be obtained. The OTA upgrade task is issued to the target vehicle according to the vehicle VIN code. The target vehicle data contains the software version information of the controller that can be upgraded (or needs to be upgraded). The targeted release task can also upgrade the specific controller.

[0170] Step S5: Upload the vehicle status data that has completed the OTA upgrade task to the OTA server.

[0171] Specifically, the vehicle VIN code of the vehicle that has completed the OTA upgrade task and the software version information of all its controllers are uploaded to the OTA server, and its source software baseline version is updated to the target OTA software baseline version of this OTA upgrade.

[0172] After completing the OTA upgrade task, the software versions of all controllers of the vehicle that has completed this OTA upgrade task are obtained, and the vehicle status data is updated and reported to the OTA server based on the VIN code of the vehicle. At the same time, its source software baseline version is updated to the target OTA software baseline version of this OTA upgrade task. This can realize real-time update of the vehicle status data in the OTA server, and then each time the vehicle completes an OTA upgrade, the data is stored in the OTA server. There is no need to obtain the vehicle status information again, which can avoid the problem of repeatedly obtaining the same vehicle status data and facilitate the next pre-solution of the vehicle.

[0173] Based on the first embodiment, the present embodiment updates the vehicle status data of each completed OTA upgrade task in the OTA server, which can not only realize the real-time update of the vehicle status data in the OTA server, but also avoid the problem of repeatedly obtaining the same vehicle status data, further reducing the pressure on the server.

[0174] Embodiment 3

[0175] like Figure 3 As shown, an OTA upgrade system 2 based on data pre-calculation is deployed in an OTA server, including:

[0176] A data storage module 21, used to store all acquired vehicle status data and OTA software baseline versions;

[0177] A pre-calculation module 22, used for pre-calculating the vehicle according to the OTA software baseline version and vehicle status data;

[0178] The vehicle pool 23 is used to store the pre-solved target vehicle data;

[0179] The task publishing module 24 is used to create and publish OTA upgrade tasks according to the vehicle pool 23.

[0180] In actual applications, the vehicle pool 23 stores the pre-solved target vehicle data based on the OTA software baseline version. Each baseline version stores different target vehicle data. When the software versions of all vehicle controllers in the target vehicle data change, the target vehicle data needs to be extracted from the vehicle pool. The vehicle can only be returned to the vehicle pool after the pre-solved software versions of all controllers after the change, so as to avoid the problem of the same vehicle VIN corresponding to multiple vehicle status data, and also avoid the problem of the vehicle being unable to complete subsequent OTA upgrade tasks due to bypassing the OTA upgrade activities in other ways.

[0181] Embodiment 4

[0182] like Figure 4 As shown, an OTA upgrade device based on data pre-calculation includes:

[0183] A memory 100, used for storing computer programs;

[0184] The processor 200 is used to execute the computer program to implement the steps of the OTA upgrade method based on data pre-calculation as described in Example 1 and Example 2.

[0185] Embodiment 5

[0186] A readable storage medium for OTA upgrade based on data pre-solution, wherein a computer program is stored on the readable storage medium, and when the computer program is executed, the steps of the OTA upgrade method based on data pre-solution as described in Embodiment 1 and Embodiment 2 are implemented.

[0187] The present invention may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium (or medium) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform aspects of the present invention.

[0188] The readable storage medium is a computer-readable storage medium, which can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punch card or a raised structure in a groove with instructions recorded thereon), and any suitable combination of the above.

[0189] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0190] The computer programs described herein are computer-readable program instructions that can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0191] The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, an electronic circuit (including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA)) may execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions so as to perform aspects of the present invention.

[0192] Aspects of the present invention are described herein with reference to flowcharts of methods, systems, devices, and computer program products according to embodiments of the present invention and / or block diagrams. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0193] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine that, when executed by a processor of the computer or other programmable data processing apparatus, creates a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0194] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with the art within the technical scope disclosed in the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. An OTA upgrade method based on data pre-calculation, characterized in that: The OTA upgrade method based on data pre-calculation includes the following steps: Acquire all vehicle status data and OTA software baseline versions in the OTA server, wherein the vehicle status data at least includes the vehicle VIN code, software version information of all vehicle controllers, and the existing source software baseline version on the vehicle, wherein the OTA software baseline version includes the OTA software baseline version uniformly released by the vehicle manufacturer and the existing source software baseline version of the vehicle, wherein the OTA software baseline version uniformly released by the vehicle manufacturer includes the software versions of all controllers to be upgraded in the vehicle, and the source software baseline version includes the software versions of all existing controllers on the vehicle, wherein acquiring all vehicle status data in the OTA server specifically includes establishing unique vehicle file information for the vehicle through the vehicle VIN code, acquiring software version information of all vehicle controllers through multiple channels, and associating the acquired software version information with the vehicle file information; Based on the OTA software baseline version and the vehicle status data, the vehicle is pre-solved, wherein the pre-solved includes: defining a matching logic for the pre-solved, taking the latest released OTA software baseline version as the target OTA software baseline version, matching the target OTA software baseline version with the vehicle status data, pre-solving the vehicle to obtain target vehicle data, and outputting the successfully matched target vehicle data; The pre-calculated matching logic is: based on the latest released OTA software baseline version, obtain the upgradeable source software baseline version; according to the upgradeable source software baseline version, match the upgradeable vehicle and output the vehicle VIN code corresponding to the vehicle; based on the output vehicle VIN code, match the software version information of all controllers of each vehicle one by one, output the software version information of the upgradeable controller, and output the target vehicle data including the vehicle VIN code and the software version information of the upgradeable controller; Build a vehicle pool and store the target vehicle data generated after pre-calculation into the vehicle pool; Based on the vehicle pool, create and publish OTA upgrade tasks in a targeted manner. Specifically, select the target OTA software baseline version, create an OTA upgrade task, obtain the pre-solved target vehicle data from the vehicle pool according to the selected target OTA software baseline version, and publish the OTA upgrade task in a targeted manner according to the obtained pre-solved target vehicle data.

2. The OTA upgrade method based on data pre-calculation according to claim 1, characterized in that: The obtaining of software version information of all controllers of the vehicle through multiple channels at least includes: obtaining software version information of all controllers reported before the vehicle leaves the factory, after each OTA upgrade task is completed, each time the vehicle is powered on, and each time after-sales maintenance.

3. The OTA upgrade method based on data pre-calculation according to claim 1, characterized in that: The pre-calculation of the vehicle specifically includes: determining whether the OTA server is idle, and pre-calculating the vehicle when the OTA server is idle.

4. An OTA upgrade system based on data pre-calculation, characterized in that: The OTA upgrade system based on data pre-calculation is deployed in the OTA server, including: A data storage module, used to store all acquired vehicle status data and OTA software baseline versions, wherein the vehicle status data at least includes the vehicle VIN code, software version information of all vehicle controllers and the existing source software baseline version on the vehicle, wherein the OTA software baseline version includes the OTA software baseline version uniformly released by the vehicle manufacturer and the existing source software baseline version of the vehicle, wherein the OTA software baseline version uniformly released by the vehicle manufacturer includes the software versions of all vehicle controllers to be upgraded, and the source software baseline version includes the software versions of all existing controllers on the vehicle, and acquiring all vehicle status data in the OTA server specifically includes establishing unique vehicle file information for the vehicle through the vehicle VIN code, acquiring software version information of all vehicle controllers through multiple channels, and associating the acquired software version information with the vehicle file information; A pre-resolution module is used to pre-solve the vehicle according to the OTA software baseline version and the vehicle status data, wherein the pre-solving of the vehicle includes: defining the matching logic of the pre-solving, taking the latest released OTA software baseline version as the target OTA software baseline version, matching the target OTA software baseline version with the vehicle status data, pre-solving the vehicle to obtain the target vehicle data, and outputting the successfully matched target vehicle data; the matching logic of the pre-solving is: based on the latest released OTA software baseline version, obtaining the upgradeable source software baseline version; according to the upgradeable source software baseline version, matching the upgradeable vehicle, and outputting the vehicle VIN code corresponding to the vehicle; based on the output vehicle VIN code, matching the software version information of all controllers of each vehicle one by one, outputting the software version information of the upgradeable controller, and outputting the target vehicle data including the vehicle VIN code and the software version information of the upgradeable controller; The vehicle pool is used to store the target vehicle data generated after pre-calculation; The task release module is used to create and release OTA upgrade tasks in a targeted manner based on the vehicle pool. Specifically, the target OTA software baseline version is selected, an OTA upgrade task is created, and based on the selected target OTA software baseline version, pre-solved target vehicle data is obtained from the vehicle pool. Based on the obtained pre-solved target vehicle data, the OTA upgrade task is targetedly released.

Images