Iot-based distributed communication cabinet group cooperative control method and system

Abstract

This invention relates to the field of signal interference identification technology, and discloses a distributed communication cabinet group collaborative control method and system based on the Internet of Things, including: automatically collecting and semantically mapping full-dimensional data; calculating node collaborative adaptability to complete heterogeneous node admission judgment; dividing a decentralized dynamic collaborative domain; electing domain coordination nodes and building a distributed collaborative infrastructure; calculating decentralized distributed clock synchronization and deviation within the domain; planning a unified collaborative timing window and completing full-link timing binding; combining node twins to complete cross-validation and anomaly identification of collaborative data; building a three-layer hierarchical decision architecture; screening feasible collaborative strategies through multi-objective rigid constraints; completing distributed command interlocking and priority control; calculating and pre-diagnosing node failure probability through node twins; planning fault pre-collaborative backup strategies and executing three-level gradient self-healing; and completing incremental iteration of the collaborative decision model and full lifecycle collaborative operation and maintenance through federated learning.

Description

Technical Field

[0001] This invention relates to the field of collaborative control technology for communication cabinets, and more specifically to a method and system for collaborative control of distributed communication cabinet groups based on the Internet of Things. Background Technology

[0002] Currently, industrial control software related to the collaborative control of distributed communication cabinet groups based on the Internet of Things has completed the iteration from single cabinet remote monitoring to master-slave group management and control, and then to the initial distributed architecture. However, there are still many core drawbacks and key scenario adaptation defects, which cannot meet the collaborative control needs of high reliability, hard real-time and strong security in fields such as power, rail transit, industry and municipal.

[0003] In existing technologies, fixed master-slave or centralized architectures pose a core risk of a single point of failure in the master node leading to the loss of control of the entire group. Link interruptions and incomplete connectivity can easily create isolated control zones, failing to balance global optimization with local autonomy. Heterogeneous devices from different manufacturers and industries use gateways for data conversion, hindering native control-level collaboration. Existing technologies separate clock synchronization from business processes, resulting in substandard synchronization accuracy in underground scenarios without location tracking, easily leading to protection malfunctions and interlock failures. Furthermore, they cannot accurately distinguish between genuine faults and intermittent data anomalies caused by strong interference, leading to frequent false triggers / refusals and significant imbalances in node computing power allocation. Existing collaborative decision-making suffers from a binary contradiction: delayed centralized response and global imbalance in distributed systems. Multi-objective optimization relies on weight coefficients. Security protection is an external, add-on approach, conflicting with hard real-time collaborative performance and posing risks of unauthorized control and virus spread. Fault handling is entirely reactive, lacking pre-emptive collaboration and full lifecycle preventative maintenance capabilities, with strategy optimization lagging significantly behind dynamic changes in operating conditions.

[0004] Therefore, there is a need to provide a collaborative control method and system for distributed communication cabinet groups based on the Internet of Things. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for collaborative control of distributed communication cabinet groups based on the Internet of Things. To solve the above-mentioned problems in the prior art, this invention achieves this through the following technical solution:

[0006] In a first aspect, the distributed communication cabinet group collaborative control method based on the Internet of Things provided in the embodiments of the present invention specifically includes the following steps:

[0007] Step 1: Construct a collaborative control ontology model, complete the full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, complete the heterogeneous node admission judgment through node collaborative adaptability calculation, and realize dynamic collaborative domain partitioning and decentralized domain coordination node election.

[0008] Step 2: Combining the divided collaborative domains, complete the decentralized distributed clock synchronization and deviation calculation within the domain using the Raft consensus algorithm, plan a unified collaborative timing window and complete the full-link timing binding, and complete the collaborative data cross-validation and anomaly identification based on node twins;

[0009] Step 3: Combining the effective collaborative data after time-series binding, build a three-layer hierarchical decision-making architecture of local real-time, regional optimization, and global iteration. Select feasible collaborative strategies through unweighted multi-objective rigid constraints, and complete distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation.

[0010] Step 4: Based on the execution results of the generated collaborative strategy, the probability of node failure is calculated and pre-diagnosed through node twins. A pre-collaborative backup strategy for failure is planned and a three-level gradient self-healing is executed. Incremental iteration of the collaborative decision-making model and full lifecycle collaborative operation and maintenance are completed through federated learning.

[0011] Secondly, the distributed communication cabinet group collaborative control system based on the Internet of Things provided in this embodiment of the invention specifically includes the following modules:

[0012] Matching and Judgment Module: Constructs a collaborative control ontology model, completes full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, completes heterogeneous node admission judgment through node collaborative adaptability calculation, and realizes dynamic collaborative domain partitioning and decentralized domain coordinated node election.

[0013] Verification and identification module: Combining the divided collaborative domains, it completes the decentralized distributed clock synchronization and deviation calculation within the domain through the Raft consensus algorithm, plans a unified collaborative timing window and completes the full-link timing binding, and completes collaborative data cross-verification and anomaly identification based on node twins;

[0014] Decision Architecture Module: Combining effective collaborative data after time-series binding, a three-tiered hierarchical decision architecture is built, consisting of local real-time, regional optimization, and global iteration. Feasible collaborative strategies are selected through unweighted multi-objective rigid constraints, and distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation are achieved.

[0015] Collaborative Iteration Module: Combining the execution results of the generated collaborative strategies, it calculates and pre-diagnoses the probability of node failure through node twins, plans pre-collaborative backup strategies for failures and executes three-level gradient self-healing, and completes incremental iteration of the collaborative decision-making model and full lifecycle collaborative operation and maintenance through federated learning.

[0016] The beneficial effects of this invention are:

[0017] 1. Construct a node natively adaptable and dynamically reconfigurable collaborative domain architecture. Through collaborative control ontology modeling and node collaborative adaptability calculation, heterogeneous devices can be plugged and played by configuring point tables for each device. At the same time, through a decentralized dynamic coordination node election and link interruption self-reconfiguration mechanism, the specific problems of single-point failure of the master control cabinet in the fixed master-slave architecture and the formation of control islands in the tunnel / pipe gallery after the link interruption, which leads to business paralysis, are completely solved. Through decentralized distributed clock consensus and full-time window binding, the pain points of existing technologies such as clock synchronization and business process separation, insufficient synchronization accuracy in underground scenarios without positioning, and power differential protection malfunction / track cross-linking lock failure caused by time deviation are solved. Through node twin collaborative domain cross-validation, the real faults and intermittent data anomalies caused by strong interference are accurately distinguished, solving the problems of frequent false alarms and false control in existing technologies.

[0018] 2. By adopting a three-tiered hierarchical decision-making architecture, the dual contradiction of lagging response in centralized decision-making and global imbalance in fully distributed decision-making in existing technologies is resolved. Through unweighted multi-objective rigid constraint optimization, the pain point of existing technologies relying on weight coefficients for multi-objective collaboration and neglecting one aspect for another is addressed. Lightweight national cryptographic encryption is integrated into the entire instruction process, combined with physical isolation between OT and IT planes. Through node twin fault pre-diagnosis and pre-collaborative preparation, the upgrade from post-event emergency response to pre-event prediction is achieved, solving the pain point of unpreparedness and business interruption caused by sudden faults in existing technologies. Through three-level gradient self-healing, precise fault isolation and non-propagation are achieved, combined with federated learning incremental iteration and non-stop collaborative operation and maintenance. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of the steps of the distributed communication cabinet group collaborative control method based on the Internet of Things provided in Embodiment 1 of the present invention;

[0021] Figure 2 This is a schematic diagram of the structure of the distributed communication cabinet group collaborative control system based on the Internet of Things provided in Embodiment 2 of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art in conjunction with the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0023] Example 1: As Figure 1 As shown in the figure, the distributed communication cabinet group collaborative control method based on the Internet of Things provided in this embodiment of the invention specifically includes the following steps:

[0024] Step 1: Construct a collaborative control ontology model, complete the full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, complete the heterogeneous node admission judgment through node collaborative adaptability calculation, and realize dynamic collaborative domain partitioning and decentralized domain coordination node election.

[0025] In a specific embodiment, the full-dimensional capability data of the communication cabinet nodes is automatically acquired. After all communication cabinet nodes to be networked are powered on, the edge computing module built into the node automatically acquires the full-dimensional capability data of the node from three levels without discrimination, without manual triggering. The specific acquisition method is as follows:

[0026] Hardware capability layer data acquisition: The edge computing module reads the rated parameters of the power module, the number and type of switch ports, the type and range of built-in sensors, the computing power parameters of the edge computing module, and the type and number of wired / wireless communication links of the communication cabinet node in real time through the hardware driver bus, and generates the hardware capability set of the corresponding node. , where i is the unique node number;

[0027] Protocol layer data acquisition: The edge computing module, through its built-in full protocol stack, traverses and reads all communication protocol types natively supported by the communication cabinet nodes, generating the corresponding protocol set for each node. ;

[0028] Control Function Layer Data Acquisition: The edge computing module reads all control function types that the communication cabinet node can execute through the node control logic unit, including load switching, fault isolation, port on / off control, link scheduling, access control, and synchronous data acquisition, and generates the corresponding node's control function set. ;

[0029] Construct a collaborative control ontology model that covers the common capabilities of all communication cabinet nodes. The collaborative control ontology model defines a unified hardware capability dictionary, protocol specification semantic dictionary, and control function semantic dictionary. Each dictionary entry corresponds to a unique standardized semantic identifier, completely shielding the differentiated expressions of manufacturers, models, specifications, and hardware.

[0030] The hardware capability set, protocol set, and control function set of the i-th communication cabinet node are semantically matched with the corresponding dictionary of the ontology model to generate the standardized capability set of the corresponding node. ,in, It is the union of standardized semantic entries after matching the hardware capability set, protocol specification set, and control function set;

[0031] Obtain the standardized capability set of the communication cabinet node, the standardized capability requirement set of the target collaborative domain, and the hardware health status parameters of the communication cabinet node. The hardware health status parameters are obtained by the ratio of the normal working time to the total time within the statistical period. The value range is [0,1], where 1 represents that the node hardware is completely fault-free and 0 represents that the node hardware is completely failed.

[0032] Through the formula:

[0033]

[0034] Obtain the node collaboration adaptability of the i-th communication cabinet node. The value range is [0,1], where, Let be the hardware health status parameters of the i-th communication cabinet node. Let i be the set of standardized capabilities for the i-th communication cabinet node. A standardized set of capability requirements for the target collaborative domain;

[0035] When the node collaboration adaptability is greater than or equal to 0.6, the corresponding node is determined to be semantically adapted to the target collaboration domain and can be connected to the OT control collaboration plane to achieve control-level collaboration; when the node collaboration adaptability is less than 0.6, the adaptation is determined to be invalid.

[0036] Based on the geographical location, physical link connectivity, and business association attributes of the communication cabinet node, match up to 3 candidate collaboration domains, calculate the node collaboration adaptability between the node and each candidate collaboration domain, and automatically connect the node to the candidate collaboration domain corresponding to the maximum node collaboration adaptability.

[0037] Within each collaborative domain, all communication cabinet nodes interact point-to-point with neighboring cabinets every preset time period to synchronize their latest node collaboration adaptability. All nodes combine a completely consistent node collaboration adaptability dataset and automatically elect the node with the maximum node collaboration adaptability in the current domain as the domain coordination node. There is no fixed master control cabinet. The domain coordination node is only responsible for data interaction scheduling within the domain, cross-domain collaborative connection, and unified release of collaborative timing windows.

[0038] When a cross-domain link between collaborative domains or a link between a collaborative domain and the cloud is interrupted, the affected communication cabinet nodes automatically detect the connectivity of the links between neighboring cabinets, and, in conjunction with the real-time updated node collaboration adaptability, complete the division of temporary autonomous collaborative domains and the election of temporary domain coordination nodes within a preset time period.

[0039] Data interaction between different collaborative domains is completed through the domain coordination nodes of both parties; the domain coordination node that initiates the collaborative request transmits core collaborative parameters to the target domain coordination node. The core collaborative parameters include: collaborative business type, action timing requirements, and collaborative boundary conditions, but do not transmit full runtime data.

[0040] When more than half of the nodes in the collaborative domain are offline or all cross-domain links are completely interrupted, the domain coordination node automatically cuts off the collaborative control of non-core services, while retaining the security-related collaborative functions of fault isolation, emergency shutdown, and core service transmission. Nodes in the domain only interact with security-related collaborative data.

[0041] Step 2: Combining the divided collaborative domains, complete the decentralized distributed clock synchronization and deviation calculation within the domain using the Raft consensus algorithm, plan a unified collaborative timing window and complete the full-link timing binding, and complete the collaborative data cross-validation and anomaly identification based on node twins;

[0042] In a specific embodiment, the Raft consensus algorithm is combined to perform a decentralized distributed clock consensus in each collaborative domain, which is adapted to underground tunnels and utility tunnels without GPS signals. The domain coordination node in the collaborative domain broadcasts its own clock reference value to all nodes in the domain every 20ms. After receiving the reference value, all nodes in the domain complete the bidirectional transmission of clock messages through bidirectional point-to-point interaction with neighboring cabinets, and record the four key timestamps of message transmission and reception.

[0043] The formula and parameter definitions for calculating clock synchronization deviation and link delay are as follows:

[0044]

[0045]

[0046] Obtain clock synchronization deviation With link delay ,in, Let be the time when the i-th communication cabinet node receives the response message from the j-th node. This refers to the time when the i-th communication cabinet node sends a clock message to the j-th communication cabinet node. The time when the j-th communication cabinet node sends the response message back to the i-th node is specified. The time at which the j-th communication cabinet node receives the clock message from the i-th node;

[0047] Each node corrects its local clock in real time based on the calculated clock synchronization deviation with neighboring nodes. The domain coordination node dynamically adjusts the start time offset of the coordination timing window based on the maximum absolute value of the clock synchronization deviation among all nodes in the domain.

[0048] The domain coordination node, in conjunction with the synchronized unified clock reference, plans a unified collaborative timing window for all collaborative services within the collaborative domain. Each collaborative timing window is divided into three consecutive sub-windows: a data acquisition timing window, a transmission timing window, and an execution timing window. The duration of each sub-window is fixed according to the service type. The domain coordination node synchronizes the planned collaborative timing window to all nodes within the domain.

[0049] For example, the duration of each sub-window for power differential protection is 200μs, the duration of each sub-window for industrial motion control is 500μs, and the duration of each sub-window for rail transit train control is 1ms.

[0050] At the start of the collection timing window, all communication cabinet nodes synchronously start collecting collaborative service-related operational data. The collected data includes node load current, voltage, port status, link quality, and service traffic data. All collection actions are completed before the end of the collection timing window to ensure that the collected data of all nodes are operational data at the same time segment.

[0051] At the start of the transmission timing window, all communication cabinet nodes synchronously transmit the core collaborative data they have collected to adjacent nodes within the collaborative domain through the time-sensitive flow channel of the OT control collaborative plane. The data transmission is completed before the end of the transmission timing window.

[0052] At the start of the execution timing window, all communication cabinet nodes synchronously complete the collaborative decision calculation and synchronously execute the corresponding collaborative control actions within the execution timing window;

[0053] In the underlying network, physically isolated time-sensitive traffic channels and non-real-time monitoring channels are divided. Core real-time traffic such as collaborative control commands, synchronous data acquisition, and clock synchronization messages are transmitted only through the time-sensitive traffic channels. The channels adopt a time-gated scheduling mechanism to reserve dedicated transmission time slots for traffic in each time window.

[0054] A lightweight node twin is constructed that corresponds one-to-one with the physical node. The node twin is constructed by combining the standardized node capability set generated in step 1. The running cycle is completely synchronized with the collaborative timing window. Within each collaborative timing window, the data collected by the physical node is synchronously updated to the node twin.

[0055] The node twin combines the stable operating data of the physical node over the past 72 hours to construct a normal operating condition baseline, including the normal fluctuation range of parameters such as voltage, current, temperature, and link traffic. The baseline is automatically updated every 24 hours according to the operating status of the physical node.

[0056] For node data collected within the current acquisition time window, the node twin first compares it with the normal operating condition baseline. If the data exceeds the normal fluctuation range, it is initially judged as suspected abnormal data.

[0057] For suspected abnormal data, the domain coordination node calls the synchronously collected data of the three adjacent communication cabinet nodes for cross-verification. If the synchronous data of the adjacent nodes are all within the normal fluctuation range and the link transmission status is normal, it is determined to be intermittent data abnormality caused by strong electromagnetic interference or instantaneous sensor drift. If the synchronous data of the adjacent nodes are synchronously abnormal and there is a business logic relationship with the abnormal data of the corresponding node, it is determined to be a real equipment failure or line abnormality.

[0058] For intermittent data anomalies, the predicted value of the normal operating condition baseline of the node twin is used to replace the abnormal data in subsequent collaborative decision-making without triggering alarms or control actions; for real fault data, the fault data is immediately synchronized to all nodes in the domain.

[0059] The overall anomaly degree of the nodes is calculated using the formula:

[0060]

[0061]

[0062] Obtain the overall anomaly degree of the nodes ,in, Let be the anomaly score of the k-th collected parameter at the i-th node, with a value range of [0,1]. For the i-th communication cabinet node, the measured value of the k-th acquisition parameter within the current acquisition time window. This represents the upper limit of normal fluctuation for the k-th parameter collected at the i-th node in the normal operating baseline. This represents the lower limit of normal fluctuation for the k-th collected parameter at the i-th node in the normal operating baseline. Let the anomaly degree of the first collected parameter of the i-th node be denoted as . Let the anomaly degree of the second collected parameter of the i-th node be denoted as . Let N be the anomaly degree of the Nth collected parameter of the i-th node. This represents the total number of parameters collected by a single node. Index of the number of parameters collected by a single node;

[0063] When the overall anomaly rate of a node is ≥0.2, the data collected by the corresponding node is suspected to be abnormal, and the cross-validation process is initiated; when the overall anomaly rate of a node is <0.2, the data is determined to be normal and directly participates in collaborative decision-making.

[0064] If the overall node anomaly rate of a node is ≥0.2 within three consecutive collaborative timing windows, and cross-validation determines it to be a genuine hardware anomaly, the hardware health status parameters of the corresponding node are automatically updated. This updates the node collaboration adaptability, triggering the re-election of domain coordination nodes and the reconstruction of the collaboration domain;

[0065] The domain coordination node calculates the computing power reserve of all nodes in the domain every 100ms. For nodes with less than 30% computing power reserve, some of their computing tasks, such as data preprocessing, anomaly identification, and twin simulation, are scheduled to be executed on adjacent nodes with more than 60% computing power reserve.

[0066] Step 3: Combining the effective collaborative data after time-series binding, build a three-layer hierarchical decision-making architecture of local real-time, regional optimization, and global iteration. Select feasible collaborative strategies through unweighted multi-objective rigid constraints, and complete distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation.

[0067] In a specific embodiment, a three-tiered hierarchical collaborative decision-making architecture is constructed, consisting of a local real-time decision-making layer, a regional collaborative optimization layer, and a global offline iterative layer. The decision boundaries of each layer are clearly defined. The specific implementation method is as follows:

[0068] Local real-time decision-making layer: The edge computing module deployed in each communication cabinet node is responsible for fault isolation, emergency shutdown and real-time load scheduling. The decision-making combines locally collected data and core collaborative data from neighboring cabinets.

[0069] Regional Collaborative Optimization Layer: Deployed in the domain coordination node cluster of each regional collaborative group, responsible for load balancing, link resource scheduling, and multi-service collaborative optimization within the region, and making decisions based on the core operational data of all collaborative domains within the region;

[0070] Global Offline Iteration Layer: Deployed on the cloud-based global collaboration platform, it is responsible for offline training of collaborative decision-making models, optimization of global operation strategies, and full lifecycle operation and maintenance planning. Model training adopts federated learning mode, only obtaining the model gradients uploaded by each node, without obtaining the original running data. The optimized model is distributed to each node for local execution.

[0071] The four core objectives of collaborative decision-making are defined as four independent rigid constraint boundaries, completely abandoning weighting coefficients and weighted summation calculations. The specific constraint boundaries are: Reliability constraint: Collaborative actions must not cause any node's operating parameters to exceed the equipment's rated range; Real-time constraint: Collaborative decisions and action execution must be completed within the corresponding collaborative timing window; Security constraint: Collaborative actions must not trigger security protection actions or cause core business interruptions; Energy efficiency constraint: Collaborative actions must not cause the overall energy consumption within the collaborative domain to exceed the baseline energy consumption by 10%.

[0072] When making collaborative decisions, firstly, all feasible collaborative strategies that simultaneously satisfy the above four rigid constraint boundaries are screened out, and then the strategy with the optimal collaborative domain load balancing is selected as the final execution strategy from the feasible strategies.

[0073] The calculation of collaborative domain load balancing and its dual-scenario application, with the following formula and parameter definitions:

[0074]

[0075]

[0076] The load balancing degree of the collaborative domain is obtained, where is , is , is , is , is ;

[0077] From all feasible strategies that satisfy the four major constraints, the strategy with the minimum corresponding Bd value is selected as the final execution strategy to achieve load balancing of nodes within the domain.

[0078] All collaborative control commands are divided into four fixed priorities, from high to low: Level 1 emergency safety commands, Level 2 real-time collaborative commands, Level 3 non-real-time optimization commands, and Level 4 operation and maintenance control commands. High-priority commands directly preempt the execution channel to ensure that safety actions in emergency scenarios are executed first.

[0079] Within the collaborative domain, a unique distributed timing mutex is set for each controllable hardware resource (power switch, port, link). Before any collaborative instruction is issued and executed, it must first acquire the distributed lock of the corresponding control resource.

[0080] All collaborative control commands are intrinsically encrypted using the lightweight national cryptographic SM4 algorithm during generation. Encryption and decryption operations are completed in the hardware encryption unit of the node edge computing module. The encryption / decryption delay of a single command is ≤100μs, which does not affect the performance of hard real-time collaborative control at all, solving the defect of real-time degradation caused by external encryption in existing technologies. At the same time, combined with the national cryptographic SM2 algorithm, a unique asymmetric key pair is generated for each communication cabinet node to build a decentralized distributed identity authentication system. Command interaction and data transmission between nodes in the collaborative domain are all completed through two-way identity authentication using the two-way key pair.

[0081] The system constructs a physically isolated OT control collaboration plane and an IT monitoring and management plane. The OT control collaboration plane only carries core real-time traffic such as collaborative control commands, synchronous data acquisition, and clock synchronization messages. It only transmits data point-to-point between communication cabinet nodes within the collaboration domain and does not connect to the external IT network at all. The IT monitoring and management plane only carries non-real-time monitoring, operation and maintenance, and log data and connects to the OT control collaboration plane through a one-way isolation gateway.

[0082] All collaborative control commands are bound to a unique execution timing window and execution result feedback window. After a node completes the execution of the command within the execution timing window, the execution result is synchronized to all nodes in the collaborative domain and the domain coordination node within the feedback window. If the command execution fails, the domain coordination node immediately regenerates a backup collaborative strategy within one collaborative timing window and sends it to the corresponding node for execution.

[0083] The command execution success rate of the communication cabinet node is obtained by comparing the number of collaborative commands successfully executed by the communication cabinet node within the statistical period with the total number of collaborative commands issued by the communication cabinet node.

[0084] When the instruction execution success rate is less than 0.95%, the execution reliability of the corresponding node is determined to be insufficient. The non-core control tasks of the corresponding node are automatically scheduled to be executed on adjacent high-reliability nodes to ensure the overall reliability of collaborative control.

[0085] When the instruction execution success rate of a node is less than 0.9 for two consecutive statistical periods, the hardware health status parameter of the corresponding node is automatically updated to the instruction execution success rate, thereby updating the node's coordination adaptability and triggering a re-election of the domain coordination node to avoid coordination failure caused by hardware aging in advance.

[0086] Step 4: Based on the execution results of the generated collaborative strategy, the probability of node failure is calculated and pre-diagnosed through node twins. A pre-collaborative backup strategy for failure is planned and a three-level gradient self-healing is executed. Incremental iteration of the collaborative decision-making model and full lifecycle collaborative operation and maintenance are completed through federated learning.

[0087] In a specific embodiment, the node twin collects real-time operational data throughout the entire lifecycle of the physical node, including voltage fluctuations of the power module, the number of switching port operations, sensor drift amplitude, transmission error rate of the communication module, and equipment operating temperature and humidity. Combined with a normal aging model of the equipment, it predicts the remaining lifespan and probability of failure of each core component of the node. The specific implementation method is as follows:

[0088] The ratio of the running time of the core component of the communication cabinet node to its rated service life is obtained to get the running aging value, which is in the range of [0,1]. The arithmetic square root of the product of the running aging value and the corresponding overall abnormality of the node is calculated to obtain the probability of node failure.

[0089] When the probability of a node failure is ≥0.3, the node is determined to have a high risk of failure, is marked as a node in preparation for failure, and the failure pre-diagnosis process is initiated to achieve early prediction of failure.

[0090] The higher the probability of node failure, the higher the risk of node failure, and the redundancy level of the pre-coordination strategy is automatically adjusted; when the probability of node failure is ≥0.5, the core business of the faulty backup node is automatically hot-backed to the two adjacent communication cabinet nodes in advance.

[0091] For communication cabinet nodes marked as fault standby nodes, fault pre-coordination preparation is automatically executed. The domain coordination node in the coordination domain automatically plans backup coordination strategies for the fault standby nodes, including load takeover schemes, link switching schemes, and service redundancy schemes. The backup strategies are synchronized to the two adjacent communication cabinet nodes. The adjacent nodes complete hardware resource reservation, protocol configuration preloading, and control logic pre-verification in advance. When a fault standby node experiences a real failure, the adjacent nodes can complete load takeover and service switching within 10ms.

[0092] For faults of different levels, a three-level gradient self-healing strategy is implemented to achieve precise fault isolation and prevent fault propagation. The specific implementation method is as follows:

[0093] Local collaborative domain self-healing: When a single communication cabinet node fails, the collaborative domain automatically executes the pre-collaborative backup strategy, with adjacent nodes taking over the load and providing service redundancy for the failed node, while remotely powering off and isolating the failed node. Fault handling is completed within one collaborative time window.

[0094] Self-healing within the regional collaboration group: When a link is interrupted or more than half of the nodes fail in the entire collaboration domain, the regional collaboration group automatically schedules the services of the failed domain to be taken over by the adjacent normal collaboration domain, and at the same time completes the resource reallocation and topology reconstruction within the region.

[0095] Global collaborative recovery: When a large-scale link interruption occurs across regions or multiple regional collaborative groups fail, the cloud-based global collaborative platform initiates a global recovery strategy, re-plans the global collaborative topology, schedules redundant resources across the entire network to complete business recovery, and executes a gradient degradation strategy to prioritize the operation of core security services.

[0096] Combining local operational data with collaborative execution results, the local collaborative decision-making model is incrementally trained every 24 hours. After training, only the gradient parameters of the model are uploaded to the cloud-based global collaborative platform, without uploading the original operational data. The cloud platform aggregates the gradient parameters of all nodes, completes the aggregation and optimization of the global model, and then distributes the optimized global model to all nodes, where each node updates its model locally.

[0097] The system monitors the operational status of the collaborative domain in real time, including node health status, link quality, service load, and environmental interference intensity. It automatically adjusts the collaborative strategy according to changes in operational status: when the operational status is stable and there is no risk of failure, the collaborative strategy focuses on energy efficiency optimization and load balancing; when the operational status fluctuates and there is a risk of failure, the collaborative strategy focuses on security, reliability, and rapid response; when extreme operational conditions or link interruptions occur, the collaborative strategy automatically switches to a gradient degradation mode to prioritize the protection of core security services.

[0098] The node twin records the runtime, number of actions, fault records, and aging status of physical nodes in real time. Combined with full lifecycle data, it predicts the optimal maintenance time for nodes and generates preventative maintenance plans. It automatically schedules the services of nodes to be maintained to adjacent nodes in advance, and during the maintenance period, the adjacent nodes complete the redundant operation of the services.

[0099] Example 2: Figure 2 As shown in the embodiment of the present invention, the distributed communication cabinet group collaborative control system based on the Internet of Things specifically includes the following modules:

[0100] Matching and Judgment Module: Constructs a collaborative control ontology model, completes full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, completes heterogeneous node admission judgment through node collaborative adaptability calculation, and realizes dynamic collaborative domain partitioning and decentralized domain coordinated node election.

[0101] Verification and identification module: Combining the divided collaborative domains, it completes the decentralized distributed clock synchronization and deviation calculation within the domain through the Raft consensus algorithm, plans a unified collaborative timing window and completes the full-link timing binding, and completes collaborative data cross-verification and anomaly identification based on node twins;

[0102] Decision Architecture Module: Combining effective collaborative data after time-series binding, a three-tiered hierarchical decision architecture is built, consisting of local real-time, regional optimization, and global iteration. Feasible collaborative strategies are selected through unweighted multi-objective rigid constraints, and distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation are achieved.

[0103] Collaborative Iteration Module: Combining the execution results of the generated collaborative strategies, it calculates and pre-diagnoses the probability of node failure through node twins, plans pre-collaborative backup strategies for failures and executes three-level gradient self-healing, and completes incremental iteration of the collaborative decision-making model and full lifecycle collaborative operation and maintenance through federated learning.

[0104] The above provides a detailed description of one embodiment of the present invention, but the content described is only a preferred embodiment of the present invention and should not be considered as limiting the scope of the present invention. The above formulas are all dimensionless numerical calculations, and the formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world situation. The preset parameters in the formulas are set by those skilled in the art based on actual conditions and historical experience, and can be adjusted according to actual conditions. The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. All equivalent changes and improvements made in accordance with the scope of the present invention should still fall within the patent coverage of the present invention.

Claims

1. A distributed communication cabinet group collaborative control method based on the Internet of Things, characterized in that, Includes the following steps: Construct a collaborative control ontology model, complete the full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, complete the heterogeneous node admission determination through node collaborative adaptability calculation, and realize dynamic collaborative domain partitioning and decentralized domain coordination node election. Based on the divided collaborative domains, the Raft consensus algorithm is used to complete the decentralized distributed clock synchronization and deviation calculation within the domain, plan a unified collaborative timing window and complete the full-link timing binding, and complete the collaborative data cross-validation and anomaly identification based on node twins; By combining effective collaborative data after time-series binding, a three-tiered hierarchical decision-making architecture of local real-time, regional optimization, and global iteration is built. Feasible collaborative strategies are selected through unweighted multi-objective rigid constraints, and distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation are completed. Based on the execution results of the generated collaborative strategy, the probability of node failure is calculated and pre-diagnosed through node twins. A pre-collaborative backup strategy for failure is planned and a three-level gradient self-healing is executed. Federated learning is used to complete the incremental iteration of the collaborative decision-making model and the collaborative operation and maintenance throughout the entire lifecycle.

2. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for constructing the collaborative control ontology model is as follows: A collaborative control ontology model covering the common capabilities of all communication cabinet nodes is pre-built. Within the model, a unified hardware capability dictionary, protocol specification semantic dictionary, and control function semantic dictionary are defined, and a unique standardized semantic identifier is configured for each dictionary entry. After the network communication cabinet node is powered on, the node’s built-in edge computing module automatically reads the corresponding parameters of the node from three levels: hardware capability layer, protocol specification layer, and control function layer, and generates hardware capability set, protocol specification set, and control function set. The three sets are then semantically matched with the corresponding dictionary of the ontology model to generate a standardized capability set of the node. The standardized capability set is the union of the standardized semantic entries after the three sets are matched.

3. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for determining the collaborative adaptability of computing nodes is as follows: The node hardware health status parameters are obtained by the ratio of the normal working time of the node to the total time within the statistical period. The parameter values ​​range from [0,1]. The standardized capability set of the node and the standardized capability requirement set of the target collaborative domain are obtained. The standardized capability requirement set of the target collaborative domain is the union of the standardized capability sets of all nodes that have been connected in the domain. The node collaboration adaptation degree is calculated using a preset formula, with the adaptation degree ranging from [0,1]. When the node collaboration adaptation degree is greater than or equal to 0.6, the node is deemed to have a valid semantic adaptation with the target collaboration domain, and access to the OT control collaboration plane is allowed. When the node collaboration adaptation degree is less than 0.6, the adaptation is deemed invalid.

4. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for dividing the dynamic cooperative domain is as follows: Based on the geographical location, physical link connectivity, and business association attributes of the communication cabinet node, match up to 3 candidate collaboration domains for the node, calculate the collaboration adaptability between the node and each candidate collaboration domain, and automatically connect the node to the candidate collaboration domain corresponding to the maximum adaptability. Each node in the collaborative domain interacts with its neighboring cabinets point-to-point every preset time period to synchronize its latest collaborative adaptation degree. Based on a consistent adaptation degree dataset, all nodes elect the node with the maximum adaptation degree in the domain as the domain coordination node. When the cross-domain link or the link with the cloud in the collaborative domain is interrupted, the affected node automatically detects the connectivity of the link with the neighboring cabinet and completes the division of the temporary autonomous collaborative domain and the election of the temporary coordinating node within a preset period based on the real-time adaptability.

5. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for achieving distributed clock synchronization is as follows: Combining the Raft consensus algorithm, a decentralized distributed clock consensus is executed in each collaborative domain. Every 20ms, the domain coordination node broadcasts its own clock reference value to all nodes in the domain. After receiving the reference value, the nodes in the domain complete the bidirectional transmission of clock messages through bidirectional point-to-point interaction with neighboring cabinets, and record the four key timestamps of message transmission and reception. The one-way delay and clock synchronization deviation of the link between nodes are calculated by a preset formula; each node corrects its local clock according to the clock synchronization deviation with the neighboring cabinet; the domain coordination node dynamically adjusts the start time offset of the coordination timing window according to the absolute value of the maximum clock synchronization deviation within the domain.

6. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for end-to-end timing binding is as follows: Based on the synchronized unified clock reference, the domain coordination node plans a unified collaborative timing window for all collaborative services within the collaborative domain. Each collaborative timing window is divided into three consecutive sub-windows: acquisition timing window, transmission timing window, and execution timing window. The duration of the sub-windows is fixed according to the service type, and the planned collaborative timing window is synchronized to all nodes within the domain. All nodes synchronously start collecting collaborative service operation data at the beginning of the collection time window and complete all collection actions before the end of the collection time window; at the beginning of the transmission time window, core collaborative data is synchronously transmitted point-to-point to adjacent nodes in the domain through the time-sensitive traffic channel of the OT control collaborative plane and the data transmission is completed before the end of the transmission time window. The collaborative decision calculation is completed synchronously at the start of the execution sequence window, and the collaborative control action is executed synchronously within the execution sequence window.

7. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for constructing a three-tiered hierarchical decision-making architecture is as follows: Construct a three-tiered hierarchical collaborative decision-making architecture consisting of a local real-time decision-making layer, a regional collaborative optimization layer, and a global offline iteration layer; The local real-time decision-making layer is deployed in the edge computing module of each communication cabinet node, and the decision-making of fault isolation, emergency shutdown and real-time load scheduling is completed based on the locally collected data and the core collaborative data of neighboring cabinets. The regional collaborative optimization layer is deployed in the domain coordination node cluster of each regional collaborative group, and makes decisions on load balancing, link resource scheduling and multi-service collaborative optimization within the region based on the core operation data of all collaborative domains within the region. The global offline iteration layer is deployed on a cloud-based global collaboration platform. The federated learning model is used to complete the offline training of the collaborative decision-making model, the optimization of the global operation strategy, and the full lifecycle operation and maintenance planning. Only the model gradients uploaded by each node are obtained, and the optimized model is distributed to each node for local execution.

8. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method of intrinsic encryption protection in the national cryptographic standard is as follows: When all collaborative control commands are generated, the lightweight national cryptographic SM4 algorithm is used for intrinsic encryption. The encryption and decryption operations are completed in the hardware encryption unit of the node edge computing module. Based on the national cryptographic SM2 algorithm, a unique asymmetric key pair is generated for each communication cabinet node to build a decentralized distributed identity authentication system. This system coordinates command interaction and data transmission between nodes within the domain and completes two-way identity authentication through the key pair. A physically isolated OT control and collaboration plane and an IT monitoring and management plane are constructed. The OT control and collaboration plane only carries core real-time traffic and transmits it only point-to-point between nodes within the domain. The IT monitoring and management plane is connected to the OT control and collaboration plane through a one-way isolation gateway and can only read status data from the OT plane in one direction.

9. The distributed communication cabinet group collaborative control method based on the Internet of Things according to claim 1, characterized in that, The method for performing three-level gradient self-healing is as follows: For different levels of faults, a three-level gradient self-healing strategy is implemented; when a single communication cabinet node fails, a pre-cooperative backup strategy is automatically implemented within the cooperative domain, with adjacent nodes taking over the load and redundancy of the faulty node, and remote power-off isolation of the faulty node is performed. Fault handling is completed within one cooperative time window. When a link is interrupted in the entire collaborative domain or more than half of the nodes fail, the regional collaborative group automatically schedules the services of the failed domain to be taken over by the adjacent normal collaborative domain, and completes the resource redistribution and topology reconstruction within the region. When a large-scale link interruption occurs across regions or multiple regional collaborative groups fail, the cloud-based global collaborative platform initiates a global recovery strategy, re-plans the global collaborative topology, schedules redundant resources across the entire network to complete service recovery, and executes a gradient degradation strategy.

10. A distributed communication cabinet group collaborative control system based on the Internet of Things, the system being used to execute the control method according to any one of claims 1-9, characterized in that, include: Matching and Judgment Module: Constructs a collaborative control ontology model, completes full-dimensional data collection and semantic matching of communication cabinet node hardware capabilities, protocol specifications, and control functions, completes heterogeneous node admission judgment through node collaborative adaptability calculation, and realizes dynamic collaborative domain partitioning and decentralized domain coordinated node election. Verification and identification module: Combining the divided collaborative domains, it completes the decentralized distributed clock synchronization and deviation calculation within the domain through the Raft consensus algorithm, plans a unified collaborative timing window and completes the full-link timing binding, and completes collaborative data cross-verification and anomaly identification based on node twins; Decision Architecture Module: Combining effective collaborative data after time-series binding, a three-tiered hierarchical decision architecture is built, consisting of local real-time, regional optimization, and global iteration. Feasible collaborative strategies are selected through unweighted multi-objective rigid constraints, and distributed instruction interlocking, national cryptographic intrinsic encryption, and OT / IT dual-plane physical isolation are achieved. Collaborative Iteration Module: Combining the execution results of the generated collaborative strategies, it calculates and pre-diagnoses the probability of node failure through node twins, plans pre-collaborative backup strategies for failures and executes three-level gradient self-healing, and completes incremental iteration of the collaborative decision-making model and full lifecycle collaborative operation and maintenance through federated learning.

Images