OTA upgrade method and system based on data pre-resolution

Abstract

Disclosed are an OTA upgrade method and system based on data pre-resolution. The OTA upgrade method based on data pre-resolution comprises: acquiring all vehicle state data and OTA software baseline versions from an OTA server; pre-resolving vehicles on the basis of the OTA software baseline versions and the vehicle state data; constructing a vehicle pool, and storing target vehicle data, which is generated after the pre-resolution, into the vehicle pool; and creating and directionally releasing an OTA upgrade task on the basis of the vehicle pool. When the OTA server is idle, the vehicle state data can be pre-resolved and stored in the vehicle pool, and the OTA upgrade task is directionally released on the basis of the vehicle pool without the need to match the vehicle state data, thereby greatly reducing resource consumption of concurrent data of the server, and improving OTA upgrade efficiency.

Description

An OTA upgrade method and system based on data pre-computation Technical Field

[0001] This invention relates to OTA upgrade methods, and more particularly to an OTA upgrade method and system based on data pre-computation. Background Technology

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

[0003] Currently, when planning OTA (Over-The-Air) campaigns, automakers generally do not perform OTA upgrades for all vehicles. This is because each vehicle has different versions of its software, and not all vehicles can be upgraded through this OTA campaign. At present, automakers cannot obtain the latest version status of vehicle software in a timely manner, and operations personnel cannot accurately know which vehicles can be upgraded when creating OTA campaigns.

[0004] Furthermore, the current situation involves launching OTA (Over-The-Air) market tasks without knowing the vehicle's status. After the vehicle's power-on proactive detection task is completed, the OTA platform is then used for vehicle task matching. This postpones the entire process of vehicle detection and cloud matching, leading to server performance bottlenecks when handling a large number of vehicles in the market during concurrent OTA processing. As the trend towards software-defined vehicles evolves, scenarios with high-concurrency requests for server resources will become increasingly common, making cost savings and performance improvements essential. Summary of the Invention

[0005] Given that current OTA upgrades cannot accurately identify the vehicles that need to be upgraded, this invention provides an OTA upgrade method based on data pre-calculation. By pre-calculating vehicle status data and storing it in a vehicle pool, OTA upgrade tasks are then issued to specific vehicles based on the vehicle pool, thereby improving the efficiency of OTA upgrades.

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

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

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

[0009] Based on the OTA software baseline version and vehicle status data, the vehicle is pre-calculated;

[0010] Construct 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 target OTA upgrade tasks.

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

[0013] According to one aspect of the present invention, the acquisition of all vehicle status data in the OTA server specifically involves: establishing a unique vehicle file information for the vehicle using the vehicle VIN code, acquiring the software version information of all controllers of the vehicle through multiple means, and associating the acquired software version information with the vehicle file information.

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

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

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

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

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

[0019] The target software version is matched with the vehicle status data, and the vehicle is pre-calculated to obtain the target vehicle data.

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

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

[0022] Based on the upgradeable source software baseline version, match the upgradeable vehicle and output the corresponding vehicle VIN code.

[0023] Based on the output vehicle VIN code, match the software version information of all controllers for each vehicle one by one, and output the software version information of the upgradeable controllers.

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

[0025] According to one aspect of the present invention, the creation and targeted release of OTA upgrade tasks based on a vehicle pool includes:

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

[0027] Based on the selected target software baseline version, obtain pre-calculated target vehicle data from the vehicle pool;

[0028] Based on the pre-calculated target vehicle data, 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 involves: determining whether the OTA server is idle, and performing pre-calculation of the vehicle when the OTA server is idle.

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

[0031] The data storage module is used to store vehicle status data and OTA software baseline version;

[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 target OTA upgrade tasks based on the vehicle pool.

[0035] The advantages of this invention are as follows: The OTA upgrade method based on data pre-calculation described in this invention obtains vehicle status information through multiple channels and at regular intervals, enabling advance knowledge of vehicle status information and facilitating its processing. Based on the latest OTA software baseline version released by the OTA server, pre-calculation services are performed on vehicles during idle periods, and the pre-calculated target vehicle data is stored in a vehicle pool, significantly reducing server resource consumption for concurrent data and maintaining OTA server stability. When an OTA upgrade task needs to be released, the system can accurately retrieve the vehicle information requiring upgrades based on existing data in the vehicle pool after creating the OTA upgrade task, thereby achieving targeted OTA upgrade task release and improving OTA upgrade efficiency. Furthermore, those skilled in the art can also obtain the software versions that need upgrading in the current market through targeted OTA upgrade tasks, conduct targeted technical research and development, and achieve pre-processing of the entire market operation. Furthermore, updating the vehicle status data after each completed OTA upgrade task on the OTA server not only achieves real-time updates of vehicle status data on the OTA server but also avoids the problem of repeatedly obtaining the same vehicle status data, further reducing server pressure. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 is a flowchart of the OTA upgrade method based on data pre-computation according to Embodiment 1 of the present invention;

[0038] Figure 2 is a flowchart of the OTA upgrade method based on data pre-calculation according to Embodiment 2 of the present invention;

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

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

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Example 1

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

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

[0045] An OTA server, or OTA cloud platform, is used to manage vehicle status data and OTA software baseline versions.

[0046] The OTA software baseline version needs to go through the OTA verification process within the car manufacturer and the software maturity needs to reach a certain standard before it will be officially released. The officially released OTA software baseline version will be uploaded to the OTA server for updating and storage. The OTA software baseline version is the major software version, which contains the software version information of all controllers in the vehicle. Generally, the latest released OTA software baseline version will be used as the target software baseline version for OTA upgrade tasks.

[0047] The vehicle status data includes at least the vehicle's VIN code and the software version information of all vehicle controllers. The vehicle VIN code, also known as the Vehicle Identification Number, is a 17-digit alphanumeric code used to uniquely identify a vehicle. It can contain information such as the vehicle's manufacturer, year, model, engine type, and production plant. All vehicle controllers include: intelligent domain controllers (powertrain domain, chassis domain, intelligent driving domain, body domain, etc.) and traditional controllers (power steering system, streaming rearview mirror, electronic toll collection system, pressure and temperature sensors, wiper controller, etc.).

[0048] A unique vehicle file is established using the vehicle's VIN code. Software version information for all controllers in the vehicle is obtained through multiple means, and this software version information is associated with the vehicle file information. Specifically, the vehicle's VIN code is associated with the software version information of all controllers in the vehicle. Furthermore, based on the software version information of all controllers, the vehicle's software baseline version can be obtained, and this software baseline version is defined as the existing source software baseline version on the vehicle.

[0049] In OTA upgrade activities, in addition to obtaining the OTA software baseline version, it is also necessary to obtain the current software version information of all controllers in the vehicle to obtain the source software baseline version in order 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 from it, as follows:

[0051] Obtain vehicle file information that has been written and published on the production line before the vehicle 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, the software information obtained by the vehicle terminal through the vehicle controller software version is obtained every time the vehicle is powered on. This information includes the vehicle file information.

[0054] After the vehicle leaves the factory, each time after-sales service is completed, the staff will report the vehicle file information to the after-sales system.

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

[0056] In practical applications, when obtaining vehicle file information through some means, the amount of data that needs to be processed is large. Real-time acquisition will consume a lot of server performance. Therefore, it is possible to preset time intervals to periodically obtain vehicle file information, process the vehicle file information, extract the software version information of all controllers contained therein, and obtain the source software baseline version.

[0057] It is important to note that vehicle status data obtained through multiple channels needs to be uploaded to the OTA server for storage, facilitating future data retrieval via the OTA server. The vehicle VIN code remains constant within the acquired vehicle status data. Therefore, when obtaining vehicle status data through different channels, it is only necessary to look up the software version information of all controllers associated with the original vehicle using the vehicle VIN code, and update the software version information of all controllers to ensure that the vehicle status data in the OTA platform corresponds to the latest software version information of all controllers. The vehicle's source software baseline version is then updated based on the software version information of all controllers. Simultaneously, it is necessary to record the data from each update for easy tracing and resolution in case of problems.

[0058] Step S2: Based on the OTA software baseline version and vehicle status data, perform pre-calculation on the vehicle;

[0059] Step S21: Define the matching logic for pre-computation;

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

[0061] The specific matching logic is as follows:

[0062] Step S211: Based on the latest released OTA software baseline version, obtain the source software baseline version that can be upgraded;

[0063] When acquiring vehicle status data, in addition to the vehicle VIN code, the software version information of all controllers associated with the vehicle VIN code, as well as the source software baseline version, are also obtained. The source software baseline version contains the software version information of all controllers in the vehicle. 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 controllers, and the source software baseline version is uploaded to the OTA server for matching in the pre-calculation.

[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. 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-calculated for vehicles with the software baseline version of that 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-calculated and successfully matched can be selected as the source software baseline version of the OTA upgrade task.

[0065] Step S212: Based on the upgradeable source software baseline version, match the upgradeable vehicles and output the corresponding vehicle VIN code.

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

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

[0068] In step S212, vehicles that can use the latest released OTA software baseline version for this OTA upgrade are selected. Based on the matching result of step S212, i.e. the output vehicle VIN code, the software version information of all controllers of each vehicle is matched, and the software version information of the controllers that can be upgraded is output as the result.

[0069] In practical applications, not all vehicles can upgrade all of their controllers based on the latest OTA software baseline version. Some vehicles may have source software baseline versions that meet the conditions for OTA upgrade, but only some of their controller software versions need to be upgraded. The remaining software versions may be the same as the software versions in the latest OTA software baseline version. Therefore, step S213 is to find out which controllers of each vehicle can be upgraded by matching.

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

[0071] The source software baseline version is Base_V_2.0.0, of which some controller versions are VCU:V_0.9.0, TBOX:V_0.9.0, and GW:V_0.9.0 (the controllers are VCU, TBOX, and GW; in reality, a vehicle contains more than three controllers. In this embodiment, only three are selected for the sake of briefly explaining 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 controllers are version VCU:V_1.0.0, TBOX:V_1.0.0, and GW:V_1.0.0. The source software baseline versions of vehicles 1, 2, 3 and 4 given below are all Base_V_2.0.0.

[0073] The latest released software baseline version is Base_V_4.0.0, with some controllers having versions VCU:V_1.0.1, TBOX:V_1.2.0, and GW:V_1.3.0;

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

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

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

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

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

[0079] The software versions of all controllers in the vehicle are matched one by one according to the vehicle's VIN. The software versions of the three controllers provided by vehicle 1 are not the latest versions compared to the latest released software baseline version Base_V_4.0.0. This means that all three controllers provided by vehicle 1 can be upgraded in this upgrade. Therefore, in addition to the vehicle's VIN, the output also includes the controllers that need to be upgraded and their versions: VCU:V_1.0.0, TBOX:V_1.0.0, and 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, the VCU controller is already the latest version V_1.0.1 compared to the latest released software baseline version Base_V_4.0.0, while the TBOX and GW controllers are not the latest versions. Therefore, the output includes the vehicle's VIN code, the controllers that need to be upgraded, and the controller versions TBOX:V_1.0.0 and GW:V_1.0.0.

[0081] The result of matching the software version information of all controllers in vehicle 3 includes the vehicle's VIN code 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 controller VCU and TBOX are the latest versions, the controller GW version is V3.0.0. This version cannot be upgraded to the controller GW version V1.3.0 in Base_V_4.0.0. In fact, the vehicle can modify a 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 upgradable controller will not be output, and vehicle 4 will not proceed to the next step.

[0083] Vehicle 5's source software baseline version 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 its controller GW through non-OTA means, resulting in the software version of its controller GW being consistent with Base_V_3.0.0. In this case, since both Base_V_2.0.0 and Base_V_3.0.0 are the source software baseline versions selected for this OTA upgrade task, Vehicle 5's controllers VCU, TBOX, and GW can all be upgraded to the corresponding controller software versions in the latest software baseline version Base_V_4.0.0. Therefore, Vehicle 5 is also considered to have successfully matched.

[0084] Furthermore, if multiple source software baseline versions exist, 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 still be upgraded to the target software baseline version, i.e., the match is successful.

[0085] Matching fails if any of the vehicle's controllers has a software version that is neither in the source software baseline version nor in the target software baseline version.

[0086] Step S214: Output target vehicle data containing vehicle VIN code and 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 for output. In order to further speed up the OTA upgrade, the target vehicle data is generated by associating the vehicle VIN code with the software version information of the upgradeable (or upgradeable) controllers. The target vehicle data is used as the final output of vehicle pre-computation matching.

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

[0089] After a car manufacturer releases an OTA software baseline version, it needs 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 software baseline version, and the OTA upgrade task can be released directly.

[0090] In practical applications, after releasing the baseline version of the OTA software, 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. Furthermore, the OTA server is not always idle. Therefore, the vehicle can be pre-calculated before the OTA upgrade task is released and when the OTA server is idle, which saves server resources and improves the efficiency of OTA upgrade.

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

[0092] Step S23: Match the target software version with the vehicle status data, and perform pre-calculation on the vehicle to obtain the target vehicle data.

[0093] After initiating the pre-computation of the vehicle, the vehicle status data is matched with the target software version based on the matching logic. The target vehicle data, which includes the vehicle VIN code and the software version information of the upgradeable (or upgradeable) controller, is used as the final output. This facilitates subsequent storage in the vehicle pool and also enables OTA upgrades to be performed on the controllers that need to be upgraded, rather than all controllers, after creating an OTA release task.

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

[0095] Construct vehicle pools. 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 after pre-calculation using the current OTA software baseline version, which facilitates direct targeted release after the creation of future OTA upgrade tasks. In addition, these pre-calculated 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 an OTA task, the target vehicle data corresponding to at least one source software baseline version in the vehicle pool should be selected.

[0096] In practical applications, although the latest OTA software baseline version is always matched, there may be situations where non-latest OTA software baseline versions have not yet released corresponding OTA upgrade tasks. If necessary, OTA upgrade tasks can be released based on historical OTA software baseline versions and their associated target vehicle data in the vehicle pool. In practice, even if not all vehicle data has been matched and pre-calculated when an OTA upgrade task needs to be released, partial priority upgrades can still be performed based on the pre-calculated target vehicle data already stored in the vehicle pool. At the same time, already matched data can be excluded, reducing the amount of data that needs to be rematched for the OTA upgrade task and improving the efficiency of OTA upgrade task release and execution.

[0097] The OTA upgrade process generally involves issuing an OTA upgrade task based on the target software baseline version. It cannot screen the target vehicles. After a vehicle obtains the target software baseline version, all its controllers need to determine whether the OTA upgrade can be performed. However, by building a vehicle pool and pre-computing the vehicles to obtain the target vehicle data, this normal OTA upgrade process is pre-processed.

[0098] Step S4: Based on the vehicle pool, create and target OTA upgrade tasks.

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

[0100] When selecting an OTA software baseline version, it is generally unnecessary to choose the latest version. An OTA upgrade task is then created based on the selected software baseline version. The OTA upgrade task created at this time only contains the software versions of all vehicle controllers corresponding to this software baseline version, i.e., the target software baseline version, and does not contain any other information.

[0101] Step S42: Based on the selected target software baseline version, obtain the pre-calculated target vehicle data from the vehicle pool;

[0102] Based on the selected target software baseline version, locate the pre-calculated target vehicle data associated with that target software baseline version in the vehicle pool.

[0103] Step S43: Based on the pre-calculated target vehicle data, issue OTA upgrade tasks in a targeted manner.

[0104] By acquiring the pre-calculated target vehicle data, the VIN code of the vehicle that needs to be upgraded in this OTA upgrade task can be obtained. The OTA upgrade task is then issued to the target vehicle based on 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 task can also upgrade the specific controller.

[0105] This embodiment discloses an OTA upgrade method based on data pre-calculation. It acquires vehicle status information through multiple channels and at regular intervals, allowing for advance knowledge of vehicle status information and facilitating its processing. Based on the latest software baseline version released by the OTA server, it performs pre-calculation services on vehicles during idle periods and stores the pre-calculated target vehicle data in a vehicle pool. This significantly reduces the resource consumption of concurrent data on the server and maintains the stability of the OTA server. When an OTA upgrade task needs to be released, it can accurately retrieve the vehicle information requiring upgrade based on existing data in the vehicle pool after the OTA upgrade task is created, thereby achieving targeted release of OTA upgrade tasks and improving OTA upgrade efficiency. Furthermore, those skilled in the art can also obtain the software versions that need upgrading in the current market through targeted OTA upgrade tasks, conduct targeted technical research and development, and achieve pre-processing of the entire market operation.

[0106] Example 2

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

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

[0109] An OTA server, or OTA cloud platform, is used to manage vehicle status data and OTA software baseline versions.

[0110] The OTA software baseline version needs to go through the OTA verification process within the car manufacturer and the software maturity needs to reach a certain standard before it will be officially released. The officially released OTA software baseline version will be uploaded to the OTA server for updating and storage. The OTA software baseline version is the major software version, which contains the software version information of all controllers in the vehicle. Generally, the latest released OTA software baseline version will be used as the target software baseline version for OTA upgrade tasks.

[0111] The vehicle status data includes at least the vehicle's VIN code and the software version information of all vehicle controllers. The vehicle VIN code, also known as the Vehicle Identification Number, is a 17-digit alphanumeric code used to uniquely identify a vehicle. It can contain information such as the vehicle's manufacturer, year, model, engine type, and production plant. All vehicle controllers include: intelligent domain controllers (powertrain domain, chassis domain, intelligent driving domain, body domain, etc.) and traditional controllers (power steering system, streaming rearview mirror, electronic toll collection system, pressure and temperature sensors, wiper controller, etc.).

[0112] A unique vehicle file is established using the vehicle's VIN code. Software version information for all controllers in the vehicle is obtained through multiple means, and this software version information is associated with the vehicle file information. Specifically, the vehicle's VIN code is associated with the software version information of all controllers in the vehicle. Furthermore, based on the software version information of all controllers, the vehicle's software baseline version can be obtained, and this software baseline version is defined as the existing source software baseline version on the vehicle.

[0113] In OTA upgrade activities, in addition to obtaining the OTA software baseline version, it is also necessary to obtain the current software version information of all controllers in the vehicle to obtain the source software baseline version in order 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 from it, as follows:

[0115] Obtain vehicle file information that has been written and published on the production line before the vehicle 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, the software information obtained by the vehicle terminal through the vehicle controller software version is obtained every time the vehicle is powered on. This information includes the vehicle file information.

[0118] After the vehicle leaves the factory, each time after-sales service is completed, the staff will report the vehicle file information to the after-sales system.

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

[0120] In practical applications, when obtaining vehicle file information through some means, the amount of data that needs to be processed is large. Real-time acquisition will consume a lot of server performance. Therefore, it is possible to preset time intervals to periodically obtain vehicle file information, process the vehicle file information, extract the software version information of all controllers contained therein, and obtain the source software baseline version.

[0121] It is important to note that vehicle status data obtained through multiple channels needs to be uploaded to the OTA server for storage, facilitating future data retrieval via the OTA server. The vehicle VIN code remains constant within the acquired vehicle status data. Therefore, when obtaining vehicle status data through different channels, it is only necessary to look up the software version information of all controllers associated with the original vehicle using the vehicle VIN code, and update the software version information of all controllers to ensure that the vehicle status data in the OTA platform corresponds to the latest software version information of all controllers. The vehicle's source software baseline version is then updated based on the software version information of all controllers. Simultaneously, it is necessary to record the data from each update for easy tracing and resolution in case of problems.

[0122] Step S2: Based on the OTA software baseline version and vehicle status data, perform pre-calculation on the vehicle;

[0123] Step S21: Define the matching logic for pre-computation;

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

[0125] The specific matching logic is as follows:

[0126] Step S211: Based on the latest released OTA software baseline version, obtain the source software baseline version that can be upgraded;

[0127] When acquiring vehicle status data, in addition to the vehicle VIN code, the software version information of all controllers associated with the vehicle VIN code, as well as the source software baseline version, are also obtained. The source software baseline version contains the software version information of all controllers in the vehicle. 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 controllers, and the source software baseline version is uploaded to the OTA server for matching in the pre-calculation.

[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. 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-calculated for vehicles with the software baseline version of that 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-calculated and successfully matched can be selected as the source software baseline version of the OTA upgrade task.

[0129] Step S212: Based on the upgradeable source software baseline version, match the upgradeable vehicles and output the corresponding vehicle VIN code.

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

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

[0132] In step S212, vehicles that can use the latest released OTA software baseline version for this OTA upgrade are selected. Based on the matching result of step S212, i.e. the output vehicle VIN code, the software version information of all controllers of each vehicle is matched, and the software version information of the controllers that can be upgraded is output as the result.

[0133] In practical applications, not all vehicles can upgrade all of their controllers based on the latest OTA software baseline version. Some vehicles may have source software baseline versions that meet the conditions for OTA upgrade, but only some of their controller software versions need to be upgraded. The remaining software versions may be the same as the software versions in the latest OTA software baseline version. Therefore, step S213 is to find out which controllers of each vehicle can be upgraded by matching.

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

[0135] The source software baseline version is Base_V_3.0.0, of which some controllers are based on the source software baseline version Base_V_2.0.0, and some controllers are based on the versions VCU:V_0.9.0, TBOX:V_0.9.0, and GW:V_0.9.0 (the controllers are VCU, TBOX, and GW; in reality, a vehicle may contain more than three controllers, but in this embodiment, only three are used for the sake of briefly explaining 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 controllers are version VCU:V_1.0.0, TBOX:V_1.0.0, and GW:V_1.0.0. The source software baseline versions of vehicles 1, 2, 3 and 4 given below are all Base_V_2.0.0.

[0137] The latest released software baseline version is Base_V_4.0.0, with some controllers having versions VCU:V_1.0.1, TBOX:V_1.2.0, and GW:V_1.3.0;

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

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

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

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

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

[0143] The software versions of all controllers in the vehicle are matched one by one according to the vehicle's VIN. The software versions of the three controllers provided by vehicle 1 are not the latest versions compared to the latest released software baseline version Base_V_4.0.0. This means that all three controllers provided by vehicle 1 can be upgraded in this upgrade. Therefore, in addition to the vehicle's VIN, the output also includes the controllers that need to be upgraded and their versions: VCU:V_1.0.0, TBOX:V_1.0.0, and 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, the VCU controller is already the latest version V_1.0.1 compared to the latest released software baseline version Base_V_4.0.0, while the TBOX and GW controllers are not the latest versions. Therefore, the output includes the vehicle's VIN code, the controllers that need to be upgraded, and the controller versions TBOX:V_1.0.0 and GW:V_1.0.0.

[0145] The result of matching the software version information of all controllers in vehicle 3 includes the vehicle's VIN code 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 controller VCU and TBOX are the latest versions, the controller GW version is V3.0.0. This version cannot be upgraded to the controller GW version V1.3.0 in Base_V_4.0.0. In fact, the vehicle can modify a 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 upgradable controller will not be output, and vehicle 4 will not proceed to the next step.

[0147] Vehicle 5's source software baseline version 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 its controller GW through non-OTA means, resulting in the software version of its controller GW being consistent with Base_V_3.0.0. In this case, since both Base_V_2.0.0 and Base_V_3.0.0 are the source software baseline versions selected for this OTA upgrade task, Vehicle 5's controllers VCU, TBOX, and GW can all be upgraded to the corresponding controller software versions in the latest software baseline version Base_V_4.0.0. Therefore, Vehicle 5 is also considered to have successfully matched.

[0148] Furthermore, if multiple source software baseline versions exist, 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 still be upgraded to the target software baseline version, i.e., the match is successful.

[0149] Matching fails if any of the vehicle's controllers has a software version that is neither in the source software baseline version nor in the target software baseline version.

[0150] Step S214: Output target vehicle data containing vehicle VIN code and 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 for output. In order to further speed up the OTA upgrade, the target vehicle data is generated by associating the vehicle VIN code with the software version information of the upgradeable (or upgradeable) controllers. The target vehicle data is used as the final output of vehicle pre-computation matching.

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

[0153] After a car manufacturer releases an OTA software baseline version, it needs 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 software baseline version, and the OTA upgrade task can be released directly.

[0154] In practical applications, after releasing the baseline version of the OTA software, 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. Furthermore, the OTA server is not always idle. Therefore, the vehicle can be pre-calculated before the OTA upgrade task is released and when the OTA server is idle, which saves server resources and improves the efficiency of OTA upgrade.

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

[0156] Step S23: Match the target software version with the vehicle status data, and perform pre-calculation on the vehicle to obtain the target vehicle data.

[0157] After initiating the pre-computation of the vehicle, the vehicle status data is matched with the target software version based on the matching logic. The target vehicle data, which includes the vehicle VIN code and the software version information of the upgradeable (or upgradeable) controller, is used as the final output. This facilitates subsequent storage in the vehicle pool and also enables OTA upgrades to be performed on the controllers that need to be upgraded, rather than all controllers, after creating an OTA release task.

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

[0159] Construct vehicle pools. 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 after pre-calculation using the current OTA software baseline version, which facilitates direct targeted release after the creation of future OTA upgrade tasks. In addition, these pre-calculated 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 an OTA task, the target vehicle data corresponding to at least one source software baseline version in the vehicle pool should be selected.

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

[0161] In practical applications, even if not all vehicle data has been matched and pre-calculated when an OTA upgrade task needs to be released, partial priority upgrades can still be performed based on the pre-calculated target vehicle data already stored in the vehicle pool. At the same time, already matched data can be excluded, reducing the amount of data that needs to be rematched for the OTA upgrade task and improving the efficiency of OTA upgrade task release and execution.

[0162] The OTA upgrade process generally involves issuing an OTA upgrade task based on the target software baseline version. It cannot screen the target vehicles. After a vehicle obtains the target software baseline version, all its controllers need to determine whether the OTA upgrade can be performed. However, by building a vehicle pool and pre-computing the vehicles to obtain the target vehicle data, this normal OTA upgrade process is pre-processed.

[0163] Step S4: Based on the vehicle pool, create and target OTA upgrade tasks.

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

[0165] When selecting an OTA software baseline version, it is generally unnecessary to choose the latest version. An OTA upgrade task is then created based on the selected software baseline version. The OTA upgrade task created at this time only contains the software versions of all vehicle controllers corresponding to this software baseline version, i.e., the target software baseline version, and does not contain any other information.

[0166] Step S42: Based on the selected target software baseline version, obtain the pre-calculated target vehicle data from the vehicle pool;

[0167] Based on the selected target software baseline version, find the target software baseline version in the vehicle pool and associate it with the target vehicle data that has been pre-calculated.

[0168] Step S43: Based on the pre-calculated target vehicle data, issue OTA upgrade tasks in a targeted manner.

[0169] By acquiring the pre-calculated target vehicle data, the VIN code of the vehicle that needs to be upgraded in this OTA upgrade task can be obtained. The OTA upgrade task is then issued to the target vehicle based on 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 task can also upgrade the specific controller.

[0170] Step S5: Upload the vehicle status data after completing the OTA upgrade task to the OTA server.

[0171] Specifically, the 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 software baseline version of this OTA upgrade.

[0172] After completing the OTA upgrade task, the software versions of all controllers of the vehicle that completed the OTA upgrade task are obtained. Based on the vehicle's VIN code, the vehicle status data is updated and reported to the OTA server. At the same time, the source software baseline version is updated to the target software baseline version of this OTA upgrade task. This enables real-time updates of vehicle status data in the OTA server. Thus, the vehicle status information is stored in the OTA server after each OTA upgrade, eliminating the need to repeatedly obtain the same vehicle status data. This also facilitates the next pre-calculation of the vehicle.

[0173] Based on Example 1, this embodiment updates the vehicle status data on the OTA server after each OTA upgrade task is completed. This not only enables real-time updates of the vehicle status data on the OTA server but also avoids the problem of repeatedly obtaining the same vehicle status data, further reducing the server load.

[0174] Example 3

[0175] As shown in Figure 3, an OTA upgrade system 2 based on data pre-computation is deployed in an OTA server and includes:

[0176] Data storage module 21 is used to store vehicle status data and OTA software baseline version;

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

[0178] Vehicle pool 23 is used to store pre-calculated target vehicle data;

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

[0180] In practical applications, vehicle pool 23 stores the pre-calculated target vehicle data based on the OTA software baseline version. Each baseline version stores different target vehicle data. When the software version of all controllers in the target vehicle data changes, the target vehicle data needs to be extracted from the vehicle pool. The vehicle is then re-calculated based on the changed software versions of all controllers before returning to the vehicle pool. This avoids the problem of the same vehicle VIN corresponding to multiple vehicle status data and also avoids the problem of vehicles being unable to complete subsequent OTA upgrade tasks due to bypassing OTA upgrade activities in other ways.

[0181] Example 4

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

[0183] Memory 100 is used to store 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-computation as described in Embodiment 1 and Embodiment 2.

[0185] Example 5

[0186] A readable storage medium for OTA upgrade based on data pre-computation is provided. The readable storage medium stores a computer program, which, when executed, implements the steps of the OTA upgrade method based on data pre-computation as described in Embodiments 1 and 2.

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

[0188] A computer-readable storage medium is a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or raised structures in grooves having instructions recorded thereon), and any suitable combination of the foregoing.

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

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

[0191] The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone 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 through an Internet service provider). In some embodiments, electronic circuitry (including, for example, programmable logic circuitry, a field-programmable gate array (FPGA), or a programmable logic array (PLA)) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of the invention.

[0192] Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems, apparatuses, and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, 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, which executes via the processor of the computer or other programmable data processing apparatus, creating means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium capable of instructing a computer, a programmable data processing apparatus, and / or other devices that function in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0194] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An OTA upgrade method based on data pre-computation, characterized in that, The OTA upgrade method based on data pre-calculation includes the following steps: Obtain all vehicle status data and OTA software baseline version from the OTA server; Based on the OTA software baseline version and vehicle status data, the vehicle is pre-calculated; Construct a vehicle pool and store the target vehicle data generated after pre-calculation into the vehicle pool; Based on the vehicle pool, create and target OTA upgrade tasks.

2. The OTA upgrade method based on data pre-computation according to claim 1, characterized in that, The vehicle status data includes at least: the vehicle VIN code, the software version information of all controllers in the vehicle, and the existing source software baseline version in the vehicle; the OTA software baseline version includes the software versions of all controllers in the vehicle to be upgraded, and the source software baseline version includes the software versions of all controllers currently in the vehicle.

3. The OTA upgrade method based on data pre-computation according to claim 2, characterized in that, The specific steps for obtaining all vehicle status data from the OTA server are as follows: establishing a unique vehicle file information for the vehicle using the vehicle VIN code, obtaining the software version information of all controllers of the vehicle through multiple channels, and associating the obtained software version information with the vehicle file information.

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

5. The OTA upgrade method based on data pre-computation according to claim 2, characterized in that, 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.

6. The OTA upgrade method based on data pre-computation according to claim 2, characterized in that, The pre-calculation of the vehicle based on the OTA software baseline version and vehicle status data includes: Define the matching logic for pre-computation; Use the latest released OTA software baseline version as the target software baseline version; The target software version is matched with the vehicle status data, and the vehicle is pre-calculated to obtain the target vehicle data. Output the data of the target vehicles that were successfully matched.

7. The OTA upgrade method based on data pre-computation according to claim 6, characterized in that, The matching logic is as follows: Based on the latest released OTA software baseline version, obtain the source software baseline version that can be upgraded; Based on the upgradeable source software baseline version, match the upgradeable vehicle and output the corresponding vehicle VIN code. Based on the output vehicle VIN code, match the software version information of all controllers for each vehicle one by one, and output the software version information of the upgradeable controllers. Output target vehicle data including vehicle VIN code and software version information of the upgradable controller.

8. The OTA upgrade method based on data pre-computation according to claim 6, characterized in that, The creation and targeted release of OTA upgrade tasks based on vehicle pools includes: Select the baseline version of the OTA software and create an OTA upgrade task; Based on the selected target software baseline version, obtain pre-calculated target vehicle data from the vehicle pool; Based on the pre-calculated target vehicle data, OTA upgrade tasks are issued in a targeted manner.

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

10. An OTA upgrade system based on data pre-computation, characterized in that, The OTA upgrade system based on data pre-computation is deployed on an OTA server and includes: The data storage module is used to store vehicle status data and OTA software baseline version; The pre-calculation module is used to pre-calculate the vehicle based on the OTA software baseline version and vehicle status data; The vehicle pool is used to store the target vehicle data generated after pre-calculation. The task publishing module is used to create and target OTA upgrade tasks based on the vehicle pool.

Images