Power grid probe node elastic scheduling and safety control method and related equipment

Abstract

The invention relates to the technical field of power grid cross-domain cooperation, in particular to a power grid probe node elastic scheduling and safety control method and related equipment. The method comprises the following steps: performing trust and control capability construction on a power grid cross-domain collaborative underlying architecture to obtain a hierarchical node management architecture; on the basis of a hierarchical node management architecture, monitoring tasks are arranged through template definition boundaries and atomic fragment splitting, and an atomic task list capable of being distributed in a cross-domain mode is obtained; dynamically scheduling the atomic tasks in the atomic task list through a probe to obtain closed-loop data, a control loop and a feedback result; security compliance constraint is carried out on the process of trust and control capability construction, arrangement and dynamic scheduling through signature configuration and heartbeat verification, and full-period security compliance guarantee is obtained. According to the method, elastic scheduling and resource awareness allocation of the power grid probe nodes can be realized, a cross-domain state consistency and task synchronization mechanism is constructed, and a safety control closed loop and automatic isolation disposal capability is formed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of power grid cross-domain coordination, and in particular to a power grid probe node elastic scheduling and security control method and related equipment. BACKGROUND

[0002] Under the background of the rapid development of global energy internet, the operation and dispatch of power systems increasingly rely on cross-domain coordination and informationization means. With the continuous expansion of the scale of the power grid, the interconnection between regions is becoming increasingly close, and the power communication network, monitoring network and management network are gradually integrated, and the power grid operation environment has become more complex. In the existing power grid probe scheduling and management scheme, although a hierarchical control architecture of "center, subarea and node" has been formed, and task allocation and strategy unification have been realized in some application scenarios, when facing the cross-domain large-scale power grid operation environment, there are still a series of defects that cannot be avoided, which directly restrict the scheduling efficiency, operation resilience and security and reliability of the probe system.

[0003] Firstly, the scheduling mechanism lacks flexibility and real-time performance. Most of the existing schemes adopt a static pre-allocated task allocation mode, and once the task is allocated, there is no ability to reschedule according to the dynamic changes of probe resources. When the probe is overloaded due to CPU or memory overload, there is often no automatic migration or balancing mechanism, resulting in some nodes being overloaded or some nodes being idle, and the overall resource utilization is severely insufficient. Secondly, there is a lack of cross-domain consistency. The existing system generally relies on timed batch updates or manual intervention for task synchronization and state sharing between cross-regional or cross-provincial power grids, and lacks a real-time, stable and highly reliable state synchronization mechanism. This leads to inconsistent delays or conflicts in probe node directories, task execution states and policy libraries in cross-domain environments, which in turn causes fragmentation of monitoring information and weakens the overall efficiency of cross-regional coordination. Finally, the security control closed loop is incomplete. In most existing schemes, the configuration file distribution and node execution process lack strict digital signature verification, and the probe node only relies on clear configuration or weak verification to execute instructions. Once the configuration is tampered with or forged, the system is difficult to discover and block in time. At the same time, the self-checking mechanism and the disconnection isolation capability of the node are insufficient, and when the probe is controlled maliciously or disconnected due to abnormal state, the system often relies on manual intervention to troubleshoot, lacks an automatic isolation and disposal mechanism, and the risk continues to spread in the power communication network. In addition, the log and audit mechanism is also relatively single, and cannot form a closed-loop traceability of the whole process of configuration distribution, task execution and abnormal disposal.

[0004] In summary, the technical problems in the related art need to be improved. SUMMARY

[0005] The main purpose of the embodiments of the present application is to propose a power grid probe node elastic scheduling and security control method and related equipment, which can realize the elastic scheduling and resource perception deployment of the power grid probe node, construct the cross-domain state consistency and task synchronization mechanism, and form the security control closed loop and automatic isolation disposal capability.

[0006] To achieve the above-mentioned purpose, one aspect of the embodiments of the present application proposes a power grid probe node elastic scheduling and security control method, which comprises the following steps: The trust and control ability construction of the power grid cross-domain collaborative bottom layer architecture is obtained. Based on the layered node management architecture, the atomic task list that can be cross-domain allocated is obtained by template definition boundary and atomic fragment splitting. Based on the layered node management architecture, the closed loop data, control loop and feedback result are obtained by dynamically scheduling the atomic tasks in the atomic task list by the probe. The process of the trust and control ability construction, the arrangement and the dynamic scheduling is safely and compliantly constrained by the configuration signature and heartbeat check, and the whole cycle safety compliance guarantee is obtained.

[0007] In some embodiments, the trust and control ability construction of the power grid cross-domain collaborative bottom layer architecture comprises the following steps: The master center initializes and constructs the cross-domain collaborative trust root by establishing a certificate revocation and online check service in the hardware security module, and obtains the root trust anchor and the security policy template. The sub-center establishes a two-way transport layer security protocol long session with the master center by receiving the root trust anchor and the security policy template, and safely builds the cross-domain transmission channel, and obtains the encrypted transmission tunnel and the policy synchronization result. The probe initiates a registration request carrying a certificate signature request, a registration token and a device measurement digest, the sub-center verifies the registration request and transfers it to the master center, the master center issues a short-term boot certificate, and the identity of the probe is verified and authenticated for the first time, and the probe short-term boot certificate is obtained. The probe establishes a two-way transport layer security protocol long connection with the sub-center through the probe short-term boot certificate and reports the node descriptor, the sub-center registers the node descriptor and synchronizes it to the global node directory, and the sub-center issues a minimum security baseline configuration package, and the node registration and security configuration of the probe are obtained.

[0008] In some embodiments, the trust and control ability construction of the power grid cross-domain collaborative bottom layer architecture further comprises the following steps: The sub-center obtains a schedulable standby state node and a healthy attempt by checking the running state and configuration integrity of the probe within a time window. The power grid system controls the abnormal scene in the cross-domain trust construction process by triggering the corresponding external mechanism of the abnormal branch, and obtains an abnormal disposal result and an audit record.

[0009] In some embodiments, based on the hierarchical node management architecture, the monitoring task is arranged by defining boundaries and splitting atomic fragments based on templates, and a cross-domain distributable atomic task list is obtained, including the following steps: The main center obtains a signed task template by generating a task template with signature and version identification and writing it into a strategy library. The sub-center refines the monitoring task by receiving the task template, and obtains a set of atomic fragments. The scheduler schedules and allocates the execution nodes of the atomic fragments based on the node directory and real-time load of the probe, and obtains the cross-domain distributable atomic task list.

[0010] In some embodiments, based on the hierarchical node management architecture, the monitoring task is arranged by defining boundaries and splitting atomic fragments based on templates, and a cross-domain distributable atomic task list is obtained, including the following steps: The probe performs landing implementation of the monitoring task by checking the execution list signature and version, and obtains a task execution result and a signature digest. The sub-center signs, deduplicates and synchronizes the task execution result to the main center, and the sub-center collates and summarizes the data of the task execution result to obtain effective task data The scheduler dynamically schedules the abnormal execution scene by monitoring the state of the probe, and obtains a task execution closed loop result.

[0011] In some embodiments, based on the hierarchical node management architecture, the probe dynamically schedules the atomic tasks in the atomic task list, and obtains a closed loop data, a control loop and a feedback result, including the following steps: The sub-center checks the health status of the probe by collecting probe heartbeat and metric data, and obtains a healthy probe set and an abnormal probe identifier. The scheduler calculates the capacity score of the healthy probe and reorders the column, takes the task fragment from the multiple queues according to the DRR / WFQ algorithm, optimizes the scheduling of the execution node and dispatching order of the task fragment, and obtains an optimized task execution list. The probe controls the rate of the task fragment and performs landing execution by loading the speed limit and concurrent upper limit in the kernel and user state, and obtains a task execution progress and state feedback The power grid system obtains the anomaly handling results and the segment redistribution scheme by dynamically scheduling the abnormal scenarios of task execution; The sub-center performs deduplication verification of the execution results, while the main center completes full-domain archiving, result uniqueness, and cross-domain weight updates, summarizing and closing the loop of the entire task execution process results to obtain the closed-loop data, the control loop, and the feedback results. The dynamic scheduling includes soft error triggering exponential backoff, hard error triggering backup takeover, three heartbeat timeouts triggering disconnected fragment reassignment, and recovery triggering re-management.

[0012] In some embodiments, the process of building trust and control capabilities, orchestration, and dynamic scheduling by configuring signatures and heartbeat verification to obtain full-cycle security and compliance assurance includes the following steps: The main center generates a configuration package with version number, timestamp and signature to standardize and securely encapsulate the configuration required for cross-domain collaboration, resulting in a configuration package with security identifier; The sub-center verifies the signature and compares the version of the received configuration package to obtain the configuration verification result and the local configuration after it takes effect. The probe performs security activation and validity verification on the received configuration to obtain configuration activation results and probe status feedback. The sub-center obtains the probe health status determination result by continuously monitoring the probe's operating status; The isolation probe performs integrity self-checks and configuration consistency checks, then performs compliance repairs and status resets on abnormal probes to obtain healthy probe nodes. The power grid system achieves full-cycle safety and compliance assurance by recording all events.

[0013] To achieve the above objectives, another aspect of this application proposes a flexible scheduling and safety control system for power grid probe nodes, the system comprising: The architecture building module is used to build trust and control capabilities for the underlying architecture of cross-domain collaboration of the power grid, resulting in a hierarchical node management architecture. The list generation module is used to orchestrate monitoring tasks based on the hierarchical node management architecture by defining boundaries using templates and splitting atomic fragments, thereby obtaining a list of atomic tasks that can be allocated across domains. The dynamic scheduling module is used to dynamically schedule atomic tasks in the atomic task list based on the hierarchical node management architecture and through the probe to obtain closed-loop data, control loop and feedback results; The compliance constraint module is used to impose security and compliance constraints on the processes of trust and control capability building, orchestration and dynamic scheduling by configuring signature and heartbeat verification, so as to obtain full-cycle security and compliance protection.

[0014] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a method and related equipment for elastic scheduling and security control of power grid probe nodes. This solution establishes a unified control plane and trust foundation by constructing a hierarchical node management architecture. Based on this architecture, it defines boundaries using templates and splits atomic fragments to complete the orchestration of monitoring tasks, forming a list of atomic tasks that can be allocated across domains. Subsequently, it relies on probes to realize the dynamic scheduling of atomic tasks and form closed-loop data, control loops, and feedback results. Finally, it uses cross-cutting capabilities such as configuration signatures and heartbeat verification to constrain the entire process for security and compliance. This not only realizes the standardized orchestration, flexible scheduling, and closed-loop management of monitoring tasks in cross-domain collaboration of the power grid, ensuring the security of cross-domain data transmission, the stability of task execution, and the efficiency of resource scheduling, but also strengthens the trust mechanism and risk prevention and control capabilities in the cross-domain collaboration process through full lifecycle security and compliance constraints and audit traceability. This effectively supports the accurate perception of equipment status, the orderly advancement of tasks, and the rapid handling of anomalies in cross-domain scenarios of the power grid, and comprehensively improves the reliability, security, and controllability of cross-domain collaboration of the power grid. Attached Figure Description

[0017] Figure 1 This is a flowchart of the flexible scheduling and safety control method for power grid probe nodes provided in the embodiments of this application; Figure 2 yes Figure 1 A flowchart illustrating step S110 in the process; Figure 3 yes Figure 1 A flowchart illustrating step S120 in the process; Figure 4 yes Figure 1 A flowchart illustrating step S130 in the process; Figure 5 yes Figure 1 A flowchart illustrating step S140 in the process; Figure 6This is a schematic diagram of the structure of the power grid probe node elastic scheduling and safety control system provided in the embodiments of this application; Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

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

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] Probe nodes are not limited to standalone hardware devices; they can also run in virtualized form on edge computing platforms or cloud computing resource pools. Their core capability lies in performing monitoring, data collection, and probing tasks on target networks, and interacting with branch centers via encrypted communication tunnels. Therefore, this application is applicable to both distributed deployments of physical probes and containerized, virtualized, lightweight probe instance operation scenarios.

[0023] Task fragmentation can be based not only on IP address ranges or network segments, but also on protocol characteristics, service types, or time slices. The essence of fragmentation is to ensure sufficiently fine-grained task granularity, enabling flexible task migration and scheduling, thereby achieving efficient concurrency and redundancy control. Therefore, fragmentation is not limited to IP space partitioning but can also be extended to the application layer or business logic layer.

[0024] Isolation goes beyond simple network disconnection; it also includes application-layer session revocation, certificate and key revocation, and forced termination of local tasks. This multi-layered isolation mechanism ensures that even if a probe node has been compromised or exhibits abnormal behavior, the risk of its continued spread can be completely eliminated. Furthermore, this isolation process is reversible; once the probe node completes self-checks and repairs, it can be reinstated after the observation period, demonstrating the system's self-healing capabilities.

[0025] Cross-domain: This refers not only to different control areas in the geographical division of the power grid, but also to the collaboration between different management domains or organizational boundaries. For example, the mechanism of this invention is applicable in environments such as cross-enterprise power joint dispatch, cross-provincial power grid interconnection, and even international interconnected power grids. Its core is to ensure that tasks, configurations, and states between different domains remain consistent through encrypted tunnels and consensus algorithms, thereby providing a secure and controllable foundation for the collaborative operation of large-scale power grids.

[0026] HMAC: Hash Message Authentication Code with Key. It uses a hash algorithm (such as SHA-256) combined with a key to encrypt and authenticate data. It is used to verify the integrity and authenticity of data sources and to ensure the security of messages such as heartbeats and configurations in cross-domain communication of power grids.

[0027] SIEM: Security Information and Event Management Platform, which integrates multi-source logs and security data, and achieves real-time alerts, compliance audits and threat hunting through analysis and correlation. In the power grid, it is used to monitor security events and audit records across the entire cross-domain collaborative process.

[0028] PTP (Precision Time Protocol) and NTP (Network Time Protocol) are time synchronization protocols. PTP has nanosecond-level accuracy, while NTP has millisecond-level accuracy. They are used in the power grid for clock synchronization of the main center, branch centers, and probes to ensure the consistency of data timing and auditing.

[0029] HMAC-SHA256: HMAC is implemented using the SHA-256 hash algorithm. It performs hash operations on data and keys to generate a 256-bit authentication code, which is used in the power grid for heartbeat, integrity verification of configuration packets, and identity verification to prevent tampering.

[0030] SHA-256 is a secure hash algorithm that generates a 256-bit hash value from data of arbitrary length. It is used for data integrity verification (such as hash comparison of configuration packages and task lists) and ensures the immutability of data transmission and storage in the power grid.

[0031] RSA is an asymmetric encryption algorithm based on the problem of factoring large prime numbers. It is used for key exchange and digital signatures, such as the main center signing configuration packets, to achieve identity authentication and data confidentiality protection in cross-domain collaboration of the power grid.

[0032] DRR is a round-robin scheduling algorithm that maintains a counter for each queue, allocates bandwidth according to deficit, and ensures fairness among queues. It is used in power grids for fair scheduling of fragmented tasks in probe queues.

[0033] WFQ is a weighted fair queue scheduling algorithm that assigns weights to different priorities / categories of traffic and allocates bandwidth according to the weight ratio. It is used in the power grid for priority scheduling of fragmented tasks to ensure that critical tasks are executed first.

[0034] EWMA is an averaging algorithm that assigns exponentially decreasing weights to data sequences. It is used to smooth fluctuations (such as CPU and memory usage), and in power grids for trend analysis of probe health indicators, as well as to assist in capacity scoring and health assessment.

[0035] MAD: This is a statistic that reflects the degree of deviation of data from the median. It is used to identify outliers, such as sudden increases / decreases in probe indicators, and auxiliary health assessors in power grids to identify abnormal probe operation.

[0036] Class C network segment: is a class of IP address classification, which can accommodate 254 hosts. It is used in power grids to divide local monitoring areas into network segments.

[0037] Raft is a distributed consensus algorithm that achieves data consistency across multiple nodes through leader election, log replication, and state machine application. It is used in the main / branch center cluster of the power grid to ensure distributed consistency of configuration and task lists.

[0038] In related technologies, to ensure the safe, stable, and efficient operation of inter-regional power grids, power dispatching departments not only need to monitor the operational status of inter-regional nodes in real time, but also must possess flexible task scheduling capabilities to cope with sudden load fluctuations, resource imbalances, and potential cybersecurity threats. Especially in large-scale power grids, inter-domain probe nodes, as the frontline units for sensing and detection, need to undertake multiple tasks, including communication link detection, protocol identification, abnormal traffic detection, and operational log collection. The operational quality of probe nodes directly determines the level of precision in power grid monitoring and the overall resilience of the power system. However, in traditional power grid monitoring systems, probe nodes are mostly deployed in a static configuration, and scheduling strategies are often concentrated within a single region, lacking a unified scheduling and resource sharing mechanism at the inter-domain level. This model can basically meet the needs when the power grid is small or the task requirements are limited, but in inter-regional, inter-provincial, and even transnational power grid operation scenarios, the problems become increasingly prominent. On the one hand, the utilization rate of probe nodes under static configuration is low, with some nodes remaining idle for extended periods, while other nodes are overloaded due to excessive tasks, resulting in overall low efficiency. On the other hand, cross-domain task scheduling lacks flexibility and elasticity, making it impossible to quickly migrate tasks in the event of node failure or network anomalies, which can easily create monitoring blind spots. In addition, due to the lack of strict security verification and isolation mechanisms in the configuration file and task distribution process, once configuration is tampered with or node becomes disconnected, it will not only cause data inconsistency, but may also provide attackers with channels for intrusion and lateral expansion, thereby threatening the operational security of the power system.

[0039] The closest existing solutions to this application mainly focus on the probe deployment mechanism of power dispatch automation systems and power grid security monitoring platforms. Existing solutions generally adopt a hierarchical architecture of "center-region-node," with unified policy distribution at the central layer, local management at the regional layer, and specific tasks executed at the node layer. These solutions achieve centralized control and regional autonomy of probes to a certain extent; for example, some manufacturers propose managing probe nodes within their jurisdiction through branch centers, with the central layer maintaining communication with the branch centers via virtual private network tunnels. However, these existing solutions generally have the following limitations: First, task scheduling remains a static pre-allocation method, making it difficult to dynamically adjust based on the real-time resource status of probes; second, cross-domain synchronization and consistency mechanisms are insufficient, often relying on manual or periodic batch synchronization, failing to meet real-time requirements; third, security control measures are relatively simple, with the configuration distribution process often lacking digital signature verification and node self-checking mechanisms, relying solely on manual investigation for node disconnection or anomalies, resulting in insufficient automatic isolation and handling capabilities. These shortcomings make it difficult for existing solutions to guarantee the efficiency and security of power grid probe systems when dealing with large-scale cross-domain probe tasks, sudden resource changes, and complex security threats. Although existing power probe scheduling and safety management solutions have achieved cross-domain monitoring and centralized control to a certain extent, they still have not solved problems such as insufficient flexible scheduling, weak cross-domain consistency, and incomplete safety closed loop.

[0040] In view of this, this application provides a method and related equipment for elastic scheduling and security control of power grid probe nodes. The purpose of this solution is clearly stated in three points: First, to achieve elastic scheduling and resource-aware allocation of power grid probe nodes. By introducing a resource-aware algorithm in the branch center, the CPU, memory, and network load status of the probe nodes are monitored in real time. When a node reaches a pressure threshold, task allocation is automatically suspended, and tasks are dynamically transferred to nearby healthy nodes, thereby improving overall resource utilization and task completion stability. Second, to construct a cross-domain state consistency and task synchronization mechanism. This application establishes an encrypted tunnel between the main center and the branch center, and uses a consistency algorithm to ensure real-time synchronization of the node directory, task directory, and policy library across regions, ensuring that task allocation and policy execution in the cross-domain environment remain unified and highly reliable, avoiding information fragmentation. Third, to form a closed-loop security control system and automated isolation and handling capabilities. This application employs RSA or elliptic curve signature verification during configuration distribution. The probe can only execute after successful signature verification, preventing configuration tampering and misuse. Nodes maintain a trusted communication link via heartbeat messages protected by HMAC-SHA256. If heartbeats fail consecutively or integrity checks fail, the branch center immediately classifies the node as "disconnected" and implements triple isolation at the network, application, and host layers. Simultaneously, an immutable audit log is established to trace the entire process of configuration, execution, and isolation, achieving full lifecycle security governance for the power grid probe system.

[0041] Figure 1 This is an optional flowchart of a method for flexible scheduling and security control of power grid probe nodes provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S110 to S140.

[0042] Step S110: Build trust and control capabilities for the underlying architecture of cross-domain collaboration of the power grid to obtain a hierarchical node management architecture; Step S120: Based on the hierarchical node management architecture, the monitoring tasks are orchestrated by defining boundaries using templates and splitting atomic fragments to obtain a list of atomic tasks that can be allocated across domains. Step S130: Based on the hierarchical node management architecture, the atomic tasks in the atomic task list are dynamically scheduled through probes to obtain closed-loop data, control loops and feedback results. Step S140 involves configuring signature and heartbeat verification to impose security and compliance constraints on the process of building, orchestrating, and dynamically scheduling trust and control capabilities, thereby achieving full-cycle security and compliance assurance.

[0043] Steps S110 to S140, as illustrated in this embodiment, establish a unified control plane and trust foundation through a constructed hierarchical node management architecture to provide underlying control and trust capabilities. Subsequently, based on this hierarchical node management architecture, monitoring targets and boundaries are defined using declarative templates. Large network segments are split into atomic fragments with idempotent keys. Consistent hashing and topology awareness are combined to orchestrate monitoring tasks, resulting in a list of atomic tasks that can be allocated across domains and rebalanced. Then, relying on the underlying trust and control capabilities, tasks in the atomic task list are executed via probes, combined with heartbeat and metric data. The system enables dynamic current limiting, backoff, preemption, or failover, forming a closed-loop data, control loop, and feedback results. These feedback results then feed back into the rebalancing of task orchestration and the updating of the underlying architecture's health view. Finally, through cross-cutting capabilities such as configuration signature and atomic replacement, heartbeat integrity verification and timeout determination, isolation and re-management, and full lifecycle auditing and evidence collection, the system imposes security and compliance constraints on the entire process of building a hierarchical node management architecture, monitoring task orchestration, and dynamic scheduling of atomic tasks. Ultimately, this achieves full-cycle security and compliance assurance covering the entire process, ensuring the stability, security, and compliance of cross-domain collaboration in the power grid.

[0044] In some embodiments, step S110 involves constructing a hierarchical node management architecture of "main center - branch center - probe" and completing the full implementation of cross-domain trusted access and control plane. In step S110, the main center serves as the global trust anchor and policy orchestration core, the branch center serves as the jurisdictional scheduling and access agent unit, and the probe serves as the task execution entity with the lowest privileges. This approach spans key technology domains such as public key infrastructure, public and private key lifecycle, secure tunnels, two-way authentication, clock consistency, state consistency, and audit trails, ensuring that cross-domain collaboration establishes verifiable trust relationships at both the network and application layers and forms a rollbackable and auditable control loop.

[0045] Specifically, this includes sub-steps A1 through A7. Sub-step A1 establishes a global trust anchor and public key infrastructure. More specifically, the main center deploys the public key infrastructure root certificate service and issuance layer, and strictly hosts the root private key in a hardware security module. The issuance layer uses a trusted server to host intermediate certificate authorities. At the cryptographic algorithm level, certificate signatures uniformly adopt elliptic curve digital signature algorithms P-256 or P-384, while retaining the 3072-bit modulus RSA algorithm for adaptation to older devices. The certificate validity period and rotation cycle are clearly defined: device certificates not exceeding one year, and service certificates not exceeding two years. The certificate subject's alternate name field carries the node identifier, domain name, and management interface address. Extended fields carry roles and permission scopes. Roles are limited to "Master (Main Center)," "Regional (Branch Center)," and "Probe," with permission scopes bound to a minimum set policy. The certificate revocation list and online certificate status protocol service are mirrored in the main center and each branch center, ensuring cross-domain offline tolerance and online verification capabilities. During the initial startup of a node, a one-time registration token is used in conjunction with the device fingerprint to complete the initial trust binding. The device fingerprint is derived from the measurement value and read-only sequence number of the Trusted Platform Module or the Trusted Execution Environment. The main center performs dual verification of the signed Certificate Signing Request using both the link and the fingerprint. If the verification is successful, a short-term boot certificate is issued. The node switches to a long-term running certificate after the tunnel and two-way authentication are stably established.

[0046] In sub-step A2, cross-domain encrypted tunnels and network topology isolation are implemented. More specifically, site-to-site tunnels based on Internet Protocol (IP) security are established between the main center and each branch center, using Internet Key Exchange v2 (IPE2) for negotiation. The data plane uniformly uses Galois / counter mode for symmetric encryption and enables full forward secrecy. The tunnel adopts a routed virtual tunnel interface scheme. All north-south and east-west control traffic is explicitly whitelisted by the access control list before entering the tunnel, and a bidirectional transport layer security protocol is superimposed within the tunnel to protect application layer sessions. On the branch center side, the control plane and data plane are placed in different virtual routing forwarding instances, and the control traffic is strictly routed through the tunnel path according to the policy issued by the software-defined network, rejecting all unauthenticated direct access. No inbound ports are opened between the branch center and the probe. The probe only initiates long-term connection sessions with the branch center in an outbound manner. Long-term connections all use bidirectional transport layer security protocols, online verification of certificate verification chains and revocation status, mandatory verification of node roles and permission scope during the handshake phase, and direct recording and blocking of handshake failures.

[0047] In sub-step A3, the probe's trusted boot and minimum privilege registration are completed. More specifically, the probe device pre-configures a minimal boot agent in a read-only image. Upon initial power-up, it derives a session key using a one-time registration token and the sealed key of the trusted platform module, signs the certificate signing request and device measurement digest, and sends them to the branch center's registration endpoint. The branch center verifies the boot certificate and device fingerprint using a bidirectional transport layer security protocol, then forwards the registration materials to the main center's certificate service. After successful verification, the main center issues a short-term boot certificate, and the branch center instructs the probe to establish a long-lived connection within an Internet Protocol secure tunnel. After establishing the long-lived connection, the probe immediately reports its node descriptor, including static and dynamic capability parameters such as the number of processor cores, memory capacity, management and business network interfaces, the power grid topology identifier, the whitelist of reachable business network segments, the maximum number of concurrent tasks, the file descriptor limit, and the default rate limit. The branch center registers the descriptor in its jurisdiction's node directory and synchronizes it with the main center's global node directory. The main center uses this directory as the unique trusted node baseline, and all subsequent policy orchestration and allocation are based on this. After registration, the probe does not have task execution permissions until the configuration governance process sends out the minimum security baseline policy and heartbeat cycle parameters and receives a receipt. Only after the receipt is verified can it enter the "schedulable standby" state.

[0048] In sub-step A4, cross-domain state consistency and configuration governance capabilities are built. More specifically, the main center hosts a strongly consistent key-value store based on the Raft consensus algorithm, storing authoritative copies of the global "node directory," "task directory," and "policy library." Sub-centers host writable copies of their respective jurisdictions. Policy and task metadata are modeled using a conflict-free, replicated data type, allowing for local advancement within the domain under short-term network isolation, converging causally after connectivity is restored. All configuration, policy, and task lists undergo strict version governance and signature encapsulation. Version numbers use a three-part semantic identifier: "major version.minor version.revision number," and signatures use an elliptic curve digital signature algorithm with accompanying version metadata and timestamps. Sub-centers obtain incremental updates from the main center via a subscription channel, write them to their local read-only mirror area, and have their boundary conditions and mutual exclusion relationships verified by a pre-check engine. Upon successful verification, the new version is activated via atomic replacement, while the old version is retained as a snapshot to support instantaneous rollback. After receiving the signed and version-verified configuration package, the configuration client on the probe side performs idempotent disk write, atomic switching, and minimum-cost no-load self-check. Then, it sends the configuration summary and signature verification result in the form of an acknowledgment. Based on this, the branch center and the main center complete the archiving and auditing of a configuration closed-loop event.

[0049] In sub-step A5, observability, logging, and auditing links are woven in. More specifically, the entire domain adopts open observability standards for unified modeling of metrics, logging, and link tracing. The transport protocol uses a general remote procedure call overlaid with a bidirectional transport layer security protocol, and the metric granularity is fixed at a five- to ten-second window. Probes collect CPU utilization, memory usage, average load, network throughput, packet loss rate, system call error rate, disk I / O queues, and task execution latency percentiles, and carry incremental reporting in the heartbeat payload. Logs are stored in immutable, one-time write-to-multiple-copy storage at the branch center, and critical security events are synchronized to the security information and event management system of the main center. The auditing layer records the causal chain of every certificate issuance, configuration distribution, version switch, policy application, heartbeat verification, and anomaly handling using an event model. Event records include the initiator's identity, target object summary, signature, timestamp, and receipt reference, meeting the requirements for long-term retention and compliant evidence collection.

[0050] In sub-step A6, clock synchronization and replay protection are implemented. More specifically, the branch center deploys a precise time protocol master clock in qualified substations and dispatch centers, while edge sites use a network time protocol as a source of redundancy. The master center and branch center periodically compare and publish observable clock deviation indicators. The heartbeat message structure is fixed, including a timestamp, a monotonically increasing sequence number, and a random number. Within a strict time window, the branch center verifies the message's key-based hash message authentication code (HMAC) tag and verifies the sequence number continuity. Out-of-window or duplicate messages are directly rejected and recorded in the audit to eliminate the risks of replay and time-series poisoning. The validity period and acceptance offset of all signatures and tokens are parameterized and written into the policy library. When the local time drift exceeds the threshold, the probe end proactively degrades to a read-only observation state and triggers a time calibration process.

[0051] Sub-step A7 solidifies the operation and maintenance permissions and access control model. More specifically, the main center uniformly implements a combination model of role-based access control and attribute-based access control. Operation and maintenance personnel and system accounts achieve single sign-on through open identity connections. Sensitive operations require dual review and binding of approval documents. All cross-domain policies must have an approval receipt before taking effect. Quota and rate limits are enabled for all application interfaces. The call credentials and certificate rotation policy is consistent with the certificate lifecycle. Any credential abuse, abnormal rate, or unauthorized access is alerted in real time and drives an automated isolation process. Through the above permission and access model, the layered nodes logically obtain a unified guarantee of static minimum permissions and dynamic on-demand authorization, eliminating the systemic risk of "excessive permissions - unauthorized paths".

[0052] like Figure 2 As shown, Figure 2 yes Figure 1The flowchart for step S110 is shown below. The process begins with "Main Center Initializes Trust Anchor." The main center generates a root key and issues an intermediate certificate within the hardware security module, establishes certificate revocation and online status verification services, and then publishes cross-domain security baseline policies and tunnel orchestration templates. After receiving the main center's policies, the branch center locally installs the intermediate certificate and verification chain, creates an Internet Protocol (IP) security tunnel endpoint, constructs virtual routing and forwarding instances for the control plane and data plane, and then establishes a long-term bidirectional transport layer security protocol session with the main center through the tunnel and completes policy synchronization. During the power-on boot phase, the probe initiates a registration request, carrying a certificate signing request, a one-time registration token, and a device measurement digest. After verifying the boot certificate and device fingerprint, the branch center forwards the request to the main center. The main center issues a short-term boot certificate and sends it back to the branch center and the probe. The probe uses the short-term boot certificate to establish a bidirectional transport layer security protocol long connection with the branch center and reports the node descriptor. The branch center registers the node and completes full-domain node directory synchronization in the main center, then sends a minimum security baseline configuration package to the probe. After verifying the configuration signature and version, the probe is activated via an atomic switch, immediately initiating a heartbeat and carrying a metric digest in the heartbeat message. Within a time window, the branch center verifies the key-based hash message authentication code and sequence number, completing the node's state transition from "registration complete" to "schedulable and ready." If the configuration signature verification fails, the process follows the "security verification failure branch" to terminate by rejecting registration and recording audits; if tunnel establishment fails, the process follows the "network establishment fallback branch" to switch to a backup link or wait for manual intervention; if the heartbeat times out, the process follows the "health detection anomaly branch" to set the node to "disconnected" and stop policy pushing; if local self-check fails, the process follows the "integrity anomaly branch" to transfer the node to "isolation" status for further handling. The normal path ends with "the main center and branch center completing state closed-loop synchronization, and the probe entering schedulable and ready stage," after which it proceeds to the task orchestration and sharding phase. Through continuous technical sub-steps, a clear process flow, and a device structure layout, the hierarchical node management architecture and trusted access complete a closed loop across five dimensions: network, identity, configuration, clock, and auditing, providing a verifiable, maintainable, and scalable foundation for subsequent steps.

[0053] In some embodiments, step S120 involves constructing a cross-domain task orchestration and scanning fragmentation model to achieve declarative modeling, fragmented decomposition, cross-domain allocation, and idempotent execution mechanisms for cross-domain tasks. The core objective is to enable fine-grained decomposition, verifiable allocation, and recoverable rescheduling of large-scale power grid detection tasks at the sub-center and probe levels, ensuring the continuity, non-repetition, and cross-domain controllability of task execution.

[0054] Specifically, step S120 includes sub-steps B1 to B6. In sub-step B1, a task declarative template is constructed. More specifically, the task template is generated by the main center and stored in the policy library. The template declaratively represents the boundaries and constraints of the task, including task type, protocol family, target set, concurrency limit, rate limit, retry and backoff parameters, whitelist and blacklist targets, and compliance attribute tags. When the template is generated, it is signed by the main center using an elliptic curve digital signature algorithm, and includes a template number, version number, and validity period to ensure that the branch centers and probes verify the integrity and legality of the template.

[0055] In sub-step B2, the task is broken down into a sharding plan. More specifically, the sharding plan is generated locally by the branch center based on a template, using a fixed network segment splitting and hash mapping method. Taking a Class C network segment as an example, the entire network segment is divided into / 24 subnets, and each subnet forms an atomic shard. Each shard is accompanied by a unique shard identifier, a target subnet address, a sequence number, and a checksum. The shard identifier is obtained by calculating the shard content using a hash function (e.g., SHA-256), ensuring uniqueness and idempotency. The sharding plan is stored in the task directory of the branch center and kept in state synchronization with the main center, thereby ensuring cross-domain consistency.

[0056] In sub-step B3, an execution list is generated. More specifically, the execution list is dynamically generated by the branch center scheduler based on the probe's real-time status and resource load. Each execution list corresponds to a specific distribution batch and includes a fragment set, task template reference, batch number, configuration version, and signature. Upon receiving the execution list, the probe must first verify the signature and compare the version. If the configuration version is lower than the locally activated version, execution is rejected; if the signature is invalid, an alarm is triggered and communication is terminated. The execution list is distributed via a bidirectional transport layer security protocol channel. The probe records the status of receipt, execution, and completion in ledger form. The ledger is stored in the probe's local immutable storage area and is guaranteed to be idempotent through a transaction log.

[0057] In sub-step B4, cross-domain allocation and rebalancing are implemented. More specifically, shard allocation employs a consistent hashing algorithm combined with topology-aware scheduling. First, shard identifiers are mapped to the hash ring of the probe set within the sub-center, selecting a primary and backup node. Subsequently, the candidate order is scored and rearranged based on the probes' topology proximity, resource score, and historical reliability indicators to form the optimal allocation result. If a probe in a shard loses connection or malfunctions during execution, the sub-center scheduler immediately triggers rebalancing, allocating the shard to a backup probe for execution. During rebalancing, the original shard identifier and batch number are retained, thus ensuring idempotency and result uniqueness.

[0058] In sub-step B5, rate control and fairness mechanisms are implemented. More specifically, each shard carries maximum rate and concurrency parameters during generation. During probe execution, a token bucket is used to control the rate of new connections and the number of concurrent sessions, ensuring no sudden impact on the target network. A multi-tenant quota model is configured on the branch center side, using a Defict Round Robin scheduling algorithm to fairly allocate bandwidth and computing resources among different task sources, preventing a single service from monopolizing resources. The main center periodically collects queue levels and completion rates within the domain, calculates cross-domain scheduling weights based on historical throughput and failure rates, and rebalances tasks to less loaded partitions as needed.

[0059] In sub-step B6, a result feedback and deduplication mechanism is established. More specifically, after the probe completes sharding, the result data and execution digest are compressed, signed, and uploaded to the branch center. The branch center verifies the signature and compares the idempotent keys, stores the results in its local database, and then synchronizes them to the main center for archiving. If the probe is executed multiple times due to sharding reassignment, the branch center deduplicates the results based on the shard identifier, ultimately retaining only one copy. All execution logs, digests, and state transition events are written to an immutable ledger to support subsequent auditing and compliance checks.

[0060] In step S120, as Figure 3 As shown, Figure 3 yes Figure 1 The flowchart for step S120 is as follows. The process begins with "the main center generating a task template," which is then signed and version-identified and written to the policy database. After receiving the template, the branch center generates a sharding plan locally, breaking down the large network segment into multiple atomic shards, each with a unique shard identifier. The scheduler selects a primary and backup probe for each shard based on the probe node directory and real-time load, forming an execution list. The execution list is sent to the probes via a bidirectional transport layer security protocol channel. The probes perform signature verification and version comparison; upon successful verification, the results are written to their local ledger and execution begins. During execution, the probes control the rate at the shard granularity, and upon completion, they send the results and execution digest signature back to the branch center. The branch center verifies the signature and removes duplicates, writing the valid results to the database and synchronizing them to the main center. If a probe fails or loses connection, the scheduler triggers rebalancing, allocating the shard to a backup probe and repeating the process until successful. The process ends with "the main center archiving the task results and audit logs," forming a complete task loop.

[0061] In some embodiments, a resource-aware elastic scheduling and failover mechanism is implemented in step S130. A resource-aware elastic scheduling and failover closed loop is implemented at the sub-center level, using online measurements from the probe side as input, with the three links of "availability threshold - capacity scoring - allocation decision" as the core, and the three fault-tolerance mechanisms of "disconnection determination - backup takeover - deduplication receipt" as guarantees. Unified landing rate control, concurrency shaping, priority preemption, backoff, and circuit breaker strategies are implemented to ensure that the task proceeds stably without disturbing the power grid production network and possesses rapid self-healing capabilities.

[0062] Specifically, step S130 includes sub-steps C1 to C10. Sub-step C1 constructs a probe-side metric model and a health arbiter. More specifically, the probe reports raw metrics such as CPU utilization, memory usage, average load, network throughput and packet loss, system call error ratio, disk I / O saturation, and task latency quantiles at fixed heartbeat intervals. The branch center synchronously maintains instantaneous values, EWMA values, and MAD standardized residuals for each metric, and performs health assessments using parameterized thresholds from a policy library. The health assessment executes a triple gate of "instantaneous-smoothing-steady-state": instantaneous values ​​exceeding the upper limit are directly marked as "stress," EWMA exceeding the threshold is marked as "sustained stress," and MAD residuals exceeding a set multiple are marked as "abnormal fluctuations." Triggering any gate marks the probe as "stressed" and returns a "prohibit new fragmentation" gating signal to the scheduler; the "stress" status is revoked only if the probe recovers to within the threshold within three consecutive heartbeat windows to eliminate jitter.

[0063] In sub-step C2, entry control and dynamic concurrency shaping are implemented. More specifically, upon receiving a gating signal, the sub-center scheduler immediately reduces the "new fragment quota" for that probe to zero, while preserving its convergence window for running fragments. The scheduler sets a "concurrency limit" and a "new startup rate limit" for each probe and dynamically shapes it based on EWMA feedback during runtime; when EWMA approaches the limit, the new startup rate is reduced; when the instantaneous value approaches the limit, new startups are paused and priority preemption is triggered. Concurrency shaping and entry control are strategically configured based on probe labels and hardware levels to ensure that probes of different models within the same domain receive matched pressure bandwidth.

[0064] Capacity scoring and candidate selection are implemented in sub-step C3. More specifically, the scheduler calculates a capacity score for each health probe. The scoring function is a deterministic form that weights and normalizes resource availability, network quality, and topology proximity, and the formula is: ; Where Score represents the capacity score result, and the parameter is... This represents the weight coefficients for each dimension. The exponentially weighted moving average (EWMA) value representing the CPU utilization of the probe. This represents the exponentially weighted moving average of probe memory usage. This represents the normalized value of network bandwidth. This represents the normalized value of the network packet loss rate. Topological proximity measures the physical or logical proximity of the probe to the target monitoring object in the power grid topology. This represents the normalized value of network latency. Weighting coefficients are loaded from the policy library and support hot updates. The scoring results are used to rearrange the preferred-alternate sequences generated by consistent hashing, forming the final candidate sequences. The candidate sequences strictly adhere to three types of hard constraints: "single probe concurrency limit," "single subnet concurrency limit," and "tenant quota limit." Candidates that violate these constraints are directly eliminated.

[0065] In sub-step C4, multi-queue fair queuing and cross-domain backpressure are established. More specifically, the branch center maps the fragments waiting for allocation to independent queues according to "tenant / service line / network segment priority". Queue scheduling adopts DRR, and the weight is jointly determined by the tenant quota and work order priority. Within the same queue, WFQ is used to refine the granularity to the subnet level to ensure that hot subnets do not starve unpopular subnets. When the remaining capacity in the domain is lower than the policy threshold, the branch center reports a "domain capacity alarm" to the main center. The main center adjusts the cross-domain weights accordingly and suspends the push of new batches to that domain, thereby forming an inter-domain backpressure link.

[0066] Sub-step C5 implements probe-side rate control, connectivity shaping, and preemption. More specifically, the probe execution engine uses a token bucket to control the rate of new connections in user space, and controls the total number of active sessions in kernel space through connection concurrency limits and queue length constraints on the network stack. The execution engine records progress at the shard granularity and implements fine-grained preemption based on shard priority: when resources approach the limit, low-priority shards are paused and their corresponding connections are released, while high-priority shards are prioritized for completion. After preemption recovery, the execution engine continues from the shard progress checkpoint. The checkpoint includes the target subnet scan cursor, retry count, and local result buffer summary to ensure that recovery does not introduce duplication or missed scans.

[0067] In sub-step C6, failure classification, backoff, and circuit breaker strategies are unified. More specifically, probes report errors in three categories: hard errors (unrecoverable, such as permission denial and permanent unreachability of the target network), soft errors (recoverable, such as momentary timeouts and temporary increases in packet loss), and policy errors (configuration signature / version inconsistency). The sub-center applies exponential backoff to soft errors, with the initial backoff time being the shortest, increasing exponentially thereafter and setting an upper limit. For hard errors, the sub-segment is terminated directly with an acknowledgment, triggering backup takeover of the sub-segment at the sub-center layer. For policy errors, configuration self-healing is triggered, and the process enters the configuration closed-loop branch. Both the sub-center and the probe implement circuit breakers. When the error rate exceeds a threshold within a window, the circuit breaker sets the target sub-network or the probe to "half-open / open," stopping further distribution or testing. It closes again after the cooling-off period and verification by probes.

[0068] In sub-step C7, the disconnection determination and seamless task takeover are implemented. More specifically, the sub-center uses a dual-channel approach of heartbeat and receipt to drive the disconnection determination. If three consecutive heartbeat timeouts occur or the receipt channel experiences consecutive unrecoverable errors, the probe status is set to "disconnected." The disconnection event triggers two atomic operations: first, the unfinished fragment held by the probe is switched to "redistributable," and the scheduler selects the next healthy probe from the candidate sequence, attaching "original batch number + idempotent key + progress summary" for redistribution; second, the domain content change is reported to the main center, and the main center performs cross-domain rebalancing according to domain weights. To avoid cascading failures, redistribution is carried out in stages on a batch basis, and the maximum number of parallel redistributions limits the instantaneous surge.

[0069] In sub-step C8, deduplication of receipts and result uniqueness are implemented. More specifically, the probe-side ledger maintains a state machine (receive, start, pause, complete, fail) using the "sharding idempotent key" as the primary key. When a branch center aggregates results, it uses the "idempotent key + batch number" for deduplication. If multiple completion receipts exist, a unique record is determined based on the rule of "earliest completion time - lowest error code priority - latest branch center consistency stamp," and redundant records are marked as "duplicate completion." The main center performs global deduplication again using the idempotent key during cross-domain archiving to ensure unique results across all domains.

[0070] In sub-step C9, recovery and re-management are implemented. More specifically, after the lost probe is restored to online status, it must complete integrity self-check, configuration consistency verification, and ledger upload. The branch center compares the ledger with the central system in "observation" status. After confirming that there are no unmerged valid results or policy differences, its status is switched back to "healthy". At the same time, the probe entry in the original reallocation plan is removed, and its normal entry and allocation qualifications are restored.

[0071] In sub-step C10, end-to-end auditing and metric governance are solidified. More specifically, the sub-center generates event records for each allocation, preemption, backoff, circuit breaker, takeover, and recovery. The events carry the operator / algorithm version, object summary, signature, timestamp, and causal reference, and are written to immutable storage with one-write-multiple-copy. The main center periodically calculates metrics such as "success rate, failure rate distribution by cause, P95 / P99 (95th / 99th percentile) latency, redistribution rate, mean time to recovery (MTR), and drop rate," and automatically issues optimization suggestions or rate limiting instructions to domains below the threshold, forming an operable SLO / SLA (Service Level Objective / Service Level Agreement) governance closed loop.

[0072] In step S130, as Figure 4 As shown, Figure 4 yes Figure 1The flowchart for step S130 is shown below. Starting with "Collecting heartbeats and measurements at the branch center," the health arbiter performs instantaneous, EWMA, and MAD triple checks on probe metrics. If any gate is triggered, the process enters the "Pressure Gating" branch, where the scheduler reduces the new shard quota for that probe to zero and enters dynamic shaping. If the health check passes, the process enters "Capacity Scoring and Candidate Selection," where the scheduler calculates the capacity score and rearranges it on the sequence obtained from consistent hashing. Then, it enters "Multi-Queue Fair Queuing," retrieving shards from the queues according to DRR / WFQ, forming an "Execution List," and distributing it via a bidirectional encrypted channel. On the probe side, the "Rate Control and Concurrency Shaping" layer loads rate limits and concurrency limits in kernel and user space. The execution engine advances shards according to priority and reports progress in real time. If a "soft error" is triggered during execution, the process enters the "exponential backoff sub-process"; if a "hard error" is triggered, the process enters the "standby takeover sub-process," where the branch center switches the shard to the standby probe and continues; if the probe "times out three consecutive heartbeats," the process enters the "disconnection branch," where the branch center performs phased redistribution of the incomplete shards and reports to the main center for cross-domain rebalancing; if the probe "returns online and passes self-inspection," the process enters the "re-management branch," where the branch center restores its allocation eligibility after completing ledger merging during the observation period. All normal execution paths eventually enter "deduplication receipt and full-domain archiving," where the main center completes result uniqueness and audit archiving and updates cross-domain weights, after which the process returns to the loop starting point of "branch center collecting heartbeats and metrics." By using resource-aware elastic scheduling and failover mechanisms, resource fluctuations of probes are digested at the scheduling entry point. During the runtime, priority and concurrent shaping are used to maintain stable task progress. In case of anomalies, classification backoff and phased takeover are used to avoid storm amplification. Idempotent ledger and global deduplication are used to ensure unique results and auditable trajectories. Thus, a unified optimal balance between high throughput and short-tail latency is achieved without exceeding any control thresholds.

[0073] In some embodiments, step S140 performs a security control loop, configuration signing, and isolation processing. This achieves a security loop centered on configuration trust, identity verification, heartbeat monitoring, anomaly isolation, and audit evidence collection. This, combined with the layered architecture, sharding scheduling, and resource elasticity mechanisms described in the preceding steps, completes the process, ensuring that the cross-domain probe system possesses immutability, verifiability, and automated self-healing capabilities throughout the entire chain of configuration, execution, monitoring, and processing.

[0074] Specifically, step S140 includes sub-steps D1 to D5. In sub-step D1, a configuration signing and version governance mechanism is established. More specifically, the main center generates a globally unique version number for each policy update, task template distribution, and configuration file modification, and signs the configuration package and metadata using RSA or elliptic curve digital signature algorithms. A timestamp, generator identity, and policy hash are appended to the signature. After receiving the configuration, the branch center writes it to its local mirror area, performs signature verification and version comparison, and immediately rejects the write and initiates a security alert if the signature or version is invalid. When the probe configuration client receives the configuration list, it performs three steps: first, signature verification and version number confirmation; second, atomic replacement in the read-only snapshot area; and third, a minimal-cost no-load self-check to verify whether configuration items are mutually exclusive or out of bounds. After completing the self-check, the probe packages and signs the "configuration version number + hash value + signature verification result," forming a complete closed loop of "distribution—application—receipt." Old version configurations are retained in the read-only snapshot area to ensure rollback at any time.

[0075] In sub-step D2, the node self-check and heartbeat verification mechanisms are strengthened. More specifically, the probe sends heartbeat packets to the branch center at fixed intervals. The heartbeat includes the node identifier, timestamp, monotonically increasing sequence number, random number, configuration version number, and metric digest. The message body is encrypted and verified using HMAC-SHA256 (key-based hash message authentication code, SHA-256 hash function) to ensure integrity and prevent replay. Upon receiving the heartbeat, the branch center performs double verification: first, it checks whether the HMAC tag is correct; second, it confirms whether the timestamp is within the allowed offset window (relying on PTP / NTP to ensure clock consistency). If three consecutive heartbeats fail to arrive or the HMAC verification fails, the branch center marks the probe status as "disconnected" and automatically executes the isolation procedure.

[0076] In sub-step D3, an automated isolation and handling process is established. More specifically, when a probe is determined to be "out of contact" or "integrity abnormal" (e.g., configuration signature verification failed, runtime self-check failed), the system switches it to an "isolated" state and performs a triple blockade: at the network layer, by updating rules through software-defined networking or access control lists, the interaction between the node and the management channel is immediately cut off; at the application layer, its certificate, token, and session are revoked, and any task requests and configuration synchronization are rejected; at the local host layer, the daemon process is triggered to uninstall the key and certificate, stop task execution, and write the runtime log to the read-only evidence area. The isolated node is only allowed to maintain a one-way "observation heartbeat" channel to the branch center. This channel only uploads self-check results and integrity status, and rejects downlink tasks and configurations. During the handling process, the branch center can trigger a self-check sequence, including binary integrity comparison, file system verification, critical configuration version verification, and system call baseline verification. If all pass, the probe enters the "observation period," during which no tasks are accepted, and only ledger and configuration consistency are synchronized; if it fails, the isolated state is maintained and reported to the main center for manual review.

[0077] In sub-step D4, the evidence collection and auditing loop is solidified. The branch center and the main center maintain immutable audit databases locally and globally, respectively. All events (including configuration distribution, signature verification, heartbeat loss, isolation execution, and recovery management) are written to the logs using an event model. Event records include the initiator's identity, target node, configuration version number, hash digest, signature, timestamp, and causal chain reference. The logs are stored on immutable media using a write-once, multi-copy mechanism and centrally analyzed through the SIEM platform. The main center periodically compiles statistics on metrics such as the number of isolated events uploaded by each branch center, recovery time, heartbeat anomaly rate, and configuration rejection count. If thresholds are exceeded, automatic optimization suggestions are triggered, such as key rotation, configuration template revision, or probe replacement.

[0078] In sub-step D5, a secure self-healing and re-management mechanism is established. After the isolated probes complete integrity verification and configuration consistency checks again, the branch center switches their status to "observation." During the observation window, no new tasks are accepted; only ledger and results are allowed to be transmitted back. After verifying the consistency between the ledger and the central database, if there are no conflicts, the branch center immediately restores its status to "healthy" and reintegrates it into the scheduling pool. If data conflicts exist, the ledger differences are submitted for manual review, and only after approval is the probe reinstated. This mechanism enables automated self-healing of nodes, ensuring a smooth transition between disconnection and recovery for all tasks across the entire domain.

[0079] In step S140, as Figure 5 As shown, Figure 5 yes Figure 1The flowchart for step S140 is shown below. Starting from "The main center generates and signs the configuration package," the configuration package includes a version number, timestamp, and signature. Upon receiving the package, the branch center verifies the signature and compares the version. If successful, it writes to the mirror area and atomically replaces the existing configuration; otherwise, it enters the "Reject Configuration and Alarm" branch. Upon receiving the configuration, the probe executes "Signature Verification - Atomic Switching - Self-Check - Receipt." If the receipt is successful, the configuration loop ends and the task execution process begins. If signature verification fails or the self-check is abnormal, the process enters the "Isolation Branch," the probe status is set to "Isolated," and triple blocking at the network, application, and host layers is implemented. During normal operation, the probe periodically reports heartbeats. The branch center performs HMAC verification and time window detection. If three consecutive heartbeat timeouts or verification failures occur, the process enters the "Disconnection Branch," immediately executing isolation and task transfer. If the isolated probe subsequently completes integrity self-checks and configuration consistency verification, it enters the "Observation Period." After successful observation, the process enters "Recovery and Management," and the node returns to a healthy state. All events are written to an immutable audit database and synchronized to the main center. The process ultimately concludes with "probes being reinstated and re-entering task scheduling." Through a closed-loop security control system, a complete chain is achieved, from trusted configuration release to node self-checks and heartbeat monitoring, and then to disconnection isolation and automatic recovery. This mechanism ensures that every step of the probe node's operation in cross-domain collaboration is verifiable, traceable, isolated, and recoverable, thus providing long-term stable and compliant reliable operational assurance for the power grid cross-domain probe system.

[0080] Compared with existing power grid probe scheduling and safety management schemes, this application demonstrates significant advantages in cross-domain consistency, scheduling flexibility, and security closed-loop. Existing schemes mostly rely on static task allocation and timed batch synchronization, resulting in insufficient resource utilization, inconsistent cross-domain information, and delayed handling of node anomalies. This application, by introducing a fragmented task scheduling mechanism and a resource-aware algorithm, achieves dynamic balancing and rapid fault takeover among probe nodes, enabling the system to maintain efficient and stable detection capabilities in large-scale cross-regional power grid environments. Simultaneously, the state synchronization mechanism between the main center and branch centers based on a consistency algorithm ensures real-time consistency of cross-domain directories and task states, avoiding monitoring blind spots caused by delays or conflicts in traditional schemes.

[0081] In terms of security control, this application establishes a triple protection mechanism of configuration signature verification, heartbeat integrity verification, and automatic isolation and handling, forming a full-link security closed loop that runs through configuration distribution, task execution, node monitoring, and anomaly recovery. This not only avoids the systemic risks caused by configuration tampering or node disconnection in existing technologies, but also achieves node self-healing and risk convergence through automatic isolation and re-management mechanisms, significantly improving the system's security resilience. In summary, this application not only makes up for the shortcomings of existing technologies in scheduling flexibility and security closed loop, but also provides a power grid probe node management method with cross-domain collaboration, elastic scheduling, and adaptive security protection capabilities, thereby improving the overall reliability and security of cross-regional power system operation.

[0082] In some embodiments, in achieving the overall goal of elastic scheduling and secure control of cross-domain power grid probe nodes, besides the layered architecture, fragmented task scheduling, and secure closed-loop mechanism proposed in this application, several other technical approaches can achieve similar objectives. One alternative is to achieve unified scheduling across the entire domain through a centralized, ultra-large-scale controller, where the main control center directly manages the task allocation and operational status of all probe nodes, eliminating the need for sub-center hierarchies. The advantage of this approach is a more centralized global perspective and unified scheduling logic; however, in cross-domain scenarios, communication link latency is significant, and if the main control center fails, the entire probe system is prone to stagnation, lacking resilience. Another approach is to adopt a scheduling mode based on a distributed blockchain ledger. By writing task allocation, execution status, and node reputation into a distributed blockchain, the consistency and immutability of cross-domain data are ensured. The advantages of this approach are high security and transparency, naturally resisting data tampering; however, its consensus overhead is large, making it difficult to meet the high real-time requirements of power grid detection tasks. A third alternative is to achieve dynamic deployment and elastic scheduling of probe nodes through virtualization and container orchestration platforms. This approach achieves flexible task migration by quickly launching or destroying probe containers on edge computing nodes in different regional power grids. While demonstrating excellent scheduling flexibility, this approach suffers from limitations in stability and determinism due to the stringent requirements of power communication networks for determinism and low latency. A fourth alternative is the introduction of AI-driven predictive scheduling. Machine learning models predict the load and network status of probe nodes, making scheduling decisions in advance to avoid node overload or disconnection. This approach enhances the foresight and adaptability of scheduling, but its model training requires a large amount of historical data, and its interpretability and controllability under abnormal conditions are inferior to rule-based scheduling strategies. A fifth approach considers an architecture based on multi-tenant isolation and virtual probe pools. This involves running multiple logical probe instances on a unified hardware resource pool, achieving elastic scheduling and security control through tenant-level isolation policies. This method offers superior resource utilization and flexibility, but vulnerabilities or attacks on the underlying virtualization platform could affect multiple logical probes simultaneously, posing a concentrated risk.

[0083] In summary, although various alternative technical approaches exist, in cross-domain power grid operation scenarios, these alternatives either lack real-time performance, have centralized single-point risks, or have deficiencies in the security closed-loop mechanism. This application, through the combination of a layered architecture and a security closed-loop mechanism, balances real-time performance, reliability, and security, and is therefore more suitable for the actual needs of cross-domain power grid probe nodes.

[0084] In some embodiments, from an overall architectural perspective, step S110 is the "foundation and framework," which sets up the most basic trust and control capabilities at once, including the three-layer topology of the main center-sub-center-probe, encrypted tunnels and two-way authentication, public key infrastructure, clock and audit, configuration governance and state directory. Without this step, any subsequent task orchestration, scheduling and security handling would lack a trusted communication channel, a unified identity system and a consistent source of state. Therefore, step S110 is a strict prerequisite for steps S120, S130 and S140.

[0085] Step S120 is the "definition and decomposition work" stage on this framework. It fixes the monitoring targets and boundaries using declarative templates, then breaks down large network segments into atomic fragments with idempotent keys, and uses consistent hashing and topology awareness to form an execution list that can be allocated across domains and rebalanced. This stage mainly solves the problem of "how to standardize, divide, and verify which probe to send the task to", directly consumes the identity, directory, and configuration capabilities provided by step S110, and provides "atomic tasks" that can be executed and measured for step S130.

[0086] Step S130 is the "implementation and self-regulation" stage, where the atomic fragments output from step S120 are run on specific probes. Based on heartbeats and metrics, automatic rate limiting, backoff, preemption, or failover occurs when resources approach the threshold. This stage relies on both the metric collection and reliable heartbeats from step S110 and the fragmentation and allocation results from step S120. The three form a closed-loop data-control loop during operation, namely, "directory and configuration from step S110 - fragmentation and allocation from step S120 - execution and feedback occur in step S130 - feedback then affects the rebalancing of step S120 and the health view of step S110."

[0087] Step S140 forms a comprehensive security and governance framework across the entire chain, both encompassing and constraining every configuration, allocation, and execution step S120 and S130: configuration signatures and atomic replacements take effect when tasks are generated and distributed; heartbeat integrity and three-timeout disconnection checks remain effective during execution; isolation and re-management intervene at any time during anomalies and change scheduling boundaries; and auditing and forensics begin recording from the start of step S110 and continue throughout the entire lifecycle. Therefore, in terms of relationships, step S110 provides a unified control plane and trust foundation for subsequent steps; steps S120 and S130 exhibit a sequential dependency relationship of "orchestration first, execution second, and orchestration feedback" in the business process, but can be iterated in parallel during long-term system operation; step S140 represents a cross-stage lateral capability, acting like a security and compliance exoskeleton that encapsulates the entire orchestration and execution process.

[0088] The overall design of this application is highly scalable. As the scale of the power grid and the number of probes increase, the collaborative capabilities between the main center and branch centers can be achieved through horizontal scaling. Furthermore, the task sharding and scheduling logic of the probes inherently possesses distributed characteristics in its architecture, thus avoiding single-point bottlenecks. Simultaneously, this application employs idempotent keys and a ledger mechanism to ensure the uniqueness and traceability of tasks during repeated scheduling, task recovery, and cross-domain rebalancing—a feature lacking in existing technologies. Regarding compliance and standard compatibility, this application is compatible with existing power information security standards, such as the State Grid's power secondary system security protection requirements, IEC 61850, and IEC 62351 international standards. Its configuration signature, encrypted tunnel, and log auditing modules can be integrated with existing security infrastructure, avoiding redundant construction and standard incompatibility issues. This feature enhances the feasibility and promotional value of this application in actual power grid engineering environments.

[0089] It is important to emphasize that this application is not limited to a single hardware architecture or algorithm implementation, but rather represents a systematic design philosophy. Its core value lies in forming a complete cross-domain probe elastic scheduling and security control framework through layered management, fragmented scheduling, resource awareness, and a security closed loop. In practical applications, specific algorithms can be flexibly configured according to different power grid operating environments and security requirements. For example, the selection of consistent hash functions, the weighting factor for capacity scoring, and the backoff and circuit breaker strategy parameters provide flexibility for deployment in different scenarios.

[0090] Please see Figure 6 This application also provides a flexible scheduling and safety control system for power grid probe nodes, which can implement the above-mentioned method. The system includes: The architecture building module is used to build trust and control capabilities for the underlying architecture of cross-domain collaboration of the power grid, resulting in a hierarchical node management architecture. The list generation module is used to orchestrate monitoring tasks based on a hierarchical node management architecture by defining boundaries using templates and splitting atomic fragments, resulting in a list of atomic tasks that can be assigned across domains. The dynamic scheduling module is used to dynamically schedule atomic tasks in the atomic task list based on a hierarchical node management architecture, and obtain closed-loop data, control loops and feedback results. The compliance constraint module is used to impose security compliance constraints on the process of building, orchestrating and dynamically scheduling trust and control capabilities by configuring signatures and heartbeat verification, thereby achieving full-cycle security compliance protection.

[0091] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0092] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0093] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0094] Please see Figure 7 , Figure 7 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 710 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 720 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 720 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 720 and is called and executed by the processor 710 using the methods described in the embodiments of this application. The input / output interface 730 is used to implement information input and output; The communication interface 740 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 750 transmits information between various components of the device (e.g., processor 710, memory 720, input / output interface 730, and communication interface 740); The processor 710, memory 720, input / output interface 730 and communication interface 740 are connected to each other within the device via bus 750.

[0095] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0096] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0097] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0098] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0099] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0100] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0101] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0102] It should be understood that the data used in this way can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than those illustrated or described herein. Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover a non-exclusive inclusion, for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0103] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0104] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0105] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for flexible scheduling and security control of power grid probe nodes, characterized in that, The method comprises the following steps: The trust and control capability construction of the power grid cross-domain collaborative bottom layer architecture is performed to obtain a hierarchical node management architecture; Based on the hierarchical node management architecture, the monitoring tasks are arranged through template definition boundaries and atomic fragment splitting to obtain an atomic task list that can be cross-domain allocated; Based on the hierarchical node management architecture, the atomic tasks in the atomic task list are dynamically scheduled through the probe to obtain a closed-loop data, control loop and feedback result; The process of the trust and control capability construction, the arrangement and the dynamic scheduling is safely and compliantly constrained through configuration signature and heartbeat check to obtain all-cycle safe and compliant guarantee.

2. The method of claim 1, wherein, The trust and control capability construction of the power grid cross-domain collaborative bottom layer architecture comprises the following steps: The main center initializes and constructs a cross-domain collaborative trust root by establishing a certificate revocation and online check service in a hardware security module to obtain a root trust anchor and a security policy template; The sub-center establishes a two-way transport layer security protocol long session with the main center by receiving the root trust anchor and the security policy template to safely build a cross-domain transmission channel to obtain an encrypted transmission tunnel and a policy synchronization result; The probe initiates a registration request carrying a certificate signature request, a registration token and a device measurement digest, the sub-center verifies the registration request and transfers it to the main center, the main center issues a short-term boot certificate, and the identity of the probe is verified and authenticated for the first time to obtain a probe short-term boot certificate; The probe establishes a two-way transport layer security protocol long connection with the sub-center through the probe short-term boot certificate and reports a node descriptor, the sub-center registers the node descriptor and synchronizes it to a global node directory, and the sub-center issues a minimum security baseline configuration package to register and configure the node of the probe to obtain a hierarchical node management architecture.

3. The method of claim 2, wherein, The trust and control capability construction of the power grid cross-domain collaborative bottom layer architecture further comprises the following steps: The sub-center verifies the running state and configuration integrity of the probe within a time window to obtain a schedulable standby state node and a healthy attempt; The power grid system triggers the corresponding external mechanism of the abnormal branch to closed-loop control the abnormal scene in the cross-domain trust construction process to obtain an abnormal disposal result and an audit record.

4. The method of claim 2, wherein, Based on the hierarchical node management architecture, the monitoring tasks are arranged through template definition boundaries and atomic fragment splitting to obtain an atomic task list that can be cross-domain allocated, comprising the following steps: The main center generates a signed task template with version identification and writes it into a policy library to obtain a signed task template; The sub-center refines the monitoring tasks by receiving the task template to obtain a set of atomic fragments; The scheduler schedules and allocates the execution nodes of the atomic fragments through the node directory and real-time load of the probe to obtain the atomic task list that can be cross-domain allocated.

5. The method of claim 4, wherein, The method comprises the following steps of: The probe performs landing implementation on the monitoring task by checking the execution list signature and version, and obtains task execution results and signature digest; The sub-center signs, de-duplicates, and synchronizes the task execution results to the main center, and the sub-center collates and summarizes the data of the task execution results to obtain effective task data The scheduler dynamically schedules abnormal execution scenarios by monitoring the state of the probe, and obtains task execution closed loop results.

6. The method of claim 4, wherein, The method comprises the following steps of: The sub-center checks the health state of the probe by collecting probe heartbeat and metric data, and obtains a healthy probe set and an abnormal probe identifier; The scheduler scores and reorders the healthy probes, optimizes the execution node and dispatching order of the task fragments according to the DRR / WFQ algorithm, and obtains an optimized task execution list; The probe controls the rate of the task fragments and performs landing implementation by loading a speed limit and a concurrent upper limit in the kernel and the user state, and obtains task execution progress and state feedback The power grid system dynamically schedules abnormal execution scenarios to obtain abnormal disposal results and fragment redistribution schemes; The sub-center checks the execution results by de-duplication, the main center completes global archiving, result uniqueness, and cross-domain weight updating, and the task execution whole-process results are summarized and closed looped to obtain the closed loop data, the control loop, and the feedback results; The dynamic scheduling comprises soft error trigger exponential backoff, hard error trigger standby takeover, three heartbeat timeout trigger disconnection fragment redistribution, and recovery online trigger re-integration.

7. The method of claim 6, wherein, The process of the arrangement and the dynamic scheduling is safely and compliantly constrained by configuring a signature and heartbeat check to build trust and control ability, and a whole-cycle safety compliance guarantee is obtained, comprising the following steps: The main center standardizes and safely encapsulates the configurations required for cross-domain cooperation by generating a configuration package with a version number, a timestamp, and a signature, and obtains a configuration package with a security identifier; The sub-center obtains configuration verification results and effective local configurations by verifying and comparing the versions of the received configuration packages; The probe obtains configuration activation results and probe state feedback by safely activating and verifying the effectiveness of the received configurations; The sub-center obtains probe health state determination results by continuously monitoring the running state of the probe; The isolated probe performs compliance repair and state reset on the abnormal probe by completing integrity self-check and configuration consistency check, and obtains a healthy probe node; The power grid system obtains a whole-cycle safety compliance guarantee by recording all events.

8. A power grid probe node elastic scheduling and security control system, characterized in that, The system comprises: An architecture construction module is configured to construct trust and management capabilities of a power grid cross-domain collaborative underlying architecture to obtain a layered node management architecture. An inventory generation module is configured to arrange monitoring tasks by defining boundaries and splitting atomic shards based on the layered node management architecture to obtain an atomic task inventory that can be allocated across domains. A dynamic scheduling module is configured to dynamically schedule atomic tasks in the atomic task inventory based on the layered node management architecture and the probes to obtain a closed-loop data, control loop and feedback result. A compliance constraint module is configured to perform security compliance constraints on the process of the trust and management capability construction, the arrangement and the dynamic scheduling by configuring signatures and heartbeat checks to obtain whole-cycle security compliance guarantees.

9. An electronic device, comprising: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor executes the computer program to implement the method of any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the method of any one of claims 1-7.

Images