Software updating method and device, movable carrier and server
By verifying the matching between the target update task and the historical update task on the movable carrier, the problems of repeated execution and version fallback during the software update process are solved, and the operation efficiency and system stability of the carrier are improved.
Patent Information
- Application Number
- CN202411874239.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-18
- Publication Date
- 2025-04-11
AI Technical Summary
During the software update process of movable carriers, network fluctuations and other problems caused the server to not receive feedback, resulting in repeated execution of update tasks or version fallback, affecting the operation efficiency of the carrier.
After the movable carrier receives the target update task, verify that it matches the successfully executed historical update task. If it matches, the target update task is refused; if it does not match, the target update task is executed.
It avoids repeated execution of successful update tasks, improves the operation efficiency of the movable carrier, and prevents version fallback, ensuring the normal operation of the carrier.
Smart Images
Figure CN119806584A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to a software updating method, device, removable carrier and server. Background Art
[0002] At present, removable carriers, such as unmanned logistics vehicles, are often updated remotely based on Over-the-Air (OTA) technology. However, during the update process, due to network fluctuations and other issues, the server may not receive the "update success" message fed back by the removable carrier, which will cause the following two problems: First, the update task continues to be in an unsuccessful state. When the removable carrier is powered on next time, the server will send the update task to the vehicle again, resulting in repeated updates of the removable carrier software, affecting the operating efficiency of the removable carrier. Second, if the removable carrier is updated based on the old version of the software, the "update success" message fed back by the removable carrier is not received. Subsequently, a new version of the software update task is submitted and a feedback "update success" message is received. When the vehicle is powered on next time, the server will send the old version of the software update task to the removable carrier again, resulting in the removable carrier software version error rollback, causing the removable carrier system module version mismatch, and ultimately causing the removable carrier to fail to operate normally. Summary of the invention
[0003] The embodiments of the present application provide a software updating method, device, removable carrier and server. On the one hand, when a certain version of software is successfully updated on the removable carrier, it is possible to avoid repeated updating of the removable carrier with the same version of software. On the other hand, when the removable carrier successfully updates the old version of software and the new version of software in sequence, it is possible to avoid version rollback of the removable carrier with the old version of software.
[0004] In a first aspect, an embodiment of the present application provides a software update method, which is applied to a removable carrier, and the method includes: Receive target update tasks from the server; Verify whether the target update task matches the successfully executed historical update task; If they match, refusing to execute the target update task; If not, execute the target update task.
[0005] In the embodiment of the present application, when the removable carrier receives a target update task from the server, the target update task can be matched with a successfully executed historical update task. If the target update task does not match a successfully executed historical update task, it indicates that the target update task has not been executed or has not been successfully executed in history, and the removable carrier can execute the target update task; if the target update task matches a successfully executed historical update task, it indicates that the target update task has been successfully executed in history, and the removable carrier will refuse to execute the target update task, thereby avoiding repeated execution of the successfully executed update task, thereby improving the operating efficiency of the removable carrier. At the same time, when the old version software and the new version software are successfully updated in sequence, it can also avoid using the old version software to perform version rollback on the removable carrier.
[0006] Optionally, the target update task includes target task attribute information, there are multiple historical update tasks, each of the historical update tasks includes corresponding historical task attribute information, and verifying whether the target update task matches the successfully executed historical update task includes: Traversing the plurality of historical task attribute information based on the target task attribute information; If historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information, it is determined that the target update task matches the successfully executed historical update task; If no historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information, it is determined that the target update task does not match the successfully executed historical update task.
[0007] In an embodiment of the present application, the target update task includes target task attribute information, and each historical update task includes historical task attribute information. Therefore, when there are multiple historical update tasks that have been successfully executed, the multiple historical task attribute information can be traversed according to the target task attribute information. If attribute information that is the same as the target task attribute information exists in the multiple historical task attribute information, it can be more accurately determined that the target update task matches the successfully executed historical update task; conversely, if attribute information that is the same as the target task attribute information does not exist in the multiple historical task attribute information, it can be more accurately determined that the target update task does not match the successfully executed historical update task.
[0008] Optionally, traversing the plurality of historical task attribute information based on the target task attribute information includes: Finding a task list based on the task list table name, wherein the plurality of historical task attribute information is stored in the task list; In the task list, multiple pieces of historical task attribute information are traversed based on the target task attribute information.
[0009] In an embodiment of the present application, multiple historical task attribute information can be considered to be stored in a task list in a database, so the task list can be found in the database, and then in the task list, multiple historical task attribute information can be traversed based on the target task attribute information, thereby improving the traversal efficiency.
[0010] Optionally, the method further includes: In response to entering the high voltage power-on state, determining whether there is a task list in the database; If it does not exist, create the task list in the database with the preset task attribute information as the table header and the table body content as an empty value.
[0011] In an embodiment of the present application, after the movable carrier enters the high-voltage power-on state, it can automatically determine whether there is a task list in the database. If the task list does not exist, a task list can be automatically created with preset task attribute information as the table header and an empty table body content without relying on manual creation, thereby simplifying the operation process.
[0012] Optionally, the target task attribute information includes a target domain identifier, a target task identifier, and a target update file name, each of the historical task attribute information includes a historical domain identifier, a historical task identifier, and a historical update file name, the task list includes multiple task sublists, each task sublist contains multiple historical task attribute information with the same historical domain identifier, and in the task list, traversing the multiple historical task attribute information based on the target task attribute information includes: In the plurality of task sublists, searching for a target task sublist where a historical domain identifier matching the target domain identifier is located; In the target task sublist, based on the target task identifier and the target update file name, the stored multiple historical task identifiers and multiple historical update file names are traversed.
[0013] In the embodiment of the present application, the target task attribute information includes the target domain identifier, the target task identifier and the target update file name, each historical task attribute information includes the historical domain identifier, the historical task identifier and the historical update file name, and the task list includes multiple task sublists, each task sublist contains historical task attribute information with the same historical domain identifier, then first, from the multiple task sublists, the target task sublist where the historical domain identifier that matches the target domain identifier is located can be found, and then, in the target task sublist, traversal is performed based on the target task identifier and the target update file name. In other words, first, according to the domain where the current target update task is located, the historical update tasks that have been successfully executed in the domain are determined, and then the historical update tasks that have been successfully executed in the domain are traversed, thereby further improving the traversal efficiency.
[0014] Optionally, the target update task belongs to a repeatable task.
[0015] In the embodiment of the present application, the server only sends the repeatable tasks to the removable carrier, which reduces the probability of task update failure on the removable carrier side.
[0016] Optionally, after refusing to execute the target update task, the method further includes: A task execution result indicating successful task execution is sent to the server, so that the server marks the target update task as a non-repeatable task.
[0017] In the embodiment of the present application, after the removable carrier determines that the target update task has been successfully executed in the past, the removable carrier refuses to execute the target update task again, but can send a message to the server indicating that the target update task has been successfully executed. After receiving the message, the server can mark the target update task as a task that cannot be sent repeatedly, thereby avoiding sending the target update task to the removable carrier again, thereby saving server resources.
[0018] Optionally, after executing the target update task, the method further includes: If the target update task fails to execute, determining the failure reason corresponding to the target update task; A task execution result indicating task execution failure and the reason for the failure is sent to the server, so that when the server determines that the target update task has failed and the reason for the failure indicates that it cannot be updated again, it marks the target update task as a non-repeatable task.
[0019] In an embodiment of the present application, after the removable carrier determines that the target update task has not been successfully executed in the past, the removable carrier end can execute the target update task. If the removable carrier fails to execute the target update task, the failure reason that caused the failure of the target update task can be determined. Then, a task execution result indicating the failure of the target update task and the failure reason is sent to the server. When the server determines that the target update task has failed and the failure reason indicates that it cannot be updated again, that is, the problem of task update failure cannot be solved by updating again, the target update task is marked as a non-repeatable task, thereby avoiding the server from sending the target update task to the removable carrier end again, thereby reducing the probability of task update failure on the removable carrier end.
[0020] In a second aspect, an embodiment of the present application provides a software update method, which is applied to a server, and the method includes: Classify the tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly; In the repeatedly sendable task, a target update task is sent to the removable carrier, so that the removable carrier refuses to execute the target update task when it is determined that the target update task matches the successfully executed historical update task, or executes the target update task when it is determined that the target update task does not match the successfully executed historical update task; receiving a task execution result from the removable carrier; If the task execution result indicates that the target update task is successfully executed, the target update task is marked as a non-repeatable sending task.
[0021] Optionally, the method further includes: If the task execution result indicates that the target update task has failed to execute, and the corresponding failure reason indicates that it cannot be updated again, the target update task is marked as a non-repeatable sending task.
[0022] In a third aspect, an embodiment of the present application provides a software updating device, which is applied to a removable carrier, and the device includes: A receiving unit, used for receiving a target update task from a server; A verification unit, used to verify whether the target update task matches the successfully executed historical update task; An execution unit, configured to refuse to execute the target update task if there is a match; The execution unit is further configured to execute the target update task if there is no match.
[0023] Optionally, the target update task includes target task attribute information, there are multiple historical update tasks, each of the historical update tasks includes corresponding historical task attribute information, and the verification unit includes: An attribute information traversal unit, used for traversing the attribute information of the plurality of historical tasks based on the attribute information of the target task; A determination unit, configured to determine that the target update task matches the successfully executed historical update task if historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information; The determining unit is further configured to determine that the target update task does not match the successfully executed historical update task if no historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information.
[0024] Optionally, the attribute information traversal unit includes: A search subunit, used for searching a task list based on a preset task list table name, wherein the plurality of historical task attribute information is stored in the task list; The traversal subunit is used to traverse the plurality of historical task attribute information in the task list based on the target task attribute information.
[0025] Optionally, the device further comprises: A determination unit, configured to determine whether a task list exists in a database in response to entering a high voltage power-on state; The creation unit is used to create the task list in the database with the preset task attribute information as the table header and the table body content as an empty value if it does not exist.
[0026] Optionally, the target task attribute information includes a target domain identifier, a target task identifier, and a target update file name, each of the historical task attribute information includes a historical domain identifier, a historical task identifier, and a historical update file name, the task list includes multiple task sublists, each task sublist contains multiple historical task attribute information with the same historical domain identifier, and the traversal subunit is specifically used to: In the plurality of task sublists, searching for a target task sublist where a historical domain identifier matching the target domain identifier is located; In the target task sublist, based on the target task identifier and the target update file name, the stored multiple historical task identifiers and multiple historical update file names are traversed.
[0027] Optionally, the target update task belongs to a repeatable task.
[0028] Optionally, the device further comprises: The first sending unit is used to send a task execution result indicating successful task execution to the server, so that the server marks the target update task as a non-repeatable task.
[0029] Optionally, the device further comprises: A determination unit, configured to determine a failure reason corresponding to the target update task if the target update task fails to be executed; The second sending unit is used to send a task execution result indicating task execution failure and the reason for the failure to the server, so that when the server determines that the target update task has failed and the reason indicates that it cannot be updated again, it will mark the target update task as a non-repeatable task.
[0030] In a fourth aspect, an embodiment of the present application provides a software updating device, which is applied to a server, and the device includes: A classification unit is used to classify tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly; a sending unit, configured to send a target update task to a removable carrier in the repeatable sendable task, so that the removable carrier refuses to execute the target update task when determining that the target update task matches a successfully executed historical update task, or executes the target update task when determining that the target update task does not match a successfully executed historical update task; A receiving unit, configured to receive a task execution result from the movable carrier; The classification unit is further configured to mark the target update task as a non-repeatable sending task if the task execution result indicates that the target update task is successfully executed.
[0031] Optionally, the classification unit is further used to: if the task execution result indicates that the target update task has failed to execute, and the corresponding failure reason indicates that it cannot be updated again, mark the target update task as a non-repeatable sending task.
[0032] In a fourth aspect, an embodiment of the present application provides a removable carrier, comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the removable carrier is triggered to execute the steps of the method described in any embodiment of the first aspect.
[0033] In a fifth aspect, an embodiment of the present application provides a server, comprising a memory for storing computer program instructions and a processor for executing program instructions, wherein when the computer program instructions are executed by the processor, the server is triggered to execute the steps of the method described in any embodiment of the second aspect.
[0034] In the seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store computer instructions, and when the computer is running, the computer enables the computer to execute the steps of the method described in any embodiment of the first aspect or the second aspect.
[0035] It should be understood that the second to seventh aspects of the embodiments of the present application are consistent with the technical solutions of the first aspect of the embodiments of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0037] Figure 1 A flowchart of a software update method provided in an embodiment of the present application; Figure 2 A flowchart of a method for verifying the matching of a target update task and a historical update task provided in an embodiment of the present application; Figure 3 A flowchart of a method for traversing historical task attribute information provided in an embodiment of the present application; Figure 4 A flowchart of another method for traversing historical task attribute information provided in an embodiment of the present application; Figure 5 A schematic diagram of the structure of a software updating device provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of a software updating device provided in an embodiment of the present application; Figure 7 A schematic diagram of the structure of a movable carrier provided in an embodiment of the present application; Figure 8 A schematic diagram of the structure of a server provided in an embodiment of the present application. DETAILED DESCRIPTION
[0038] In order to better understand the technical solution of this specification, the embodiments of the present application are described in detail below with reference to the accompanying drawings.
[0039] It should be clear that the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.
[0040] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit this specification. The singular forms of "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.
[0041] At present, removable carriers, such as unmanned logistics vehicles, are often updated remotely based on Over-the-Air (OTA) technology. However, due to network fluctuations and other issues during the update process, the server may not receive the "update success" message fed back by the removable carrier, which will cause the following two problems: First, the update task continues to be in an unsuccessful state. When the removable carrier is powered on next time, the server will send the update task to the vehicle again, resulting in repeated updates of the removable carrier software, affecting the operating efficiency of the removable carrier. Second, if the removable carrier is updated based on the old version of the software, the "update success" message fed back by the removable carrier is not received. Subsequently, a new version of the software update task is submitted and a feedback "update success" message is received. When the removable carrier is powered on next time, the server will send the old version of the software update task to the removable carrier again, resulting in the removable carrier software version error rollback, causing the removable carrier system module version mismatch, and ultimately causing the removable carrier to fail to operate normally.
[0042] In view of this, the embodiment of the present application provides a software update method, in which the removable carrier matches the currently received target update task with the successfully executed historical update task, and then refuses to execute the target update task after determining that the target update task has been successfully executed in the past, thereby avoiding repeated execution of the successfully executed update task, thereby improving the operating efficiency of the removable carrier. At the same time, when the old version software and the new version software are successfully updated in sequence, it is also possible to avoid using the old version software to roll back the removable carrier.
[0043] The technical solution protected by the embodiments of the present application is described in detail below with reference to the accompanying drawings.
[0044] See also Figure 1, is a software update method provided in an embodiment of the present application, and the process of the method is described as follows: Step 101: The server classifies tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly.
[0045] In the embodiment of the present application, the tasks to be updated include newly added update tasks, historical update tasks that have been sent but have not received feedback indicating successful execution, historical update tasks that have been sent and received feedback indicating execution failure, and the reason for the execution failure indicates that they cannot be updated again, and historical update tasks that have been sent and received feedback indicating execution failure, and the reason for the execution failure indicates that they can be updated again. It should be understood that "cannot be updated again" here means that the reason for the failure of the historical update task cannot be overcome by updating again; "can be updated again" means that the reason for the failure of the historical update task can be overcome by updating again.
[0046] The server can classify the above-mentioned tasks to be updated into repeatedly sendable tasks and non-repeatable sendable tasks, among which the repeatedly sendable tasks include: newly added update tasks, historical update tasks that have been sent but have not received feedback indicating successful execution, and historical update tasks that have been sent and received feedback indicating execution failure, and the reason for the failure indicates that they can be updated again; the non-repeatable sendable tasks include: historical update tasks that have been sent and received feedback indicating execution failure, and the reason for the failure indicates that they cannot be updated again.
[0047] Step 102: The server sends a target update task to the removable carrier in a repeatable sending task.
[0048] In an embodiment of the present application, the server determines a target update task among the repeatable tasks. The target update task can be considered as a newly added update task, or a historical update task that has been sent but has not received feedback indicating successful execution, thereby effectively reducing the probability of software update failure on the removable carrier side.
[0049] Step 103: The removable carrier verifies whether the target update task matches the successfully executed historical update task.
[0050] Step 104: If a match is found, the removable carrier refuses to execute the target update task.
[0051] Step 105: If there is no match, the removable carrier executes the target update task.
[0052] In the embodiment of the present application, when the removable carrier receives a target update task from the server, the target update task can be matched with a successfully executed historical update task. If the target update task does not match a successfully executed historical update task, it indicates that the target update task has not been executed or has not been successfully executed in history, and the removable carrier can execute the target update task; if the target update task matches a successfully executed historical update task, it indicates that the target update task has been successfully executed in history, and the removable carrier will refuse to execute the target update task, thereby avoiding repeated execution of the successfully executed update task, thereby improving the operating efficiency of the removable carrier. At the same time, when the old version software and the new version software are successfully updated in sequence, it can also avoid using the old version software to perform version rollback on the removable carrier.
[0053] The following describes in detail how the removable carrier verifies whether the target update task matches the successfully executed historical update task.
[0054] See also Figure 2 , which is a flowchart of a method for verifying the matching of a target update task and a historical update task provided in an embodiment of the present application. Step 103 can be implemented by executing sub-steps 1031 to 1033: Step 1031: The movable carrier traverses multiple historical task attribute information based on the target task attribute information.
[0055] Step 1032: If historical task attribute information matching the target task attribute information is found among the multiple historical task attribute information, the removable carrier determines that the target update task matches the successfully executed historical update task.
[0056] Step 1033: If no historical task attribute information matching the target task attribute information is found in the plurality of historical task attribute information, the removable carrier determines that the target update task does not match the successfully executed historical update task.
[0057] In an embodiment of the present application, the target update task includes target task attribute information, and each historical update task includes historical task attribute information. Therefore, when there are multiple historical update tasks that have been successfully executed, the multiple historical task attribute information can be traversed according to the target task attribute information. If attribute information that is the same as the target task attribute information exists in the multiple historical task attribute information, it can be more accurately determined that the target update task matches the successfully executed historical update task; conversely, if attribute information that is the same as the target task attribute information does not exist in the multiple historical task attribute information, it can be more accurately determined that the target update task does not match the successfully executed historical update task.
[0058] In some embodiments, considering that multiple historical task attribute information may be stored in different storage locations in the database, it is necessary to switch between different storage locations during traversal, thereby reducing the efficiency of traversal. Therefore, in the embodiments of the present application, multiple historical figure attribute information can be stored in the same location, so there is no need to switch between different storage locations during traversal, which is conducive to improving traversal efficiency.
[0059] See also Figure 3 , which is a flowchart of a method for traversing historical task attribute information provided by an embodiment of the present application. Step 1031 can be implemented by executing sub-steps 201 to 202: Step 201: The removable carrier searches out a task list based on the task list table name, wherein a plurality of historical task attribute information is stored in the task list.
[0060] Step 202: The movable carrier traverses multiple historical task attribute information in the task list based on the target task attribute information.
[0061] In the embodiment of the present application, multiple historical task attribute information can be considered to be stored in the task list in the database, that is, the task list can be considered to store the list of historical update tasks that have been successfully executed. Then, the task list can be found in the database, and then the multiple historical task attribute information can be traversed directly in the task list based on the target task attribute information, without having to traverse the multiple historical task attribute information multiple times in different storage locations, thereby improving the traversal efficiency.
[0062] It is worth noting that after the removable carrier enters the high-voltage power-on state, it can automatically determine whether the above-mentioned task list exists in the database. If the task list does not exist, a task list can be automatically created with preset task attribute information as the table header and an empty table body content without relying on manual creation, thereby simplifying the operation process.
[0063] In some embodiments, when the movable carrier is an unmanned vehicle, the unmanned vehicle can often be divided into a power domain, a body domain, a cockpit domain, an automatic driving domain, a chassis domain, an energy management domain, a thermal management domain, a safety domain, etc. Therefore, in the embodiment of the present application, the historical update tasks that have been successfully executed in the domain can be determined based on the domain where the current target update task is located, and then the historical update tasks that have been successfully executed in the domain can be traversed, thereby further improving the traversal efficiency.
[0064] See also Figure 4, which is a flowchart of another method for traversing historical task attribute information provided by an embodiment of the present application. Step 202 can be implemented by executing sub-steps 2021 to 2022: Step 221: Find the target task sublist containing the historical domain identifier that matches the target domain identifier in the multiple task sublists.
[0065] Step 2022: In the target task sublist, based on the target task identifier and the target update file name, traverse the stored multiple historical task identifiers and multiple historical update file names.
[0066] In an embodiment of the present application, the target task attribute information includes a target domain identifier, a target task identifier and a target update file name, each historical task attribute information includes a historical domain identifier, a historical task identifier and a historical update file name, and the task list includes multiple task sublists, each task sublist contains historical task attribute information with the same historical domain identifier. Then, first, from multiple task sublists, you can find the target task sublist where the historical domain identifier that matches the target domain identifier is located, and then in the target task sublist, traverse based on the target task identifier and the target update file name.
[0067] For example, if the target task attribute information includes a target domain identifier indicating a chassis domain, then the target task sublist corresponding to the chassis domain is found in multiple task sublists, and then the target task sublist corresponding to the chassis domain is traversed directly without paying attention to the task sublists corresponding to other domains, which helps to improve traversal efficiency.
[0068] In some embodiments, after the removable carrier determines that the target update task matches the successfully executed historical update task, that is, the target update task has been successfully executed in history, the removable carrier refuses to execute the target update task again, but can send a task execution result indicating that the target update task has been successfully executed to the server. After receiving the task execution result, the server can mark the target update task as a non-repeatable task, thereby avoiding sending the target update task to the removable carrier again, thereby saving server resources.
[0069] In some embodiments, after the removable carrier determines that the target update task does not match the successfully executed historical update task, that is, the target update task has not been successfully executed in history, the removable carrier end can execute the target update task. If the removable carrier successfully executes the target update task, a task execution result indicating that the target update task has been successfully executed can be sent to the server. After receiving the task execution result, the server can mark the target update task as a non-repeatable task, thereby avoiding sending the target update task to the removable carrier end again, thereby saving server resources.
[0070] In some embodiments, after the removable carrier determines that the target update task does not match the historical update task that has been successfully executed, that is, the target update task has not been successfully executed in history, the removable carrier end can execute the target update task. If the removable carrier fails to execute the target update task, the removable carrier can determine the reason for the failure of the target update task. Then send the task execution result indicating the failure of the target update task and the reason for the failure to the server. When the server determines that the target update task has failed and the reason for the failure indicates that it cannot be updated again, the target update task is marked as a non-repeatable task, thereby avoiding the server from sending the target update task to the removable carrier end again, thereby reducing the probability of task update failure on the removable carrier end; if the server determines that the target update task has failed and the reason for the failure indicates that it can be updated again, the target update task is marked as a repeatable task and sent to the removable carrier end again for re-updating. The re-updating process is similar to the first updating process and will not be repeated here.
[0071] For example, the failure reason that makes it impossible to update again may be: the module and file selected by the target update task are inconsistent, the update path is incorrect, and other target update task setting errors cause update failures, and this application does not make special restrictions on this. The failure reason that makes it possible to update again may be: due to network reasons, the removable carrier update file is not downloaded completely, and this application does not make special restrictions on this.
[0072] See also Figure 5 , an embodiment of the present application provides a software updating device, which is applied to a removable carrier, and the device includes: A receiving unit 301 is used to receive a target update task from a server; A verification unit 302, used to verify whether the target update task matches the successfully executed historical update task; An execution unit 303 is used to refuse to execute the target update task if there is a match; The execution unit 303 is further configured to execute the target update task if there is no match.
[0073] Optionally, the target update task includes target task attribute information, there are multiple historical update tasks, each historical update task includes corresponding historical task attribute information, and the verification unit 302 includes: An attribute information traversal unit, used for traversing multiple historical task attribute information based on the target task attribute information; A determination unit, configured to determine that the target update task matches the successfully executed historical update task if historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information; The determination unit is further configured to determine that the target update task does not match the successfully executed historical update task if no historical task attribute information matching the target task attribute information is traversed among the multiple historical task attribute information.
[0074] Optionally, the attribute information traversal unit includes: A search subunit, used to search for a task list based on a preset task list table name, wherein a plurality of historical task attribute information is stored in the task list; The traversal subunit is used to traverse multiple historical task attribute information in the task list based on the target task attribute information.
[0075] Optionally, the device further comprises: A determination unit, configured to determine whether a task list exists in a database in response to entering a high voltage power-on state; The creation unit is used to create a task list in the database with the preset task attribute information as the table header and the table body content as an empty value if it does not exist.
[0076] Optionally, the target task attribute information includes a target domain identifier, a target task identifier, and a target update file name, each historical task attribute information includes a historical domain identifier, a historical task identifier, and a historical update file name, the task list includes multiple task sublists, each task sublist contains multiple historical task attribute information with the same historical domain identifier, and the traversal subunit is specifically used to: In the multiple task sublists, find the target task sublist where the historical domain identifier matching the target domain identifier is located; In the target task sublist, based on the target task identifier and the target update file name, the stored multiple historical task identifiers and multiple historical update file names are traversed.
[0077] Optionally, the target update task is a repeatable task.
[0078] Optionally, the device further comprises: The first sending unit is used to send a task execution result indicating successful task execution to the server, so that the server marks the target update task as a non-repeatable task.
[0079] Optionally, the device further comprises: A determination unit, configured to determine a failure reason corresponding to the target update task if the target update task fails to execute; The second sending unit is used to send a task execution result indicating task execution failure and the reason for the failure to the server, so that when the server determines that the target update task has failed and the reason indicates that it cannot be updated again, it will mark the target update task as a non-repeatable task.
[0080] See also Figure 6 , an embodiment of the present application provides a software updating device, applied to a server, the device comprising: The classification unit 401 is used to classify the tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly; The sending unit 402 is used to send the target update task to the removable carrier in the removable carrier task, so that the removable carrier refuses to execute the target update task when it is determined that the target update task matches the successfully executed historical update task, or executes the target update task when it is determined that the target update task does not match the successfully executed historical update task; The receiving unit 403 is used to receive the task execution result from the removable carrier; The classification unit 402 is further configured to mark the target update task as a non-repeatable sending task if the task execution result indicates that the target update task is successfully executed.
[0081] Optionally, the classification unit 402 is further configured to: if the task execution result indicates that the target update task execution fails, and the corresponding failure reason indicates that it cannot be updated again, mark the target update task as a non-repeatable sending task.
[0082] See also Figure 7 The embodiment of the present application further provides a removable carrier, the removable carrier comprising at least one processor 501, the processor 501 is used to execute the computer program stored in the memory, and implement the embodiment of the present application as provided in the example Figure 1-4 Flowchart steps of the software update method shown.
[0083] Optionally, the processor 501 may specifically be a central processing unit, a specific ASIC, or one or more integrated circuits for controlling program execution.
[0084] Optionally, the removable carrier may further include a memory 502 connected to at least one processor 501, and the memory 502 may include a ROM, a RAM, and a disk memory. The memory 502 is used to store data required by the processor 501 when it is running, that is, it stores instructions that can be executed by at least one processor 501. At least one processor 501 executes the instructions stored in the memory 502 to execute the following operations: Figure 1-4 The method shown. Wherein, the number of the memory 502 is one or more. Wherein, the number of the memory 502 is one or more.
[0085] See also Figure 8 The embodiment of the present application further provides a server, the server comprising at least one processor 601, the processor 601 is used to execute a computer program stored in a memory, and implement the embodiment of the present application as follows Figure 1-4 Flowchart steps of the software update method shown.
[0086] Optionally, the processor 601 may specifically be a central processing unit, a specific ASIC, or one or more integrated circuits for controlling program execution.
[0087] Optionally, the server may further include a memory 602 connected to at least one processor 601, and the memory 602 may include a ROM, a RAM, and a disk memory. The memory 602 is used to store data required by the processor 601 when it is running, that is, to store instructions that can be executed by at least one processor 601. At least one processor 601 executes the instructions stored in the memory 602 to execute the following steps: Figure 1-4 The method shown. Wherein, the number of memories 602 is one or more. Wherein, the number of memories 602 is one or more.
[0088] The present application also provides a computer storage medium, wherein the computer storage medium stores computer instructions, and when the computer instructions are executed on a computer, the computer executes Figure 1-4 method.
[0089] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.
Claims
1. A software updating method, characterized in that: Applied to a removable carrier, the method comprises: Receive target update tasks from the server; Verify whether the target update task matches the successfully executed historical update task; If they match, refusing to execute the target update task; If not, execute the target update task.
2. The method according to claim 1, characterized in that: The target update task includes target task attribute information, there are multiple historical update tasks, each of the historical update tasks includes corresponding historical task attribute information, and verifying whether the target update task matches the successfully executed historical update task includes: Traversing the plurality of historical task attribute information based on the target task attribute information; If historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information, it is determined that the target update task matches the successfully executed historical update task; If no historical task attribute information matching the target task attribute information is found among the plurality of historical task attribute information, it is determined that the target update task does not match the successfully executed historical update task.
3. The method according to claim 2, characterized in that Traversing the plurality of historical task attribute information based on the target task attribute information includes: Finding a task list based on a preset task list table name, wherein the plurality of historical task attribute information is stored in the task list; In the task list, multiple pieces of historical task attribute information are traversed based on the target task attribute information.
4. The method according to claim 3, characterized in that The method further comprises: In response to entering the high voltage power-on state, determining whether there is a task list in the database; If it does not exist, create the task list in the database with the preset task attribute information as the table header and the table body content as an empty value.
5. The method according to claim 3, characterized in that: The target task attribute information includes a target domain identifier, a target task identifier, and a target update file name, each of the historical task attribute information includes a historical domain identifier, a historical task identifier, and a historical update file name, the task list includes multiple task sublists, each task sublist contains multiple historical task attribute information with the same historical domain identifier, and in the task list, multiple historical task attribute information are traversed based on the target task attribute information, including: In the plurality of task sublists, searching for a target task sublist where a historical domain identifier matching the target domain identifier is located; In the target task sublist, based on the target task identifier and the target update file name, the stored multiple historical task identifiers and multiple historical update file names are traversed.
6. The method according to any one of claims 1 to 5, characterized in that: The target update task belongs to a task that can be sent repeatedly.
7. The method according to claim 6, characterized in that After refusing to execute the target update task, the method further includes: A task execution result indicating successful task execution is sent to the server, so that the server marks the target update task as a non-repeatable task.
8. The method according to claim 6, characterized in that After executing the target update task, the method further includes: If the target update task fails to execute, determining the failure reason corresponding to the target update task; A task execution result indicating task execution failure and the reason for the failure is sent to the server, so that when the server determines that the target update task has failed and the reason for the failure indicates that it cannot be updated again, it marks the target update task as a non-repeatable task.
9. A software updating method, characterized in that: Applied to a server, the method comprises: Classify the tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly; In the repeatedly sendable task, a target update task is sent to the removable carrier, so that the removable carrier refuses to execute the target update task when it is determined that the target update task matches the successfully executed historical update task, or executes the target update task when it is determined that the target update task does not match the successfully executed historical update task; receiving a task execution result from the removable carrier; If the task execution result indicates that the target update task is successfully executed, the target update task is marked as a non-repeatable sending task.
10. The method according to claim 9, characterized in that The method further comprises: If the task execution result indicates that the target update task has failed to execute, and the corresponding failure reason indicates that it cannot be updated again, the target update task is marked as a non-repeatable sending task.
11. A software updating device, characterized in that: Applied to a removable carrier, the device comprises: A receiving unit, used for receiving a target update task from a server; A verification unit, used to verify whether the target update task matches the successfully executed historical update task; An execution unit, configured to refuse to execute the target update task if there is a match; The execution unit is further configured to execute the target update task if there is no match.
12. A software updating device, characterized in that: Applied to a server, the device comprises: A classification unit is used to classify tasks to be updated to obtain tasks that can be sent repeatedly and tasks that cannot be sent repeatedly; a sending unit, configured to send a target update task to a removable carrier in the repeatable sendable task, so that the removable carrier refuses to execute the target update task when determining that the target update task matches a successfully executed historical update task, or executes the target update task when determining that the target update task does not match a successfully executed historical update task; A receiving unit, configured to receive a task execution result from the movable carrier; The classification unit is further configured to mark the target update task as a non-repeatable sending task if the task execution result indicates that the target update task is successfully executed.
13. A movable carrier, characterized in that: The removable carrier comprises a memory for storing computer program instructions and a processor for executing program instructions, wherein when the computer program instructions are executed by the processor, the removable carrier is triggered to execute the steps of the method according to any one of claims 1 to 8.
14. A server, characterized in that: The server comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the server is triggered to execute the steps of the method as claimed in any one of claims 9 to 10.