OTA upgrade task pushing method and device, medium and equipment

Abstract

The invention provides an OTA upgrading task pushing method and device, a medium and equipment, and relates to the technical field of vehicle upgrading. According to the method, firstly, a plurality of historical versions of various controllers are subjected to target upgrading testing to detect whether the historical versions can be directly upgraded to target versions or not, and a basis is provided for creating and pushing subsequent upgrading tasks. And then, when the upgrading task is created, selecting a transition version for the controller with the historical version which cannot be directly upgraded to the target version, and generating the upgrading task according to the transition version. Therefore, when the vehicle requests upgrading, if the current version of a certain controller of the vehicle cannot be directly upgraded to the target version by querying the test record, an upgrading task containing the transition version is pushed to the controller, so that the controller is upgraded to the transition version first and then upgraded to the target version from the transition version next time, and the success rate of OTA upgrading is ensured; and the vehicle is prevented from blindly upgrading the target version to cause upgrading failure and influence on each controller function of the vehicle.

Description

Technical Field

[0001] The present application relates to the field of vehicle upgrade technology, and in particular to an OTA upgrade task push method, device, medium and equipment. Background Art

[0002] With the development of software-defined cars, the update and iteration rate of vehicle software is getting faster and faster, and the demand for vehicle software upgrades in the market has increased dramatically. Vehicle remote upgrade (Over The Air, referred to as OTA) has become the main way for major automakers to update vehicle software due to its high efficiency and low cost.

[0003] In the prior art, when pushing an OTA upgrade task, the software version to be released is directly pushed as the version to be upgraded to the vehicle requesting the upgrade. However, there are many types of software versions for vehicles on the market, and it is difficult to ensure that different vehicle software versions are successfully upgraded, which affects the success rate of the OTA upgrade. Summary of the invention

[0004] The present application provides an OTA upgrade task push method, device, medium and equipment, which can improve the success rate of OTA task upgrades.

[0005] A first aspect of an embodiment of the present application provides an OTA upgrade task push method, the method comprising: Acquire upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any of the controllers to be upgraded to a target version corresponding to the controller to be upgraded; Based on the upgrade test result, a first upgrade task is created; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions in which the upgrade test result of the to-be-upgraded controller is successful; In response to an OTA upgrade request of the current vehicle, if it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle fails, the first upgrade task is pushed to the current vehicle.

[0006] Optionally, based on the upgrade test result, creating a first upgrade task includes: For any of the controllers to be upgraded, if the upgrade test result of any of the historical versions of the controller to be upgraded is failed, determine a transition version of the controller to be upgraded from the remaining historical versions of the controller to be upgraded whose upgrade test results are successful; Count all the controllers to be upgraded that have transition versions, determine the transition versions as the upgrade versions of the controllers to be upgraded, and create the first upgrade task.

[0007] Optionally, the method further comprises: For all the controllers to be upgraded, determining the target version corresponding to the controllers to be upgraded as the upgraded version of the controllers to be upgraded, and creating a second upgrade task; In response to the OTA upgrade request of the current vehicle, when it is found from the upgrade test record that the upgrade test results of the current versions of all the controllers to be upgraded of the current vehicle are successful, the second upgrade task is pushed to the current vehicle.

[0008] Optionally, the method further comprises: In the case that the current versions of all the controllers to be upgraded in the current vehicle are the target versions corresponding to the controllers to be upgraded, an updated reminder is fed back.

[0009] Optionally, the method further comprises: For any of the controllers to be upgraded of the current vehicle, if no upgrade test result for the current version of the controller to be upgraded is found from the upgrade test record, a retest reminder for the current version of the controller to be upgraded is fed back.

[0010] Optionally, the method further comprises: Determine multiple controllers to be upgraded and target versions corresponding to the multiple controllers to be upgraded; Based on version distribution information of multiple controllers to be upgraded of multiple vehicles to be upgraded, determining multiple historical versions corresponding to each of the controllers to be upgraded; An upgrade test is performed based on a plurality of historical versions corresponding to each of the plurality of controllers to be upgraded and the target version to obtain the upgrade test record.

[0011] Optionally, performing an upgrade test based on a plurality of historical versions corresponding to each of the plurality of controllers to be upgraded and the target version to obtain the upgrade test record includes: For any of the controllers to be upgraded, perform upgrade tests on each of the historical versions of the controller to be upgraded to the target version, and record the upgrade test results accordingly; In the case where the upgrade test result of any of the historical versions of the controller to be upgraded to the target version fails, determining the historical version as an upgrade failure version; Selecting one of the remaining historical versions with successful upgrade test results as a transition version corresponding to the upgrade failure version; wherein the version number of the transition version is between the version number of the upgrade failure version and the target version; The upgrade test record is obtained based on the historical upgrade test result from the upgrade-failed version to the transition version and the upgrade test result from each of the historical versions of each controller to be upgraded to the target version.

[0012] Based on the same inventive concept, a second aspect of an embodiment of the present application provides an OTA upgrade task push device, the device comprising: A test record module, used to obtain upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any of the controllers to be upgraded to a target version corresponding to the controller to be upgraded; A first task creation module is used to create a first upgrade task based on the upgrade test result; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions whose upgrade test result of the to-be-upgraded controller is successful; The first task pushing module is used to respond to the OTA upgrade request of the current vehicle and push the first upgrade task to the current vehicle when it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle has failed.

[0013] Based on the same inventive concept, the third aspect of an embodiment of the present application provides a storage medium, which stores machine executable instructions. When the machine executable instructions are executed by a processor, the OTA upgrade task push method proposed in the first aspect of the present application is implemented.

[0014] Based on the same inventive concept, the fourth aspect of an embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes, the OTA upgrade task push method proposed in the first aspect of the present application is implemented.

[0015] Compared with the prior art, this application has the following advantages: An OTA upgrade task push method provided in an embodiment of the present application, on the one hand, performs target upgrade tests on multiple historical versions of various controllers in advance to detect whether the existing historical versions can be directly upgraded to the target version, and records the corresponding test results, so as to provide a basis for the creation and push of subsequent upgrade tasks. On the other hand, when creating an upgrade task, for controllers with historical versions that cannot be directly upgraded to the target version, a transition version is selected for it and an upgrade task is generated accordingly. Thus, when a vehicle requests an upgrade, if the test record is queried and it is found that the current version of a certain controller of the vehicle cannot be directly upgraded to the target version, an upgrade task containing a transition version is pushed to it, so that the controller of the vehicle is first upgraded to the transition version, and the subsequent vehicle can upgrade from the transition version to the target version when it requests an upgrade again, so as to ensure the success rate of the OTA upgrade and avoid letting the vehicle blindly upgrade the target version, resulting in upgrade failure affecting the functions of various controllers of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 This is a flowchart of an OTA upgrade task push method in one embodiment of the present application; Figure 2 This is an operational architecture diagram of OTA upgrade in one embodiment of the present application; Figure 3 is a flowchart of creating an upgrade task in an embodiment of the present application; Figure 4 This is a push flow chart of an upgrade task in an embodiment of the present application; Figure 5 This is a functional module diagram of an OTA upgrade task push device in one embodiment of the present application; Figure 6 It is a structural schematic diagram of an electronic device in one embodiment of the present application. DETAILED DESCRIPTION

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

[0019] With the development of software-defined cars, the update and iteration rate of vehicle software is getting faster and faster, and the demand for vehicle software upgrades in the market has increased dramatically. Vehicle remote upgrade (Over The Air, referred to as OTA) has become the main way for major automakers to update vehicle software due to its high efficiency and low cost.

[0020] The current OTA operation release generally includes: release version, create strategy, test version, review version, create task, review task, check results and other processes. First, the OTA operator releases the new version, then creates a new upgrade strategy for the new version, screens test vehicles to test the upgrade strategy, and observes whether the new version meets the requirements. When the test passes, apply for version release, and the reviewer determines whether the version meets the conditions for market launch based on the test results. After the review is passed, the version is available. Finally, the OTA operator creates an upgrade task with the version, determines the target vehicle for the upgrade, and then initiates the task review. After the reviewer passes the review, the task takes effect.

[0021] The existing technology usually only tests the upgrade of the adjacent versions during version testing, which makes it difficult to fully cover the scenarios where there are many vehicles and versions on the market, resulting in incomplete testing, which in turn affects the subsequent actual upgrade effect. In addition, when pushing OTA upgrade tasks, the software version to be released is directly pushed as the version to be upgraded to the vehicle requesting the upgrade, which makes it difficult to ensure that different vehicle software versions are successfully upgraded, affecting the success rate of OTA upgrades.

[0022] In view of this, the present application proposes a method for pushing OTA upgrade tasks. On the one hand, by performing target upgrade tests on multiple historical versions of various controllers in advance, it is detected whether the existing historical versions can be directly upgraded to the target version, and the corresponding test results are recorded to provide a basis for the creation and push of subsequent upgrade tasks. On the other hand, when creating an upgrade task, for controllers with historical versions that cannot be directly upgraded to the target version, a transition version is selected for it and an upgrade task is generated accordingly. Thus, when a vehicle requests an upgrade, if the test record is queried and it is found that the current version of a certain controller of the vehicle cannot be directly upgraded to the target version, an upgrade task containing a transition version is pushed to it, so that the controller of the vehicle is first upgraded to the transition version, and the subsequent vehicle can upgrade from the transition version to the target version when it requests an upgrade again, so as to ensure the success rate of the OTA upgrade and avoid letting the vehicle blindly upgrade the target version, resulting in upgrade failure and affecting the functions of various controllers of the vehicle.

[0023] Please refer to Figure 1 , Figure 1 1 is a flow chart of an OTA upgrade task push method proposed in an embodiment of the present application. Figure 1 As shown, the method comprises the following steps: S101: Acquire upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any controller to be upgraded to a target version corresponding to the controller to be upgraded.

[0024] In this implementation, the controller to be upgraded refers to a controller with a new version to be released, the target version of the controller to be upgraded is the new version to be released corresponding to the controller (a controller to be upgraded has only one target version), and the historical version is the version of the controller that currently exists and is being used.

[0025] Please refer to Figure 2 , Figure 2 This is an operational architecture diagram of OTA upgrade in one embodiment of the present application. Figure 2 As shown, OTA upgrade includes statistics, testing, task release and other processes. First, it is necessary to confirm the controller to be upgraded and its target version, as well as the scope of the vehicles to be upgraded. Then, use the data statistics method to count the historical version distribution of various controllers to be upgraded in the vehicles within the upgrade range. For example, 70% of the vehicles have an engine management controller version of SWA.1.0.0, 20% of the vehicles have an engine management controller version of SWA.1.0.1, and 10% of the vehicles have an engine management controller version of SWA.1.0.2. These three versions are the historical versions of the engine management controller. Then, the OTA tester will perform upgrade verification tests from the historical version to the target version in turn according to the historical version distribution of these controllers to be upgraded. After the upgrade verification test is completed, the test data will be reported and recorded to the cloud database to form a test database. After that, the OTA operator will create an upgrade task based on the test data. When a vehicle requests an upgrade, it is determined whether it needs to be upgraded based on the current version of the vehicle's controller, and the corresponding upgrade task is pushed to the vehicle through the task release module to achieve OTA upgrade.

[0026] It should be noted that in an OTA upgrade, multiple controllers may need to be upgraded at the same time, and each controller may have multiple different historical versions. Therefore, during testing, it is necessary to perform upgrade tests on each historical version of each controller to be upgraded separately to detect whether each historical version of the controller to be upgraded can be successfully upgraded to the target version corresponding to the controller to be upgraded. That is, in this application, the upgrade test record includes the upgrade test results of multiple historical versions of any controller to be upgraded to the target version corresponding to the controller to be upgraded. Among them, the upgrade test result may be success or failure.

[0027] S102: creating a first upgrade task based on the upgrade test result; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions for which the upgrade test result of the to-be-upgraded controller is successful.

[0028] In this embodiment, the first upgrade task includes one or more controllers to be upgraded, and the versions to be upgraded corresponding to the controllers to be upgraded. The controllers to be upgraded included in the first upgrade task are controllers to be upgraded for which one or more historical versions have failed the upgrade test in the above upgrade test records. For these controllers to be upgraded with test failure records, if the target version to be released is directly used as the upgraded version of the controller to be upgraded to create an upgrade task, just like other controllers to be upgraded with all historical versions successfully upgraded, then when the current version of the controller to be upgraded of the vehicle to be upgraded that is requested to be upgraded happens to be the historical version that failed the upgrade test, if the upgrade is performed with the target version, there is a high probability that the upgrade will fail.

[0029] Therefore, in this application, a first upgrade task is first created for the controllers to be upgraded that have test failure records. In the first upgrade task, the upgraded version of the controller to be upgraded is a transitional version, and the transitional version is one of the historical versions of the controller to be upgraded whose upgrade test result is successful. Thus, the historical version that failed the test is first upgraded to the transitional version, and then upgraded from the transitional version to the final target version, so as to improve the upgrade success rate.

[0030] Specifically, based on the upgrade test result, the process of creating the first upgrade task includes: S102-1: For any controller to be upgraded, if any historical version of the controller to be upgraded has an upgrade test result of failure, determine a transition version of the controller to be upgraded from the remaining historical versions of the controller to be upgraded with successful upgrade test results.

[0031] In this embodiment, the transition version of the controller to be upgraded is: one of the historical versions with successful upgrade test results except the historical version of the controller to be upgraded that failed the test. It is easy to understand that the version number of the transition version is greater than the version number of the historical version that failed the test.

[0032] For example, it is assumed that the upgrade test record of the cockpit domain controller is as shown in Table 1 below: Table 1 Cockpit domain controller upgrade test record

[0033] According to Table 1, the upgrade test record of the cockpit domain controller with the historical version SWA.3.0.0 is not passed, and the upgrade test records of the other historical versions are all passed. Therefore, it is necessary to find a transition version for the cockpit domain controller, and the transition version can be any one of SWA.3.0.1, SWA.3.0.2, and SWA.3.0.3.

[0034] In this implementation, in order to facilitate the determination of the transition version, the historical version whose version number is closest to the target version among the historical versions that have successfully undergone the upgrade test can be determined as the transition version. In this way, when multiple historical versions fail the test, a common transition version can be determined without hesitation. For example, in Table 1 above, if the upgrade test records of the historical versions SWA.3.0.0 and SWA.3.0.2 of the cockpit domain controller do not pass, then the historical version SWA.3.0.3 that is closest to the target version SWA.4.0.0 will be directly used as the transition version of the cockpit domain controller.

[0035] In addition, for a controller to be upgraded, the upgrade test from a historical version that failed the test to a transitional version is assumed to be successful by default, because the transitional version was tested last time as a new version to be released.

[0036] S102-2: Count all controllers to be upgraded that have transition versions, determine the transition versions as the upgrade versions of the controllers to be upgraded, and create a first upgrade task.

[0037] In this implementation, firstly, the first upgrade task does not include all controllers to be upgraded at once, but only includes controllers to be upgraded that have historical versions that have failed the test and have corresponding transition versions. Secondly, in the first upgrade task, the upgrade version of the controller to be upgraded this time is its transition version, so that all the controllers to be upgraded are first upgraded to an intermediate version that can be successfully upgraded to its target version.

[0038] S103: In response to the OTA upgrade request of the current vehicle, if it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle fails, push a first upgrade task to the current vehicle.

[0039] In this embodiment, the current version of the controller to be upgraded of the current vehicle is one of the historical versions in the above upgrade test record. If among the many controllers to be upgraded of the current vehicle, one or more current versions of the controllers to be upgraded have failed upgrade test results in the above upgrade test record, then it means that for the current vehicle, these one or more controllers to be upgraded cannot be directly and successfully upgraded to the target version corresponding to the controller to be upgraded. At this time, if, as in the prior art, an upgrade task with the target version of each controller to be upgraded as the upgrade version is directly pushed to the current vehicle, and these controllers to be upgraded are forced to upgrade to the target version, it is very likely that the upgrade will fail, which may cause the vehicle to malfunction at the least, or even make the vehicle unusable, affecting the user's use of the vehicle.

[0040] Therefore, in this embodiment, when it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle has failed, the above-mentioned first upgrade task is pushed to the current vehicle, so as to upgrade the controller to be upgraded of the current vehicle that cannot be directly upgraded to the target version to a transitional version first, and the transitional version can be successfully upgraded to the target version, thereby performing an indirect upgrade to ensure the upgrade success rate.

[0041] In addition, in addition to the controller to be upgraded and its corresponding version to be upgraded, the first upgrade task also includes the download address corresponding to the version to be upgraded. The download address refers to the server address where the upgrade package (i.e., the file containing the upgraded version of software or firmware) is stored. After receiving the first upgrade task pushed by the OTA operator, the current vehicle will compare the current version of each of its controllers to be upgraded with the version to be upgraded of the controller to be upgraded in the first upgrade task. If the current version is lower than the version to be upgraded, the download address corresponding to the version to be upgraded will be accessed and the upgrade package will be downloaded from it. Then, the integrity and validity of the upgrade package will be checked. After the check passes, the upgrade package will be installed to update the controller to be upgraded to the corresponding version to be upgraded. After the upgrade is completed, the controller restarts and applies the new version, and the user can experience the new functions or improvements.

[0042] Optionally, the above method further includes: S201: For all controllers to be upgraded, determine the target version corresponding to the controller to be upgraded as the upgraded version of the controller to be upgraded, and create a second upgrade task.

[0043] In this embodiment, the second upgrade task includes all controllers to be upgraded in the upgrade test record and the corresponding upgraded versions of the controllers to be upgraded, wherein the upgraded version is the target version corresponding to the controller to be upgraded, so as to upgrade all controllers to be upgraded to the latest version to be released this time.

[0044] S202: In response to the OTA upgrade request of the current vehicle, when the upgrade test results of the current versions of all controllers to be upgraded of the current vehicle are found to be successful from the upgrade test records, a second upgrade task is pushed to the current vehicle.

[0045] In this embodiment, if the upgrade test results of all the current versions of the controllers to be upgraded in the current vehicle in the upgrade test record are all successful, it means that for the current vehicle, all its controllers to be upgraded can be directly and successfully upgraded to the target version corresponding to the controller to be upgraded. Therefore, the second upgrade task is pushed to the current vehicle, so that all the controllers to be upgraded in the current vehicle are updated and upgraded to the corresponding target version at one time, and the final OTA upgrade is achieved.

[0046] It should be noted that the second upgrade task is relative to the first upgrade task mentioned above. Figure 3 , Figure 3 This is a flowchart of creating an upgrade task in an embodiment of the present application. Figure 3 As shown, if there are controllers to be upgraded that have failed the historical version upgrade test in the above upgrade test records, that is, there are controllers to be upgraded that cannot be directly and successfully upgraded to the target version, then first create a first upgrade task for these controllers to be upgraded, use the transition versions corresponding to these controllers to be upgraded as their versions to be upgraded, and include these controllers to be upgraded in the list of the first upgrade task in turn. Then, generate a second upgrade task, use the target versions corresponding to all the controllers to be upgraded as their corresponding versions to be upgraded, and include all the controllers to be upgraded in the list of the second upgrade task. If there are no controllers to be upgraded that have failed the historical version upgrade test in the above upgrade test records, that is, all the controllers to be upgraded can be directly and successfully upgraded to the corresponding target versions, then only one upgrade task needs to be created for all the controllers to be upgraded, that is, in this case, the above second upgrade task is called the first upgrade task.

[0047] For further information, please refer to Figure 4 , Figure 4 This is a push flow chart of an upgrade task in an embodiment of the present application. Figure 4 As shown, when a vehicle requests an upgrade, it first selects an upgrade task (when there are the first upgrade task and the second upgrade task, the first upgrade task is selected first), and determines whether an upgrade is required based on the current version of the controller to be upgraded of the current vehicle. If an upgrade is not required, the next upgrade task is selected for determination, and when the current versions of all controllers to be upgraded of the current vehicle are the target versions corresponding to the controllers to be upgraded, an updated reminder is fed back to the current vehicle. That is, if all controllers to be upgraded of the current vehicle have been upgraded to the latest version, there is no need to push the upgrade task to the vehicle, and a message reminder is directly fed back to the vehicle to remind the user that the update has been made to the latest version.

[0048] like Figure 4 As shown, for the selected upgrade task, if an upgrade is required, a matching query is performed in the above-mentioned upgrade test records for the current version of each controller to be upgraded in the current vehicle in turn. If it is found that each controller to be upgraded has a related successful upgrade test record (a successful test record from the current version to the transition version, or a successful test record from the current version to the target version), it is considered a successful match and the upgrade task is pushed to the current vehicle.

[0049] However, for any controller to be upgraded in the current vehicle, if the upgrade test result for the current version of the controller to be upgraded is not found in the upgrade test record, a retest reminder for the current version of the controller to be upgraded will be fed back. That is to say, if for a certain controller to be upgraded, no test record about the current version of the controller to be upgraded is found in the above upgrade test record, the upgrade task will not be pushed to the current vehicle temporarily, and a message warning will be sent to the OTA operator, who will notify the OTA tester to retest the current version of the controller to be upgraded, and add the retest information to the test record to update the above upgrade test record. In this way, when the vehicle requests an upgrade next time, there will be relevant test records, and the corresponding upgrade tasks can be pushed to the vehicle normally to ensure that all controllers to be upgraded in the vehicle can be upgraded to the target version in a unified manner, avoiding confusion caused by a single upgrade, and simplifying the push process, which is conducive to improving the overall OTA upgrade efficiency.

[0050] The following is a detailed description of the above OTA upgrade statistics, testing, task creation and release processes using a specific embodiment: The first stage - statistics and testing, mainly includes the following steps: S301: Determine multiple controllers to be upgraded and target versions corresponding to the multiple controllers to be upgraded.

[0051] In this implementation, the OTA operator will first confirm the list of vehicle VIN codes (Vehicle Identification Numbers) for this upgrade activity, the controllers that need to be upgraded, and the target version to be released for each controller. After confirming the information, the OTA operator will synchronize the information to the OTA tester.

[0052] For example, the controllers that need to be upgraded in this upgrade activity and the target versions corresponding to the controllers are shown in Table 2 below: Table 2 Information to be upgraded

[0053] S302: Based on version distribution information of multiple controllers to be upgraded of multiple vehicles to be upgraded, determine multiple historical versions corresponding to each of the controllers to be upgraded.

[0054] In this implementation, after all vehicles to be upgraded are unlocked and powered on, they will automatically collect the version information of the vehicle controller and report it to the cloud. The cloud will record the version information of each vehicle as follows: Figure 2The OTA tester will then extract the controllers to be upgraded from the controller version information of all vehicles to be upgraded, and count the distribution of each version of each controller to be upgraded to obtain the distribution and proportion of the historical versions of the controllers to be upgraded.

[0055] Exemplarily, the historical version distribution of the three controllers to be upgraded in Table 2 is shown in Table 3 below: Table 3 Distribution of historical versions of controllers to be upgraded

[0056] S303: Perform upgrade tests based on multiple historical versions and target versions corresponding to the multiple controllers to be upgraded, and obtain upgrade test records.

[0057] In this implementation, for any controller to be upgraded, each historical version of the controller to be upgraded is tested to the target version, and the upgrade test results (passed or failed) are recorded accordingly. In the case where the upgrade test result from any historical version of the controller to be upgraded to the target version is a failure, the historical version is determined as the upgrade failure version, and then one of the remaining historical versions with successful upgrade test results is selected as a transition version corresponding to the upgrade failure version; wherein the version number of the transition version is between the version numbers of the upgrade failure version and the target version. Finally, based on the historical upgrade test results from the upgrade failure version to the transition version, and the upgrade test results from each historical version of each controller to be upgraded to the target version, an upgrade test record is obtained.

[0058] For example, the upgrade test record is shown in Table 4 below: Table 4 Upgrade test record

[0059] In this embodiment, when judging whether a certain historical version of a controller has passed or failed the test, the OTA tester determines it based on the overall upgrade success rate of the vehicles to be upgraded that have the historical version. For example, assuming that there are 100 vehicles to be upgraded whose historical version of the engine management controller is SWA.1.0.0, if the test shows that more than 90% of the vehicles to be upgraded have successfully upgraded, then the upgrade test result corresponding to the historical version of the engine management controller SWA.1.0.0 is considered to have passed.

[0060] During the above test process, after performing upgrade tests on each historical version of the three controllers to be upgraded in Table 4 to the corresponding target version, it was found that the historical version SWA.3.0.0 of the cockpit domain controller failed the test, so this version was determined as the failed upgrade version, and then one of the other successful historical versions SWA.3.0.1 and SWA.3.0.2 of the cockpit domain controller was selected as the transition version of the cockpit domain controller. For example, the historical version SWA.3.0.1 was selected as the transition version, and then the historical upgrade test results of the failed version to the transition version (the historical upgrade test results of SWA.3.0.0 to SWA.3.0.1, this embodiment assumes that the result is passed because the previous version SWA.3.0.1 has been tested when it was the target version to be released) were added to Table 4, forming the final upgrade test record table for this upgrade.

[0061] The second stage - task creation, mainly includes the following steps: S304: For a controller to be upgraded that has one or more historical versions that have failed the upgrade test, use the corresponding transition version as the version to be upgraded and create a first upgrade task.

[0062] In this implementation, after the OTA tester completes the test, the OTA tester will feed back the information to the OTA operator, and the OTA operator will create an upgrade task based on the test results.

[0063] Exemplarily, according to the test results of Table 4 above, the first upgrade task created this time is shown in Table 5 below: Table 5 The first upgrade task

[0064] Therefore, when a vehicle requests an upgrade, all vehicles with cockpit domain controller version SWA.3.0.0 will be uniformly upgraded to version SWA.3.0.1 first, and then upgraded from version SWA.3.0.1 to the final target version SWA.4.0.0.

[0065] The specific process of creating the first upgrade task may refer to the above step S102 and will not be described in detail here.

[0066] S305: For all controllers to be upgraded, the corresponding target versions are used as the versions to be upgraded, and a second upgrade task is created.

[0067] In this implementation, according to the test results of Table 4 above, the second upgrade task created this time is shown in Table 6 below: Table 6 Second upgrade task

[0068] The specific process of creating the second upgrade task may refer to the above step S201, which will not be described in detail here.

[0069] The third stage - task push, mainly includes the following steps: S306: For any vehicle to be upgraded for which the upgrade test result of the current version of any controller to be upgraded is failed, the first upgrade task is pushed to the vehicle to be upgraded.

[0070] In this implementation, after the OTA operator creates an upgrade task, when a vehicle requests an upgrade task, a task comparison is performed based on the vehicle's own controller version information to determine whether to issue the first upgrade task or the second upgrade task to the vehicle.

[0071] Exemplarily, the controller version information of a vehicle A requesting an upgrade is shown in Table 7 below: Table 7 Controller version information of a vehicle A

[0072] When pushing tasks, first select the first upgrade task shown in Table 5 above for version comparison. It is found that in the first upgrade task table, the cockpit domain controller's to-be-upgraded version SWA.3.0.1 is higher than the vehicle's current version SWA.3.0.0, and it needs to be upgraded. Then, query the upgrade test record shown in Table 4 above. The upgrade test record table contains the test pass record of the cockpit domain controller version SWA.3.0.0 to SWA.3.0.1. Therefore, the first upgrade task is pushed to vehicle A to upgrade the cockpit domain controller of vehicle A to the transition version first.

[0073] It should be noted that when there are multiple controllers to be upgraded to transition versions in the first upgrade task table, for vehicle A, as long as any controller of vehicle A needs to be upgraded to the transition version first, the first upgrade task will be pushed to it. After receiving the first upgrade task, vehicle A will compare the upgraded version of the controller to be upgraded in the first upgrade task table with its current version. After confirming that an upgrade is required, it will download the upgrade package corresponding to the upgraded version for upgrading. After vehicle A is upgraded, when it requests an upgrade task again (for example, the upgrade request is automatically triggered when it is powered on next time, or the user manually triggers the upgrade request), the second upgrade task will be issued to it.

[0074] S307: For all vehicles to be upgraded whose upgrade test results of the current versions of the controllers to be upgraded are successful, push the second upgrade task to them.

[0075] Exemplarily, the controller version information of a vehicle B that requests an upgrade is shown in Table 8 below: Table 8 Controller version information of a vehicle B

[0076] When pushing tasks to vehicle B, the cloud also compares the current versions of the first upgrade task and each vehicle controller, and finds that the cockpit domain controller of vehicle B is already version SWA.3.0.1, so there is no need to push the first upgrade task to vehicle B. Then, the cloud continues to select the second upgrade task shown in Table 6 above for version comparison, and finds that the engine management controller, cockpit domain controller and battery management system in the second upgrade task table all need to be upgraded, and queries the upgrade test records shown in Table 4 above to find that there are test pass records for the engine management controller version SWA.1.0.1 to the target version SWA.2.0.0, the cockpit domain controller version SWA.3.0.1 to the target version SWA.4.0.0 and the battery management system version SWA.1.4.0 to the target version SWA.2.0.0, so the second upgrade task is pushed to vehicle B for version upgrade.

[0077] On this basis, after the vehicle B is upgraded, it requests the upgrade task again. At this time, the cloud compares the first upgrade task and the second upgrade task in sequence and finds that the vehicle B no longer has a controller that needs to be upgraded, so it feeds back a message reminder to the vehicle B to remind the user that it has been updated to the latest version.

[0078] In addition, it is assumed that the controller version information of a vehicle C that requests an upgrade is shown in Table 9 below: Table 9 Controller version information of a vehicle C

[0079] When pushing tasks to vehicle C, the cloud compares tasks in turn and finds that it needs to be upgraded to the target version of the second upgrade task. However, the upgrade test records shown in Table 4 above are queried and it is found that there is no test record for the engine management controller version SWA.1.0.3 to the target version SWA.2.0.0. At this time, in order to ensure the success rate of the upgrade, the second upgrade task is not pushed to vehicle C, but a message warning is sent to the OTA operator, who notifies the OTA tester to perform a supplementary test on the engine management controller version SWA.1.0.3 to update the upgrade test records shown in Table 4 above. Therefore, when vehicle C requests an upgrade next time, the upgrade task can be pushed to it normally.

[0080] Please refer to Figure 5 Based on the same inventive concept, the second aspect of the embodiment of the present application provides an OTA upgrade task push device, and the OTA upgrade task push device 500 includes: The test record module 501 is used to obtain upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any controller to be upgraded to the target version corresponding to the controller to be upgraded; A first task creation module 502 is used to create a first upgrade task based on the upgrade test result; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions whose upgrade test result of the to-be-upgraded controller is successful; The first task pushing module 503 is used to respond to the OTA upgrade request of the current vehicle and push the first upgrade task to the current vehicle when it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle fails.

[0081] Optionally, the first task creation module 502 includes: A transition version determination submodule is used to determine, for any controller to be upgraded, a transition version of the controller to be upgraded from the remaining historical versions of the controller to be upgraded whose upgrade test results are successful, if any historical version of the controller to be upgraded has an upgrade test result that fails; A submodule is created to count all controllers to be upgraded that have transition versions, determine the transition version as the upgrade version of the controller to be upgraded, and create a first upgrade task.

[0082] Optionally, the device further comprises: A second task creation module, used for determining, for all controllers to be upgraded, a target version corresponding to the controller to be upgraded as the upgraded version of the controller to be upgraded, and creating a second upgrade task; The second task push module is used to respond to the OTA upgrade request of the current vehicle and push the second upgrade task to the current vehicle when the upgrade test results of the current versions of all controllers to be upgraded of the current vehicle are found to be successful from the upgrade test records.

[0083] Optionally, the device further comprises: The first reminder module is used to feedback an updated reminder when the current versions of all controllers to be upgraded in the current vehicle are the target versions corresponding to the controllers to be upgraded.

[0084] Optionally, the device further comprises: The second reminder module is used to feedback a retest reminder for the current version of any controller to be upgraded of the current vehicle if no upgrade test result for the current version of the controller to be upgraded is found from the upgrade test record.

[0085] Optionally, the device further comprises: A target determination module, used to determine a plurality of controllers to be upgraded and target versions corresponding to the plurality of controllers to be upgraded; A distribution statistics module, used for determining a plurality of historical versions corresponding to each of the controllers to be upgraded based on version distribution information of a plurality of controllers to be upgraded of a plurality of vehicles to be upgraded; The test module is used to perform upgrade tests based on multiple historical versions and target versions corresponding to multiple controllers to be upgraded, and obtain upgrade test records.

[0086] Optionally, the test module includes: The result recording submodule is used to perform upgrade tests on each historical version of any controller to be upgraded to the target version, and record the upgrade test results accordingly; A failure determination submodule is used to determine the historical version as an upgrade failure version when the upgrade test result of any historical version of the controller to be upgraded to the target version fails; The transition test submodule is used to select a transition version corresponding to the upgrade failure version from the remaining historical versions with successful upgrade test results; wherein the version number of the transition version is between the version number of the upgrade failure version and the version number of the target version; The statistics submodule is used to obtain upgrade test records based on historical upgrade test results from the failed upgrade version to the transition version and upgrade test results from each historical version of each controller to be upgraded to the target version.

[0087] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0088] On the third aspect, based on the same inventive concept, an embodiment of the present application provides a storage medium, which stores machine executable instructions. When the machine executable instructions are executed by the processor, the OTA upgrade task push method proposed in the first aspect of the present application is implemented.

[0089] It should be noted that the specific implementation of the storage medium in the embodiment of the present application refers to the specific implementation of the OTA upgrade task push method proposed in the first aspect of the embodiment of the present application, and will not be repeated here.

[0090] In the fourth aspect, based on the same inventive concept, refer to Figure 6 An embodiment of the present application provides an electronic device 600, including a processor 601 and a memory 602; the memory 602 stores machine executable instructions that can be executed by the processor 601, and the processor 601 is used to execute the machine executable instructions to implement the OTA upgrade task push method proposed in the first aspect of the present application.

[0091] It should be noted that the specific implementation of the electronic device 600 in the embodiment of the present application refers to the specific implementation of the OTA upgrade task push method proposed in the first aspect of the embodiment of the present application, and will not be repeated here.

[0092] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

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

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

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

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

[0097] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0098] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0099] The above is a detailed introduction to the OTA upgrade task push method, device, medium and equipment provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for pushing an OTA upgrade task, characterized in that: The method comprises: Acquire upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any of the controllers to be upgraded to a target version corresponding to the controller to be upgraded; Based on the upgrade test result, a first upgrade task is created; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions in which the upgrade test result of the to-be-upgraded controller is successful; In response to an OTA upgrade request of the current vehicle, if it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle fails, the first upgrade task is pushed to the current vehicle.

2. The method according to claim 1, characterized in that Based on the upgrade test result, creating a first upgrade task includes: For any of the controllers to be upgraded, if the upgrade test result of any of the historical versions of the controller to be upgraded is failed, determine a transition version of the controller to be upgraded from the remaining historical versions of the controller to be upgraded whose upgrade test results are successful; Count all the controllers to be upgraded that have transition versions, determine the transition versions as the upgrade versions of the controllers to be upgraded, and create the first upgrade task.

3. The method according to claim 1, characterized in that The method further comprises: For all the controllers to be upgraded, determining the target version corresponding to the controllers to be upgraded as the upgraded version of the controllers to be upgraded, and creating a second upgrade task; In response to the OTA upgrade request of the current vehicle, when it is found from the upgrade test record that the upgrade test results of the current versions of all the controllers to be upgraded of the current vehicle are successful, the second upgrade task is pushed to the current vehicle.

4. The method according to claim 3, characterized in that The method further comprises: In the case that the current versions of all the controllers to be upgraded in the current vehicle are the target versions corresponding to the controllers to be upgraded, an updated reminder is fed back.

5. The method according to claim 1, characterized in that The method further comprises: For any of the controllers to be upgraded of the current vehicle, if no upgrade test result for the current version of the controller to be upgraded is found from the upgrade test record, a retest reminder for the current version of the controller to be upgraded is fed back.

6. The method according to claim 1, characterized in that The method further comprises: Determine multiple controllers to be upgraded and target versions corresponding to the multiple controllers to be upgraded; Based on version distribution information of multiple controllers to be upgraded of multiple vehicles to be upgraded, determining multiple historical versions corresponding to each of the controllers to be upgraded; An upgrade test is performed based on a plurality of historical versions corresponding to each of the plurality of controllers to be upgraded and the target version to obtain the upgrade test record.

7. The method according to claim 6, characterized in that Performing an upgrade test based on multiple historical versions corresponding to the multiple controllers to be upgraded and the target version to obtain the upgrade test record includes: For any of the controllers to be upgraded, perform upgrade tests on each of the historical versions of the controller to be upgraded to the target version, and record the upgrade test results accordingly; In the case where the upgrade test result of any of the historical versions of the controller to be upgraded to the target version fails, determining the historical version as an upgrade failure version; Selecting one of the remaining historical versions with successful upgrade test results as a transition version corresponding to the upgrade failure version; wherein the version number of the transition version is between the version number of the upgrade failure version and the target version; The upgrade test record is obtained based on the historical upgrade test result from the upgrade-failed version to the transition version and the upgrade test result from each of the historical versions of each controller to be upgraded to the target version.

8. An OTA upgrade task push device, characterized in that: The device comprises: A test record module, used to obtain upgrade test records of multiple controllers to be upgraded; the upgrade test records include upgrade test results of multiple historical versions of any of the controllers to be upgraded to a target version corresponding to the controller to be upgraded; A first task creation module is used to create a first upgrade task based on the upgrade test result; in the first upgrade task, the to-be-upgraded version of the to-be-upgraded controller is a transitional version, and the transitional version is one of the historical versions whose upgrade test result of the to-be-upgraded controller is successful; The first task pushing module is used to respond to the OTA upgrade request of the current vehicle and push the first upgrade task to the current vehicle when it is found from the upgrade test record that the upgrade test result of the current version of any controller to be upgraded in the current vehicle has failed.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the OTA upgrade task push method as described in any one of claims 1 to 7 is implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, it implements the OTA upgrade task push method as described in any one of claims 1 to 7.

Images