Upgrade interruption recovery method and system of Internet of Things equipment

Abstract

The invention discloses an upgrading interruption recovery method and system for Internet of Things equipment, and the method comprises the steps: receiving first equipment data uploaded by an equipment monitoring end through a platform end; the platform end performs upgrade interruption analysis on the first equipment data to obtain an interruption indication instruction; the equipment monitoring end obtains the interruption indication instruction, and obtains second equipment data and breakpoint data of the equipment upgrading end according to the interruption indication instruction; the platform end obtains the second equipment data and the breakpoint data, and performs dynamic recovery strategy generation on the second equipment data to obtain a target recovery strategy of the equipment upgrading end; and the platform end performs strategy upgrading recovery on the equipment upgrading end according to the target recovery strategy and the breakpoint data. According to the method, the adaptive capacity of interruption recovery can be effectively improved, and the stability and success rate of software upgrading can be improved. The invention relates to the technical field of remote software upgrading.

Description

Technical Field

[0001] The present invention relates to the technical field of remote software upgrade, and in particular to an upgrade interruption recovery method and system for Internet of Things devices. Background Art

[0002] With the popularization of smart grids and other Internet of Things devices, after an upgrade interruption occurs during the remote software upgrade process of Internet of Things devices, the interruption recovery of the remote software upgrade process has become one of the key concerns.

[0003] Currently, the existing technology usually performs interruption recovery on the remote software upgrade process based on the upgrade log of the Internet of Things device itself or a simple retry mechanism after an upgrade interruption occurs. This method has low adaptability for interruption recovery during the software upgrade process of Internet of Things devices, and the stability and success rate of software upgrade are not satisfactory.

[0004] Therefore, the problems existing in the existing technology still need to be solved and optimized urgently. Summary of the Invention

[0005] An object of the present invention is to solve at least to some extent one of the technical problems existing in the related art.

[0006] To this end, an object of an embodiment of the present invention is to provide an upgrade interruption recovery method and system for Internet of Things devices, wherein the method can effectively improve the adaptability of interruption recovery and is beneficial to improving the stability and success rate of software upgrade.

[0007] To achieve the above technical object, the technical solutions adopted in the embodiments of the present application include:

[0008] In a first aspect, an embodiment of the present application provides an upgrade interruption recovery method for Internet of Things devices, including:

[0009] The platform end receives the first device data uploaded by the device monitoring end, and the first device data includes the first operation information, the first resource information, and the first network connection information of the device upgrade end;

[0010] The platform end performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction;

[0011] The device monitoring end obtains the interruption indication instruction, and according to the interruption indication instruction, obtains the second device data and breakpoint data of the device upgrade end, and the second device data includes the second operation information, the second resource information, and the second network connection information;

[0012] The platform end obtains the second device data and the breakpoint data, and generates a dynamic recovery strategy for the second device data to obtain the target recovery strategy of the device upgrade end;

[0013] The platform end performs policy upgrade and recovery on the device upgrade end according to the target recovery policy and the breakpoint data.

[0014] In addition, according to the method of the above embodiments of the present application, the following additional technical features may also be included:

[0015] Further, in an embodiment of the present application, the platform end performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction, including:

[0016] The platform end obtains historical upgrade data, and the historical upgrade data is the historical record of the device upgrade end;

[0017] Generate a dynamic threshold according to the first operation information, the first resource information, and the first network connection information;

[0018] Perform interruption prediction analysis on the first device data according to the historical upgrade data to obtain an interruption prediction value;

[0019] Generate the interruption indication instruction according to the interruption prediction value and the dynamic threshold.

[0020] Further, in an embodiment of the present application, the platform end generates a dynamic recovery policy for the second device data to obtain the target recovery policy of the device upgrade end, including:

[0021] The platform end generates a resource load policy for the second resource information to obtain a resource recovery sub-policy;

[0022] Generate a network environment policy for the second network connection information to obtain a network recovery sub-policy;

[0023] Generate a device operation policy for the second operation information to obtain an operation recovery sub-policy;

[0024] Obtain the target recovery policy according to the resource recovery sub-policy, the network recovery sub-policy, and the operation recovery sub-policy.

[0025] Further, in an embodiment of the present application, the platform end performs policy upgrade and recovery on the device upgrade end according to the target recovery policy and the breakpoint data, including:

[0026] The platform end obtains the upgrade package version corresponding to the breakpoint data, and generates recovery data for the breakpoint data according to the upgrade package version and the target recovery policy to obtain breakpoint update data;

[0027] The platform terminal transmits the breakpoint update data to the device upgrade terminal according to the target recovery policy;

[0028] The device upgrade terminal performs breakpoint recovery upgrade according to the breakpoint update data.

[0029] Further, in an embodiment of the present application, the breakpoint update data is differential update data or incremental update data, and the platform terminal generates recovery data for the breakpoint data according to the upgrade package version and the target recovery policy to obtain breakpoint update data, including:

[0030] The platform terminal obtains the upgrade scheduling policy of the device upgrade terminal according to the target recovery policy, and the upgrade scheduling policy includes an incremental update policy or a differential update policy;

[0031] If the upgrade scheduling policy is the incremental update policy, incremental data is generated for the breakpoint data according to the upgrade package version to obtain the incremental update data; or, if the upgrade scheduling policy is the differential update policy, differential data is generated for the breakpoint data according to the upgrade package version to obtain the differential update data.

[0032] Further, in an embodiment of the present application, the method further includes:

[0033] The device upgrade terminal obtains the current software version file and the upgrade package version;

[0034] Perform file consistency verification on the current software version file according to the upgrade package version to obtain a file verification result;

[0035] If the file verification result is that the version files do not completely match, perform software version recovery on the current software version file.

[0036] Further, in an embodiment of the present application, the method further includes:

[0037] The platform terminal obtains the third device data uploaded by the device monitoring terminal;

[0038] The platform terminal verifies the device status of the second device data according to the third device data to obtain a status verification result, and the status verification result is used to indicate whether the device status of the device upgrade terminal has changed;

[0039] If the status verification result is that the device status of the device upgrade terminal has changed, the platform terminal adjusts and updates the target recovery policy according to the third device data to obtain an updated target recovery policy.

[0040] Second aspect, an embodiment of the present application provides a method for upgrading interruption recovery of an Internet of Things device, including:

[0041] Obtain first device data, which is uploaded through a device monitoring end, and the first device data includes first operation information, first resource information, and first network connection information of a device upgrade end;

[0042] Perform upgrade interruption analysis on the first device data to obtain an interruption indication instruction;

[0043] Obtain second device data and breakpoint data, which are obtained by the device monitoring end according to the interruption indication instruction, and the second device data includes second operation information, second resource information, and second network connection information;

[0044] Perform dynamic recovery measurement generation on the second device data to obtain a target recovery strategy for the device upgrade end;

[0045] Perform policy upgrade recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

[0046] Third aspect, an embodiment of the present application provides an upgrading interruption recovery system for an Internet of Things device, including a device monitoring end and a platform end;

[0047] The device monitoring end is used to upload first device data to the platform end, and obtain second device data and breakpoint data of a device upgrade end according to an interruption indication instruction; the first device data includes first operation information, first resource information, and first network connection information of the device upgrade end; the second device data includes second operation information, second resource information, and second network connection information;

[0048] The platform end is used to perform upgrade interruption analysis on the first device data to obtain an interruption indication instruction; perform dynamic recovery strategy generation on the second device data to obtain a target recovery strategy for the device upgrade end; and perform policy upgrade recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

[0049] Fourth aspect, an embodiment of the present application provides an upgrading interruption recovery system for an Internet of Things device, including:

[0050] A first processing unit for obtaining first device data, which is uploaded through a device monitoring end, and the first device data includes first operation information, first resource information, and first network connection information of a device upgrade end;

[0051] A second processing unit for performing upgrade interruption analysis on the first device data to obtain an interruption indication instruction;

[0052] A third processing unit, configured to obtain second device data and breakpoint data, where the second device data and the breakpoint data are obtained by the device monitoring end according to the interruption indication instruction, and the second device data includes second operation information, second resource information, and second network connection information;

[0053] A fourth processing unit, configured to perform dynamic recovery measurement generation on the second device data to obtain a target recovery policy for the device upgrade end;

[0054] A fifth processing unit, configured to perform policy upgrade and recovery on the device upgrade end according to the target recovery policy and the breakpoint data.

[0055] In a fifth aspect, an embodiment of the present application further provides an electronic device, including:

[0056] At least one processor;

[0057] At least one memory, configured to store at least one program;

[0058] When the at least one program is executed by the at least one processor, the at least one processor implements the above method.

[0059] In a sixth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which a program executable by a processor is stored, and the program executable by the processor is used to implement the above method when executed by the processor.

[0060] The advantages and beneficial effects of the present application will be partially given in the following description, partially become obvious from the following description, or be understood through the practice of the present application:

[0061] An upgrade interruption recovery method and system for an Internet of Things device disclosed in an embodiment of the present application. In this method, the platform end receives first device data uploaded by the device monitoring end, and the first device data includes first operation information, first resource information, and first network connection information of the device upgrade end; the platform end performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction; the device monitoring end obtains the interruption indication instruction, and according to the interruption indication instruction, obtains second device data and breakpoint data of the device upgrade end, and the second device data includes second operation information, second resource information, and second network connection information; the platform end obtains the second device data and the breakpoint data, and generates a dynamic recovery strategy for the second device data to obtain a target recovery strategy for the device upgrade end; the platform end performs policy upgrade recovery on the device upgrade end according to the target recovery strategy and the breakpoint data. This method dynamically generates a target recovery strategy for the device upgrade end based on the second device data, which can effectively improve the adaptability of interruption recovery during software upgrade, and is beneficial to improving the stability and success rate of software upgrade. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following introduces the accompanying drawings related to the technical solutions in the embodiments of the present application or the prior art. It should be understood that the accompanying drawings introduced below are only for conveniently and clearly expressing some embodiments of the technical solutions in the present application, and those skilled in the art can also obtain other drawings based on these drawings without creative efforts.

[0063] Figure 1 It is a schematic flowchart of an upgrade interruption recovery method for an Internet of Things device provided by an embodiment of the present application;

[0064] Figure 2 It is a schematic structural framework diagram of an upgrade interruption recovery system for an Internet of Things device provided by an embodiment of the present application;

[0065] Figure 3 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0066] Embodiments of the present application will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where like or similar reference numerals denote like or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and are only used to explain the present application, and should not be construed as a limitation to the present application. For the step numbers in the following embodiments, they are only set for the convenience of explanation and illustration, and no limitation is imposed on the order between steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0067] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0068] In practical applications, during the remote software upgrade process of Internet of Things (IoT) devices, upgrade interruptions may occur due to various factors (such as poor network connection status, device power-off, upgrade data transmission errors, shortage of remaining resources of the device, etc.). These upgrade interruptions will delay the upgrade time of IoT devices and may also cause the software versions of multiple IoT devices to be in an inconsistent state, affecting the stability and security of the IoT device control system.

[0069] Currently, in the prior art, usually after an upgrade interruption occurs, based on static strategies such as the upgrade log of the IoT device itself or a simple retry mechanism, etc., to perform interruption recovery for the remote software upgrade process. It requires the IoT device itself to initiate the interruption recovery, that is, the IoT device itself needs to consume a certain amount of power resources or operating resources to execute the interruption recovery; and in practical applications, this method may increase the burden on the IoT device. For example, if the upgrade interruption of the IoT device is caused by low device power or shortage of remaining resources of the device, the effect of interruption recovery is poor, and it cannot well adapt to the actual situation of upgrade interruptions of IoT devices, with low adaptability, and thus the stability and success rate of software upgrade are not satisfactory.

[0070] In addition, the method using static strategies often cannot fully consider factors such as the actual resource status, network environment, or system load of IoT devices during the software upgrade process, resulting in a low success rate of the IoT device in performing interruption recovery, that is, the static strategy of this method also cannot well adapt to the actual situation of upgrade interruptions of IoT devices, with poor adaptability, and thus the stability and success rate of software upgrade are not satisfactory.

[0071] In addition, since software upgrades for Internet of Things (IoT) devices often take a certain amount of time, and during the software upgrade process of IoT devices, the device status of IoT devices (such as the power level of IoT devices, remaining resources of the devices, etc.) and the external environment (such as network connection status, etc.) often change. When performing interruption recovery operations in this way, it often cannot well adapt to changes in the device status and external environment, and it is easy to have a situation where the interruption recovery process is also interrupted. The adaptability of interruption recovery is not high, and thus the stability and success rate of software upgrades are not satisfactory.

[0072] In view of this, embodiments of the present invention provide an upgrade interruption recovery method and system for IoT devices. Among them, in this method, the platform side dynamically generates a target recovery strategy for the device upgrade side based on the second device data. This target recovery strategy can better adapt to the actual situation of upgrade interruption of IoT devices, effectively improve the adaptability of interruption recovery, and thus is conducive to improving the stability and success rate of software upgrades.

[0073] In addition, this method collects the first device data, second device data, and breakpoint data of the device upgrade side by the device monitoring side, and determines the target recovery strategy based on the data obtained from the device monitoring side by the platform side and performs measurement upgrade recovery on the device upgrade side. It can reduce the burden of IoT devices during interruption recovery, effectively improve the adaptability of interruption recovery, and thus is conducive to improving the stability and success rate of software upgrades.

[0074] Furthermore, this method also verifies whether there are changes between the second device data and the third device data. Specifically, it can verify whether there are changes between the device data at the current time point (such as the third device data) and the device data at the previous time point (such as the second device data), so that the upgrade interruption recovery system can real-time sense and respond to changes in the device status and external environment of IoT devices. Thus, the upgrade interruption recovery system can perform dynamic strategy upgrade recovery based on the target recovery measurement obtained by real-time update (such as the updated target recovery measurement). The adaptability of interruption recovery is relatively high, which is conducive to improving the stability and success rate of software upgrades.

[0075] Refer to Figure 1 , in an embodiment of the present application, an upgrade interruption recovery method for an IoT device includes:

[0076] Step 110, the platform side receives the first device data uploaded by the device monitoring side, and the first device data includes the first running information, first resource information, and first network connection information of the device upgrade side;

[0077] In an embodiment of the present application, the device upgrade end may be an Internet of Things device for software upgrade; the device monitoring end may be a hardware device for monitoring the device upgrade end, or a hardware monitoring module embedded in the device upgrade end; the platform end may be a software upgrade platform that communicates with the device upgrade end and the device monitoring end respectively.

[0078] It can be understood that during the software upgrade process of the device upgrade end, the device monitoring end can periodically or real-time collect data such as the battery power, power status, network bandwidth, network signal strength, CPU occupancy rate, memory usage, and current task load of the device upgrade end, and determine data such as battery capacity and power status as the first operation information, determine data such as network bandwidth and network signal strength as the first network connection information, and determine data such as CPU occupancy rate, memory usage, and current task load as the first network connection information. Additionally, after the device monitoring end collects the first network connection information, the first operation information, and the first network connection information, it can integrate the above information into the first device data, and upload the first device data to the platform end through the real-time communication channel between the device monitoring end and the platform end.

[0079] Step 120: The platform end performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction;

[0080] In an embodiment of the present application, after receiving the first device data, the platform end can perform interruption detection on the information of the corresponding type of the first device data based on multiple interruption detection mechanisms, and generate an interruption indication instruction when the detection result indicates that there is an interruption risk in the software upgrade of the device upgrade end.

[0081] In some embodiments, the platform end performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction, including:

[0082] A1: The platform end obtains historical upgrade data, and the historical upgrade data is the historical record of the device upgrade end;

[0083] A2: Generate a dynamic threshold according to the first operation information, the first resource information, and the first network connection information;

[0084] A3: Perform interruption prediction analysis on the first device data according to the historical upgrade data to obtain an interruption prediction value;

[0085] A4: Generate the interruption indication instruction according to the interruption prediction value and the dynamic threshold.

[0086] In the embodiments of the present application, for a certain device upgrade end, after the platform end receives the first device data of the device upgrade end, it can obtain the historical upgrade record stored in the platform end of the device upgrade end, denoted as historical upgrade data. Then, based on the current running state of the device upgrade end (such as the first running information, the first resource information, and the first network connection information), a dynamic threshold adapted to the real-time running state of the device upgrade end is generated.

[0087] Specifically, in the first feasible implementation manner, a weight can be assigned to the first running information, the first resource information, and the first network connection information respectively in advance, and the first running information, the first resource information, and the first network connection information are respectively input into a neural network model for score prediction, so as to obtain the prediction score of the first running information, the prediction score of the first resource information, and the prediction score of the first network connection information; then, based on all the prediction scores and the corresponding weights, the dynamic threshold is calculated by means of weighted summation or weighted average.

[0088] Alternatively, in the second feasible implementation manner, a score level table can be constructed for the first running information, the first resource information, and the first network connection information respectively in advance, and based on the constructed score level table, the running score of the first running information, the resource score of the first resource information, and the network score of the first network connection information are determined; then, the dynamic threshold is calculated based on the running score, the resource score, and the network score. There are various calculation methods for the dynamic threshold, such as summation average, weighted summation, weighted average, etc., which will not be elaborated herein in the present application.

[0089] It can be understood that step A3 can be to construct an interruption prediction analysis model based on a historical upgrade model and a neural network model (such as a CNN network, an LSTM network, etc.), and input the first device data into the interruption prediction analysis model for prediction to obtain the predicted value output by the interruption prediction analysis model. Step A4 can first be to compare the size relationship between the interruption predicted value and the dynamic threshold. If the interruption predicted value is greater than or equal to the dynamic threshold, it indicates that there is an interruption risk in the software upgrade of the device upgrade end. At this time, an interruption indication instruction can be generated; or, if the interruption predicted value is less than the dynamic threshold, it indicates that there is no interruption risk in the software upgrade of the device upgrade end. At this time, step 110 can be returned for execution.

[0090] Step 130, the device monitoring end obtains the interruption indication instruction, and according to the interruption indication instruction, obtains the second device data and breakpoint data of the device upgrade end. The second device data includes the second running information, the second resource information, and the second network connection information;

[0091] In the embodiment of the present application, after generating an interrupt indication instruction, the platform side can transmit the interrupt indication instruction to the device monitoring side; the device monitoring side receives and responds to the interrupt indication instruction, and collects the current data of the device upgrade side (such as second device data and breakpoint data). Among them, the second device data is similar to the foregoing first device data and can be simply deduced by analogy; and the breakpoint data can be obtained by the device monitoring side collecting or reading the interrupt log of the device upgrade side.

[0092] Step 140, the platform side obtains the second device data and the breakpoint data, and generates a dynamic recovery policy for the second device data to obtain the target recovery policy of the device upgrade side;

[0093] In the embodiment of the present application, after receiving the second device data and the breakpoint data uploaded by the device monitoring side, the platform side first adaptively generates a target recovery policy corresponding to the device upgrade side based on the second device data at the current time point.

[0094] In some embodiments, the platform side generates a dynamic recovery policy for the second device data to obtain the target recovery policy of the device upgrade side, including:

[0095] B1. The platform side generates a resource load policy for the second resource information to obtain a resource recovery sub-policy;

[0096] B2. Generate a network environment policy for the second network connection information to obtain a network recovery sub-policy;

[0097] B3. Generate a device operation policy for the second operation information to obtain an operation recovery sub-policy;

[0098] B4. Obtain the target recovery policy according to the resource recovery sub-policy, the network recovery sub-policy and the operation recovery sub-policy.

[0099] In the embodiment of the present application, for the current task load in the second resource information, step B1 can be to compare the current task load based on the preset task load threshold in the platform side. If the current task load is greater than or equal to the task load threshold, generate load recovery information indicating reducing the recovery priority of high-load tasks in software upgrade and increasing the recovery priority of low-load tasks in software upgrade; or, if the current task load is less than the task load threshold, generate load recovery information indicating that the priority of the load task is not adjusted.

[0100] For the remaining data in the second piece of information, such as CPU occupancy rate and memory usage, etc., they are similar to the content of the aforementioned current task load and can be simply analogized. After obtaining the load recovery information, CPU occupancy recovery information, memory usage recovery information, etc., a resource recovery sub-strategy can be directly constructed based on the load recovery information, CPU occupancy recovery information, memory usage recovery information, etc.

[0101] It can be understood that the content of steps B2 to B3 is similar to the content of the aforementioned step B1 and can be simply analogized. Specifically, step B2 can be to compare the corresponding network bandwidth or network signal strength in the second device data based on the bandwidth threshold and intensity threshold preset on the platform side. When the network bandwidth is greater than or equal to the bandwidth threshold or the network signal strength is less than the intensity threshold in at least one case, a network recovery sub-strategy representing a reduction in the data transmission volume of software upgrade is generated; otherwise, a network recovery sub-strategy representing no adjustment to the data transmission volume is generated.

[0102] For the battery power in the second piece of running information, step B3 can be to compare the battery power based on the power threshold preset on the platform side. If the battery power is less than the power threshold, a running recovery information is generated to reduce the recovery priority of high-power-consuming tasks in software upgrade and increase the recovery priority of low-load tasks in software upgrade; otherwise, a running recovery information representing no adjustment to the priority of power-consuming tasks is generated. For the power state of the second piece of running information, it is similar to the content of the aforementioned battery power, and the running recovery sub-strategy is similar to the content of the aforementioned resource recovery sub-strategy and can be simply analogized.

[0103] It should be noted that there can be multiple thresholds of the same type in the embodiments of the present application. The thresholds of the same type can be any one of the task load threshold, bandwidth threshold, intensity threshold, power threshold, etc. In the embodiments of the present application, the number of thresholds of the same type is taken as 2 as an example.

[0104] Exemplarily, for the current task load in the second resource information, the corresponding task load thresholds may include a first task load threshold and a second task load threshold, where the first task load threshold is greater than the second task load threshold; if the current task load is greater than or equal to the first task load threshold, load recovery information may be generated to represent reducing the recovery priorities of high-load tasks and medium-load tasks in software upgrade and increasing the recovery priorities of low-load tasks in software upgrade; or, if the current task load is less than the first task load threshold and greater than or equal to the second task load threshold, load recovery information may be generated to represent reducing the recovery priority of high-load tasks in software upgrade and increasing the recovery priorities of low-load tasks and medium-load tasks in software upgrade; or, if the current task load is less than the second task load threshold, load recovery information may be generated that does not adjust the priorities of load tasks.

[0105] It is worth mentioning that step B4 may be to integrate the resource recovery sub-strategy, network recovery sub-strategy, and operation recovery sub-strategy, and determine the integrated strategy as the target recovery sub-strategy.

[0106] Step 150, the platform end performs policy upgrade recovery on the device upgrade end according to the target recovery policy and the breakpoint data.

[0107] In the embodiments of the present application, after obtaining the target recovery policy and breakpoint data, the platform end performs interruption recovery on the upgrade interruption position indicated by the breakpoint data by executing the target recovery policy, so that the software upgrade of the device upgrade end is completed.

[0108] In some embodiments, the platform end performs policy upgrade recovery on the device upgrade end according to the target recovery policy and the breakpoint data, including:

[0109] C1. The platform end obtains the upgrade package version corresponding to the breakpoint data, and generates recovery data for the breakpoint data according to the upgrade package version and the target recovery policy to obtain breakpoint update data;

[0110] Further, the platform end generates recovery data for the breakpoint data according to the upgrade package version and the target recovery policy to obtain breakpoint update data, including:

[0111] C11. The platform end obtains the upgrade scheduling policy of the device upgrade end according to the target recovery policy, and the upgrade scheduling policy includes an incremental update policy or a differential update policy;

[0112] C12. If the upgrade scheduling policy is the incremental update policy, incremental data is generated for the breakpoint data according to the upgrade package version to obtain the incremental update data;

[0113] Or, C13. If the upgrade scheduling policy is a differential update policy, differential data is generated from the breakpoint data according to the upgrade package version to obtain the differential update data.

[0114] In an embodiment of the present application, step C11 may be to obtain, through a target recovery policy generated by the platform side, an upgrade scheduling policy for the platform side to the device upgrade side, and this upgrade scheduling policy is used to indicate that the breakpoint update data provided by the platform side to the device upgrade side is incremental update data or differential update data. Specifically, when at least one of the resource recovery sub-policy in the target recovery policy indicates that the resources of the device upgrade side are in short supply, the network recovery sub-policy indicates that the network connection status of the device upgrade side is poor, or the operation recovery sub-policy indicates that the operation status of the device upgrade side is at high risk, etc., the upgrade scheduling policy may be a differential update policy; otherwise, the upgrade scheduling policy is an incremental update policy.

[0115] It can be understood that for the resource recovery sub-policy, it includes load recovery information, CPU occupancy recovery information, memory usage recovery information, etc., and there is load recovery information that represents reducing the recovery priority of high-load tasks in software upgrade and increasing the recovery priority of low-load tasks in software upgrade, CPU occupancy recovery information that represents reducing the recovery priority of high-CPU occupancy tasks in software upgrade and increasing the recovery priority of low-CPU occupancy tasks in software upgrade, and memory usage recovery information that represents reducing the recovery priority of high-memory usage tasks in software upgrade and increasing the recovery priority of low-memory usage tasks in software upgrade. When at least one of them exists, the constructed resource recovery sub-policy can indicate that the resources of the device upgrade side are in short supply; the content of the network recovery sub-policy and the operation recovery sub-policy is similar to the aforementioned resource recovery sub-policy and can be simply deduced by analogy.

[0116] It should be noted that step C12 can first be to compare the version of the upgrade package with the device version corresponding to the breakpoint data through the platform side, and this device version is the original software version of the device upgrade side; then, based on the difference between the upgrade package version and the device version, incremental update data for incremental update is generated from the breakpoint position in the software upgrade process through incremental update technology and the breakpoint data; step C13 is similar to the aforementioned step C12, and the difference is that differential update data for differential update is generated from the breakpoint position in the software upgrade process through differential update technology and the breakpoint data.

[0117] C2. The platform side transmits the breakpoint update data to the device upgrade side according to the target recovery policy;

[0118] C3. The device upgrade side performs breakpoint recovery upgrade according to the breakpoint update data.

[0119] In an embodiment of the present application, step C2 may be that the platform side sorts each update task in the breakpoint update data based on the resource recovery sub-strategy and the operation recovery sub-strategy in the target recovery strategy, and then the platform side transmits the sorted breakpoint update data to the device upgrade side based on the network recovery sub-strategy in the target recovery strategy.

[0120] Exemplarily, if the resource recovery sub-strategy includes load recovery information indicating reducing the recovery priority of high-load tasks in software upgrade and increasing the recovery priority of low-load tasks in software upgrade, and the operation recovery sub-strategy includes operation recovery information indicating reducing the recovery priority of high-power consumption tasks in software upgrade and increasing the recovery priority of low-load tasks in software upgrade; then the platform side can use the load recovery information and the operation recovery information as sorting conditions to jointly sort each update task of the breakpoint update data, so as to obtain the sorted breakpoint update data. Then, the platform side transmits the sorted breakpoint update data to the device upgrade side based on the data transmission volume determined by the network recovery sub-strategy.

[0121] It can be understood that step C3 may be that the device upgrade side performs interruption recovery on the interrupted software upgrade process based on the order of receiving the sorted breakpoint update data and the breakpoint position, so that the device upgrade side completes the software upgrade.

[0122] In some embodiments, the method further includes:

[0123] D1. The device upgrade side obtains the current software version file and the upgrade package version;

[0124] D2. According to the upgrade package version, perform file consistency verification on the current software version file to obtain a file verification result;

[0125] D3. If the file verification result is that the version files do not completely match, perform software version recovery on the current software version file.

[0126] In the embodiments of the present application, after the device upgrade end completes the software upgrade process during the execution of the interruption recovery, it can obtain its current software version file and the version of the upgrade package for the most recent execution of the interruption recovery; step D2 can be that the device upgrade end compares the public key or hash value of the current software version file of the device upgrade end based on the digital signature or hash value of the upgrade package version, so as to obtain the file verification result. Specifically, step D2 can be that the device upgrade end verifies the public key corresponding to the current software version file received during the software upgrade process based on the digits in front of the upgrade package version, so as to obtain the file verification result; if it is verified that the current software version file is true and complete, a file verification result indicating that the version files match exactly is obtained, otherwise, a file verification result indicating that the version files do not match exactly is obtained.

[0127] It can be understood that if the file verification result is that the version files do not match exactly, the current software version file of the device upgrade end is rolled back to the version before the software upgrade, and the software upgrade is performed again based on the upgrade package.

[0128] In some embodiments, the method further includes:

[0129] E1. The platform end obtains the third device data uploaded by the device monitoring end;

[0130] E2. The platform end verifies the device status of the second device data according to the third device data to obtain a status verification result, and the status verification result is used to indicate whether the device status of the device upgrade end has changed;

[0131] E3. If the status verification result is that the device status of the device upgrade end has changed, the platform end adjusts and updates the target recovery policy according to the third device data to obtain an updated target recovery policy.

[0132] In the embodiments of the present application, the third device data is similar to the foregoing first device data or second device data. The third device data is device data collected in real time by the device monitoring end after the platform end obtains the second device data. Step E2 can be to compare whether the second running information and the third running information are the same or different, compare whether the second resource information and the third resource information are the same or different, and compare whether the second network connection information and the third network connection information are the same or different. If there is at least one piece of information that is different, a status verification result indicating that the device status of the device upgrade end has changed can be generated; or, if all the information is the same, a status verification result indicating that the device status of the device upgrade end has not changed can be generated.

[0133] It can be understood that if the status verification result is that the device status of the device upgrade end has changed, the target recovery strategy corresponding to the second device data can be replaced based on the target recovery strategy corresponding to the third device data to obtain an updated target recovery strategy, thereby improving the adaptability of interrupt recovery to changes in the internal status and external environment of the device upgrade end.

[0134] In an embodiment of the present application, another method for restoring an upgrade interruption of an IoT device includes:

[0135] Acquire first device data, where the first device data is uploaded by a device monitoring terminal, and the first device data includes first operation information, first resource information, and first network connection information of a device upgrade terminal;

[0136] Performing upgrade interrupt analysis on the first device data to obtain an interrupt indication instruction;

[0137] Acquire second device data and breakpoint data, where the second device data and the breakpoint data are acquired by the device monitoring terminal according to the interrupt indication instruction, and the second device data includes second operation information, second resource information, and second network connection information;

[0138] Performing dynamic recovery measurement on the second device data to generate a target recovery strategy for the device upgrade end;

[0139] According to the target recovery strategy and the breakpoint data, the device upgrade end is subjected to strategy upgrade recovery.

[0140] In the embodiment of the present application, the upgrade interruption recovery method is the same as the aforementioned upgrade interruption recovery method, and can be simply deduced by analogy, so the present application will not repeat it here.

[0141] An upgrade interruption recovery system for an IoT device proposed in an embodiment of the present application includes a device monitoring end and a platform end;

[0142] The device monitoring end is used to upload first device data to the platform end, and obtain second device data and breakpoint data of the device upgrade end according to the interrupt indication instruction; the first device data includes first operation information, first resource information and first network connection information of the device upgrade end; the second device data includes second operation information, second resource information and second network connection information;

[0143] The platform end is used to perform upgrade interrupt analysis on the first device data to obtain an interrupt indication instruction; generate a dynamic recovery strategy for the second device data to obtain a target recovery strategy for the device upgrade end; and perform policy upgrade recovery on the device upgrade end based on the target recovery strategy and the breakpoint data.

[0144] It is understandable that the content in the above method embodiments is applicable to the present system embodiment. The functions specifically implemented in the present system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those in the above method embodiments.

[0145] Next, a system for upgrading interruption recovery of an Internet of Things device proposed according to an embodiment of the present application will be described in detail with reference to the accompanying drawings.

[0146] Refer to Figure 2 , a system for upgrading interruption recovery of an Internet of Things device proposed in an embodiment of the present application includes:

[0147] A first processing unit 101, configured to obtain first device data, where the first device data is uploaded through a device monitoring end, and the first device data includes first operation information, first resource information, and first network connection information of a device upgrade end;

[0148] A second processing unit 102, configured to perform an upgrade interruption analysis on the first device data to obtain an interruption indication instruction;

[0149] A third processing unit 103, configured to obtain second device data and breakpoint data, where the second device data and the breakpoint data are obtained by the device monitoring end according to the interruption indication instruction, and the second device data includes second operation information, second resource information, and second network connection information;

[0150] A fourth processing unit 104, configured to perform dynamic recovery measurement generation on the second device data to obtain a target recovery strategy for the device upgrade end;

[0151] A fifth processing unit 105, configured to perform policy upgrade recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

[0152] It is understandable that the content in the above method embodiments is applicable to the present system embodiment. The functions specifically implemented in the present system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those in the above method embodiments.

[0153] Refer to Figure 3 , an embodiment of the present application further provides an electronic device, including:

[0154] At least one processor 201;

[0155] At least one memory 202, configured to store at least one program;

[0156] When the at least one program is executed by the at least one processor 201, the at least one processor 201 implements the method embodiments described above.

[0157] Similarly, it can be understood that the content in the above method embodiments is applicable to this device embodiment. The functions specifically implemented in this device embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those in the above method embodiments.

[0158] This application embodiment also provides a computer-readable storage medium, which stores a program executable by the processor 201. The program executable by the processor 201 is used to implement the above method embodiments when executed by the processor 201.

[0159] Similarly, the content in the above method embodiments is applicable to this computer-readable storage medium embodiment. The functions specifically implemented in this computer-readable storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those in the above method embodiments.

[0160] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order mentioned in the operation diagrams. For example, depending on the functions / operations involved, two consecutive blocks shown may actually be executed substantially simultaneously or the blocks can sometimes be executed in the reverse order. In addition, the embodiments presented and described in the flowcharts of this application are provided by way of example for the purpose of providing a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logical flows presented herein. Alternative embodiments are foreseeable, where the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0161] In addition, although this application is described in the context of functional modules, it should be understood that unless stated otherwise, one or more of the functions and / or features may be integrated in a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It can also be understood that a detailed discussion of the actual implementation of each module is not necessary for understanding this application. More precisely, considering the attributes, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the module will be understood within the ordinary skills of an engineer. Therefore, those skilled in the art can implement this application as set forth in the claims without undue experimentation using ordinary skills. It can also be understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0162] If a function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method of the embodiment of this application. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs, etc., various media that can store program codes.

[0163] The logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a definite sequence list of executable instructions for implementing a logical function, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch instructions from the instruction execution system, apparatus, or device and execute the instructions), or in combination with these instruction execution systems, apparatus, or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device.

[0164] More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection part with one or more wirings (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber device, and portable compact disc read-only memory (CDROM). Additionally, a computer-readable medium can even be paper or other suitable media on which a program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media, then editing, interpreting, or processing it in other suitable ways as necessary, and then storing it in a computer memory.

[0165] It should be understood that each part of the present application can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one of the following techniques well known in the art or a combination thereof can be used: discrete logic circuits with logic gate circuits for implementing logical functions on data signals, application specific integrated circuits with appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0166] In the above description of this specification, the description with reference to the terms "one embodiment / example", "another embodiment / example" or "certain embodiments / examples", etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0167] Although the embodiments of the present application have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present application, and the scope of the present application is defined by the claims and their equivalents.

[0168] The above is a specific description of the preferred embodiments of the present application, but the present application is not limited to the embodiments. Those skilled in the art can make various equivalent deformations or substitutions without departing from the spirit of the present application, and these equivalent deformations or substitutions are all included within the scope defined by the claims of the present application.

Claims

1. An upgrade interruption recovery method for an Internet of Things device, characterized in that, Including: The platform - side receives the first device data uploaded by the device monitoring - side. The first device data includes the first operation information, the first resource information, and the first network connection information of the device upgrade - side; The platform - side performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction; The device monitoring - side obtains the interruption indication instruction and, according to the interruption indication instruction, obtains the second device data and breakpoint data of the device upgrade - side. The second device data includes the second operation information, the second resource information, and the second network connection information; The platform - side obtains the second device data and the breakpoint data, and generates a dynamic recovery strategy for the second device data to obtain the target recovery strategy of the device upgrade - side; The platform - side performs policy upgrade recovery on the device upgrade - side according to the target recovery strategy and the breakpoint data.

2. The method according to claim 1, wherein The platform - side performs upgrade interruption analysis on the first device data to obtain an interruption indication instruction, including: The platform - side obtains historical upgrade data, and the historical upgrade data is the historical record of the device upgrade - side; Generates a dynamic threshold according to the first operation information, the first resource information, and the first network connection information; Performs interruption prediction analysis on the first device data according to the historical upgrade data to obtain an interruption prediction value; Generates the interruption indication instruction according to the interruption prediction value and the dynamic threshold.

3. The method according to claim 1, characterized in that The platform - side generates a dynamic recovery strategy for the second device data to obtain the target recovery strategy of the device upgrade - side, including: The platform - side generates a resource load strategy for the second resource information to obtain a resource recovery sub - strategy; Generates a network environment strategy for the second network connection information to obtain a network recovery sub - strategy; Generates a device operation strategy for the second operation information to obtain an operation recovery sub - strategy; Obtains the target recovery strategy according to the resource recovery sub - strategy, the network recovery sub - strategy, and the operation recovery sub - strategy.

4. The method according to claim 1, wherein The platform - side performs policy upgrade recovery on the device upgrade - side according to the target recovery strategy and the breakpoint data, including: The platform - side obtains the upgrade package version corresponding to the breakpoint data, and generates recovery data for the breakpoint data according to the upgrade package version and the target recovery strategy to obtain breakpoint update data; The platform - side transmits the breakpoint update data to the device upgrade - side according to the target recovery strategy; The device upgrade - side performs breakpoint recovery upgrade according to the breakpoint update data.

5. The method according to claim 4, wherein The breakpoint update data is differential update data or incremental update data. The platform - side generates recovery data for the breakpoint data according to the upgrade package version and the target recovery strategy to obtain breakpoint update data, including: The platform - side obtains the upgrade scheduling strategy of the device upgrade - side according to the target recovery strategy, and the upgrade scheduling strategy includes an incremental update strategy or a differential update strategy; If the upgrade scheduling policy is the incremental update policy, incremental data is generated from the breakpoint data according to the upgrade package version to obtain the incremental update data; or, if the upgrade scheduling policy is the differential update policy, differential data is generated from the breakpoint data according to the upgrade package version to obtain the differential update data.

6. The method according to claim 1, characterized in that The method further includes: The device upgrade end obtains the current software version file and the upgrade package version; According to the upgrade package version, file consistency verification is performed on the current software version file to obtain a file verification result; If the file verification result is that the version files do not fully match, the current software version file is restored.

7. The method according to claim 1, characterized in that The method further includes: The platform end obtains the third device data uploaded by the device monitoring end; The platform end verifies the device status of the second device data according to the third device data to obtain a status verification result, and the status verification result is used to indicate whether the device status of the device upgrade end has changed; If the status verification result is that the device status of the device upgrade end has changed, the platform end adjusts and updates the target recovery strategy according to the third device data to obtain an updated target recovery strategy.

8. An upgrade interruption recovery method for an Internet of Things device, characterized in that, Includes: Obtain first device data, which is uploaded by the device monitoring end, and the first device data includes the first running information, first resource information, and first network connection information of the device upgrade end; Perform upgrade interruption analysis on the first device data to obtain an interruption indication instruction; Obtain second device data and breakpoint data, which are obtained by the device monitoring end according to the interruption indication instruction, and the second device data includes second running information, second resource information, and second network connection information; Generate dynamic recovery measurement for the second device data to obtain the target recovery strategy of the device upgrade end; Perform policy upgrade and recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

9. An upgrade interruption recovery system for an Internet of Things device, characterized in that, Includes a device monitoring end and a platform end; The device monitoring end is used to upload the first device data to the platform end and obtain the second device data and breakpoint data of the device upgrade end according to the interruption indication instruction; the first device data includes the first running information, first resource information, and first network connection information of the device upgrade end; The second device data includes second running information, second resource information, and second network connection information; The platform end is used to perform upgrade interruption analysis on the first device data to obtain an interruption indication instruction; generate a dynamic recovery strategy for the second device data to obtain the target recovery strategy of the device upgrade end; and perform policy upgrade and recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

10. An upgrade interruption recovery system for an Internet of Things device, characterized in that, Includes: A first processing unit for obtaining first device data, which is uploaded by the device monitoring end, and the first device data includes the first running information, first resource information, and first network connection information of the device upgrade end; A second processing unit for performing upgrade interruption analysis on the first device data to obtain an interruption indication instruction; A third processing unit for obtaining second device data and breakpoint data, where the second device data and the breakpoint data are obtained by the device monitoring end according to the interruption indication instruction, and the second device data includes second operation information, second resource information, and second network connection information; A fourth processing unit for dynamically generating a recovery measurement for the second device data to obtain a target recovery strategy for the device upgrade end; A fifth processing unit for performing policy upgrade and recovery on the device upgrade end according to the target recovery strategy and the breakpoint data.

Images