Device instruction issuing method and device, electronic device and computer readable storage medium

Abstract

Embodiments of the present application provide a device instruction issuing method and device, electronic device and computer readable storage medium, relating to the technical field of computer. The method integrates multiple to-be-issued instructions of the same target device into a single integrated instruction, reduces the number of communications with the device, reduces network interaction cost, avoids abnormal conditions such as repeated transmission and response timeout caused by network fluctuations, thereby reducing unnecessary execution failures and retries. At the same time, according to the hierarchical structure to which each device in the target device list belongs, the root level is traversed step by step downwards, and the online target device at the bottom layer is progressively and batch-selected for instruction issuing. When an abnormality occurs in a local device, it can be rolled back in time and prevent the fault from spreading to other branches, preventing large-scale execution failures and effectively controlling the risk impact range.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a device instruction issuing method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Currently, in scenarios involving remote command delivery to a large number of devices, common methods include: pushing commands to multiple target devices via the batch application programming interface (API) provided by the IoT platform; improving delivery efficiency under high concurrency by utilizing memory caching and asynchronous processing mechanisms; or achieving centralized control within a local area by relying on intermediate nodes such as protocol gateways and controllers. These methods can accomplish the task of batch command delivery to a certain extent.

[0003] However, in actual operation, it is difficult to dynamically adjust according to the execution status after the task is started, and there is a lack of process control mechanism based on execution feedback. At the same time, the response capability to deal with abnormal situations is limited, the resource scheduling method is relatively static, and it cannot flexibly adapt to the group management needs of different dimensions, resulting in insufficient overall control flexibility, low resource utilization, and weak fault tolerance. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a device instruction issuing method, apparatus, electronic device and computer-readable storage medium that can improve the efficiency and stability of device instruction execution.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, the present invention provides a method for issuing device commands, the method comprising: Multiple instructions to be issued are generated based on the target policy template, target policy parameters, and target device list selected by the user. Multiple instructions to be issued to the same target device are integrated to obtain an integrated instruction for each target device. Based on the hierarchical structure of each target device in the target device list, the process is traversed from the root level downwards, and any online target device at the lowest level is selected as the instruction issuing device for the current batch; the online target device is a target device that is in an online state. Back up the current effective policy of the instruction issuing device, and issue the corresponding integration instruction to the instruction issuing device; The system determines whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and rolls back instructions for devices with abnormal monitoring indicators according to the corresponding currently effective policy. If it is determined that the integration command should continue to be issued, the next batch of command issuing devices is identified, and the corresponding integration command is continued to be issued to the next batch of command issuing devices; the next batch of command issuing devices is selected from the sibling level of the current batch of command issuing devices.

[0006] In an optional implementation, the step of generating multiple instructions to be issued based on the user-selected target policy template, target policy parameters, and target device list includes: Based on the user-configured instruction type, retrieve the corresponding target policy template from the preset policy template library; Distribute the target policy template to each target device in the target device list; Based on the target policy parameters configured by the user for each of the instruction types, the target policy template distributed to each of the target devices is populated, and device instructions corresponding to each of the target devices are generated. The device instructions are displayed to the user, and the device instructions that the user confirms are effective are identified as the instructions to be issued.

[0007] In an optional implementation, the process of integrating multiple instructions to be issued to the same target device to obtain an integrated instruction for each target device includes: Identify multiple pending instructions belonging to the same target device based on device identification; The multiple instructions to be issued are deduplicated, and the deduplicated instructions are merged according to a preset merging rule to obtain the integrated instructions for each target device.

[0008] In an optional implementation, the step of merging the deduplicated instructions to be issued according to a preset merging rule to obtain the integrated instruction for each target device includes: According to the priority of each instruction type, the deduplicated instructions to be issued are sorted from high to low priority. For instructions to be issued with the same priority, they are sorted according to the order in which the timestamps of the instructions to be issued were generated. The sorted instructions to be issued for each target device are merged to obtain the integrated instructions for each target device.

[0009] In an optional implementation, the monitoring indicators include instruction execution results and device health status; the step of determining whether to continue issuing integration instructions based on the monitoring indicators of the device that issued the instruction includes: If there are still online target devices in the statistical level specified by the user that have not received the integration instruction, it is determined that the integration instruction will continue to be issued. If all online target devices in the user-specified statistical level have received the integration instruction, the number of failures will be counted based on the instruction execution results and device health status of the devices. The failure rate is calculated based on the number of failures and the total number of online target devices in the statistical hierarchy specified by the user. The decision on whether to continue issuing integration instructions is based on the failure rate.

[0010] In an optional implementation, determining whether to continue issuing integration instructions based on the failure rate includes: If the failure rate is less than the low threshold, then it is determined that the integration command will continue to be issued; If the failure rate is not less than the low threshold and the failure rate is not greater than the high threshold, a confirmation request is sent to the user to confirm whether to continue execution. If the user does not choose to continue, it will be determined that no more integration instructions will be issued. If the user chooses to continue, the integration command will continue to be issued. If the failure rate is greater than the high threshold, it is determined that no more integration instructions will be issued.

[0011] In an optional implementation, determining the next batch of instruction issuing devices includes: If the current batch of instruction issuing devices has a sibling level with the same parent, and the online target devices contained in the sibling level with the same parent have not received the integration instruction, then the online target devices contained in any of the sibling levels with the same parent will be determined as the instruction issuing devices for the next batch. If the current batch of instructions is issued by a device that does not have a sibling level with the same parent, or if all online target devices contained in the sibling level with the same parent have received the integration instructions, backtrack to the parent level of the current batch of instructions issued by the device and check if the parent level has a sibling level that has not completed the integration instructions. If there are sibling levels in the parent level that have not completed the integration instructions, the online target device that has not yet received the integration instructions in any sub-level of the sibling level in the parent level will be identified as the instruction issuing device in the next batch. If the parent level does not have any sibling levels that have not completed the integration instructions, recursively trace back to the higher-level ancestor levels, select online target devices that have not received integration instructions as the next batch of instruction-issuing devices, and so on until the root level is reached.

[0012] In a second aspect, the present invention provides a device for issuing device commands, the device comprising: The generation module is used to generate multiple instructions to be issued based on the target policy template, target policy parameters, and target device list selected by the user. The integration module is used to integrate multiple instructions to be issued to the same target device to obtain an integrated instruction for each target device. The instruction issuing module is used to traverse the hierarchical structure of each target device in the target device list from the root level down, selecting any online target device at the lowest level as the instruction issuing device for the current batch; the online target device is a target device that is in an online state; backing up the current effective policy of the instruction issuing device, and issuing the corresponding integration instruction to the instruction issuing device; determining whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and rolling back the instruction issuing devices with abnormal monitoring indicators according to the corresponding current effective policy; if it is determined that to continue issuing integration instructions, then determining the next batch of instruction issuing devices, and continuing to issue the corresponding integration instruction to the next batch of instruction issuing devices; the next batch of instruction issuing devices is selected from the sibling levels of the instruction issuing devices in the current batch.

[0013] Thirdly, the present invention provides an electronic device including a processor and a memory, wherein the memory stores a computer program executable by the processor, and the processor can execute the computer program to implement the device instruction issuing method described in any of the foregoing embodiments.

[0014] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the device instruction issuing method as described in any of the foregoing embodiments.

[0015] Compared to existing technologies, the device instruction issuance method, apparatus, electronic device, and computer-readable storage medium provided in this invention integrate multiple instructions to be issued to the same target device into a single integrated instruction. This reduces the number of communications with the device, lowers network interaction costs, and avoids abnormal situations such as repeated transmissions and response timeouts caused by network fluctuations, thereby reducing unnecessary execution failures and retries. Simultaneously, based on the hierarchical structure of each device in the target device list, the method progressively selects the lowest-level online target devices for instruction issuance by traversing downwards from the root level. When an anomaly occurs in a local device, it can promptly roll back and prevent the fault from spreading to other branches, preventing large-scale execution failures and effectively controlling the scope of risk impact.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This diagram illustrates a flowchart of a device instruction issuance method provided in an embodiment of the present invention.

[0019] Figure 2 This diagram illustrates another flowchart of the device instruction issuance method provided in an embodiment of the present invention.

[0020] Figure 3 A block diagram of a device command issuing apparatus provided in an embodiment of the present invention is shown.

[0021] Figure 4 A block diagram of an electronic device provided in an embodiment of the present invention is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0023] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0024] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0025] The inventors discovered that existing IoT platform API batch distribution relies on directly calling the platform interface to push instructions. Configuration templates and script distribution achieve a certain degree of parameterization through variable filling. High-performance instruction management systems improve concurrency capabilities through memory caching and asynchronous processing. Protocol gateways and local batch control achieve multi-device management through centralized gateways.

[0026] However, these solutions generally suffer from a lack of automated control, failing to automatically pause, advance, or roll back tasks upon failure. Furthermore, they do not incorporate device feedback and business health into execution decisions, resulting in a lack of closed-loop control. Additionally, they are inefficient in policy distribution, requiring the same device to receive policies multiple times without the ability to merge or avoid duplicate or conflicting policies. Moreover, they do not support fine-grained batch control based on multiple dimensions such as business unit, geographical location, and device model, making it difficult to meet the needs for flexibility, security, and intelligent management in large-scale equipment operation and maintenance.

[0027] Based on this, embodiments of the present invention provide a device instruction issuance method, apparatus, electronic device, and computer-readable storage medium. This method integrates multiple instructions to be issued to the same target device into a single integrated instruction, reducing the number of communications with the device, lowering network interaction costs, and avoiding abnormal situations such as duplicate transmissions and response timeouts caused by network fluctuations, thereby reducing unnecessary execution failures and retries. Simultaneously, according to the hierarchical structure of each device in the target device list, it progressively selects the lowest-level online target devices for instruction issuance by traversing downwards from the root level. When an anomaly occurs in a local device, it can promptly roll back and prevent the fault from spreading to other branches, preventing large-scale execution failures and effectively controlling the scope of risk impact.

[0028] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0029] Please refer to Figure 1 , Figure 1 This illustration shows a flowchart of a device command issuance method provided by an embodiment of the present invention. The device command issuance method is applied to electronic devices and includes the following steps: Step S10: Generate multiple instructions to be issued based on the target policy template, target policy parameters, and target device list selected by the user.

[0030] In this embodiment of the invention, the transformation from abstract policy definitions to concrete executable instructions is achieved by structurally parsing and instantiating the policy elements input by the user. Specifically, based on the target policy template and target policy parameters specified by the user, one or more corresponding instructions to be issued are generated for each target device in the target device list. Each instruction to be issued is associated with a specific target device, instruction type, and parameter value.

[0031] It should be understood that a user can configure multiple target devices, or configure the same target device multiple times. Similarly, the same target device can be configured by multiple users, depending on the specific application scenario, and this invention does not limit this.

[0032] Step S20: Integrate multiple instructions to be issued for the same target device to obtain an integrated instruction for each target device.

[0033] In scenarios involving the batch issuance of device commands, especially in large-scale IoT device management environments, the same target device may be designated as the execution target by multiple users or multiple policy tasks simultaneously, resulting in the generation of multiple commands to be issued for that device. If these commands are not pre-processed and are executed concurrently, it is easy to cause problems such as duplicate operations, resource contention, and even configuration conflicts, thereby affecting the stability and overall performance of device operation. Therefore, it is necessary to centrally integrate multiple commands belonging to the same target device before the actual issuance of commands to eliminate redundancy, resolve conflicts, and form a unique, orderly, and executable integrated command.

[0034] In this embodiment of the invention, instruction integration logic is introduced to address the execution conflicts and resource waste caused by multiple strategies being applied concurrently to a single device. First, all pending instructions belonging to the same target device are identified, and all pending instructions are processed uniformly to eliminate redundancy and coordinate the execution order of different instructions, ultimately forming an integrated instruction suitable for the target device.

[0035] The integrated instruction, as an atomic execution unit, contains all the change operations that need to be applied to the target device, thereby avoiding the performance loss and state inconsistency risks caused by multiple independent communications and effectively improving instruction transmission efficiency.

[0036] Step S30: Based on the hierarchical structure of each target device in the target device list, traverse downwards from the root level and select any online target device at the lowest level as the instruction issuing device for the current batch; an online target device is a target device that is in an online state.

[0037] In this embodiment of the invention, by introducing a hierarchical progressive device selection mechanism, orderly control of the instruction issuance path is achieved, thereby supporting a progressive release mode that advances step by step according to the organizational structure. This enables spatial granular control and risk isolation of instruction issuance, ensuring that the change process has risk isolation capabilities.

[0038] Specifically, the hierarchical structure information of the target device is obtained, which consists of multiple nested levels. Starting from the root level, the process explores downwards in a depth-first or breadth-first manner until the lowest level containing the actual device is located. From one of the lowest levels, the target devices that are currently online are selected as the devices for issuing instructions in the current batch.

[0039] In one possible implementation, taking equipment management in a power system as an example, the target devices in the target equipment list are divided into a hierarchical structure according to their organizational or functional attributes. This hierarchical structure can specifically include multiple levels, such as departments, transmission levels, and lines, where each line contains at least one pole, and each pole is equipped with a unique corresponding monitoring device. Since there is a one-to-one correspondence between poles and monitoring devices, from the logical perspective of command issuance, the monitoring device can be regarded as directly subordinate to the line.

[0040] Therefore, the transmission line, as the level that directly carries the actual physical equipment, constitutes the bottom layer in the hierarchical structure. Under this setting, the department, as the highest management unit, corresponds to the first level (i.e., the root level), the transmission level, as the intermediate classification dimension, corresponds to the second level, and the transmission line, as the level to which the end execution unit belongs, corresponds to the third level (i.e., the bottom layer).

[0041] It should be understood that issuing instructions by traversing the hierarchical structure from the root level downwards ensures that the issuing behavior has clear topological path dependencies, making the scope of the change's impact controllable. During this process, whether a device is included in the current batch depends on its network reachability and the traversal order of its layer.

[0042] It should be noted that target devices periodically report their operational status to electronic devices via heartbeat mechanisms or long-term connections to maintain their online status. This status reporting behavior constitutes the primary basis for determining whether a target device is online.

[0043] If an electronic device does not receive a heartbeat from the target device, the target device that has not received a heartbeat is considered an offline target device. The integration command for the offline target device will be cached in a pending delivery queue. When the electronic device receives a heartbeat from the offline target device, it sets the corresponding online identifier and queries the pending delivery queue. If the integration command for the target device exists in the pending delivery queue, the integration command will be sent to the newly online target device.

[0044] The heartbeat-based delivery mechanism offers significant advantages in large-scale distributed deployment scenarios. Especially in unstable network environments or when terminal devices are intermittently offline, as long as the device reconnects and sends a heartbeat in a subsequent communication window, it can immediately retrieve the backlog of integration instructions from the queue. This avoids operational failures caused by momentary network outages and effectively improves the delivery success rate of policy updates under complex network conditions.

[0045] Step S40: The backup instruction is sent to the current effective policy of the device, and the corresponding integration instruction is sent to the instruction sending device.

[0046] In this embodiment of the invention, before sending an integration command to any command-issuing device, the currently running policy configuration content (i.e., the currently effective policy) of that device is proactively obtained and completely saved to form an independent backup record. This backup is bound to the integration command to be executed for subsequent traceability. Only after the backup is completed is the integration command officially pushed to the device. Therefore, during the execution of the above steps, each policy change is accompanied by the implementation of pre-emptive protection measures to support fault recovery, significantly enhancing fault tolerance and operational reversibility.

[0047] Step S50: Determine whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and roll back the instruction issuing device with abnormal monitoring indicators according to the corresponding currently effective policy.

[0048] In this embodiment of the invention, the monitoring quality of the collected command-issuing devices is comprehensively evaluated to determine whether the execution effect of the current batch meets expectations. If an anomaly is detected in the command-issuing device, such as execution failure, response timeout, or sudden increase in system load, a rollback mechanism is immediately triggered. The previously saved currently effective policy is used to restore the configuration of the device, bringing it back to its stable state before the change. By introducing dynamic monitoring and anomaly response mechanisms, a closed-loop control logic based on real-time feedback is achieved, effectively preventing local faults from spreading into global problems.

[0049] In step S60, if it is determined that the integration command should continue to be issued, the next batch of command issuing devices is determined, and the corresponding integration command is issued to the next batch of command issuing devices; the next batch of command issuing devices is selected from the sibling level of the current batch of command issuing devices.

[0050] In this embodiment of the invention, when the current batch of devices has completed execution and been evaluated and confirmed to be ready to continue, the system does not randomly select the next group of devices. Instead, it strictly follows the sibling relationships in the hierarchical structure, selecting the next batch of instruction-issuing devices from the sibling levels of the current batch of instruction-issuing devices. If there are devices that meet the conditions in the parent sibling levels, then the device is selected from those sibling levels. If there are no devices that meet the conditions in the parent sibling levels, then the device is selected from other sibling levels. Once the hierarchical structure has been traversed, the device instruction issuance is completed. This design ensures that the change process unfolds gradually along the preset organizational boundaries, avoiding the uncontrollable risks caused by jumping across levels.

[0051] In summary, the device instruction issuance method provided in this embodiment of the invention integrates multiple instructions to be issued to the same target device into a single integrated instruction, reducing the number of communications with the device, lowering network interaction costs, and avoiding abnormal situations such as duplicate transmissions and response timeouts caused by network fluctuations, thereby reducing unnecessary execution failures and retries. Simultaneously, based on the hierarchical structure of each device in the target device list, the method progressively selects the lowest-level online target devices for instruction issuance by traversing downwards from the root level. This allows for timely rollback and prevention of the fault from spreading to other branches when an anomaly occurs in a local device, preventing large-scale execution failures and effectively controlling the scope of risk impact.

[0052] It should be understood that this method has a clear operation path and a stable control mechanism, and can be widely used in scenarios such as IoT platforms and data center operations and maintenance where there is a large demand for hierarchical management of devices and batch command issuance, making it highly practical for industrial applications.

[0053] Alternatively, one possible implementation method for generating instructions to be issued is provided below. Figure 1 The sub-steps of step S10 may include: Step S100: Based on the instruction type configured by the user, obtain the corresponding target policy template from the preset policy template library.

[0054] In this embodiment of the invention, by logically separating the policy template, target device, and execution parameters (i.e., policy parameters) and dynamically combining them at runtime, standardized definition and flexible reuse of multiple types of device instructions are achieved. This process relies on a preset policy template library, which stores various abstract instruction sets (i.e., policy templates). Each set corresponds to device control requirements for a specific instruction type, such as firmware upgrades, configuration changes, or operating mode switching.

[0055] Users configure command types according to the actual operation and maintenance tasks required, and select target policy templates that match their intentions from the preset policy template library based on the user-configured command types. In addition to configuring command types, users may also configure the planned policy name, execution method (including immediate execution or scheduled execution), and execution time, which are not limited in this invention.

[0056] Step S110: Distribute the target policy template to each target device in the target device list.

[0057] In this embodiment of the invention, to adapt the selected target strategy template to specific management objects, it needs to be distributed to each target device in the target device list specified by the user. The target device list is constructed through a device selection interface, which supports multiple device filtering methods, including importing static device lists, matching based on device attributes (such as model, version, and geographical location), and dynamic grouping based on organizational structure (such as affiliated institution and department level).

[0058] The resulting list of target devices defines the scope of this policy. The target policy template is bound to each target device in the target device list. Clicking on the policy details allows you to view the basic information of the policy. A menu page displays the list of target devices to which the target policy template is distributed, ensuring that subsequent command generation has a clear target.

[0059] Step S120: Based on the target policy parameters configured by the user for each instruction type, fill in the target policy template distributed to each target device and generate the device instruction corresponding to each target device.

[0060] In this embodiment of the invention, since the control parameters corresponding to different instruction types differ, the parameter filling interface template associated with the currently selected instruction type is dynamically loaded based on the enumeration value of that instruction type. The parameter filling interface is generated at runtime, and its structure and input items are rendered according to the parameter requirements defined in the target strategy template, ensuring that the user only needs to fill in the valid fields related to the current strategy.

[0061] Users configure corresponding target policy parameters for each type of instruction. These parameters reflect the specific values ​​or configuration options required by the device when executing the instruction. Then, these configured target policy parameters are used to populate the target policy templates distributed to each target device, generating device instructions with complete execution information one by one. For example, if the policy is to issue shutdown instructions to 1000 devices, the target policy template for each target device is populated according to the user-configured target policy parameters, generating and caching one thousand device instructions.

[0062] Step S130: Display the instructions of each device to the user, and determine the device instructions that the user confirms are effective as instructions to be issued.

[0063] In this embodiment of the invention, before the strategy is executed, all generated device instructions are presented on a strategy confirmation interface. The strategy confirmation interface centrally displays complete summary information of the strategy task, including but not limited to the target strategy template used, the target device list, the specific values ​​of each target strategy parameter, the execution method and the planned execution time. This aims to introduce a manual review process to improve the security of the operation.

[0064] Only after receiving a confirmation command from the user is the aforementioned device command officially designated as a pending command, and the subsequent integration and distribution process begins. If the user actively issues a cancellation command, or fails to respond within the preset timeout period, the batch of device commands remains in an inactive state, preventing large-scale anomalies caused by misoperation. This mechanism not only realizes a "define once, reuse many times" strategy management model, but also enhances the controllability and reliability of large-scale device command distribution through step-by-step guidance and final confirmation control.

[0065] It should be understood that by logically separating the strategy definition, target device specification, and parameter configuration, functional decoupling is achieved, thereby improving the flexibility and reusability of the device command issuance process. This makes the strategy definition reusable, the target specification adjustable, and the parameter configuration dynamically updated, significantly enhancing the adaptability to diverse command issuance needs.

[0066] Alternatively, regarding how to integrate multiple instructions for the same target device, the following is a possible implementation method. Figure 1 The sub-steps of step S20 may include: Step S200: Identify multiple pending instructions belonging to the same target device based on the device identifier.

[0067] During the instruction integration phase, all instructions to be processed are first grouped and aggregated according to the device identification information carried in each instruction to be issued, so that all instructions sent to the same target device are gathered into the same processing unit for subsequent instruction integration.

[0068] Step S210: Deduplication is performed on multiple instructions to be sent, and the deduplicated instructions to be sent are merged according to a preset merging rule to obtain the integrated instructions for each target device.

[0069] In this embodiment of the invention, deduplication is performed on multiple instructions to be issued belonging to the same target device. Here, "deduplication" does not simply refer to removing completely identical instruction copies, but rather encompasses logical equivalence judgment. That is, when two or more instructions are substantially identical in instruction type, parameter content, and expected behavior, they are still considered duplicate instructions even if their generation time or source is different.

[0070] For example, suppose user A creates a device upgrade command for device code ST0011 and submits it to the distribution queue; simultaneously, user B independently initiates another device upgrade command of the same type, also specifying ST0011 as the target device. Although these two commands are initiated by different entities and may have different task tags, their core operational intent is the same. Figure 1 At this point, by comparing the semantic features of the instruction with the target parameters, the deduplication process identifies that the two have overlapping functions, thus retaining one valid instruction and avoiding the repeated application of the same change action to the same device.

[0071] After deduplication is completed, the remaining instructions are further merged according to preset merging rules. It should be noted that the "preset merging rules" here are a pre-configured strategy decision-making mechanism used to solve the problem of consistency in execution order and results when multiple instructions of different types or with different priorities act on the same device.

[0072] As can be seen, the embodiments of the present invention perform clustering identification, deduplication, and orderly merging according to preset merging rules on multiple instructions to be issued to the same target device based on device identifiers. This not only significantly reduces the communication frequency and system resource consumption caused by repeatedly issuing instructions to the device, but also reduces the risk of state oscillation caused by frequent instruction processing by the device, thereby improving overall execution efficiency and resource utilization. By introducing an intelligent strategy integration mechanism, the problem of state inconsistency caused by the superposition of multiple strategies is solved, enhancing the coherence, controllability, and automation level of the device management process, thereby achieving efficient, reliable, and intelligent control of device instructions in complex environments.

[0073] Optionally, regarding how to merge multiple instructions for the same target device, the following is a possible implementation. The sub-steps of step S210 may include: Step S210-1: Deduplication is performed on multiple instructions to be issued.

[0074] In this embodiment of the invention, multiple instructions to be issued that are of the same type and execution time and belong to the same target device are deduplicated. For example, in the operation and maintenance management process after the equipment is put into operation, it is often necessary to batch set configuration parameters such as capture time and recording time period for a large number of devices according to business needs. Such operations often involve configuring dozens or even hundreds of time points or intervals for a single device, with a large amount of data and frequent operations.

[0075] Since multiple users may simultaneously initiate configuration tasks for the same device, for example, user A and user B may submit capture time policies containing overlapping content to the same target device. If left unchecked, this will cause the platform to repeatedly issue essentially the same instructions, resulting in a waste of network bandwidth, device processing resources, and platform scheduling capabilities.

[0076] To avoid such redundancy, a deduplication mechanism is introduced during the instruction integration phase. By analyzing the semantics and target of each instruction to be issued, duplicate instructions targeting the same device are identified before execution. If an identical or functionally equivalent instruction already exists, subsequent duplicates are removed, ensuring that identical instruction content is executed only once. For instructions that have been merged, a success response is still sent to the original initiator (e.g., user A and user B) after execution, ensuring the integrity of each user's operation process.

[0077] Step S210-2: Sort the deduplicated instructions to be sent from high to low priority according to the priority corresponding to each instruction type.

[0078] In this embodiment of the invention, after deduplication, the instruction sorting and merging process begins. First, based on the instruction type associated with each instruction to be issued and its preset priority, all remaining instructions are sorted in descending order. The priority is used to characterize the importance or urgency of different instruction types in the business logic. For example, an instruction like "capture short video" might be configured with a higher priority than "device restart" to ensure that critical business operations are not interrupted.

[0079] Step S210-3: For instructions to be issued with the same priority, sort them according to the order in which the timestamps of the instructions to be issued were generated.

[0080] In this embodiment of the invention, when multiple instructions have the same priority, they are further sorted according to the order in which their timestamps were generated. It should be noted that the timestamp refers to the time stamp recorded at the creation time of each device instruction, used to reflect the temporal sequence of instruction generation. By introducing a time dimension as a secondary sorting criterion, the historical continuity of operations can be maintained when priorities are the same, avoiding semantic ambiguity or execution chaos caused by disordered merging.

[0081] Step S210-4: Merge the sorted instructions to be sent from each target device to obtain the integrated instructions for each target device.

[0082] In this embodiment of the invention, the sorted instructions to be issued are encapsulated to form an integrated instruction for the target device. The integrated instruction not only contains the content of the original multiple instructions, but also embeds execution order information determined by priority and timestamp, enabling the device to complete various operations sequentially according to predetermined logic.

[0083] For example, in a typical application scenario of device upgrades, the complete operation process usually involves multiple sequential steps: first, querying the device's current version number to confirm the initial state; then, issuing the upgrade command and monitoring its execution progress; and finally, querying the new version number to verify the result after the upgrade is complete. If the traditional method is used, each of these steps needs to be completed through multiple independent communications, leading to frequent interactions between the platform and the device, increasing network load. Furthermore, if any step fails, a compensation mechanism must be introduced for retrying, resulting in high levels of re-verification and operational risks.

[0084] If the device instruction delivery method provided in the embodiments of the present invention is adopted, in the instruction integration stage, multiple instructions to be delivered to the same target device are deduplicated, and sorted according to the priority and generation timestamp corresponding to their instruction types. The sorted instructions are then merged into one integrated instruction and delivered to the target device at once.

[0085] After receiving the integration command, the device executes its internal sub-operations sequentially and reports the final execution result upon completion. This achieves atomicity throughout the process, effectively reducing communication frequency and preventing intermediate state loss and redundant updates. In scenarios involving large-scale device upgrades, this significantly reduces scheduling pressure, improves task execution efficiency and reliability, and saves considerable time.

[0086] Optionally, monitoring indicators include command execution results and device health status. Regarding how to determine whether to continue issuing integration commands, one possible implementation method is provided below. Figure 1 The sub-steps of step S50 may include: In step S500, if there are still online target devices in the statistical level specified by the user that have not received the integration instruction, it is determined that the integration instruction will continue to be issued.

[0087] In this embodiment of the invention, if there are still online target devices in the statistical level specified by the user that have not received the integration instruction, it is determined that the task has not been completed, and the integration instruction is continued to be issued to advance the execution scope.

[0088] Step S510: If all online target devices in the user-specified statistical level have received the integration instruction, the number of failures is counted based on the instruction execution results and device health status of the devices.

[0089] In this embodiment of the invention, if all online target devices within the statistical level have received the instruction, the process proceeds to the result statistics stage. Based on the instruction execution results and device health status reported by each instruction-issuing device, failure instances are identified, and the number of failures is counted.

[0090] The execution results of the instructions include successful execution and execution failure. Execution failure includes, but is not limited to, explicit error situations such as device offline, device execution timeout, parameter error, device incompatibility, and sudden abnormality. All of these are actively reported by the device after executing the integrated instructions, and then reported to the user terminal after being summarized by the electronic device.

[0091] Based on this, the status of all issued tasks is visualized globally by combining real-time monitoring dashboards, presenting monitoring indicators such as device health status (e.g., device online rate) and command execution results (e.g., strategy execution success rate), enabling operators to intuitively grasp the progress of command execution and the overall health of the system, and realizing closed-loop monitoring from data collection to status visualization.

[0092] If the instruction execution result indicates failure, the failure count is increased. If the instruction execution result indicates success, the device health status is checked to determine if the target device can operate normally. If the instruction execution result is successful but the device health status indicates that the target device cannot operate normally, the failure count is increased.

[0093] Step S520: Calculate the failure rate based on the number of failures and the total number of online target devices in the statistical tier specified by the user.

[0094] Step S530: Determine whether to continue issuing integration instructions based on the failure rate.

[0095] In this embodiment of the invention, the failure rate is determined by the ratio of the number of failures to the total number of online target devices in the statistical level specified by the user. A graded response mechanism is established by setting a threshold range. The comparison result of the failure rate and preset conditions is used to determine whether the task continues. This realizes the dynamic control capability based on quantitative indicators and improves the security and controllability of large-scale equipment operation and maintenance.

[0096] Optionally, regarding how to use the failure rate to determine whether to continue issuing integration instructions, the following is a possible implementation method. The sub-steps of step S530 may include: Step S530-1: If the failure rate is less than the low threshold, then it is determined to continue issuing integration instructions.

[0097] In this embodiment of the invention, if the failure rate is less than a low threshold (e.g., 5%), the number of failures in the current batch is considered to be within an acceptable range and is regarded as normal fluctuation, without needing to interrupt the task process. The results of the failures are recorded, and a rollback operation is performed on the failed target devices according to the currently effective backup strategy. Integration instructions are then sent to the next batch of instruction-issuing devices to ensure efficient task progress.

[0098] Step S530-2: If the failure rate is not less than the low threshold and not greater than the high threshold, send a confirmation request to the user to confirm whether to continue execution.

[0099] In this embodiment of the invention, when the failure rate enters the middle range consisting of a low threshold and a high threshold, it indicates that the execution anomaly has exceeded the normal range but has not yet reached a severe level. The task will be paused, and an alarm message will be sent to the user (e.g., an administrator) requesting manual intervention. At this time, the administrator assesses the situation and makes a decision.

[0100] For example, if the low threshold is 5% and the high threshold is 10%, and 1000 devices execute the integration command, and 60 target devices fail to execute the integration command, the calculated failure rate is 6%, and a confirmation request needs to be sent to the user to confirm whether to continue execution.

[0101] In step S530-3, if the user does not choose to continue, it is determined that no further integration instructions will be issued.

[0102] In step S530-4, if the user chooses to continue execution, it is determined that the integration command will continue to be issued.

[0103] In this embodiment of the invention, if the user chooses to terminate execution, or if the user does not choose to continue execution, it is determined that no further integration instructions will be issued to prevent the risk from escalating. If the user chooses to continue execution, it is determined that further integration instructions will be issued.

[0104] In step S530-5, if the failure rate is greater than the high threshold, it is determined that no more integration instructions will be issued.

[0105] In this embodiment of the invention, if the failure rate is greater than a high threshold, a high-risk scenario occurs, indicating that there may be serious configuration errors or platform anomalies. The task is determined to be uncontrollable, and the entire distribution process is immediately terminated. A batch rollback mechanism is triggered to uniformly restore all target devices that have received the integration instructions (regardless of whether the execution was successful or not) to the effective policy before the change (i.e., the current effective policy), thereby ensuring overall stability and business continuity.

[0106] It should be noted that, when the failure rate is not higher than the high threshold, and a rollback operation is performed on the command-issuing device with abnormal monitoring indicators, each batch of abnormal devices can be rolled back independently, or all abnormal devices can be rolled back uniformly after all integration commands have been executed. This invention does not limit the scope of this approach.

[0107] As can be seen, this embodiment of the invention dynamically determines whether to continue issuing integration instructions based on the comparison results of the failure rate with preset low and high thresholds, thereby achieving hierarchical risk control of the instruction issuance process; when the failure rate is below the low threshold, it automatically continues to issue instructions to ensure execution efficiency; when the failure rate is in the middle range, a manual confirmation mechanism is introduced to balance automation and security; when the failure rate exceeds the high threshold, the issuance is terminated to effectively prevent the spread of faults and improve the stability and controllability of the device policy update process.

[0108] Optionally, regarding how to determine the devices issuing the next batch of instructions, the following is one possible implementation. Please refer to... Figure 2 , Figure 1 The sub-steps of step S60 may include: Step S600: If the instruction issuing device of the current batch has a sibling level with the same parent, and the online target device contained in the sibling level with the same parent has not received the integration instruction, then the online target device contained in any sibling level with the same parent is determined as the instruction issuing device of the next batch.

[0109] In this embodiment of the invention, it is assumed that the target devices are managed according to a hierarchical structure of department, transmission level, and line. The target devices are installed on their respective towers, with one device installed on each tower, meaning that the target devices are all located in the lowest-level lines. The instruction issuance does not cover all target devices at once, but rather traverses downwards from the root level (i.e., department), prioritizing the selection of one of the lowest-level online target devices as the instruction issuance device for the current batch.

[0110] For example, it is necessary to upgrade all the equipment in Department A. Department A has power transmission levels of 110KV, 220KV, and 500KV. The 110KV lines include Line 1, Line 2, and Line 3; the 220KV lines include Line 4 and Line 5; and the 500KV lines include Line 6. Each line has a different number of poles and towers. Assume that all equipment is online.

[0111] Assume that equipment under line 1 of the 110kV transmission line in Department A is selected as the command issuing equipment for the current batch. If all command issuing equipment in the current batch has executed the complete integration command and it is determined that the integration command will continue to be issued, then it is determined whether line 1 of the 110kV transmission line in Department A has a sibling level with the same parent. Since the 110kV transmission line in Department A also includes line 2 and line 3, then equipment under line 2 of the 110kV transmission line in Department A is selected as the command issuing equipment for the next batch. If all equipment under line 2 of the 110kV transmission line in Department A has executed the complete integration command, then equipment under line 3 of the 110kV transmission line in Department A is selected as the command issuing equipment for the third batch, thus achieving horizontal expansion under the same parent node.

[0112] It should be understood that when selecting the first batch of equipment to be deployed, any transmission level can be selected from 110KV, 220KV, and 500KV as the corresponding transmission level for the current batch. Furthermore, equipment under any line in the current batch can be selected as the first batch of equipment to be deployed.

[0113] It should be noted that if the number of devices contained in the lowest layer is too large, they can be split into multiple batches for processing, and this invention does not limit this.

[0114] Step S610: If the layer where the instruction issuing device of the current batch is located does not have a sibling layer with the same parent, or if all online target devices contained in the sibling layer with the same parent have received the integration instruction, backtrack to the parent layer where the instruction issuing device of the current batch is located, and check if there is a sibling layer in the parent layer that has not completed the integration instruction.

[0115] In this embodiment of the invention, if the target equipment under the three lines of the 110KV transmission level has completed the corresponding integration instructions, it is determined whether there is a sibling level of the 110KV transmission level with incomplete instructions, and it is checked whether there are other sibling branches of the parent level with incomplete integration instructions.

[0116] For example, after completing the tower equipment of all lines under the entire 110KV transmission level, the process traces back to the previous level (i.e., the transmission level) node and identifies two unprocessed sibling branches, 220KV and 500KV, thereby triggering the transfer to these new branches.

[0117] Step S620: If there is a sibling level in the parent level that has not completed the integration instruction, determine the online target device that has not yet received the integration instruction in any sub-level of the sibling level in the parent level that has not completed the integration instruction as the instruction issuing device for the next batch.

[0118] In this embodiment of the invention, since the equipment included in transmission levels 220kV and 500kV has not yet completed integration instructions, transmission level 220kV or 500kV is determined as the next batch of transmission levels to be upgraded. Assuming that transmission level 220kV is selected as the next batch of transmission levels to be upgraded, the equipment under line 4 or line 5 of transmission level 220kV is obtained as the next batch of instruction issuing equipment, continuing the top-down and left-to-right traversal logic to ensure that the overall execution order conforms to the natural division of the organizational structure.

[0119] Step S630: If the parent level does not have any sibling levels that have not completed the integration instructions, recursively trace back to the higher-level ancestor levels, select online target devices that have not received integration instructions as the next batch of instruction issuing devices, until the root level is reached.

[0120] In this embodiment of the invention, if all equipment under all power transmission levels has completed the integration instructions, the higher-level ancestor level is searched, that is, the root level (Department A) is found, so as to ensure that even if some paths end prematurely in a complex nested structure, the next target position to be executed in the global scope can still be located, avoiding process interruption or omission.

[0121] As can be seen, this embodiment of the invention, through predefined traversal rules and backtracking logic, ensures that the instruction issuance process strictly follows the preset organizational hierarchy. Based on phased evaluation using monitoring indicators, it achieves phased rollout of change operations and minimizes the scope of anomalies. If a branch fails, its propagation can be terminated at the current level, and the original effective strategy can be restored using the "abstention and rollback" mechanism, ensuring that other branches are not disturbed and comprehensively improving the security and controllability of large-scale equipment management.

[0122] Based on the same inventive concept, the basic principle and technical effects of the device instruction issuing device provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments.

[0123] Please refer to Figure 3 , Figure 3 This is a block diagram of a device instruction issuing device 400 provided in an embodiment of the present invention. The device instruction issuing device 400 includes a generation module 410, an integration module 420, and an instruction issuing module 430.

[0124] The generation module 410 is used to generate multiple instructions to be issued based on the target policy template, target policy parameters, and target device list selected by the user. The integration module 420 is used to integrate multiple instructions to be issued to the same target device to obtain the integrated instructions for each target device; The instruction issuing module 430 is used to traverse the hierarchical structure of each target device in the target device list from the root level down, and select any online target device at the lowest level as the instruction issuing device for the current batch; an online target device is a target device that is in an online state; back up the current effective policy of the instruction issuing device and issue the corresponding integration instruction to the instruction issuing device; determine whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and roll back the instruction issuing device with abnormal monitoring indicators according to the corresponding current effective policy; if it is determined that to continue issuing integration instructions, then determine the instruction issuing device for the next batch, and continue to issue the corresponding integration instruction to the instruction issuing device for the next batch; the instruction issuing device for the next batch is selected from the sibling level of the instruction issuing device in the current batch.

[0125] In summary, the device instruction issuing apparatus provided in this embodiment of the invention integrates multiple instructions to be issued to the same target device into a single integrated instruction, reducing the number of communications with the device, lowering network interaction costs, and avoiding abnormal situations such as repeated transmissions and response timeouts caused by network fluctuations, thereby reducing unnecessary execution failures and retries. Simultaneously, based on the hierarchical structure of each device in the target device list, it progressively selects the lowest-level online target devices for instruction issuance by traversing downwards from the root level. When an anomaly occurs in a local device, it can promptly roll back and prevent the fault from spreading to other branches, preventing large-scale execution failures and effectively controlling the scope of risk impact.

[0126] Optionally, the generation module 410 is specifically used to: obtain the corresponding target policy template from the preset policy template library according to the instruction type configured by the user; distribute the target policy template to each target device in the target device list; fill the target policy template distributed to each target device according to the target policy parameters configured by the user for each instruction type, generate the device instruction corresponding to each target device; display each device instruction to the user, and determine the device instruction confirmed by the user as the instruction to be issued.

[0127] Optionally, the integration module 420 is specifically used to identify multiple instructions to be issued that belong to the same target device based on the device identifier; to perform deduplication processing on the multiple instructions to be issued, and to merge the deduplicated instructions to be issued according to a preset merging rule to obtain the integrated instruction for each target device.

[0128] Optionally, the integration module 420 is specifically used to sort the deduplicated instructions to be issued from high to low priority according to the priority corresponding to each instruction type; for instructions to be issued with the same priority, sort them according to the order of their generation timestamps; and merge the sorted instructions to be issued for each target device to obtain the integrated instructions for each target device.

[0129] Optionally, the monitoring indicators include command execution results and device health status. The command issuance module 430 is specifically used to determine whether to continue issuing integration commands if there are still online target devices in the user-specified statistical level that have not received the integration command; if all online target devices in the user-specified statistical level have received the integration command, it counts the number of failures based on the command execution results and device health status of the issuing device; calculates the failure rate based on the number of failures and the total number of online target devices in the user-specified statistical level; and determines whether to continue issuing integration commands based on the failure rate.

[0130] Optionally, the instruction issuing module 430 is specifically used to determine whether to continue issuing integration instructions if the failure rate is less than a low threshold; to send a confirmation request to the user to confirm whether to continue execution if the failure rate is not less than the low threshold and not greater than the high threshold; to determine whether to stop issuing integration instructions if the user does not choose to continue execution; to determine whether to continue issuing integration instructions if the user chooses to continue execution; and to determine whether to stop issuing integration instructions if the failure rate is greater than the high threshold.

[0131] Optionally, the instruction issuing module 430 is specifically used to determine any online target device contained in any of the sibling levels of the same parent as the instruction issuing device in the current batch, if the current batch of instruction issuing devices has a sibling level with the same parent, and the online target devices contained in the sibling level with the same parent have not received the integration instruction; if the current batch of instruction issuing devices has no sibling level with the same parent, or the online target devices contained in the sibling level with the same parent have all received the integration instruction, it traces back to the parent level of the current batch of instruction issuing devices to check if there is a sibling level in the parent level that has not completed the integration instruction.

[0132] If the parent level has sibling levels that have not completed the integration instructions, the online target devices that have not yet received the integration instructions in any child level of the sibling level that has not completed the integration instructions are identified as the instruction issuing devices for the next batch. If the parent level does not have sibling levels that have not completed the integration instructions, the process recursively backtracks to the higher-level ancestor levels and selects online target devices that have not received the integration instructions as the instruction issuing devices for the next batch, until the root level is reached.

[0133] Please refer to Figure 4 This is a block diagram illustrating an electronic device 500 provided in an embodiment of the present invention. The electronic device 500 includes, but is not limited to, a personal computer (PC), a personal digital assistant (PDA), a laptop computer, a tablet computer, and a server. The electronic device 500 includes a memory 510, a processor 520, a communication module 530, a policy management center 540, and a dispatch scheduler 550. The memory 510, processor 520, communication module 530, policy management center 540, and dispatch scheduler 550 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0134] The memory 510 is used to store programs or data. The memory 510 may be, but is not limited to, random access memory, read-only memory, programmable read-only memory, erasable read-only memory, electrically erasable read-only memory, etc.

[0135] The processor 520 is used to read / write data or programs stored in the memory 510 and perform corresponding functions. For example, when a computer program stored in the memory 510 is executed by the processor 520, it can drive the dispatch scheduler 550 to implement the device instruction dispatching methods disclosed in the above embodiments.

[0136] The communication module 530 is used to establish a communication connection between the electronic device 500 and other communication terminals via a network, and to send and receive data via the network.

[0137] The policy management center 540 is used to manage the preset policy template library so that the dispatcher 550 can obtain policy templates from the preset policy template library.

[0138] It should be understood that, Figure 4 The structure shown is only a schematic diagram of the electronic device 500. The electronic device 500 may also include components that are larger than... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0139] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor 520, implements the device instruction issuing method disclosed in the above embodiments.

[0140] This invention also provides a program product that, when executed by the processor 520, implements the device instruction issuing method disclosed in the above embodiments.

[0141] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0142] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0143] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0144] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for issuing device commands, characterized in that, The method includes: Multiple instructions to be issued are generated based on the target policy template, target policy parameters, and target device list selected by the user. Multiple instructions to be issued to the same target device are integrated to obtain an integrated instruction for each target device. Based on the hierarchical structure of each target device in the target device list, the process is traversed from the root level downwards, and any online target device at the lowest level is selected as the instruction issuing device for the current batch; the online target device is a target device that is in an online state. Back up the current effective policy of the instruction issuing device, and issue the corresponding integration instruction to the instruction issuing device; The system determines whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and rolls back instructions for devices with abnormal monitoring indicators according to the corresponding currently effective policy. If it is determined that the integration command should continue to be issued, then the next batch of command issuing devices is determined, and the corresponding integration command is continued to be issued to the next batch of command issuing devices; the next batch of command issuing devices is selected from the sibling level of the current batch of command issuing devices; The device for determining the next batch of instructions includes: If the current batch of instruction issuing devices has a sibling level with the same parent, and the online target devices contained in the sibling level with the same parent have not received the integration instruction, then the online target devices contained in any of the sibling levels with the same parent will be determined as the instruction issuing devices for the next batch. If the current batch of instructions is issued by a device that does not have a sibling level with the same parent, or if all online target devices contained in the sibling level with the same parent have received the integration instructions, backtrack to the parent level of the current batch of instructions issued by the device and check if the parent level has a sibling level that has not completed the integration instructions. If there are sibling levels in the parent level that have not completed the integration instructions, the online target device that has not yet received the integration instructions in any sub-level of the sibling level in the parent level will be identified as the instruction issuing device in the next batch. If the parent level does not have any sibling levels that have not completed the integration instructions, recursively trace back to the higher-level ancestor levels, select online target devices that have not received integration instructions as the next batch of instruction-issuing devices, and so on until the root level is reached.

2. The device instruction issuance method according to claim 1, characterized in that, The process generates multiple instructions to be issued based on the user-selected target policy template, target policy parameters, and target device list, including: Based on the user-configured instruction type, retrieve the corresponding target policy template from the preset policy template library; Distribute the target policy template to each target device in the target device list; Based on the target policy parameters configured by the user for each of the instruction types, the target policy template distributed to each of the target devices is populated, and device instructions corresponding to each of the target devices are generated. The device instructions are displayed to the user, and the device instructions that the user confirms are effective are identified as the instructions to be issued.

3. The device instruction issuance method according to claim 1, characterized in that, The process of integrating multiple pending instructions for the same target device to obtain an integrated instruction for each target device includes: Identify multiple pending instructions belonging to the same target device based on device identification; The multiple instructions to be issued are deduplicated, and the deduplicated instructions are merged according to a preset merging rule to obtain the integrated instructions for each target device.

4. The device instruction issuance method according to claim 3, characterized in that, The step of merging the deduplicated instructions to be sent according to a preset merging rule to obtain the integrated instructions for each target device includes: According to the priority of each instruction type, the deduplicated instructions to be issued are sorted from high to low priority. For instructions to be issued with the same priority, they are sorted according to the order in which the timestamps of the instructions to be issued were generated. The sorted instructions to be issued for each target device are merged to obtain the integrated instructions for each target device.

5. The device instruction issuance method according to claim 1, characterized in that, The monitoring indicators include command execution results and device health status; the step of determining whether to continue issuing integration commands based on the monitoring indicators of the device that issued the command includes: If there are still online target devices in the statistical level specified by the user that have not received the integration instruction, it is determined that the integration instruction will continue to be issued. If all online target devices in the user-specified statistical level have received the integration instruction, the number of failures will be counted based on the instruction execution results and device health status of the devices. The failure rate is calculated based on the number of failures and the total number of online target devices in the statistical hierarchy specified by the user. The decision on whether to continue issuing integration instructions is based on the failure rate.

6. The device instruction issuance method according to claim 5, characterized in that, The step of determining whether to continue issuing integration instructions based on the failure rate includes: If the failure rate is less than the low threshold, then it is determined that the integration command will continue to be issued; If the failure rate is not less than the low threshold and the failure rate is not greater than the high threshold, a confirmation request is sent to the user to confirm whether to continue execution. If the user does not choose to continue, it will be determined that no more integration instructions will be issued. If the user chooses to continue, the integration command will continue to be issued. If the failure rate is greater than the high threshold, it is determined that no more integration instructions will be issued.

7. A device for issuing equipment instructions, characterized in that, The device includes: The generation module is used to generate multiple instructions to be issued based on the target policy template, target policy parameters, and target device list selected by the user. The integration module is used to integrate multiple instructions to be issued to the same target device to obtain an integrated instruction for each target device. The instruction issuing module is used to traverse the hierarchical structure of each target device in the target device list from the root level down, select any online target device at the lowest level as the instruction issuing device for the current batch; the online target device is a target device that is in an online state; back up the current effective policy of the instruction issuing device, and issue the corresponding integration instruction to the instruction issuing device; determine whether to continue issuing integration instructions based on the monitoring indicators of the instruction issuing device, and roll back the instruction issuing device with abnormal monitoring indicators according to the corresponding current effective policy; The instruction issuing module is used to determine the next batch of instruction issuing devices if it is determined that integration instructions should continue to be issued. This includes: if the current batch of instruction issuing devices has a sibling level with the same parent, and the online target devices included in that sibling level have not received integration instructions, then the online target devices included in any of the sibling levels with the same parent are determined as the next batch of instruction issuing devices; if the current batch of instruction issuing devices does not have a sibling level with the same parent, or all online target devices included in the sibling levels with the same parent have received integration instructions, then the module traces back to the parent level of the current batch of instruction issuing devices to check if there are any incomplete integration tasks in that parent level. The integration command is distributed among sibling levels. If the parent level has sibling levels that have not completed the integration command, the online target devices that have not yet received the integration command in any child level of the sibling level that has not completed the integration command are identified as the command issuing devices for the next batch. If the parent level does not have sibling levels that have not completed the integration command, the process recursively traces back to the higher-level ancestor levels, selecting online target devices that have not received the integration command as the command issuing devices for the next batch, until the root level is reached, and continues to issue the corresponding integration command to the command issuing devices for the next batch. The command issuing devices for the next batch are selected from the sibling levels of the command issuing devices in the current batch.

8. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program executable by the processor, the processor being able to execute the computer program to implement the device instruction delivery method according to any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the device instruction delivery method as described in any one of claims 1-6.

Images