Central control equipment dynamic routing algorithm supporting access of multi-protocol terminal equipment

Abstract

The invention relates to the technical field of multi-device merging, in particular to a central control device dynamic routing algorithm supporting multi-protocol terminal device access. The method comprises the following steps of: acquiring a real-time communication signal in an access initialization stage, performing comprehensive protocol compatibility evaluation, and generating a multi-protocol dynamic access behavior portrait; obtaining a multi-dimensional operation state parameter of the central control equipment, and carrying out resource utilization rate calculation and one-by-one routing module capacity margin calculation to generate a precise load bearing capacity of each routing module; according to the real-time communication signal, carrying out adaptive routing adaptation request to obtain a merging priority of each device; and performing maximum concurrency protocol calculation and dynamic routing distribution boundary calculation based on the precise load bearing capacity and the multi-protocol dynamic access behavior portrait to obtain a dynamic routing adaptation capacity constraint. According to the invention, through dynamic and real-time adjustment of multi-protocol adaptive merging, the grid connection efficiency and response performance of multiple devices are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-device incorporation, and in particular to a dynamic routing algorithm for a central control device supporting access of multi-protocol terminal devices. Background Art

[0002] With the rapid development of emerging technologies and application scenarios such as the Internet of Things (IoT), smart manufacturing, and smart cities, various terminal devices have been widely deployed in systems such as traffic management, energy dispatch, and security monitoring. These terminal devices play a crucial role in achieving system intelligence and automation. They include sensors, actuators, cameras, PLCs, edge computing devices, and more. They use a variety of communication protocols, including Modbus, KNS, BACnet, MQTT, CoAP, ZigBee, and LoRa. Faced with complexities such as inconsistent protocol standards, a wide variety of devices, and widely varying data formats, achieving unified access and efficient management of multi-protocol terminal devices has become a core challenge in intelligent system integration.

[0003] Traditional central control systems often rely on static configuration or dedicated gateway devices for protocol conversion when connecting to terminal devices using multiple protocols. While these solutions can achieve a certain degree of protocol compatibility and data aggregation, they suffer from numerous issues such as slow response, poor scalability, and high adaptation costs when dealing with dynamic environments with high real-time requirements and frequently changing access devices. In real-world applications, terminal devices may come online, go offline, or change communication methods at any time. Traditional static adaptation mechanisms are no longer sufficient to meet the requirements for efficient, flexible, and sustainable system access. Furthermore, current central control systems generally lack intelligent judgment and adaptive scheduling mechanisms during terminal access. They are unable to automatically select the optimal access path and communication method based on dynamic factors such as network load, device status, and communication quality, limiting overall system performance and reliability. In complex environments with multiple terminals operating concurrently and large-scale devices collaborating, this lack of dynamic scheduling capabilities further exacerbates system bottlenecks, impacting the central control system's unified management and control of downstream devices. Summary of the Invention

[0004] In order to solve the above technical problems, the present invention proposes a dynamic routing algorithm for a central control device that supports access of multi-protocol terminal devices, so as to solve at least one of the above technical problems.

[0005] To achieve the above object, the present invention provides a dynamic routing algorithm for a central control device that supports access of multi-protocol terminal devices, comprising the following steps: Step S1: Collect real-time communication signals during the access initialization phase, perform comprehensive protocol compatibility assessment, and generate a multi-protocol dynamic access behavior profile; Step S2: Obtain multi-dimensional operating status parameters of the central control device, calculate resource utilization and capacity margin of each routing module, and generate the precise load carrying capacity of each routing module; Step S3: performing adaptive routing adaptation request according to the real-time communication signal, and performing device integration priority evaluation to obtain the integration priority of each device; Step S4: Calculate the maximum concurrent protocols and the dynamic routing allocation boundary based on the precise load carrying capacity and the multi-protocol dynamic access behavior profile to obtain the dynamic routing adaptation capacity constraint; Step S5: performing intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints, and performing intelligent protocol path adjustment according to the incorporation priority, thereby obtaining a multi-device intelligent adjustment incorporation path; Step S6: Identify the routing protocols with abnormal latency, optimize the routing resource topology, and perform multi-protocol routing adaptation and self-evolution based on the multi-device intelligent adjustment and incorporation paths to build a multi-protocol routing adaptation engine.

[0006] The present invention achieves the following beneficial effects: It proactively identifies and models the underlying behavioral structure of multiple communication protocol terminals during their initial access phase, eliminating the need for predefined protocol sets. By combining real-time signal acquisition with protocol behavior analysis, it accurately identifies core features such as the protocol type, interaction model, and handshake mechanism used by the terminal device. It constructs a "multi-protocol dynamic access behavior profile," enabling the central control device to model access behavior at the behavioral level, providing a key "soft label" foundation for subsequent dynamic adaptation. This significantly improves the system's adaptability to unknown, edge, or customized protocols, enhancing its protocol generalization and real-time responsiveness. It also meticulously monitors the real-time operational status of key resources within the central control device (CPU, memory, I / O channels, protocol conversion modules, etc.) to avoid resource bottlenecks. Unit-level calculation of routing module margins ensures clear, quantified, and controllable load capacity for each routing subsystem. This creates a precise load-carrying capacity profile, which serves as the core basis for dynamic scheduling and concurrency control, supporting highly reliable protocol routing. It effectively avoids anomalies such as "overloaded access" and "soft routing congestion," improving overall system stability and service quality assurance. The system adaptively generates routing adaptation requests dynamically based on communication content and protocol structure, eliminating manual configuration and improving the system's autonomous decision-making capabilities. By combining multiple dimensions such as device type, communication frequency, data importance, and protocol complexity, it scientifically assesses device access priority. This resolves the "competitive access" issue when multiple devices are connected simultaneously, implementing a value-based access ranking mechanism. It supports prioritizing access to high-value devices (such as master control units and security sensors) to ensure the system's "strategy optimality" under resource-constrained conditions. By integrating protocol behavior profiling with device resource capability analysis, it achieves dynamic concurrency control oriented toward behavioral semantics. Dynamic calculation of the maximum concurrent protocol capacity ensures resource scheduling flexibility and boundary control for the central control system in "high concurrency + multi-protocol" scenarios. Route allocation boundaries establish intelligent "hard limits" for the system, effectively preventing over-allocation, device congestion, and protocol conflicts. The formation of a "soft and hard boundary" mechanism for routing capacity facilitates strategic decision-making and scenario deduction for subsequent topology adjustments, enhancing the system's support for a multi-protocol ecosystem. Dynamic routing topology reconstruction supports operations such as module-level protocol channel rearrangement and path optimization replacement to form a "flexible network" that can adapt to changes; dynamically adjusts protocol paths according to the integration priority to build an "on-demand guidance, dynamic optimization" protocol access path planning strategy; solves technical shortcomings such as static routing binding, path redundancy, and response delay in traditional systems, and enhances the active adjustment capability of the routing system; supports efficient collaboration under the dynamic batch integration of a large number of heterogeneous protocol devices in complex application scenarios (such as the Internet of Things and the Internet of Vehicles).Real-time capture of "abnormal edge routing" during protocol adaptation, especially communication delays and slow responses caused by protocol conversion; resource topology optimization driven by problem feedback to achieve real-time tuning of access paths, adaptation nodes, and protocol bridge modules; combined with an intelligent path adjustment mechanism to build a self-evolving routing control engine with learning, adjustment, and self-evolution capabilities; ultimately achieving the system's continuous adaptation and self-optimization capabilities to new protocols, abnormal communications, and frequently fluctuating behaviors, thereby enhancing system vitality and environmental adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A schematic flow chart of the steps of a dynamic routing algorithm for a central control device supporting access of multi-protocol terminal devices according to the present invention; Figure 2 Detailed implementation flow chart of step S1; Figure 3 Detailed implementation flow chart of step S2; Figure 4 Schematic diagram of the detailed implementation steps of step S3. DETAILED DESCRIPTION

[0008] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0009] This application example provides a dynamic routing algorithm for a central control device that supports access by multi-protocol terminal devices. The execution entities of the dynamic routing algorithm for a central control device that supports access by multi-protocol terminal devices include, but are not limited to, the following: mechanical equipment, data processing platforms, cloud server nodes, network upload devices, etc. equipped with the system, which can be regarded as general computing nodes of this application. The data processing platform includes, but is not limited to, at least one of an audio and image management system, an information management system, and a cloud data management system.

[0010] See also Figures 1 to 4 The present invention provides a dynamic routing algorithm for a central control device that supports access of multi-protocol terminal devices. The dynamic routing algorithm for a central control device that supports access of multi-protocol terminal devices includes the following steps: Step S1: Collect real-time communication signals during the access initialization phase, perform comprehensive protocol compatibility assessment, and generate a multi-protocol dynamic access behavior profile; Step S2: Obtain multi-dimensional operating status parameters of the central control device, calculate resource utilization and capacity margin of each routing module, and generate the precise load carrying capacity of each routing module; Step S3: performing adaptive routing adaptation request according to the real-time communication signal, and performing device integration priority evaluation to obtain the integration priority of each device; Step S4: Calculate the maximum concurrent protocols and the dynamic routing allocation boundary based on the precise load carrying capacity and the multi-protocol dynamic access behavior profile to obtain the dynamic routing adaptation capacity constraint; Step S5: performing intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints, and performing intelligent protocol path adjustment according to the incorporation priority, thereby obtaining a multi-device intelligent adjustment incorporation path; Step S6: Identify the routing protocols with abnormal latency, optimize the routing resource topology, and perform multi-protocol routing adaptation and self-evolution based on the multi-device intelligent adjustment and incorporation paths to build a multi-protocol routing adaptation engine.

[0011] In the embodiment of the present invention, see Figure 1 , is a schematic flow chart of the steps of a dynamic routing algorithm for a central control device supporting access of multi-protocol terminal devices according to the present invention. In this example, the steps of the dynamic routing algorithm for a central control device supporting access of multi-protocol terminal devices include: Step S1: Collect real-time communication signals during the access initialization phase, perform comprehensive protocol compatibility assessment, and generate a multi-protocol dynamic access behavior profile; In this embodiment, after obtaining authorization, the initialization phase of access is prepared, ensuring that all multi-protocol terminal devices to be connected are connected to the central control system. Real-time data capture is performed using a high-performance network packet capture tool (such as Wireshark). Capture filters are set to capture only data streams related to the access request. These filter conditions can include specific protocol types (such as TCP, UDP, HTTP), port numbers, and source and destination IP addresses. To ensure data integrity, the data capture frequency is set to capture at least 1,000 packets per second to capture rapidly changing signals. During this process, appropriate network interfaces are used to ensure stable and accurate data transmission. Next, the captured real-time communication signals are parsed to extract key protocol features. The header information of each packet is analyzed in detail to determine the protocol used, data frame encapsulation format, handshake timing structure, and error control mechanism. By parsing the packets, the characteristic information of each protocol is recorded and a protocol identification feature list is generated. This process helps identify the protocol types used by different terminal devices and their communication behavior parameters. After obtaining the protocol features, a comprehensive protocol compatibility assessment is performed. Evaluation metrics such as latency, bandwidth, and error rate are set. By analyzing the similarities and compatibility between different protocols, the performance of each protocol during actual access can be identified. A weighted scoring system can be used, with each metric weighted to its corresponding priority, ultimately generating a compatibility score for each protocol. This approach quantifies the adaptability of the protocols and provides data support for subsequent dynamic routing decisions. Finally, based on this information, a dynamic access behavior profile for multiple protocols is generated. This profile should comprehensively consider protocol characteristics, compatibility scores, and access behavior to form a comprehensive view of the behavioral patterns of different devices during access. Visualization tools can be used to present this data in a graphical format for easier analysis and decision-making. This dynamic access behavior profile not only provides real-time monitoring capabilities for the central control system but also provides a scientific basis for future protocol optimization and routing adjustments.

[0012] Step S2: Obtain multi-dimensional operating status parameters of the central control device, calculate resource utilization and capacity margin of each routing module, and generate the precise load carrying capacity of each routing module; In this embodiment, a network management system (NMS) or dedicated monitoring software is used to regularly collect performance metrics for the central control device. These metrics include CPU utilization, memory usage, network bandwidth, storage space, and load balancing status. Data collection can be set to occur every 5 seconds to ensure sufficient real-time information. During the experiment, data collection accuracy and completeness were ensured to avoid any data loss or delay. Next, resource utilization is calculated. Based on the collected operating status parameters, resource utilization of the central control device is calculated. CPU utilization can be calculated using the following formula: CPU utilization = current CPU usage time / total available CPU time × 100%. Memory and storage utilization are calculated using a similar method. These utilization rates are recorded in a database, and a resource utilization report is generated, detailing the current value, maximum value, and utilization percentage for each parameter. This process helps identify resource bottlenecks in the device and ensures system stability. Next, the capacity headroom of each routing module is calculated. First, the maximum load capacity of each routing module is identified, which is typically provided by hardware specifications or network design documents. Next, the headroom is calculated by monitoring the current load of the routing module in real time. If a routing module has a maximum processing capacity of 1000 packets per second (pps) and a current processing capacity of 600 pps, then: Capacity headroom = Maximum processing capacity - Current processing capacity = 1000 pps - 600 pps = 400 pps. The capacity headroom for each routing module is recorded in the database, and module capacity reports are generated. These reports should clearly identify each module's current load, maximum capacity, and headroom to facilitate subsequent decision-making and analysis. Finally, combining this data, a precise load-carrying capacity report is generated for each routing module. This report should not only display each module's utilization and capacity headroom but also provide trend analysis and forecasts of potential future load conditions. Visualization tools can be used to present this data graphically, helping decision-makers quickly understand the current system status and providing a crucial basis for subsequent dynamic routing adaptation.

[0013] Step S3: performing adaptive routing adaptation request according to the real-time communication signal, and performing device integration priority evaluation to obtain the integration priority of each device; In this embodiment, real-time communication signal characteristics of devices are collected. These signals primarily include RSSI (Received Signal Strength Indicator), SNR (Signal-to-Noise Ratio), link stability (calculated based on the continuous packet loss rate), protocol type (e.g., MQTT, HTTP, CoAP), and the physical / logical distance between the device and the central control node. This data is extracted and cached in real time from device registration signal packets or access heartbeats via the central control device's access monitoring module. In the experiment, 50 devices of various models (such as IoT sensors, smart terminals, and edge nodes) were used to simulate access in a typical smart factory network environment, with a collection period of 500ms. The system then inputs these signal characteristics into an adaptive priority assessment model. This model quantifies and scores various signal indicators based on a preset weighted scoring function. An RSSI above -70 dBm is assigned a score of 5, a SNR above 25 dB is assigned a score of 4, and protocol priority (MQTT is higher) is assigned a score ranging from 3 to 5. This scoring system uses a combination of configurable weighting parameters (e.g., communication quality accounts for 40%, protocol level accounts for 30%, service urgency accounts for 20%, and historical access performance accounts for 10%) to construct an overall priority score. To enhance the model's dynamic adaptability, the scoring system also adjusts based on the current state of network resources. When network congestion is high (link utilization exceeding 80%), the system increases the weight of the communication quality dimension in the weighting function, prioritizing high-quality link access. Furthermore, service urgency (e.g., whether a device reports an abnormality alarm or a control instruction) also has a variable weight in the model. Ultimately, each access request is assigned an incorporation priority score from 0 to 100, which the system uses to rank and determine the incorporation scheduling order. In experimental verification, by dynamically evaluating the access priorities of 200 devices, the system effectively prioritized the access of critical devices (such as environmental anomaly sensors and core controllers) during peak congestion periods, reducing access response time by an average of 26.4% and improving the concurrent access stability rate by 18.7%.

[0014] Step S4: Calculate the maximum concurrent protocols and the dynamic routing allocation boundary based on the precise load carrying capacity and the multi-protocol dynamic access behavior profile to obtain the dynamic routing adaptation capacity constraint; In this embodiment, in the complex scenario of multi-protocol terminal devices accessing the central control system, resource consumption varies significantly across each network path, each protocol instance, and each routing node. Therefore, to ensure system stability and improve concurrent processing and access efficiency, it is necessary to accurately calculate the maximum concurrent processing limits for different protocols based on their load carrying capacity and historical access behavior. This is then used to quantitatively model the dynamic routing allocation boundaries, ultimately determining the actual constraints for dynamic routing adaptation capacity. Detailed modeling of the resource usage of different communication protocols (such as MQTT, CoAP, and HTTP) within the central control system is required to form a baseline model of protocol load carrying capacity. In an experimental environment, simulated access traffic (100 to 1000 access requests per second) was generated for each protocol, and performance data was collected on CPU utilization, memory consumption, network bandwidth usage, and I / O blocking frequency. MQTT consumes relatively high CPU resources due to its connection maintenance mechanism and QoS management; whereas HTTP places significant pressure on I / O and bandwidth in scenarios with short connections and high request frequencies. Through multiple rounds of performance testing, we extracted the critical load points of each protocol across different resource dimensions, and determined the concurrent access limits corresponding to the maximum available resources on the central control device. The maximum concurrent access for MQTT is 850 connections / second, for HTTP it is 610 requests / second, and for CoAP it is 920 packets / second. After determining the protocol-level carrying capacity limits, a multi-protocol access behavior profiling analysis mechanism is required. The system models the access frequency, access time distribution, and data interaction patterns of different devices and protocols over a recent period (e.g., 1 hour, 6 hours, 24 hours) to form access behavior density maps across multiple time windows. Using sliding windows and cluster analysis algorithms (such as DBSCAN), the behavioral profiling model identifies high-density protocol concurrency periods and device groups, thereby predicting potential concurrency peaks in the near future. Experiments revealed significant concurrent access peaks in the half-hour after the lunch break (1:00 PM–1:30 PM) and the hour before shift changes (4:00 PM–5:00 PM). In particular, access from MQTT-based temperature control devices and security terminals surged by more than 2.2 times the average during normal hours during these two periods. Combining these two aspects, the system can further construct a dynamic routing boundary model. This model, based on the current load capacity of the central control system and the predicted future multi-protocol concurrency intensity, dynamically allocates the maximum allowable access capacity and available path distribution for each protocol within the current time window. If MQTT devices are predicted to request 950 connections within the next five minutes, based on system load assessment results, 150 of these connections will be transferred to edge nodes via protocol proxy relays, leaving the main router with a dynamic access boundary of only 800 connections.Through these calculations, the system generates a dynamically updated routing capacity constraint table. This table specifies the maximum number of concurrent accesses allowed for each protocol, time window, and routing node, as well as the dynamic range of changes. This table serves as a strong constraint input for subsequent access scheduling and path planning, effectively preventing resource overflow and path conflicts, and improving overall system stability.

[0015] Step S5: performing intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints, and performing intelligent protocol path adjustment according to the incorporation priority, thereby obtaining a multi-device intelligent adjustment incorporation path; In this embodiment, based on the existing protocol concurrent processing limit and path resource distribution, the system samples and analyzes the resource status of routing nodes throughout the entire network structure, including but not limited to parameters such as link utilization, node CPU / memory remaining capacity, current protocol share, and historical congestion records. By combining the dynamic routing adaptation capacity constraint table (generated in the previous step S4), a set of edge-weighted constrained dynamic graph structures is established based on the topology graph. Each edge not only reflects the logical connection relationship but also carries a real-time performance label (such as latency, packet loss rate, number of concurrent accesses, etc.). Then, based on this dynamic graph model, the system uses a multi-constrained intelligent topology reconstruction algorithm for calculation. Common methods include re-ranking the importance of topological nodes based on an improved Dijkstra algorithm (with the addition of multiple weight evaluation factors) or using graph convolutional networks (GCNs), and then performing edge replacement and path reconnection in accordance with the constraints. In experiments, this reconfiguration mechanism was applied to a control network with 30 core nodes and over 400 terminal access points. The network response time and access throughput were measured under different load levels (30%, 60%, and 90% system load). The results showed that the intelligent topology reconfiguration resulted in an average access throughput improvement of 28.6% under high load conditions, with significant improvements in link utilization and load balancing. After the reconfiguration, the system initiated an intelligent protocol path adjustment mechanism based on the device priorities assessed in the previous step. Based on the reconfigured path set, this mechanism prioritizes high-priority devices (such as control command source devices and security monitoring terminals) with the best-performing and most resource-rich path segments. Lower-priority devices are allocated in descending order based on remaining bandwidth and node margin. Furthermore, to prevent the spread of localized path congestion, the system sets a localized congestion propagation threshold: if the bandwidth utilization of a path exceeds 85%, the system triggers a soft migration mechanism, temporarily redirecting some medium-priority devices to alternate paths and periodically reassessing the adjustment. Ultimately, the system generates an intelligently adjusted, personalized access path for each device. This path not only meets protocol requirements but also closely matches the current network resource status and device priority. The resulting path configuration is pushed to the device or edge agent in real time for the path to take effect. Experimental statistics show that this mechanism reduces the device access conflict rate to less than 2.3% in multi-protocol mixed scenarios and keeps the average access latency below 80ms, meeting the real-time control requirements of various scenarios.

[0016] Step S6: Identify the routing protocols with abnormal latency, optimize the routing resource topology, and perform multi-protocol routing adaptation and self-evolution based on the multi-device intelligent adjustment and incorporation paths to build a multi-protocol routing adaptation engine.

[0017] In this embodiment, routing protocols with abnormal latency are identified and located. Based on the immediate access data flow of the preceding device, the system records the access response time of each protocol path in real time and performs statistical analysis of the latency mean and fluctuation range using sliding windows (e.g., 10 seconds, 30 seconds, or 5 minutes). The system uses the Z-score anomaly detection method to identify protocol routes whose latency deviates from the mean by more than 2.5 standard deviations, defining them as abnormal latency paths. Experiments examining 70 active paths for protocols including MQTT, HTTP, and CoAP revealed that MQTT paths were more likely to experience latency spikes when connections were dense and QoS levels were high. The average response latency during peak periods reached 280ms, while the average was only 90ms under normal conditions. The second phase involves in-depth attribution analysis and topological bottleneck identification of these abnormal paths. This phase employs a causal graph-based anomaly attribution method to correlate the resource status (CPU usage, I / O queue length, bandwidth usage, number of connections, etc.) of each hop in the path with latency fluctuations. Mutual information and Granger causality analysis are introduced to identify "critical hops" that cause path performance anomalies. For example, in an HTTP protocol channel, the CPU utilization of edge node E5 periodically spiked to over 95%, showing a significant positive correlation with the overall path latency peak, ultimately identifying it as a bottleneck node. After identifying the bottleneck, the system performs routing resource topology optimization to mitigate the systemic impact of the bottleneck. Optimization strategies include node migration (migrating protocol instances to nodes with more abundant resources), link weight adjustment (lowering the priority of bottleneck path selection), and replica expansion (providing multi-path replica access for hot protocol instances). In practical verification, by deploying MQTT protocol proxy replicas at bottleneck nodes and adjusting the load balancing algorithm to be resource-aware, the maximum latency of the protocol channel decreased by approximately 38%, and overall access stability improved by over 20%. Finally, combining the optimized path structure with the previously generated intelligent path adjustment results based on device priorities, the system executes a multi-protocol routing adaptive self-evolution strategy update. This strategy uses deep reinforcement learning (such as DQN and PPO) to train a policy network, guiding the system to automatically select the optimal protocol path combination under new network conditions and also incorporates path history feedback memory. Each optimization action is recorded as a state-action-reward triplet for continuous strategy optimization. In the experimental platform, after 50 rounds of self-evolutionary training, the system reduced average path adjustment latency by 25% in multi-protocol hybrid access scenarios, and increased device access success rate to over 98%.

[0018] In this embodiment, refer to Figure 2 , is a flowchart of the detailed implementation steps of step S1. In this embodiment, the detailed implementation steps of step S1 include: When a multi-protocol terminal device requests to access the central control system, it collects real-time communication signals during the access initialization phase; Identify protocol identification features, data frame encapsulation format, handshake timing structure and error control mechanism of the real-time communication signal to obtain communication behavior parameters of multiple protocol terminal devices; Performing a multi-dimensional protocol similarity cluster analysis on the communication behavior parameters to obtain a semantic affinity graph for each type of protocol; Quantitatively evaluating the compatibility of real-time communication signal protocols based on the semantic affinity graph to obtain the routing adaptation complexity of each protocol; Real-time protocol behavior pattern recognition is performed based on protocol identification features and data frame encapsulation formats to obtain access behavior preferences of different terminal devices; A comprehensive protocol compatibility assessment is performed based on the routing adaptation complexity and the access behavior preference to generate a multi-protocol dynamic access behavior profile.

[0019] In this embodiment, when a terminal device first initiates a connection with the central control system, the communication signal is in the handshake and initialization phase, typically containing information such as protocol identification, communication initialization packets, and synchronization signaling. During this phase, a dedicated monitoring module is deployed on the gateway side or in the controller's front-end proxy node. Using a high-performance network data capture engine (such as DPDK or libpcap), it continuously captures network packets at millisecond intervals (e.g., 1ms). In the experimental environment, a variety of mainstream protocol terminal devices (such as those based on Modbus, BACnet, KNS, and MQTT) were deployed. Upon initial connection, the monitoring module non-intrusively recorded the packet stream of each device, generating a raw communication data log. For each connection, at least 20 seconds of communication data, comprising approximately 1000-3000 data frames, was collected at the line rate of a 100Mbps link to ensure integrity. The signal acquisition module also records timestamps, source / destination MAC / IP addresses, port numbers, and transport layer protocol information (such as TCP / UDP), ensuring complete context for the subsequent protocol identification phase. A multi-layered data parsing strategy was employed based on the collected communication data. First, preliminary protocol inference is made through the characteristics of the transport layer ports (for example, port 502 is mostly used for Modbus TCP, and port 1883 is used for MQTT). Then, a method based on Deep Packet Inspection (DPI) is used to parse the data frame structure, including the frame header, function code, length field, CRC checksum area, etc.

[0020] Time series analysis techniques, such as the DTW (Dynamic Time Warping) algorithm, analyze the send-response time interval, message sequence length, and response format consistency using handshake timing structures. By comparing these with a known protocol signature base, the typical handshake behavior for each protocol type is identified. For example, the Modbus TCP handshake typically includes a specific transaction identifier and function code return; MQTT includes CONNECT and CONNACK message pairs. Error control mechanisms are identified based on checksum fields (such as CRC-16), retransmission flags, and sequence number anomalies. Frame-level comparison and anomaly detection algorithms (such as Isolation Forest or HDBSCAN-based inter-frame behavior detection) are used to determine the mechanism type. Several MQTT devices sampled in the experiment exhibited lightweight error control, while Modbus devices exhibited strong checksum characteristics. Through these identifications, the system was able to build a protocol feature database, including communication frequency, checksum method, and frame structure. The behavioral parameters extracted from the previous step (such as data frame length distribution, handshake packet sequence characteristics, checksum mechanism, and connection frequency) were used as multidimensional feature vectors and input into the clustering model. A density-based clustering algorithm, such as DBSCAN or HDBSCAN, is used to group the communication behaviors of different terminals and capture their similarities at the protocol level. Feature normalization (such as z-score normalization) is required before clustering to prevent features of different scales from affecting distance calculations. PCA or t-SNE is used to reduce the dimensionality of high-dimensional features in order to visualize the similarity relationship between protocols. In the experiment, the communication behavior data of 10 types of terminal devices were analyzed, and four main clusters were formed using the DBSCAN algorithm, representing the Modbus, BACnet, MQTT, and KNS protocol families respectively. Based on the clustering results, a semantic affinity graph is constructed, in which the nodes represent the protocols, the weights of the edges represent the similarity, and the metric is the cosine similarity of the behavioral features. This graph structure can be used for subsequent compatibility calculations and adaptation path planning. A "protocol compatibility quantification model" is introduced to score the adaptation difficulty of each protocol. The scoring model considers the following indicators: Protocol semantic affinity (Affinity Index); The complexity of the protocol encapsulation structure (such as the number of nested layers and verification complexity); The interaction steps required for the handshake process (Latency Index); Existing resolver coverage of central control equipment (existing resolvers have higher scores); These dimensions are weighted and combined to form a "routing adaptation complexity score" on a scale of [0, 1], with higher values ​​indicating greater adaptation difficulty. The adaptation score for Modbus and MQTT was 0.83 (due to significant structural differences), while the score for Modbus TCP and Modbus RTU was 0.25.

[0021] Complexity score = α*structural inconsistency + β*handshake asymmetry + γ*error mechanism incompatibility; α, β, and γ can be tuned through experiments, with initial values ​​of (0.4, 0.3, 0.3).

[0022] By mining behavioral patterns in the behavior sequences of terminal devices, Hidden Markov Models (HMMs) or Long Short-Term Memory (LSTMs) are used to analyze common behavioral paths during device access. For example, some MQTT devices initiate a subscription request immediately upon connection, while Modbus devices remain connected for a period of time before polling the master. A behavioral pattern vector (e.g., connection latency, initial data transmission time, subscription / query frequency, etc.) is constructed and recorded as a behavioral profile for each device. Behavioral preferences are expressed as biases along different dimensions, such as high connection retry frequency, high-speed data push, and strong state preservation requirements. Experiments revealed that a certain type of environmental monitoring device (MQTT protocol) pushed more than five rapid messages within three seconds of connection, while BACnet-based building control equipment maintained a stable connection but exhibited significant response delays. This information is mapped into a preference matrix for reference in adaptation strategies. The "protocol routing adaptation complexity score" is combined with the "device behavior preference characteristics" to form a multi-dimensional protocol profile, which includes but is not limited to the following information: Protocol type, Access complexity score (e.g. 0.76), Average first response delay (ms), Data push frequency (items / s), Error control requirement level (high / medium / low), Access stability (high / medium / low), This profile is presented through a visual dashboard, updated in real time through integration with Grafana or ElasticSearch. The system can dynamically adjust routing policies based on the profile, for example prioritizing master gateway resources for low-complexity, high-stability devices, while directing high-complexity devices to compatible proxy modules for protocol bridging.

[0023] In this embodiment, refer to Figure 3 , is a flowchart of the detailed implementation steps of step S2. In this embodiment, the detailed implementation steps of step S2 include: Continuously monitor the multi-dimensional operating status parameters of each routing module within the central control equipment; Calculating processor occupancy, memory buffer status, and port throughput data of the multi-dimensional operating status parameters; Perform a comprehensive resource utilization analysis on processor occupancy, memory buffer status, and port throughput data, and perform multi-scale time series smoothing to obtain a resource utilization smoothing curve. Perform nonlinear trend prediction on the resource utilization smooth curve to extract the instantaneous fluctuation characteristics and long-term evolution trend of the central control equipment routing resources; Performing dynamic modeling of routing load based on the instantaneous fluctuation characteristics and long-term evolution trends to obtain a routing load prediction model; The routing load prediction model calculates the capacity margin of each routing module one by one to generate the accurate load carrying capacity of each routing module.

[0024] In this embodiment, as multi-protocol terminal devices continuously connect to the central control system, each protocol routing module within the central control system will assume different communication processing tasks. To achieve dynamic adaptation and intelligent resource allocation, the operating status of these routing modules must first be monitored continuously in real time to obtain basic operating parameters. These parameters should not only include CPU usage, but also memory buffer occupancy, thread execution queue load, network port data transmission status, I / O latency, system call frequency, and more. In specific implementation, the system deploys independent lightweight resource monitoring agents (such as Telegraf or the Prometheus-based Node Exporter plugin) in each protocol routing module. These agents run independently within the module's running thread or its container environment, without interfering with the main business processing flow. A sampling frequency of once per second is recommended to ensure high temporal resolution data recording. Furthermore, the processor core number, allocated memory pages, and number of active connections associated with each module during runtime are also recorded to facilitate multi-dimensional cross-analysis. All data is structured and fed into a unified time series database (such as InfluxDB or Prometheus TSDB) and bound to the module's unique identifier to form a complete data profile. After collecting monitoring data, it's necessary to extract key resource metrics representing the module's operational load. This involves aggregating and calculating the raw monitoring data to extract three core performance metrics: CPU utilization, memory buffer usage, and port throughput. These three metrics, taken together, provide the primary resource bottleneck indicator. To calculate CPU utilization, the system analyzes the runtime of the routing module's core, separating the proportions of user-mode processing time, kernel-mode processing time, and wait time, and outputs the average percentage of CPU utilization per second. Furthermore, in containerized deployments, the virtual CPU resource limit must also be considered. Memory buffer usage primarily analyzes memory allocation ratios, page cache pressure, memory page swap frequency, system buffer / cached trends, and the current available memory ratio. Port throughput assesses load by counting the number of packets received and sent per second (PPS) and the data transfer rate (bps). Information such as packet loss rate, congestion window status, and socket queue length must also be recorded to determine whether network bandwidth is a bottleneck. Since the original resource indicator data will be affected by various disturbance factors such as sudden access, system jitter, instantaneous thread scheduling changes, etc., directly using the original curve for trend prediction will lead to large errors.Therefore, it's necessary to comprehensively normalize multi-dimensional resource metrics to construct a unified "resource utilization" time series, and then perform multi-scale smoothing to eliminate short-term noise and abnormal fluctuations. First, standardize the three dimensions of CPU, memory, and port utilization and then perform a weighted sum to form a single resource usage intensity indicator. Weights can be set based on historical load test results, such as CPU (0.4), memory (0.3), and port (0.3), or they can be optimized through training and parameter tuning. This way, each module has a unified "utilization value" at every point in time.

[0025] Next, a two-stage smoothing strategy is implemented for the resource utilization series. First, a moving average (SMA) is used to filter out short-term fluctuations (for example, a 60-second window is set to accommodate typical network fluctuations). Second, exponentially weighted moving average (EWMA) and cubic spline interpolation are used in data regions with significant trend changes to maintain curve smoothness and trend sensitivity. This data curve accurately reflects actual resource pressure and avoids misleading transient jitter. After smoothing the resource utilization curve, the next step is to use nonlinear time series analysis to predict resource consumption trends over a period of time, identifying both short-term fluctuations and long-term evolutionary trends in the system. To accurately identify potential resource bottleneck risks or scheduling pressures facing the central control system, a combined approach of trend extraction and predictive modeling is required. For short-term trends, the autoregressive moving average (ARIMA) model is used to handle linear variations, while deep learning methods such as LSTM (Long Short-Term Memory) are used to model the medium- and long-term nonlinear components. LSTM models are particularly well-suited for capturing both cyclical patterns in resource utilization (such as peak traffic) and aperiodic emergencies (such as concentrated device access). Model training uses a sliding window of data from the last 72 hours for sample construction, with predictions targeting resource utilization intervals for the next 1, 6, and 24 hours. This model is supplemented with outlier detection algorithms (such as the Local Outlier Factor (LOF)) to extract transient fluctuations. For example, resource spikes caused by concurrent device access or gateway failure recovery can be promptly identified using the LOF by setting a threshold (e.g., 5 standard deviations from the average trend). The trend prediction results from the previous stage are further structured into a systematic "routing load prediction model," providing accurate forecasting data for dynamic resource scheduling and protocol adaptation decisions. The model integrates multiple dimensions, including resource utilization trends, cyclical behavior patterns, transient shock fluctuations, and protocol access policies.

[0026] When building the model, a hierarchical structure is used: the bottom layer is the trend prediction results (time series), the middle layer is feature extraction (maximum load point, growth rate, cycle amplitude, etc.), and the top layer is the prediction model aggregation layer. The model structure is as follows: Long-term prediction submodule (LSTM): predicts the overall resource growth trend in the next few hours; Cyclic behavior modeling (Fourier transform): Extracting daily / weekly load cycle patterns; The anomaly adjustment module adaptively adjusts prediction results for segments with excessively large errors. These submodules work together to form a multi-factor, adjustable load forecasting system. The system also features online learning capabilities, adjusting parameters based on real-time data feedback to improve forecast accuracy and stability. The predicted future resource utilization curve is compared with the current hardware resource limit (or policy allocation ceiling) to determine the "resource headroom" and "load carrying capacity" of each protocol routing module. This capacity metric serves as the core decision-making basis for determining whether to allow new device access, perform protocol forwarding, or enable edge offloading. The calculation method is to take the difference between the "peak usage forecast" and the "maximum configured capacity" for CPU, memory, and bandwidth, namely: resource headroom = maximum resource limit - predicted peak resource usage. The "load carrying capacity index (LCI)" is then calculated based on the current system scheduling policy (such as the maximum number of module connections and priority policy). The higher the LCI value, the more capable the module is of handling the access and communication tasks of more terminal devices. The final output is a standardized module resource status assessment table, as shown below: In this embodiment, refer to Figure 4 , is a flowchart of the detailed implementation steps of step S3. In this embodiment, the detailed implementation steps of step S3 include: Perform time-series routing load analysis based on the resource utilization smooth curve to obtain the time-series routing load trend; Calculating the transmission throughput of each device unit based on the real-time communication signal to generate a periodic transmission throughput; Calculate the transmission demand of the periodic transmission throughput and generate the real-time transmission demand value of each device; Performing an adaptive routing adaptation request on a temporal routing load trend according to the real-time transmission demand value to generate multi-device routing adaptation request data; The device incorporation priority is evaluated on the multi-device routing adaptation request data to obtain the incorporation priority of each device.

[0027] In this embodiment, each protocol routing module in the central control system is responsible for data parsing, handshake confirmation, and transaction management for a specific type of terminal device. Resource consumption is highly dependent on the protocol complexity and concurrent usage of the connected devices. During system operation, resource utilization exhibits distinct time series characteristics, such as a rise in load during daytime peak hours and a plateau at night or on weekends. To implement effective dynamic adaptive scheduling, a "time series load trend analysis" is first performed based on the smoothed resource utilization curve. This process uses a sliding window technique to perform local slope analysis on the resource utilization time series. A window width of 30 minutes and a step size of 5 minutes are set. The local slope (i.e., Δ resource utilization / Δ time) is calculated for each time window to determine whether the trend is "upward," "downward," or "plateauing." Furthermore, to identify key fluctuation points, the system incorporates a second-order derivative change monitoring mechanism (i.e., changes in the rate of change). This, combined with a Savitzky-Golay filter to eliminate noise interference, extracts "load inflection points." The experiment monitored the load of KNS and MQTT routing modules deployed in a virtual cluster for 72 hours, with a sampling period of 10 seconds, resulting in nearly 360 samples per hour. Processing revealed a significant "high-frequency upswing" in the MQTT module between 8:30 and 10:00 AM, with the load increasing from 35% to 87%. This trend was accurately captured by the system and marked as a "critical congestion window." The final output includes trend status labels (increasing, decreasing, plateauing), key inflection point timestamps, and the rate of sustained load change for each module. This creates a time-series load trend chart, providing a basis for time prediction for access scheduling. Terminal devices connected to the system exchange data with the central control system using multiple protocols. Their communication behavior manifests as a series of continuous data frames, request messages, and response messages, which are highly specific to the protocols and usage scenarios. To fully understand the real-time demand of devices for routing module resources, their communication behavior must be quantified as "unit throughput." The system captures network messages and the central control system's communication logs to extract basic communication unit information for each device, including but not limited to data frame length (bytes), timestamp, communication direction (uplink / downlink), and protocol type. The communication records for each device are aggregated and calculated over a 60-second period to determine the total transmission volume and average throughput rate for that period. Throughput calculation method: Data volume statistics: the total number of bytes of all messages in the period; Throughput calculation: total data volume divided by cycle length (usually 60 seconds); PPS statistics: The number of packets sent / received per second reflects the frequency of communication. Fifty devices (30 using the MQTT protocol and 20 using the Modbus protocol) were tested on the experimental platform with a one-minute period, recording the total communication volume and average throughput. During a given sampling period, the average uplink throughput of a vibration sensor was 1.3 Mbps (high-frequency sensor data), while the Modbus electricity meter maintained an average of 120 Kbps. The system ultimately stores this data in a device behavior profile database, providing input for transmission demand assessment. Starting from unit throughput, the system further extracts the "immediate pressure" or "transmission intensity" of each terminal device on the communication channel and computing resources, converting it into a comparable and schedulable numerical metric—the real-time transmission demand rating (TDR). This value not only reflects throughput but also incorporates device service attributes and protocol characteristics.

[0028] The construction of TDR takes into account the following elements: Throughput grade: The actual data transmission rate as a percentage, normalized to 0–1; Service sensitivity factors: QoS tags, such as real-time control equipment (high), environmental monitoring equipment (medium), and logging equipment (low); Delay tolerance label: Label according to business needs, such as ≤50ms for high real-time and ≤500ms for medium; Retransmission rate factor: a network quality indicator. The more retransmissions there are, the lower the required value will be.

[0029] TDR_i = α1 × throughput standard value + α2 × QoS coefficient + α3 × delay factor – α4 × retransmission rate. α1–α4 are system tuning parameters (initially set to 0.4, 0.3, 0.2, and 0.1), which can be optimized through regression based on actual deployment scenarios. The central control system cross-matches the device's real-time TDR value with the current sequential load trends of each routing module to determine which devices are suitable for initiating access or migration requests, during which time periods, and in which modules. This process constitutes a dynamic routing adaptation request generation mechanism, supporting adaptive, multi-goal-driven device access.

[0030] When a module's load is decreasing and its predicted value for the next 10 minutes falls below the access threshold (e.g., 80%), new devices are allowed to be assigned. The current TDR value must be greater than the module's minimum access requirement threshold (TDR ≥ 0.6). If the target module is a protocol bridge, additional protocol conversion latency must be considered (e.g., Modbus to MQTT requires an additional 20ms latency). Each adaptation request contains the following fields: {device ID, current TDR value, protocol type, recommended module ID, recommended access time window, and access cost estimate}. The experiment simulated 100 concurrent devices, including 20 high-throughput video devices, 30 sensor terminals, and the remainder control devices. After a real-time assessment, the system generated 72 adaptation requests based on current resource trends. 45 of these devices were recommended for allocation to the lower-loaded MQTT module. The remaining devices were temporarily rejected due to low TDR or access conflicts. This mechanism effectively reduces the risk of system jitter caused by indiscriminate concurrency during peak hours. All generated adaptation requests are scheduled and prioritized to determine the device inclusion priority, ensuring that limited routing resources prioritize devices with high service value and strong transmission requirements. This ranking mechanism uses a "multi-factor scoring model" for evaluation.

[0031] The scoring factors are as follows: TDR value (40%): device instant communication needs; System load compatibility (25%): whether the current module has capacity; Protocol bridging cost (15%): the lower the better; Access history stability score (10%): Devices with frequent failures or abnormal disconnections have lower scores; Policy priority rules (accounting for 10%): For example, whitelisting of critical devices is prioritized.

[0032] Each device is eventually assigned an incorporation score (combined 0–1) and forms a priority queue, such as: Equipment IDTDR Load Compatibility Protocol Bridging Cost Total Score Incorporated Level Dev-0010.88High (0.9)Low (0.95)0.91Priority merge Dev-0130.67Medium (0.6)High (0.45)0.61Access suspended During the test, in a peak scenario (120 devices concurrently attempting to access), the system completed all priority calculations in less than 220ms, ultimately selecting the top 50 devices to enter the queue and triggering the corresponding access control protocol.

[0033] In this embodiment, step S4 includes the following steps: Performing maximum concurrent protocol calculation based on the precise load carrying capacity to obtain the upper limit of concurrent protocol processing for each reason module; Perform multi-time window concurrent load prediction on multi-protocol dynamic access behavior profiles and generate multi-time window concurrent load prediction graphs; Perform large-scale concurrent access scenario simulation based on the concurrent processing upper limit of the protocol and the multi-time window concurrent load prediction diagram to obtain large-scale concurrent simulation data; Based on the incorporation priority, dynamic routing allocation boundary calculation is performed on large-scale concurrent simulation data to obtain a dynamic routing adaptation capacity constraint for each device.

[0034] In this embodiment, all communication protocols supported in the current system are categorized, such as MQTT, CoAP, HTTP, Modbus, and KNS. For each protocol type, a load testing environment is constructed, and stress testing of concurrent connections is performed under controlled variables. In MQTT protocol testing, the number of concurrent connections is gradually increased by simulating 1,000 to 10,000 terminal devices, with each test performed in steps of 500. The system response time, packet loss rate, and CPU utilization at different concurrency levels are recorded. The testing platform can use Apache JMeter or a self-developed protocol simulator to simulate the access behavior of different protocols through multithreading or distributed nodes. After data collection, a multidimensional parametric surface fitting analysis (such as using multiple regression or nonlinear fitting methods) is used to plot the protocol load curve. Ultimately, the maximum concurrency value that achieves a system response time of no more than 100ms, a packet loss rate of less than 1%, and a CPU utilization of no more than 85% is selected as the "protocol concurrent processing upper limit" for each protocol. Using time series analysis models (such as ARIMA, LSTM, or Transformer), we predict access loads for different protocols at different time scales, such as hourly, daily, and weekly. Each time window (e.g., 5 minutes, 15 minutes, 1 hour, or 24 hours) is considered an analysis unit, and the model outputs the estimated concurrent access volume per unit time. The data used in the experiment includes device access records from the past 30 days, annotated with event types (such as data reporting, alarm uploads, and heartbeat packets). After model training, error evaluation is performed using mean absolute error (MAE) and root mean square error (RMSE). An RMSE below 10% indicates the prediction model is stable and reliable. The prediction results are ultimately output in the form of heat maps and line charts, forming a "multi-window concurrent load forecast chart." Based on the data obtained in the first two steps, a simulation environment is constructed to simulate device access behavior under high, medium, and low load scenarios. For example, a simulation scenario is set to the "weekday peak" (8:00 a.m. to 10:00 a.m.), with the number of concurrent devices ranging from 5,000 to 10,000. Device protocol distribution is modeled based on the proportion of multi-protocol access (e.g., MQTT accounts for 40%, HTTP accounts for 30%, KNS accounts for 20%, and the remaining 10%). Using a simulation platform such as NS-3 or a proprietary network simulation tool, a complete system architecture is constructed, including the network topology, protocol stack, central control nodes, and load balancing nodes, and realistic device behavior models are embedded. The system records data such as response time, processing load, queue length, and number of retransmissions for each node in the simulation, generating detailed simulation logs and statistical reports. This data constitutes "large-scale concurrent simulation data" and serves as the basis for subsequent routing strategy decisions. The capacity constraints of each routing node are calculated based on the protocol's concurrent processing limit and the current predicted load.For example, if a node can handle a maximum of 3,000 MQTT connections, and the forecast window indicates that the number of MQTT connections will reach 2,800 in the next period, with a reserved boundary value of 10%, the node's current MQTT access capacity constraint is dynamically calculated to be 2,700. The system uses a priority algorithm to route high-priority devices to nodes with sufficient resources, while low-priority devices are dynamically routed or placed in a standby queue based on current capacity. This process can be used to continuously optimize routing strategies using genetic algorithms or reinforcement learning methods, with the training objectives being to maximize system throughput and minimize average response time. In experiments, overall processing latency, successful access rate, and task completion time under different routing strategies were used as performance indicators to select the optimal strategy for live network deployment. In this embodiment, step S5 includes the following steps: Intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints and building adaptive multi-protocol routing scheduling strategies; Perform heterogeneous protocol path planning based on adaptive multi-protocol routing scheduling strategy to generate personalized protocol scheduling paths for different devices; Perform multi-device access execution based on the personalized protocol scheduling path and collect real-time device access data streams; Intelligent protocol path adjustment is performed based on the instant device access data flow, thereby obtaining a multi-device intelligent adjustment and integration path.

[0035] In this embodiment, based on the known "dynamic routing adaptation capacity constraints" (the access capacity of each node under different protocols obtained in the previous steps), a protocol-aware routing graph model is established. This graph uses network nodes as vertices and communication paths as edges. The edge weights are determined based on node load, protocol priority, and link stability. The following parameters are used: Link delay (ms), Packet loss rate (%), Current access load ratio (%), Supported protocol types (boolean vector), The optimal path set is constructed using a weighted graph shortest path algorithm (such as a modified version of Dijkstra) or the A* protocol-aware search algorithm. During this process, a "protocol adaptation weight function" is set to ensure that node selection is protocol-biased. KNS protocol paths tend to select nodes with low latency and low jitter, while HTTP protocol paths prioritize nodes with ample bandwidth.

[0036] In the experiment, 100 virtual network nodes were constructed, with each protocol deployed on 10 to 20 nodes. By simulating 5,000 concurrent devices, the average routing hop count, load balancing, and access success rate of the system before and after topology reconstruction were measured. If the average hop count decreased by more than 10% and the standard deviation of the load distribution decreased by more than 15%, the topology reconstruction was considered successful. Each device was assigned a multi-dimensional label based on its communication protocol, access cycle, priority, and data characteristics (such as bandwidth requirements and real-time requirements). Using this label as input, the policy scheduling engine (which can be based on a rule engine combined with reinforcement learning) assigns the optimal access path. The path planning process is similar to a multi-objective optimization problem, with the objective function including: Minimize path delay; Minimize the probability of protocol conflicts; Maximize protocol adaptability; Ensure that the path is within the capacity constraint.

[0037] The planning algorithm can use NSGA-II (non-dominated sorting genetic algorithm) or MCTS (Monte Carlo Tree Search) to search the solution space and establish a set of candidate paths for specific device types. Finally, the path with the most balanced load is selected from the candidate set as the device's "personalized protocol scheduling path." The experiment used 2,000 devices, distributed across MQTT (40%), HTTP (30%), Modbus (20%), and CoAP (10%). The stability of the scheduling path planning was evaluated by simulating path conflicts and congestion scenarios. Key evaluation metrics included average path planning calculation time (target <300ms), conflict rate (target <1%), and path execution rate (target >98%). The personalized paths generated in the previous step are deployed to the central control system, where the scheduling engine directs devices to initiate connections along the designated paths in real time. Devices connect to the core system through load-balancing gateways or intelligent edge nodes, with the system recording the protocol type, path selection, node load status, and link quality of each connection in real time. To ensure the timeliness and integrity of data, a high-throughput real-time stream processing platform such as Kafka is used to encapsulate incoming data into data stream events. The structure includes: Device ID, protocol type, Access timestamp, Path (node ​​list), Each hop delay and node status, During the experiment, 2,000 devices were simulated, connected every five minutes for 24 hours, and over 500,000 data streams were collected. This data was used to create device access behavior trajectory maps, heat maps, and abnormal event maps, providing a basis for subsequent intelligent path adjustment decisions.

[0038] Based on a real-time streaming data analysis engine (such as Flink or Spark Streaming), extract key indicators from the access data stream collected in the previous stage: Path load trends (access frequency, latency fluctuations), Protocol conflict (multiple protocols with the same path experiencing peak traffic at the same time), Node pressure (CPU, memory, connection number changes), Use sliding window aggregation analysis (e.g., every minute or every 5 minutes) to model path load in real time. Simultaneously, use anomaly detection algorithms (such as Isolation Forest, Z-Score, or custom rules) to identify bottleneck nodes or links on the current path.

[0039] Once the load index of a path exceeds the threshold (such as CPU usage > 90%, access requests exceeding scheduling capacity by 20%), the system triggers the "path adjuster" to re-plan the access path for such devices. Adjustment methods include: Switch to a suboptimal path; Introducing backup routes; Temporarily add relay nodes or buffer nodes. The results of these adjustments are fed back to the system evaluation module in real time for the next round of optimization of the adjustment strategy. In experimental evaluations, the average response time for path adjustments was less than 200ms, the fault response rate exceeded 95%, and access latency was reduced by approximately 20%.

[0040] In this embodiment, the specific steps of performing intelligent protocol path adjustment based on the instant device access data flow to obtain the multi-device intelligent adjustment and integration path are as follows: Calculate the information entropy of the data stream accessed by the instant device to obtain the information entropy of the data stream; Performing information entropy multi-period evolution analysis on the data stream information entropy to generate multi-period information entropy evolution characteristics for each device; Calculating the data flow complexity based on the multi-period information entropy evolution characteristics to generate a data flow incorporation complexity evaluation value; Performing a current protocol path adaptability analysis on the data flow integration complexity evaluation value to generate a current protocol path adaptability of each device; Perform multi-device merge path conflict detection on the personalized protocol scheduling path and extract the conflicting merge paths; The conflicting incorporation paths are dynamically adjusted according to the incorporation priority of each device, and intelligent protocol path adjustment is performed based on the current protocol path adaptability, thereby obtaining a multi-device intelligently adjusted incorporation path.

[0041] In this embodiment, the central control device collects access data streams from each device in real time. These data streams contain multiple fields, such as timestamp, protocol type, packet size, access frequency, and path information. Each field is discretized, converting continuous variables into finite categories (e.g., the number of accesses within a time window is divided into intervals of 0-10, 11-20, etc.), to facilitate statistical calculation of probability distributions. Subsequently, for a specific time window (e.g., 5 minutes or 15 minutes), the probability distribution P(xi) of each field is calculated, and the information entropy of the device data stream within that time window is calculated using the Shannon information entropy formula: For a particular device, the probability distribution of access frequency within a 15-minute window is {0.3, 0.5, 0.2}, corresponding to an information entropy of approximately 1.485 bits. Higher information entropy indicates more complex and unpredictable data flows accessed by the device. In this experiment, data was collected continuously for one month from 1,000 devices. The information entropy of data flows from different protocols (such as MQTT, HTTP, and CoAP) was calculated. The results showed that the information entropy of devices using real-time control protocols was significantly lower than that of big data upload protocols, validating the effectiveness of information entropy in characterizing traffic characteristics. Based on the time-based information entropy calculation in step 1, a device information entropy time series was constructed. This time series records the corresponding information entropy values ​​in time windows (e.g., every 5 minutes). A sliding window technique was used to smooth the information entropy series and remove extreme noise points. Time series analysis methods (such as moving average, seasonality factorization (STL), and Fourier transform) were used to identify periodic changes and sudden fluctuations in information entropy. Furthermore, statistical feature extraction (such as mean, variance, maximum, minimum, skewness, kurtosis) and change rate analysis (first-order derivative of information entropy) are used to construct the "information entropy evolution feature" vector.

[0042] In experimental data, we analyzed the evolution of information entropy over a week for different devices and found that the information entropy of access data flows was generally higher during working hours, while it tended to be more stable at night. Furthermore, we compared the changes in information entropy before and after unexpected events (such as equipment failures and network anomalies) to verify that this feature effectively reflects abnormal behavior. We constructed a complexity evaluation function that combines the statistics and change trends of information entropy to calculate a complexity index. A common method is weighted summation: ; Among them, H‾ is the mean, σ_H is the standard deviation, max(ΔH) is the maximum rate of change, and the weight wi is adjusted according to the actual application scenario (such as 50% for the mean, 30% for the fluctuation, and 20% for the burst). After normalization, the complexity evaluation value C is normalized to the range of 0~1. The higher the value, the greater the access traffic complexity of the device, and higher flexibility and resource allocation need to be considered during scheduling. The protocol path adaptability is defined as the match between the path carrying capacity and the device complexity requirements. The path carrying capacity parameters include the bandwidth, processing capacity, and historical load of the path node. Assume that the maximum path carrying complexity threshold is Tp and the current complexity of the device is Cd. The calculation formula for the adaptability A can be designed as: The fitness index ranges from 0 to 1, with values ​​closer to 1 indicating a close match between the path and device requirements. When the fitness index falls below a certain threshold (e.g., 0.7), it indicates excessive path pressure or resource waste, requiring path adjustment. Path parameters are acquired in real time by the network monitoring system and dynamically updated based on device complexity assessments. The experimental environment simulates 50 protocol paths, covering multiple protocol combinations. Path response time and packet loss rate are measured and compared with the fitness index to verify the effectiveness of the fitness index in predicting path performance. Based on the personalized scheduling paths and access time windows of the current device, a path-device mapping table is constructed. The number of devices connected simultaneously on each path and their cumulative complexity are counted. A path conflict threshold (e.g., the maximum number of concurrent connections or capacity limit on a node) is set. A conflict is identified when the cumulative complexity exceeds the threshold. A graph conflict detection algorithm is used, treating paths as edges in the graph and devices as weights to detect whether edge weights exceed the limit. Concurrent conflicting paths are marked for subsequent dynamic adjustment. In the experiment, a parallel computing framework was used to detect path conflicts for 10,000 devices in real time, with detection latency kept within 100ms and an accuracy rate exceeding 98%. Conflicting devices were prioritized by their inclusion priority (e.g., emergency control instructions > real-time monitoring > periodic data upload). For high-priority devices, the original paths were retained, while for low-priority devices, alternative paths were searched based on the current path fitness. A path adjustment algorithm, combining heuristic search and reinforcement learning methods, dynamically selected paths that met capacity constraints and had high fitness. During the adjustment process, device path fitness and path conflict index were continuously calculated to ensure that path adjustments effectively mitigated conflicts. Experimental tests showed that, with the priority scheduling and fitness adjustment mechanism, the overall system throughput increased by 15%, the access latency of key devices decreased by 25%, and the path conflict rate dropped by 40%.

[0043] In this embodiment, step S6 includes the following steps: Calculate the device integration response time based on the instant device access data flow to obtain the device integration response time; calculating a time delay trend of the device incorporating a response time; Performing routing performance deviation analysis based on the time delay trend and tracing the source of the incorporated routing protocol to obtain the incorporated routing protocol with abnormal delay; Conduct deep anomaly attribution mining on the routing protocol with abnormal latency to obtain the bottleneck factors of abnormal latency routing; Optimize the routing resource topology for the latency-related routing bottleneck factors to generate a latency protocol topology optimization strategy. Based on the delay protocol topology optimization strategy and the intelligent adjustment of multiple devices into the path, multi-protocol routing adaptation self-evolution is carried out to build a multi-protocol routing adaptation engine.

[0044] In this embodiment, the traffic monitoring module of the central control device captures access behavior data from all terminal devices in real time. This data includes fields such as device ID, request timestamp, response timestamp, protocol type, and path identifier. To ensure synchronization between request and response times, a time synchronization protocol (such as NTP) is used to calibrate the time between the device and the central control device to avoid errors in response time calculation due to time skew. For each access request, the response time is calculated as the response completion time minus the request initiation time, resulting in the consolidated response time for each device. The calculated response time data is stored in a structured format in a time series database for subsequent query and trend analysis. Outliers are also removed to eliminate extreme values ​​caused by network outages or data errors. Continuous response time data is aggregated into fixed time windows (e.g., every 5 minutes or every 15 minutes). The mean, maximum, standard deviation, and upper percentile (e.g., 95th percentile) of the device response time within each time window are calculated. Sliding average and exponentially weighted moving average (EWMA) techniques are used to smooth the time series, eliminating random noise and highlighting true trends. Spectral analysis or periodic decomposition methods are used to detect periodic variations in latency series (e.g., the difference in latency between weekdays and weekends) and identify peak and valley fluctuations. By setting a threshold (e.g., the mean plus three standard deviation), time periods with significant latency increases are marked, facilitating subsequent tracing of abnormal routing protocols. Simulations analyzing response time trends over a 24-hour period revealed that response latency is higher during working hours, reaching up to twice the average latency during peak hours, reflecting the impact of peak traffic load on latency. Device response times are mapped to the routing protocols they use to establish a protocol-response time relationship. Statistical analysis methods, such as analysis of variance (ANOVA), are used to compare mean response time differences across protocols to identify protocols with significant latency deviations. Combining the latency anomaly time window identified in step 2, the response time distribution of devices using specific protocols within that time period is extracted to identify the anomalous protocols. Based on the statistical results, each protocol is assigned a "normal" or "abnormal" performance label, identifying the anomalous protocols that require optimization. Simulating latency performance for MQTT, HTTP, and CoAP protocols revealed that MQTT's average response time during high-load periods exceeded that of other protocols by approximately 30%, identifying MQTT as a key source of latency anomalies. We collected multiple performance metrics along the paths corresponding to the anomalous protocols, including network link bandwidth utilization, link packet loss rate, node CPU and memory utilization, and buffer overflows. Causal inference techniques (such as Granger causality tests and Bayesian network models) were used to identify causal relationships between performance metrics and latency anomalies, eliminating correlated but non-causal noise. Machine learning anomaly detection algorithms (such as isolation forests and cluster analysis) were combined to screen for anomalous performance characteristics, focusing on bottleneck resources and failure points.Analyze the operation logs and configurations of central control devices and routing nodes to identify possible protocol implementation defects, parameter misconfigurations, or security incidents. Attribution analysis revealed that CPU utilization at two relay nodes exceeded 95%, and the link packet loss rate increased by 4%, indicating the main bottleneck. Routing load imbalance was confirmed as the triggering factor. Based on the network topology and the location of bottleneck nodes, new routing paths were designed or existing paths were adjusted. Graph algorithms (such as shortest path, maximum flow, and minimum cut) were used to ensure that data flows bypassed bottleneck nodes. Resource expansion recommendations were made for bottleneck nodes, including increasing bandwidth, upgrading computing resources, or improving cache capacity. QoS policies were also adjusted to prioritize critical protocol traffic. Multi-path load balancing was introduced to distribute traffic pressure and reduce the risk of overloading a single path or node. Network simulation tools were used to verify the solution, and protocol latency metrics were analyzed before and after optimization. Experimental results showed that after topology optimization, the average latency of the target protocol decreased by approximately 18%, and the peak latency decreased by 25%. The optimization solution was solidified as a topology optimization strategy for subsequent routing adaptation modules. It integrates real-time monitoring, latency trend analysis, anomaly detection, attribution mining, and topology optimization modules to form an end-to-end dynamic routing adaptation closed loop. It introduces machine learning and reinforcement learning algorithms to dynamically adjust protocol paths based on real-time performance feedback, optimizing load distribution and resource utilization. The engine has automatic learning and optimization capabilities, and can automatically update models and adjust strategies for emerging anomaly types and network changes to improve adaptability. It supports simultaneous access of heterogeneous protocols, implements differentiated scheduling based on the characteristics of different protocols, and ensures optimal overall performance in a multi-protocol environment. After two weeks of continuous operation in a large-scale test environment, the routing adaptation engine achieved a 40% reduction in latency anomalies, an average 15% reduction in overall system response time, and a significant improvement in system stability and access concurrency.

[0045] The present invention is therefore intended to be illustrative and non-restrictive in all respects, with the scope of the invention being defined by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalents of the application documents are intended to be embraced therein.

[0046] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be construed in the widest possible manner consistent with the principles and novel features disclosed herein.

Claims

1. A dynamic routing algorithm for central control equipment supporting access of multi-protocol terminal devices, characterized in that: The following steps are involved: Step S1: Collect real-time communication signals during the access initialization phase, perform comprehensive protocol compatibility assessment, and generate a multi-protocol dynamic access behavior profile; Step S2: Obtain multi-dimensional operating status parameters of the central control device, calculate resource utilization and capacity margin of each routing module, and generate the precise load carrying capacity of each routing module; Step S3: performing adaptive routing adaptation request according to the real-time communication signal, and performing device integration priority evaluation to obtain the integration priority of each device; Step S4: Calculate the maximum concurrent protocols and the dynamic routing allocation boundary based on the precise load carrying capacity and the multi-protocol dynamic access behavior profile to obtain the dynamic routing adaptation capacity constraint; Step S5: performing intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints, and performing intelligent protocol path adjustment according to the incorporation priority, thereby obtaining a multi-device intelligent adjustment incorporation path; Step S6: Identify the routing protocols with abnormal latency, optimize the routing resource topology, and perform multi-protocol routing adaptation and self-evolution based on the multi-device intelligent adjustment and incorporation paths to build a multi-protocol routing adaptation engine.

2. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S1 are: When a multi-protocol terminal device requests to access the central control system, it collects real-time communication signals during the access initialization phase; Identify protocol identification features, data frame encapsulation format, handshake timing structure and error control mechanism of the real-time communication signal to obtain communication behavior parameters of multiple protocol terminal devices; Performing a multi-dimensional protocol similarity cluster analysis on the communication behavior parameters to obtain a semantic affinity graph for each type of protocol; Quantitatively evaluating the compatibility of real-time communication signal protocols based on the semantic affinity graph to obtain the routing adaptation complexity of each protocol; Real-time protocol behavior pattern recognition is performed based on protocol identification features and data frame encapsulation formats to obtain access behavior preferences of different terminal devices; A comprehensive protocol compatibility assessment is performed based on the routing adaptation complexity and the access behavior preference to generate a multi-protocol dynamic access behavior profile.

3. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S2 are: Continuously monitor the multi-dimensional operating status parameters of each routing module within the central control device; Calculating processor occupancy, memory buffer status, and port throughput data of the multi-dimensional operating status parameters; Perform a comprehensive resource utilization analysis on processor occupancy, memory buffer status, and port throughput data, and perform multi-scale time series smoothing to obtain a resource utilization smoothing curve. Perform nonlinear trend prediction on the resource utilization smooth curve to extract the instantaneous fluctuation characteristics and long-term evolution trend of the central control equipment routing resources; Performing dynamic modeling of routing load based on the instantaneous fluctuation characteristics and long-term evolution trends to obtain a routing load prediction model; The routing load prediction model calculates the capacity margin of each routing module one by one to generate the accurate load carrying capacity of each routing module.

4. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S3 are: Perform time-series routing load analysis based on the resource utilization smooth curve to obtain the time-series routing load trend; Calculating the transmission throughput of each device unit based on the real-time communication signal to generate a periodic transmission throughput; Calculate the transmission demand of the periodic transmission throughput and generate the real-time transmission demand value of each device; Performing an adaptive routing adaptation request on a temporal routing load trend according to the real-time transmission demand value to generate multi-device routing adaptation request data; The device incorporation priority is evaluated on the multi-device routing adaptation request data to obtain the incorporation priority of each device.

5. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S4 are: Performing maximum concurrent protocol calculation based on the precise load carrying capacity to obtain the upper limit of concurrent protocol processing for each reason module; Perform multi-time window concurrent load prediction on multi-protocol dynamic access behavior profiles and generate multi-time window concurrent load prediction graphs; Perform large-scale concurrent access scenario simulation based on the concurrent processing upper limit of the protocol and the multi-time window concurrent load prediction diagram to obtain large-scale concurrent simulation data; Based on the incorporation priority, dynamic routing allocation boundary calculation is performed on large-scale concurrent simulation data to obtain a dynamic routing adaptation capacity constraint for each device.

6. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S5 are: Intelligent routing topology reconstruction based on dynamic routing adaptation capacity constraints and building adaptive multi-protocol routing scheduling strategies; Perform heterogeneous protocol path planning based on adaptive multi-protocol routing scheduling strategy to generate personalized protocol scheduling paths for different devices; Perform multi-device access execution based on the personalized protocol scheduling path and collect real-time device access data streams; Intelligent protocol path adjustment is performed based on the instant device access data flow, thereby obtaining a multi-device intelligent adjustment and integration path.

7. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 6, characterized in that: The specific steps of performing intelligent protocol path adjustment based on the instant device access data flow to obtain the multi-device intelligent adjustment and integration path are as follows: Calculate the information entropy of the data stream accessed by the instant device to obtain the information entropy of the data stream; Performing an information entropy multi-period evolution analysis on the data stream information entropy to generate a multi-period information entropy evolution feature for each device; Calculating the data flow complexity based on the multi-period information entropy evolution characteristics to generate a data flow incorporation complexity evaluation value; Performing a current protocol path adaptability analysis on the data flow integration complexity evaluation value to generate a current protocol path adaptability of each device; Perform multi-device merge path conflict detection on the personalized protocol scheduling path and extract the conflicting merge paths; The conflicting incorporation paths are dynamically adjusted according to the incorporation priority of each device, and intelligent protocol path adjustment is performed based on the current protocol path adaptability, thereby obtaining a multi-device intelligently adjusted incorporation path.

8. The dynamic routing algorithm for central control equipment supporting multi-protocol terminal equipment access according to claim 1, characterized in that: The specific steps of step S6 are: Calculate the device integration response time based on the instant device access data flow to obtain the device integration response time; calculating a time delay trend of the device incorporating a response time; Performing routing performance deviation analysis based on the time delay trend and tracing the source of the incorporated routing protocol to obtain the incorporated routing protocol with abnormal delay; Conduct deep anomaly attribution mining on the routing protocol with abnormal latency to obtain the bottleneck factors of abnormal latency routing; Optimize the routing resource topology for the latency-related bottleneck factors to generate a latency protocol topology optimization strategy. Based on the delay protocol topology optimization strategy and the intelligent adjustment of multiple devices into the path, multi-protocol routing adaptation self-evolution is carried out to build a multi-protocol routing adaptation engine.

Images