Dynamic interface adaptation and data interaction management method for dcs full network architecture

Abstract

The application discloses a dynamic interface adaptation and data interaction management method of a DCS full network architecture and belongs to the technical field of industrial automation control. The method comprises the following steps: collecting network topology snapshots of each control node, calculation node and communication node in the DCS full network architecture in real time, and extracting a node connection matrix and link quality parameters; inputting the node connection matrix and the link quality parameters into an interface adaptation rule generation engine to generate a dynamic interface adaptation rule set through protocol stack negotiation processing; distributing the dynamic interface adaptation rule set to protocol stack adapters of each node, performing runtime recombination on a local protocol stack by the protocol stack adapters, and forming a heterogeneous protocol unified channel; executing data interaction through the heterogeneous protocol unified channel, monitoring data interaction flow in real time, and dynamically adjusting the dynamic interface adaptation rule set according to the flow.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, specifically to a dynamic interface adaptation and data interaction management method for a DCS full-network architecture. Background Technology

[0002] A DCS (Distributed Control System) network architecture typically includes control nodes, compute nodes, and communication nodes from different vendors. These nodes carry communication protocol stacks with significant differences in version, data format, and transmission mechanisms. To achieve data interaction between nodes, current technologies generally employ statically configured protocol adaptation, where a fixed combination of protocols and conversion rules is pre-specified for each communication pair during system deployment. This static configuration method cannot detect dynamic changes in network topology or real-time fluctuations in link quality. When the network structure changes or link quality deteriorates, the configured protocol combinations cannot be automatically adjusted, easily leading to communication timeouts, data loss, or bandwidth waste. Furthermore, existing protocol adaptation mechanisms rely on protocol stacks embedded in the operating system kernel within the nodes. Different types of protocol processing modules are determined during the compilation phase, and the protocol stack cannot be reassembled during runtime. When compatibility with new protocol types or dynamic switching of protocol layer combinations is required, it is often necessary to restart the node or redeploy the protocol software, interrupting current data interaction services. In the field, a large number of heterogeneous protocols coexist, with each protocol processing independently and lacking a unified interaction channel. This results in redundant data packet encapsulation and decapsulation operations, increasing node processing overhead and end-to-end latency.

[0003] In a DCS environment, node connections change frequently with production process adjustments. Links exhibit time-varying packet loss rates and latency characteristics due to factors such as electromagnetic interference and load fluctuations, requiring interface adaptation strategies to keep pace with network status changes in real time. Simultaneously, data exchange traffic exhibits differentiated peak-valley characteristics under different operating conditions such as batch control and security interlocking, making it difficult for fixed protocol configurations to simultaneously meet the transmission requirements of high throughput and low jitter. The dynamic nature of network topology and links, the runtime rigidity of protocol stacks, and the lag in traffic response have become the core obstacles to efficient communication in heterogeneous DCS networks. Summary of the Invention

[0004] This paper presents a dynamic interface adaptation and data interaction management method for a DCS full network architecture. Based on collecting network topology snapshots and extracting node connection matrices and link quality parameters, the interface adaptation rule generation engine performs protocol stack negotiation for each communication pair, generates a dynamic interface adaptation rule set, and distributes it to each node. This enables the protocol stack adapter to reassemble the local protocol stack in the running state, forming a unified channel for heterogeneous protocols. Then, the interface adaptation rule set is adjusted according to the closed loop of real-time monitored data interaction traffic, realizing the coordinated adaptation of protocol policies with network status and traffic characteristics.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a dynamic interface adaptation and data interaction management method for a DCS full network architecture. The method includes: real-time acquisition of network topology snapshots of each control node, computing node, and communication node in the DCS full network architecture; extraction of node connection matrices and link quality parameters from the network topology snapshots; inputting the node connection matrices and link quality parameters into a pre-built interface adaptation rule generation engine; performing protocol stack negotiation processing on each communication pair through the interface adaptation rule generation engine to generate a dynamic interface adaptation rule set; distributing the dynamic interface adaptation rule set to the protocol stack adapters of each node; having the protocol stack adapters perform runtime reorganization of their local protocol stacks according to the dynamic interface adaptation rule set to form a heterogeneous protocol unified channel; performing data interaction between nodes through the heterogeneous protocol unified channel, and monitoring data interaction traffic in real time, dynamically adjusting the dynamic interface adaptation rule set according to the data interaction traffic. This method constructs a closed-loop management mechanism that can perceive the entire network topology and link status in real time, thereby achieving adaptive matching of communication protocols and dynamic optimization of data channels in heterogeneous DCS networks. This significantly improves the interoperability and transmission efficiency of the system when facing complex industrial network environments.

[0006] As a technical solution of the present invention, when extracting the node connection matrix and link quality parameters from the network topology snapshot, the network topology snapshot is subjected to node deduplication and link identification processing to obtain a deduplicated node list and a link identifier list; bidirectional delay detection and packet loss rate statistics are performed on the link corresponding to each link identifier to generate an original quality dataset; the original quality dataset is smoothed by Kalman filtering to obtain the link quality parameters; based on the deduplicated node list and the link identifier list, the node connection matrix is ​​generated, wherein each element of the node connection matrix represents the index of whether there is a valid link between two nodes and the link quality parameters. This processing method can effectively eliminate data noise caused by instantaneous network jitter, providing a stable and accurate topology and quality basis for subsequent rule generation.

[0007] As a technical solution of the present invention, when performing protocol stack negotiation processing on each communication pair through the interface adaptation rule generation engine, all communication pairs are extracted from the node connection matrix, and each communication pair consists of a source node identifier and a target node identifier. For each communication pair, the protocol capability matching module in the interface adaptation rule generation engine is called to query the protocol stack versions and data format lists supported by the source node and the target node respectively. Based on the protocol stack version and data format lists, the longest common protocol stack matching algorithm is executed to obtain the negotiated protocol stack sequence. The negotiated protocol stack sequence is associated with the corresponding communication pair to generate the dynamic interface adaptation rule set. This process ensures that any two nodes that need to communicate can always automatically negotiate an optimal protocol combination that both parties support, fundamentally solving the protocol compatibility problem when heterogeneous devices are interconnected.

[0008] Preferably, when the protocol stack adapter reassembles the local protocol stack at runtime according to the dynamic interface adaptation rule set, the protocol stack adapter parses the rule entries related to this node in the dynamic interface adaptation rule set and extracts the negotiated protocol stack sequence; according to the negotiated protocol stack sequence, it starts the local node's protocol stack dynamic loader and loads the processing plugins of the corresponding protocol layers in sequence; it then attaches the processing plugins of each protocol layer to the specified location of the kernel protocol stack through hook functions, forming the heterogeneous protocol unified channel; the protocol stack adapter also maintains a protocol stack state hash table to record the version number of the protocol stack combination currently used by each communication pair. This technical solution realizes on-demand dynamic reassembly of the protocol stack, without restarting the node or interrupting services, and can complete the flexible switching and establishment of protocol channels at runtime, while maintaining effective tracking of the current protocol state.

[0009] As a technical solution of this invention, when data interaction and dynamic adjustment are performed between nodes through the heterogeneous protocol unified channel, a traffic monitoring agent is deployed on each node. The traffic monitoring agent bypasses and captures data packets passing through the heterogeneous protocol unified channel, and calculates the instantaneous bandwidth and latency jitter of each communication pair. The instantaneous bandwidth and latency jitter are uploaded to the central control module, which compares the instantaneous bandwidth with a pre-set bandwidth threshold. When the instantaneous bandwidth exceeds the bandwidth threshold or the latency jitter exceeds the jitter tolerance, the central control module triggers a rule renegotiation signal and sends the rule renegotiation signal to the interface adaptation rule generation engine. The interface adaptation rule generation engine updates the negotiation protocol stack sequence of the corresponding communication pair according to the rule renegotiation signal, generating a new dynamic interface adaptation rule set. This mechanism constructs a real-time "monitoring-evaluation-adjustment" closed loop, enabling the protocol adaptation strategy to dynamically follow changes in network traffic. When congestion or quality degradation occurs, it can autonomously initiate protocol renegotiation to ensure the transmission quality of critical services.

[0010] Preferably, when distributing the dynamic interface adaptation rule set to each node, a distributed configuration distribution bus is constructed. This distributed configuration distribution bus adopts a publish-subscribe pattern, encapsulating the dynamic interface adaptation rule set into a rule change notification. The rule change notification carries a rule effective timestamp and a rule version number, and is broadcast to all nodes via the distributed configuration distribution bus. Each node's protocol stack adapter subscribes to the distributed configuration distribution bus. Upon receiving the rule change notification, it determines whether an update is needed based on the rule effective timestamp and the rule version number. If an update is needed, the protocol stack adapter locks the write operation of its local protocol stack, loads the new rule, and updates the protocol stack state hash table. This publish-subscribe based distributed distribution mechanism ensures that, in a large-scale DCS network, the protocol adaptation rules of all nodes can be reliably and consistently updated, and prevents read-write conflicts and rule corruption through locking mechanisms and version control.

[0011] As a technical solution of this invention, when performing data interaction through the heterogeneous protocol unified channel, a unified data interaction proxy is constructed on each node. This unified data interaction proxy encapsulates data sending and receiving interfaces. The unified data interaction proxy selects the data packet format according to the corresponding negotiation protocol stack sequence for the current communication. For sending data, the unified data interaction proxy calls the sending hook of the heterogeneous protocol unified channel, sequentially executing the packetization and encryption operations of each layer of the protocol stack to generate a protocol-adapted data frame. For receiving data, the unified data interaction proxy obtains the original data frame from the receiving hook of the heterogeneous protocol unified channel, sequentially executing the unpacking and decryption operations of each layer of the protocol stack to extract application layer data. The unified data interaction proxy also maintains a data interaction log, recording the sending timestamp and receiving confirmation timestamp of each data frame. This technical solution provides a unified and transparent data transmission interface for upper-layer applications, shielding the complexity of the underlying heterogeneous protocols, allowing application development to focus on specific protocol adaptation details without needing to concern itself with them, while also providing complete timestamp records for data trace auditing.

[0012] As a technical solution of the present invention, the process of real-time monitoring of data interaction traffic includes: setting a sliding window counter in the traffic monitoring agent of each node, wherein the sliding window counter records the number of data packets and bytes of each communication pair at a preset time granularity; the traffic monitoring agent periodically reports the contents of the sliding window counter to the central control module, wherein the central control module merges the reported data from each node into a global traffic matrix; the central control module performs anomaly detection on the global traffic matrix, wherein the anomaly detection uses the isolated forest algorithm to identify communication pairs with sudden increases or decreases in traffic; the identified abnormal communication pairs are marked as objects to be adjusted, and the central control module generates the rule renegotiation signal based on the traffic characteristics of the abnormal communication pairs. This anomaly detection method based on the entire network traffic matrix can quickly and accurately identify abnormal traffic patterns in the network from a macro perspective, thereby triggering dynamic optimization of protocol rules more precisely.

[0013] Preferably, when the protocol stack adapter reassembles the local protocol stack at runtime, the protocol stack adapter preloads a protocol stack component library containing various protocol processing modules, each with a unique identifier and interface signature. The protocol stack adapter selects the corresponding protocol processing module from the protocol stack component library based on the negotiated protocol stack sequence and checks whether the interface signature matches the hook function signature of the current kernel protocol stack. If they match, the protocol stack adapter injects the code segment of the protocol processing module into the address space of the kernel protocol stack via memory mapping. If they do not match, the protocol stack adapter starts an interface adaptation and conversion module to generate a thin encapsulation layer, making the interface signature of the protocol processing module compatible with the hook function signature. This process achieves efficient loading and seamless compatibility of protocol processing modules, improves injection speed through memory mapping, and ensures that even third-party protocol components with interface differences can be quickly integrated, greatly enhancing the system's scalability.

[0014] Preferably, when dynamically adjusting the rules, the bandwidth threshold is automatically updated at preset intervals based on historical traffic statistics, and the jitter tolerance is defined as twice the root mean square value of latency jitter. This adaptive threshold setting method allows the system's judgment benchmark for traffic changes and jitter anomalies to be automatically calibrated with long-term changes in the network environment, avoiding false triggering or missed triggering problems caused by fixed thresholds, and ensuring the long-term effectiveness and accuracy of the system's control strategy.

[0015] The technical effects and advantages provided by the present invention in the above technical solution are as follows: The node connectivity matrix and link quality parameters are extracted from the network topology snapshot and input into the interface adaptation rule generation engine for protocol stack negotiation. The node connectivity matrix reflects the real-time connectivity of the entire network, and the link quality parameters are smoothed by Kalman filtering to eliminate transient noise interference. Both serve as input for protocol negotiation. The interface adaptation rule generation engine calls the protocol capability matching module to query the list of protocol stack versions and data formats supported by each end node of the communication pair, executes the longest common protocol stack matching algorithm, and obtains the negotiated protocol stack sequence. This process ensures that the protocol combination used by each communication pair is no longer a pre-fixed manual setting, but is adaptively calculated by the engine based on the current network topology and real-time link quality. When link quality fluctuates, the negotiation result can migrate to a lighter or more packet loss-resistant protocol stack combination, maintaining the continuity and reliability of data interaction, and enabling the protocol adaptation decision to follow network state changes in real time. After receiving the dynamic interface adaptation rule set, the protocol stack adapter parses out the negotiated protocol stack sequence related to its node, starts the protocol stack dynamic loader, loads the processing plugins of the corresponding protocol layers in sequence, and attaches them to the specified location of the kernel protocol stack through hook functions, forming a unified channel for heterogeneous protocols. Each protocol processing module in the protocol stack component library has a unique identifier and interface signature. If an interface signature mismatch occurs during loading, the interface adaptation and conversion module is activated to generate a thin encapsulation layer, achieving non-intrusive compatibility. This runtime reconfiguration mechanism allows nodes to complete protocol stack combination switching without restarting or offline updates. Protocol processing modules from different vendors and versions can collaborate orderly within a unified channel as plug-ins, eliminating processing redundancy between heterogeneous protocols and reducing context switching overhead during data packet encapsulation and decapsulation. Dynamic protocol loading and channel unification enable multiple types of data streams to share the same underlying communication path, and the protocol stack combination version number of each communication pair is tracked by the protocol stack state hash table, facilitating rapid rollback or version comparison.

[0016] Traffic monitoring agents deployed on each node bypass and capture data packets passing through the unified channel of heterogeneous protocols, statistically analyze the instantaneous bandwidth and latency jitter of each communication pair, and upload the statistical results to the central control module. When the instantaneous bandwidth exceeds the dynamically updated bandwidth threshold or the latency jitter exceeds the tolerance limit, the central control module triggers a rule renegotiation signal, marks the corresponding communication object as an object to be adjusted, and feeds back to the interface adaptation rule generation engine. The engine then recalculates the negotiation protocol stack sequence of the communication pair, generating a new dynamic interface adaptation rule set. Leveraging the publish-subscribe mode of the distributed configuration distribution bus and rule change notifications carrying effective timestamps and version numbers, each node can complete rule updates in an orderly manner, smoothly switching to the new protocol combination after locking the write operation. This traffic feedback-driven closed-loop adjustment mechanism enables the interface adaptation strategy to respond to changes in business traffic in real time. During high-load periods, it can automatically switch to high-throughput protocol combinations, while during low-load or high-interference periods, it prioritizes low-jitter transmission, achieving dynamic matching of communication resources and business needs. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0018] Figure 1 This is a flowchart of the dynamic interface adaptation and data interaction management method for the entire DCS network architecture; Figure 2 This is a flowchart of the method for generating dynamic interface adaptation rule sets; Figure 3 This is a flowchart illustrating the method by which the protocol stack adapter dynamically loads and mounts processing plugins based on the negotiated protocol stack sequence. Figure 4 This is a flowchart of the dynamic interface adaptation rule set distribution and update process. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] See Figure 1This invention provides a dynamic interface adaptation and data interaction management method for a DCS full network architecture, comprising: real-time acquisition of network topology snapshots of each control node, computing node, and communication node in the DCS full network architecture; extraction of node connection matrix and link quality parameters from the network topology snapshots; inputting the node connection matrix and link quality parameters into a pre-built interface adaptation rule generation engine; performing protocol stack negotiation processing on each communication pair through the interface adaptation rule generation engine to generate a dynamic interface adaptation rule set; distributing the dynamic interface adaptation rule set to the protocol stack adapters of each node; having the protocol stack adapters perform runtime reorganization of their local protocol stacks according to the dynamic interface adaptation rule set to form a heterogeneous protocol unified channel; performing data interaction between nodes through the heterogeneous protocol unified channel, and monitoring data interaction traffic in real time, dynamically adjusting the dynamic interface adaptation rule set according to the data interaction traffic.

[0021] Example 1:

[0022] In specific implementation, please refer to Figure 2 The network topology snapshot undergoes node deduplication and link identification processing to obtain a deduplicated node list and a link identifier list. Network topology snapshots are periodically acquired by a topology acquisition agent deployed throughout the DCS network architecture. The topology acquisition agent sends LLDP neighbor discovery messages to each control node, compute node, and communication node and collects the neighbor information tables returned by each node, summarizing them to form an original topology dataset containing node identifiers, port identifiers, and adjacency relationships. During node deduplication, all occurrences of node identifiers are extracted from the original topology dataset, entries with identical node identifiers are merged, and duplicate records are removed to form a deduplicated node list. During link identification, the connection relationship between each pair of adjacent nodes in the original topology dataset is parsed, extracting the source node identifier, destination node identifier, and port pair information. A unique link identifier is generated for each physical or logical link, which is composed of the source node identifier, destination node identifier, and link sequence number. All link identifiers are summarized to form a link identifier list.

[0023] In practice, bidirectional delay probing and packet loss rate statistics are performed on each link corresponding to each link identifier in the link identifier list to generate a raw quality dataset. Bidirectional delay probing is implemented using the TWAMP protocol. The probing initiating node sends a test message with a sending timestamp to the link peer node. Upon receiving the message, the peer node immediately sends back a response message with a receiving timestamp and a sending timestamp. The probing initiating node calculates the round-trip delay based on the sending timestamp, the peer receiving timestamp, the peer sending timestamp, and its own receiving timestamp. Packet loss rate statistics are performed by the sending end sending test data packets carrying incremental sequence numbers to the link peer within a preset statistical period. The receiving end counts the actual number of data packets received. The packet loss rate is defined as the ratio of the difference between the total number of sent data packets and the total number of received data packets divided by the total number of sent data packets. Each set of bidirectional delay probing results and packet loss rate statistics results is correlated by the probing timestamp to form a raw quality data record containing the link identifier, timestamp, round-trip delay value, and packet loss rate value. All the raw quality data records for all links constitute the raw quality dataset.

[0024] In practice, the original quality dataset is smoothed using a Kalman filter to obtain link quality parameters. The Kalman filter smoothing process uses link identifiers as the grouping dimension, processing the time series data corresponding to each link identifier in the original quality dataset separately. The state vector of the Kalman filter consists of the estimated link delay and the estimated rate of change of link delay, while the observation vector is the round-trip delay value from the original quality data record. In the prediction step, the Kalman filter further predicts the current state vector using the state transition matrix, calculating the predicted state vector and the prediction error covariance matrix. In the update step, the predicted state vector is corrected using the current observation values, and the updated state vector and the updated error covariance matrix are obtained after calculating the Kalman gain. The initial value of the process noise covariance matrix of the Kalman filter is set to a diagonal matrix with all diagonal elements of 0.01, the initial value of the observation noise variance is set to 0.1, the initial value of the state vector uses the first observation value for delay estimation and 0 for the rate of change of delay estimation, and the initial value of the error covariance matrix is ​​set to a diagonal matrix with all diagonal elements of 1.0. For the packet loss rate time series corresponding to each link identifier in the original quality dataset, the same Kalman filtering framework as the round-trip delay is used for processing. The state vector consists of the packet loss rate estimate and the packet loss rate change estimate. The initial value of the process noise covariance matrix is ​​set to a diagonal matrix with all diagonal elements of 0.001, and the initial value of the observation noise variance is set to 0.01. After Kalman filtering smoothing, each link identifier obtains a smoothed round-trip delay value and a packet loss rate value at each sampling time. The smoothed round-trip delay value and packet loss rate value together constitute the link quality parameters.

[0025] In practice, a node connection matrix is ​​generated based on the deduplication node list and the link identifier list. The node connection matrix is ​​a single... The matrix, where This represents the number of node identifiers in the deduplication list. The row and column indices of the node connection matrix correspond to the node identifiers in the deduplication list, respectively. The elements of the node connection matrix... This element represents the index indicating whether a valid link exists between nodes p and q, along with the index of the link quality parameters. Node p corresponds to the p-th node identifier in the deduplication list, and node q corresponds to the q-th node identifier in the deduplication list. When a link identifier exists between nodes p and q from the link identifier list, and the packet loss rate of the corresponding link in the link quality parameters is lower than a preset link disconnection packet loss rate threshold, the element... The value is assigned as the index of the link quality parameter in the link quality parameter storage array; when there is no link identifier between node p and node q, or when the packet loss rate of the corresponding link in the link quality parameters is greater than or equal to the preset link disconnection packet loss rate threshold, the element... A value of -1 indicates that no valid link exists. The diagonal elements of the node connection matrix... The value is uniformly assigned to -1. The link quality parameter storage array stores the smoothed round-trip time and packet loss rate values ​​corresponding to each link identifier in the order of the link identifier. Each element contains a time delay field and a packet loss rate field.

[0026] In practice, all communication pairs are extracted from the node connection matrix. Each communication pair consists of a source node identifier and a target node identifier. All off-diagonal elements of the node connection matrix are traversed. For each element with a value other than -1, the node identifier corresponding to the row index is extracted as the source node identifier, and the node identifier corresponding to the column index is extracted as the target node identifier. The source node identifier and the target node identifier constitute a communication pair. After removing duplicates from all extracted communication pairs, a list of communication pairs is formed.

[0027] In practice, for each communication pair in the communication pair list, the protocol capability matching module in the interface adaptation rule generation engine is invoked to query the list of protocol stack versions and data formats supported by the source node and the target node. Each node maintains a node capability information database in the DCS full network architecture, which records the protocol identifiers, protocol version numbers, and supported data encapsulation format identifiers for each layer of the protocol stack supported by the node. The protocol capability matching module sends capability query request messages to the source node and the target node in the communication pair, respectively. After receiving the capability query request messages, the source node and the target node return the list of protocol stack versions and data formats recorded in their respective node capability information databases. Each entry in the protocol stack version and data format list includes a protocol layer identifier, a protocol family identifier, a major version number, a minor version number, and a data format identifier.

[0028] In practice, based on the list of protocol stack versions and data formats, the longest common protocol stack matching algorithm is executed to obtain the negotiated protocol stack sequence. The longest common protocol stack matching algorithm abstracts the list of protocol stack versions and data formats supported by the source node and the target node into two ordered sequences. Each sequence consists of a quintuple of protocol layer identifier, protocol family identifier, major version number, minor version number, and data format identifier. The algorithm constructs a two-dimensional dynamic programming table, where the number of rows equals the length of the source node sequence plus one, and the number of columns equals the length of the target node sequence plus one. Each quintuple element in the source and target node sequences is compared sequentially. When the protocol layer identifier and protocol family identifier of two quintuple elements match, the value of the corresponding cell in the two-dimensional dynamic programming table is the value of the top-left cell plus one; when the protocol layer identifier or protocol family identifier of two quintuple elements does not match, the value of the corresponding cell in the two-dimensional dynamic programming table is the larger of the value of the cell to the left and the cell above it. After the two-dimensional dynamic programming table is populated, backtracking begins from the bottom right cell to extract the matching quintuple element sequence. The backtracked matching quintuple element sequence constitutes the negotiation protocol stack sequence. Each quintuple element in the negotiation protocol stack sequence represents the protocol family, protocol version, and data format commonly supported by both communicating parties at the corresponding protocol layer.

[0029] In practice, the negotiated protocol stack sequence is associated with the corresponding communication pair to generate a dynamic interface adaptation rule set. The dynamic interface adaptation rule set is stored in a key-value pair structure, where the key is the communication pair identifier, which is composed of the source node identifier, a separator, and the target node identifier, and the value is the negotiated protocol stack sequence. For each communication pair in the communication pair list, the communication pair identifier and the corresponding negotiated protocol stack sequence are written into the dynamic interface adaptation rule set to form a complete rule record. The dynamic interface adaptation rule set is serialized into a protocol buffer format before storage and transmission.

[0030] Example 2:

[0031] In specific implementation, please refer to Figure 3The protocol stack adapter parses the rule entries related to the current node in the dynamic interface adaptation rule set and extracts the negotiated protocol stack sequence. The dynamic interface adaptation rule set is serialized in protocol buffer format and stored in the node's local configuration cache. Upon startup, the protocol stack adapter reads the serialized data from the local configuration cache and deserializes it into a rule set memory object. The protocol stack adapter obtains the node identifier of the current node, iterates through all key-value pairs in the rule set memory object, and parses the communication pair identifier string contained in the key. The communication pair identifier string is composed of the source node identifier, a separator, and the target node identifier. The protocol stack adapter extracts the source node identifier field and the target node identifier field based on the separator position. When the source node identifier field or the target node identifier field matches the current node identifier, it indicates that the rule entry corresponding to the communication pair identifier is related to the current node. The protocol stack adapter extracts the value of this rule entry, i.e., the negotiated protocol stack sequence, and stores it in the relevant rule list. Each element in the relevant rule list contains a communication pair identifier and the corresponding complete negotiation protocol stack sequence. The negotiation protocol stack sequence is an ordered list, and each list element is a quintuple containing the protocol layer identifier, protocol family identifier, major version number, minor version number, and data format identifier.

[0032] In practice, based on the negotiated protocol stack sequence, the local node's protocol stack dynamic loader is activated, loading the corresponding protocol layer processing plugins sequentially. The protocol stack dynamic loader is a daemon process component running in the operating system's user space, communicating with the kernel protocol stack via netlink sockets. The protocol stack adapter retrieves communication pair identifiers and their corresponding negotiated protocol stack sequences from the relevant rule list. For each 5-tuple element in the negotiated protocol stack sequence, the protocol stack adapter constructs a load request message, which includes a protocol layer identifier field, a protocol family identifier field, a major version number field, a minor version number field, and a data format identifier field. Upon receiving the load request message, the protocol stack dynamic loader searches the local protocol processing plugin registry for protocol layer processing plugins that match the protocol family identifier, major version number, minor version number, and data format identifier in the load request message. The protocol processing plugin registry is a pre-built index structure, using the combination of the protocol family identifier, major version number, minor version number, and data format identifier as the index key, storing the file path and loading entry function symbol of the corresponding protocol layer processing plugin. The protocol stack dynamic loader loads the processing plugins of each protocol layer in the order of the negotiated protocol stack sequence, maps the dynamic link libraries of the processing plugins to the process address space, and resolves the entry function address.

[0033] In practice, processing plugins for each protocol layer are mounted to designated locations on the kernel protocol stack via hook functions, forming a unified channel for heterogeneous protocols. The kernel protocol stack reserves hook function mounting points at the entry point of each protocol layer, implemented as a linked list of function pointers. The protocol stack dynamic loader sends mounting instructions to the kernel protocol stack via a netlink socket, carrying the protocol layer identifier, hook mounting point identifier, and the virtual address of the processing plugin entry function in user space. Upon receiving the mounting instructions, the kernel protocol stack's hook management module uses kernel functions to convert the user space virtual address into a kernel-accessible function pointer and creates a kernel-mode proxy function. This kernel-mode proxy function calls the user space processing plugin entry function through a secure copy mechanism. The kernel protocol stack inserts the kernel-mode proxy function pointer into the end of the hook function linked list for the corresponding protocol layer. When a data packet passes through the kernel protocol stack at that protocol layer, the kernel protocol stack sequentially calls the function pointers in the hook function linked list, including the original kernel protocol stack processing function and the newly mounted processing plugin proxy function, achieving runtime reassembly of the protocol layers. After all communication pairs are mounted with the relevant processing plugins, the hook lists of each protocol layer in the kernel protocol stack and the original protocol processing paths together form a unified channel for heterogeneous protocols.

[0034] In its implementation, the protocol stack adapter also maintains a protocol stack state hash table to record the current protocol stack combination version number used by each communication pair. The protocol stack state hash table uses the communication pair identifier string as the key hash input and employs the FNV-1a hash algorithm to calculate the hash bucket index. Each entry in the protocol stack state hash table contains a communication pair identifier field, a protocol stack combination version number field, and a last update timestamp field. The protocol stack combination version number field is a string type, composed of the first sixteen characters of the SHA-256 digest obtained by concatenating the protocol family identifier, major version number, and minor version number of all five tuples in the negotiated protocol stack sequence in protocol layer order. After the protocol stack adapter completes a loading and mounting operation of a negotiated protocol stack sequence, it updates the entry in the protocol stack state hash table corresponding to the communication pair identifier, writes the protocol stack combination version number field to the calculated digest string, and writes the last update timestamp field to the current system monotonic time.

[0035] In implementation, the protocol stack adapter preloads a protocol stack component library, which contains various protocol processing modules, each with a unique identifier and interface signature. The protocol stack component library is stored in a directory tree format within the node storage file system. The root directory is categorized into subdirectories based on protocol families, and each subdirectory is further divided into subdirectories based on major and minor version numbers. Leaf nodes represent the binary relocatable target files of the protocol processing modules. During the initialization phase, the protocol stack adapter traverses the protocol stack component library directory tree, parsing the symbol table of each protocol processing module's binary target file, extracting the list of exported functions and the list of parameter types and return value types for each exported function. The protocol stack adapter concatenates the exported function names, parameter type list, and return value types into a string and calculates the CRC-64 checksum as the interface signature. The protocol stack adapter constructs a component index table. The key of the component index table is a quadruple consisting of the protocol family identifier, major version number, minor version number, and data format identifier. The values ​​are records containing the protocol processing module file path, interface signature list, and entry function symbol list.

[0036] In practice, the protocol stack adapter selects the corresponding protocol processing module from the protocol stack component library based on the negotiated protocol stack sequence. The adapter iterates through each quintuple in the negotiated protocol stack sequence, constructing a query quadtuple using the protocol family identifier, major version number, minor version number, and data format identifier from the quintuple, and searches for the corresponding record in the component index table. If a record is found, the file path and interface signature list are retrieved; otherwise, a component missing alarm is reported to the central control module, and the loading of the protocol layer corresponding to that quintuple is skipped. After selecting the corresponding protocol processing module, the adapter checks whether the interface signature matches the hook function signature of the current kernel protocol stack. The adapter queries the hook function signature of the corresponding protocol layer mount point from the kernel protocol stack hook management module. The hook function signature is also represented as a list of CRC-64 checksums. The matching judgment uses a set inclusion comparison method, requiring that the interface signature of each exported function in the interface signature list of the protocol processing module can be found in the hook function signature list with an equal value, and the parameter order must be consistent.

[0037] In practice, if the interface signature matches, the protocol stack adapter injects the code segment of the protocol processing module into the address space of the kernel protocol stack via memory mapping. The protocol stack adapter calls the operating system's memory mapping interface to map the object file of the protocol processing module into the address space of the process where the kernel protocol stack resides in read-only executable mode, and obtains the starting virtual address of the mapping. The protocol stack adapter adds the starting virtual address of the mapping to the offset of the entry function to obtain the absolute address of the entry function, and registers the absolute address of the entry function into the kernel protocol stack hook function linked list through the aforementioned mounting process.

[0038] In practical implementation, if the interface signatures do not match, the protocol stack adapter initiates the interface adaptation and conversion module, generating a thin encapsulation layer to ensure compatibility between the protocol processing module's interface signature and the hook function signature. The interface adaptation and conversion module parses the differences between the exported function parameter type list and the hook function parameter type list, generating parameter conversion code. The thin encapsulation layer takes the form of an automatically generated C language source code function. This function declares local variables to store the converted parameters, converts the hook function's input parameters to the format expected by the protocol processing module's exported function according to the conversion mapping relationship, calls the protocol processing module's exported function, and returns the value according to the type required by the hook function. The conversion mapping relationship used by the interface adaptation and conversion module is represented as a conversion matrix. Its construction process is as follows: abstracting the list of exported function parameter types into a single... A vector of parameter types, and a list of hook function parameter types abstracted into a single... A dimensional parameter type vector, if the position in the parameter type vector is... The parameter type can be converted to position using built-in type conversion rules. If the parameter type is specified, then set... No. Line number The column element value is the identifier code of the type conversion function; if it cannot be converted, the corresponding element value is zero. The formula for calculating the value after parameter type conversion is as follows: ,in, This indicates the hook function after conversion. The values ​​of the parameters, The protocol processing module's exported function is... The values ​​of the original parameters, Represents the transformation matrix of the first... Line number Column-stored identifier encoding The type conversion execution function selects the corresponding standard type conversion operation based on the identifier code; if the identifier code is zero, it returns a null operation. The interface adaptation conversion module generates source code statements for parameter conversion based on the conversion matrix, calls the compiler to compile the source code into position-independent target code, and then injects this target code, i.e., the thin wrapper layer, into the kernel protocol stack address space through memory mapping. The entry function address of the thin wrapper layer is registered to the hook function linked list, replacing the original protocol processing module entry function.

[0039] Example 3:

[0040] In specific implementation, please refer to Figure 4A distributed configuration distribution bus is constructed, employing a publish-subscribe model. The distributed configuration distribution bus consists of bus agent processes deployed on each node of the DCS network architecture and a centralized message exchange center, which runs on a redundantly deployed server cluster. Each bus agent process establishes a persistent connection with the centralized message exchange center based on the Transmission Control Protocol (TCP) upon startup and registers its node identifier and topic subscription list with the centralized message exchange center. The topic identifiers use a hierarchical naming convention, formatted as " / dcs / config / rule," where " / dcs" represents the root namespace of the DCS network architecture, " / config" represents the configuration message subspace, and " / rule" represents the dynamic interface adaptation rule set related message subspace. The centralized message exchange center maintains a topic routing table, which records the connection handle list of all subscriber nodes under each topic identifier. When the centralized message exchange center receives a message from a publisher for a specific topic identifier, it iterates through the list of subscriber connection handles corresponding to that topic identifier in the topic routing table and forwards the message one by one to the bus broker process of all subscriber nodes.

[0041] In practical implementation, the dynamic interface adaptation rule set is encapsulated as a rule change notification. After being output by the interface adaptation rule generation engine, the dynamic interface adaptation rule set is passed to the rule publishing component in the central control module. The rule publishing component performs a serialization operation on the dynamic interface adaptation rule set. The serialization format adopts the message structure defined by the protocol buffer. The message structure includes a rule set identifier field, a rule entry count field, and a rule entry duplication field. Each rule entry includes a communication pair identifier and a negotiation protocol stack sequence. The rule publishing component calls the operating system clock interface to obtain the current Coordinated Universal Time (UTC). The UTC is then added to a preset rule propagation delay margin to serve as the rule's effective timestamp. The preset rule propagation delay margin is set to 500 milliseconds. This setting is based on the 95th percentile of the maximum round-trip time between nodes in the DCS full network architecture, plus the sum of the upper bounds of the protocol stack adapter processing delays of each node. The rule publishing component calculates the SHA-256 digest of the serialized data of the dynamic interface adaptation rule set, interprets the first 8 bytes of the digest value as an unsigned 64-bit big-endian integer, and uses this unsigned 64-bit integer as the rule version number. The rule publishing component combines the rule effective timestamp, rule version number, and serialized dynamic interface adaptation rule set data body into a rule change notification. The message format of the rule change notification includes a notification type identifier field, a rule effective timestamp field, a rule version number field, a data body length field, and a data body field.

[0042] In practice, rule change notifications are broadcast to all nodes via the distributed configuration distribution bus. The rule publishing component calls the publishing interface of the local node's bus agent process, sending the rule change notification as the message payload, specifying the topic identifier as " / dcs / config / rule", to the centralized message exchange center. Upon receiving the rule change notification message, the centralized message exchange center looks up the subscriber connection handle list corresponding to " / dcs / config / rule" in the topic routing table, serializes the rule change notification message into a byte stream, and writes it sequentially to the send buffer of each subscriber connection handle, completing the broadcast operation. For subscriber connections that fail to send due to a momentary network failure, the centralized message exchange center executes a retry process. The maximum number of retries is set to 3, and the retry interval is set to 200 milliseconds. If the retry still fails after 3 attempts, the centralized message exchange center returns the node identifier of the failed node to the rule publishing component, which records the node identifier of the failed node in the log storage.

[0043] In practice, each node's protocol stack adapter subscribes to the distributed configuration delivery bus. During the initialization phase, the protocol stack adapter initiates a topic subscription request to its local bus agent process. This request carries the topic identifier " / dcs / config / rule" and a pointer to the protocol stack adapter's message callback function. The bus agent process forwards the subscription request to the centralized message exchange center, which adds the node identifier and connection handle corresponding to the protocol stack adapter to the subscriber connection handle list of " / dcs / config / rule" in the topic routing table. Internally, the protocol stack adapter maintains a rule notification receiving queue, which is a lock-free circular buffer. When the local bus agent process receives a rule change notification forwarded from the centralized message exchange center, it calls the message callback function registered by the protocol stack adapter. This callback function pushes the deserialized object pointer of the rule change notification into the rule notification receiving queue.

[0044] In practice, after receiving a rule change notification, the protocol stack adapter determines whether an update is needed based on the rule's effective timestamp and version number. The protocol stack adapter's rule consumption thread retrieves the rule change notification from the rule notification receiving queue, and the protocol stack adapter parses the rule's effective timestamp field value from the notification, recording it as follows: The parsed rule version number field value is denoted as The protocol stack adapter reads the version number of the currently effective rules from local storage, denoted as... The protocol stack adapter obtains the current monotonic clock value from the operating system, denoted as... The protocol stack adapter performs an update check, and the logical expression for the update check is:

[0045] in, This is a boolean value indicating whether an update is needed. A value of logical true indicates that an update needs to be performed. A value of logical false indicates that no update is required. The rule version number carried in the rule change notification is represented by an unsigned 64-bit integer. The larger the value, the newer the rule version. The version number of the currently effective rule, recorded locally by the protocol stack adapter, is represented as an unsigned 64-bit integer; The current monotonic clock value, in milliseconds, obtained for the protocol stack adapter; The rule effective timestamp carried in the rule change notification, in Coordinated Universal Time (UTC) timestamp in milliseconds; This is an indicator function that executes when the condition within the parentheses is true. The value is 1 if it is not 1, and 0 otherwise; inequality This indicates that the rule version number in the rule change notification is greater than the currently effective rule version number; inequality This indicates that the current monotonic clock value has reached or exceeded the rule's effective timestamp. When the logical condition is true, the protocol stack adapter determines that an update needs to be performed; when... When the logic is false, the protocol stack adapter temporarily stores the rule effective timestamp and rule version number from the rule change notification into the delayed pending list, and triggers the update judgment again after the monotonic clock value reaches the rule effective timestamp.

[0046] In practical implementation, if an update is required, the protocol stack adapter locks the write operation of the local protocol stack. The protocol stack adapter uses a read-write lock mechanism to protect the protocol stack state hash table and the kernel protocol stack hook list. The protocol stack adapter calls the write lock acquisition interface of the read-write lock, waits for all operations that already hold read locks to complete, and then exclusively acquires the write lock. After acquiring the write lock, the protocol stack adapter traverses the hook list of each protocol layer of the kernel protocol stack, sets a flag to prohibit the processing of new data in the hook list, and waits for all data packets being processed in the hook list to complete processing. After completing the wait, the protocol stack adapter loads the new rules, parses the data body field in the rule change notification, deserializes it to obtain the dynamic interface adaptation rule set, extracts all rule entries in the dynamic interface adaptation rule set one by one, and executes the protocol stack runtime reorganization process described in Example 2 to complete the mounting and updating of the local protocol stack processing plugin. The protocol stack adapter updates the protocol stack state hash table, replacing the entries in the hash table corresponding to the communication pair identifiers of the update rules with the new protocol stack combination version number. The protocol stack combination version number is generated by concatenating the protocol family identifier, major version number, and minor version number of all five-tuples in the updated negotiated protocol stack sequence in protocol layer order, recalculating the SHA-256 digest, and taking the first sixteen characters. The protocol stack adapter then stores the currently effective rule version number locally. Updated to The protocol stack adapter releases the write lock of the read-write lock, clears the prohibited data processing flag in the hook list, and completes the rule update.

[0047] Example 4:

[0048] In implementation, a traffic monitoring agent is deployed on each node. This agent bypasses and captures data packets passing through the heterogeneous protocol unified channel, calculating the instantaneous bandwidth and latency jitter for each communication pair. The traffic monitoring agent runs as a kernel-loadable module in the node's operating system kernel space, attaching a bypass packet capture hook between the data link layer and network layer of the heterogeneous protocol unified channel. The bypass packet capture hook is registered through the kernel network filtering framework. During registration, the filtering condition is set so that the protocol type field equals the DCS data interaction dedicated protocol identifier. This dedicated protocol identifier is assigned the Ethernet frame type value 0x88DC during DCS full network architecture initialization. When data frames enter or leave the heterogeneous protocol unified channel, the kernel network filtering framework triggers the callback function of the bypass packet capture hook. The callback function obtains the arrival timestamp or sending timestamp of the data frame. The callback function extracts the communication pair identifier field from the data frame header. This field is located 12 bytes off the data frame header and has a length of 64 bytes. The traffic monitoring agent maintains a hash table of communication pair statistics, with the communication pair identifier as the key. Each entry in the hash table contains a cumulative byte field required for instantaneous bandwidth calculation, a cumulative byte field for the previous statistical period, a circular buffer of one-way delay samples for each data frame required for delay jitter calculation, and a cursor field for delay sample sequence number.

[0049] In practice, the traffic monitoring agent calculates the instantaneous bandwidth of each communication pair. For each captured data frame, the agent extracts the payload length field value and adds it to the cumulative byte segment in the communication pair statistics hash table entry containing the corresponding communication pair identifier. The agent is configured with a periodic timer, with a trigger interval of 1 second. Each time the timer triggers, the agent iterates through all entries in the communication pair statistics hash table, retrieving the current cumulative byte segment value and recording it as... Extract the cumulative byte value from the previous statistical period and record it as... Calculate the instantaneous bandwidth value The calculation formula is: ,in, Indicates instantaneous bandwidth, measured in bytes per second. This indicates the cumulative number of bytes at the current moment. This represents the cumulative number of bytes at the end of the previous statistical period. Indicates the duration of the statistical period. The value is 1 second. After the calculation is complete, the traffic monitoring agent will... value assigned to This is for use in the next statistical period.

[0050] In practice, the traffic monitoring agent calculates the latency jitter for each communication pair. The agent deploys a coordinated clock reference at both the sending and receiving ends of each data frame. The sending end inserts a sending timestamp field with its monotonic clock value into the data frame, and the receiving end records its monotonic clock value as a receiving timestamp upon receiving the data frame. When the traffic monitoring agent bypasses and captures a data frame, it parses the sending timestamp field value from the data frame and subtracts it from the current monotonic clock value at the time of bypass capture to obtain the one-way latency sample value. The agent stores the one-way latency sample value in the buffer slot pointed to by the current latency sample sequence number cursor in the latency sample circular buffer of the corresponding communication pair's statistical information hash table entry. The latency sample circular buffer has a fixed capacity of 64 slots, with each slot storing one one-way latency sample value. The latency sample sequence number cursor increments cyclically in modulo 64. Latency jitter is calculated using a formula defined by the real-time transmission protocol specification, taking the average deviation of all valid one-way latency sample values ​​in the latency sample circular buffer within the current statistical period as the latency jitter value. When the periodic timer is triggered, the traffic monitoring agent traverses all valid slots in the delay sample circular buffer, calculates the first-order absolute value of the one-way delay sample value, and takes the arithmetic mean of the first-order absolute value of the difference to obtain the delay jitter value.

[0051] In practice, instantaneous bandwidth and latency jitter are uploaded to the central control module. After each periodic timer triggers and completes the calculation of instantaneous bandwidth and latency jitter, the traffic monitoring agent constructs a monitoring data reporting message. This message includes a node identifier field, a communication pair identifier field, an instantaneous bandwidth field, a latency jitter field, and a reporting timestamp field. The traffic monitoring agent sends the monitoring data reporting message to the monitoring data collection port of the central control module via a User Datagram Protocol (UDP) socket. The monitoring data collection port number of the central control module is set to 21000. The serialization format of the monitoring data reporting message uses a concise binary object representation protocol.

[0052] In practice, the central control module compares instantaneous bandwidth with a pre-set bandwidth threshold. Internally, the central control module maintains a communication pair threshold configuration table, using the communication pair identifier as the key. Each entry contains a bandwidth threshold field and a jitter tolerance field. Upon receiving a monitoring data report message from the traffic monitoring agent, the central control module parses the instantaneous bandwidth field value, latency jitter field value, and communication pair identifier field value from the report. Using the communication pair identifier field value as the key, it looks up the corresponding bandwidth threshold and jitter tolerance in the communication pair threshold configuration table. The central control module then performs a comparison operation to determine whether the instantaneous bandwidth field value exceeds the bandwidth threshold or whether the latency jitter field value exceeds the jitter tolerance. The bandwidth threshold is automatically updated at preset intervals based on historical traffic statistics. The preset interval is set to 3600 seconds. The update process involves the central control module reading all instantaneous bandwidth samples from the historical traffic database for this communication pair within the past 3600 seconds, calculating the 95th percentile of the sample value sequence, and updating the bandwidth threshold to the 95th percentile multiplied by an adjustment coefficient, which is fixed at 1.2. The jitter tolerance is defined as twice the root mean square (RMS) value of latency jitter. The central control module reads all latency jitter samples from the historical traffic database for this communication pair within the past 3600 seconds, calculates the RMS value of the latency jitter samples, and updates the jitter tolerance to the RMS value of latency jitter multiplied by 2.

[0053] In practice, when instantaneous bandwidth exceeds the bandwidth threshold or latency jitter exceeds the jitter tolerance, the central control module triggers a rule renegotiation signal and sends it to the interface adaptation rule generation engine. The central control module constructs a rule renegotiation signal message, which includes a trigger type field, a communication pair identifier field, a source node identifier field, a target node identifier field, and a trigger timestamp field. The value of the trigger type field is determined based on the triggering conditions: when triggered by instantaneous bandwidth exceeding the bandwidth threshold, the trigger type field is set to 1; when triggered by latency jitter exceeding the jitter tolerance, the trigger type field is set to 2; and when both conditions are met simultaneously, the trigger type field is set to 3. The central control module sends the rule renegotiation signal message to the receiving pipe file descriptor of the interface adaptation rule generation engine via a local inter-process communication pipe.

[0054] In practice, the interface adaptation rule generation engine updates the negotiation protocol stack sequence of the corresponding communication pair based on the rule renegotiation signal, generating a new dynamic interface adaptation rule set. The engine parses the communication pair identifier field, source node identifier field, and target node identifier field from the rule renegotiation signal message. It then calls the protocol capability matching module to re-query the supported protocol stack versions and data format lists from the source and target nodes, obtaining updated protocol support capability data. When executing the longest common protocol stack matching algorithm, the engine introduces a load overhead penalty term in the matching score calculation of the dynamic programming table. For each candidate matching quintuple element, the load overhead penalty term deducts points based on the average CPU utilization of the corresponding protocol processing plugin during historical runtime. The average CPU utilization comes from the performance monitoring data periodically reported by the protocol stack adapter. Finally, the engine associates the updated negotiation protocol stack sequence with the communication pair identifier, serializing it to generate a new dynamic interface adaptation rule set.

[0055] Example 5:

[0056] In implementation, a unified data interaction proxy is built on each node, encapsulating the data sending and receiving interfaces. Deployed as a user-space daemon on each node, the unified data interaction proxy provides a standardized inter-process communication interface for application processes on that node to call. Application processes communicate with the unified data interaction proxy through Unix domain sockets or shared memory queues. The unified data interaction proxy selects the data packet format based on the negotiation protocol stack sequence corresponding to the current communication pair. Internally, the unified data interaction proxy maintains a communication pair encapsulation format mapping table. This table uses the communication pair identifier as the key, and each entry contains an ordered list of data format identifier fields for each protocol layer's five-tuple in the negotiation protocol stack sequence. When the data sending interface is invoked, the unified data interaction proxy constructs a communication pair identifier by concatenating the target node identifier provided by the caller with the local node identifier. It then searches the communication pair encapsulation format mapping table for the corresponding entry and extracts the ordered list of data format identifiers. This ordered list specifies the data encapsulation formats used sequentially from the application layer to the physical layer.

[0057] In practical implementation, for data transmission, the unified data interaction agent calls the transmission hook of the heterogeneous protocol unified channel, sequentially executing the packetization and encryption operations of each layer of the protocol stack to generate a protocol-adapted data frame. The unified data interaction agent allocates a memory buffer for the protocol-adapted data frame, with the buffer starting at an offset space reserved for the application layer payload data. The size of this offset space is equal to the sum of the header lengths of each protocol layer. The unified data interaction agent iterates from the highest layer of the negotiated protocol stack sequence to the lowest layer, performing the following operations at each layer: The unified data interaction agent obtains the data format identifier from the current protocol layer's five-tuple; based on the data format identifier, it queries the corresponding packetization function entry address and encryption function entry address from the local node's protocol stack component library; it calls the packetization function, which receives the data buffer pointer and data length passed down from the previous layer, and outputs an extended data buffer pointer with the current protocol layer header information added, along with the updated data length. The input and output format of the packetization function is as follows: ,in, This represents a pointer to the data buffer after it has been packetized. This represents a pointer to the input data buffer. Indicates the length of the input data. This section describes the encapsulation function; it then calls the encryption function, which receives the pointer to the encapsulated data buffer and the data length. The encryption function performs in-situ encryption on all payload data in the data buffer after the current protocol layer header. The encryption algorithm corresponds to the security configuration of that protocol layer, and the algorithm identifier is obtained from the extended security attribute field of the negotiated protocol stack sequence. The data buffer pointer processed by the encryption function is used as input for the next layer. After the lowest protocol layer completes processing, a complete protocol-adapted data frame buffer is obtained. The unified data interaction proxy calls the data link layer sending hook of the heterogeneous protocol unified channel, submitting the protocol-adapted data frame buffer pointer and the total data frame length to the network device driver for physical transmission through the kernel socket sending interface.

[0058] In practical implementation, for received data, the unified data interaction agent obtains the raw data frame from the receive hook of the heterogeneous protocol unified channel, and sequentially performs unpacking and decryption operations at each layer of the protocol stack to extract application layer data. The unified data interaction agent registers a receive hook at the data link layer of the kernel protocol stack. The receive hook is bound to the DCS data interaction dedicated protocol identifier 0x88DC in raw socket mode. When the network device driver receives a data frame with protocol type 0x88DC, the receive hook copies the raw data frame from kernel space to the unified data interaction agent's receive buffer and triggers the receive processing flow. The unified data interaction agent extracts the communication pair identifier field 12 bytes off the header of the raw data frame. The communication pair identifier field is 64 bytes long. The unified data interaction agent looks up the corresponding negotiation protocol stack sequence in the communication pair encapsulation format mapping table based on the communication pair identifier. The unified data interaction proxy iterates through the negotiation protocol stack sequence from the lowest to the highest layer, performing the following operations at each layer: The unified data interaction proxy retrieves the data format identifier from the current protocol layer's 5-tuple; based on the data format identifier, it queries the corresponding decryption and unpacking function entry addresses from the protocol stack component library; it calls the decryption function, which decrypts all payload data after the current protocol layer header in-place; it calls the unpacking function, which receives the decrypted data buffer pointer, checks the integrity verification field of the current protocol layer header, and if the verification passes, it strips the current protocol layer header, extracts the start position and length of the upper-layer payload data, and outputs the unpacking function in the following format: ,in, This represents a pointer to the upper-layer payload data after unpacking. This represents a pointer to the input data frame buffer. Indicates the length of the input data frame. This represents the unpacking function; it takes the pointer to the upper-layer payload data obtained from the unpacking as the input to the next layer of processing.

[0059] In its implementation, the unified data interaction agent also maintains a data interaction log, recording the sending timestamp and receiving acknowledgment timestamp for each data frame. The data interaction log is stored in a circular file on the node's persistent storage device, with a default size of 256 megabytes. Each log entry includes either a sending direction record or a receiving direction record. The sending direction record is generated after the data frame is sent, and its fields include a log type identifier (valued at 0), a communication pair identifier, a data frame sequence number, and a sending timestamp. The sending timestamp is represented by a nanosecond-precision monotonic clock value. The receiving direction record is generated after sending a receiving acknowledgment message to the peer, and its fields include a log type identifier (valued at 1), a communication pair identifier, a data frame sequence number, and a receiving timestamp. The unified data interaction agent maintains an independent incrementing data frame sequence number counter for each communication pair. The counter is 64 bits wide, initially set to 0, and increments by 1 for each data frame sent. The receiving acknowledgment mechanism uses a piggybacking acknowledgment method; when sending a reverse data frame, the receiver appends a list of successfully received data frame sequence numbers to the acknowledgment tail field of the reverse data frame. The unified data interaction agent's log writing operation adopts lock-free circular file append writing. When writing log records, the circular file write pointer increments according to the record length. When the write pointer exceeds the preset size of the log file, the write pointer wraps back to the beginning of the file.

[0060] In implementation, a sliding window counter is set in the traffic monitoring agent of each node. The sliding window counter records the number of data packets and bytes for each communication pair according to a preset time granularity. The traffic monitoring agent allocates a sliding window counter storage area in memory, which is organized into a two-dimensional hash mapping structure with the communication pair identifier as the primary key and the time slot number as the secondary key. The preset time granularity is set to 100 milliseconds, the time span of the sliding window is set to 10 seconds, and the number of time slots included in the sliding window counter is the time span divided by the time granularity, i.e., 100 time slots. The traffic monitoring agent maintains a global sliding window start timestamp and current time slot number. The current time slot number is calculated by subtracting the sliding window start timestamp from the current monotonic clock value, dividing by the preset time granularity, and taking the modulo of the number of time slots. For each captured data packet, the traffic monitoring agent parses the communication pair identifier and payload length field value to which the data packet belongs, locates the corresponding counter entry for the communication pair identifier and time slot number based on the current time slot number, increments the data packet count field by 1, and adds the payload length field value to the byte number field. When the monotonic clock value crosses the time slot boundary, the traffic monitoring agent first freezes the counter entries for the old time slot number and stores the frozen counter snapshot in the sliding window snapshot buffer; then it clears the counter entries for the new time slot number, clearing the packet count field and byte number field.

[0061] In practice, the traffic monitoring agent periodically reports the contents of the sliding window counter to the central control module. The traffic monitoring agent sets a reporting period timer with a trigger interval of 500 milliseconds. Each time the reporting period timer is triggered, the traffic monitoring agent iterates through all frozen counter snapshots added since the last report in the sliding window snapshot buffer. It encapsulates the communication pair identifier field, time slot sequence number field, data packet quantity field value, byte number field value, and the starting monotonic clock value corresponding to the time slot for each frozen counter snapshot into a single reporting record. The traffic monitoring agent merges all records to be reported into a single reporting message. The reporting message format is a TLV-encoded sequence of triplets. Each triplet contains a type field value of 1, a length field value representing the serialized byte length of the reporting record, and a value field representing the serialized byte array of the reporting record. The traffic monitoring agent sends the reporting message to the monitoring data collection port 21000 of the central control module via a User Datagram Protocol (UDP) socket.

[0062] In practice, the central control module merges the reported data from each node into a global flow matrix. This global flow matrix is ​​represented as a three-dimensional tensor. , The three dimensions are the source node identifier dimension, the target node identifier dimension, and the time slot dimension, where the size of the source node identifier dimension is equal to the total number of nodes in the DCS network architecture. The size of the target node identifier dimension is also equal to The time slot dimension has a size of 100. Each element of the global traffic matrix... The source node identifier is The target node identifier is The communication pair in the first The number of data packets and bytes within each time slot is represented by an element structure containing `packet_count` and `byte_count` subfields. The central control module receives records reported by traffic monitoring agents at each node. For each reported record, it extracts the communication pair identifier field, parses the source node identifier and target node identifier from this field, and maps the source node identifier to the index value of the source node identifier dimension. Map the target node identifier to the index value of the target node identifier dimension. Map the time slot number to the index value of the time slot dimension. The data packet count field value in the reported record will be accumulated. Accumulate the byte number segment value. After processing all the data reported by all nodes within a 500-millisecond reporting cycle, the central control module pushes the current snapshot of the global traffic matrix to the anomaly detection pipeline.

[0063] In practice, the central control module performs anomaly detection on the global traffic matrix. Anomaly detection uses the Isolation Forest algorithm to identify communication pairs experiencing sudden increases or decreases in traffic. The Isolation Forest algorithm consists of multiple isolated trees, with the number of isolated trees set to 100 and the maximum depth of each isolated tree set to a specific value. ,in, This represents the subsample size of each isolated tree. The value is set to 256. The input feature vector of the Isolation Forest algorithm is constructed from the global traffic matrix for each communication pair. The feature vector of each communication pair contains 10 feature dimensions, specifically: the Z-score normalized value of the number of packets in the current time slot, the Z-score normalized value of the number of bytes in the current time slot, the first difference of the number of packets in the preceding and following time slots, the first difference of the number of bytes in the preceding and following time slots, the sliding window mean of the number of packets, the sliding window mean of the number of bytes, the sliding window standard deviation of the number of packets, the sliding window standard deviation of the number of bytes, the linear correlation coefficient between the number of packets and the number of bytes, and the proportion of the number of packets in the current time slot to the total number of packets in the sliding window. The training sample set of the Isolation Forest algorithm consists of the feature vectors of all communication pairs in the current time slot and 99 historical time slots backward, with the total number of samples being the number of communication pairs multiplied by 100. The training process of the Isolation Forest algorithm is as follows: 100 isolated trees are trained independently, and the training samples for each isolated tree are randomly drawn with replacement from the training sample set. For each node in each isolated tree, a feature dimension is randomly selected from 10 feature dimensions. A split value is randomly generated within the range of values ​​for that feature dimension. Samples in the sample set whose feature dimension value is less than the split value are assigned to the left child node, and samples whose value is greater than or equal to the split value are assigned to the right child node. This splitting operation is recursively performed until the node depth reaches the maximum depth or the number of samples in the node is 1. The inference process for anomaly detection is as follows: For the current time slot feature vector of each communication pair, traverse 100 isolated trees, calculate the path length of the feature vector in each isolated tree, and take the arithmetic mean of all path lengths to obtain the average path length. Calculate abnormal scores ,in, Representing the eigenvector In subsampling size The abnormal score at that time ranges from (0,1). Representing the eigenvector Path length in an isolated tree Representing the eigenvector The mean path length among all isolated trees. Subsampling size The corresponding normalization constant for average path length, The calculation formula is defined in the standard literature for the Isolation Forest algorithm. When the anomaly score... When the error score exceeds the preset abnormal score threshold of 0.7, the central control module determines that the corresponding communication pair has an abnormal surge or drop in traffic.

[0064] In practice, identified abnormal communication pairs are marked as objects to be adjusted. The central control module generates rule renegotiation signals based on the traffic characteristics of the abnormal communication pairs. After determining the abnormal communication pairs, the central control module iterates through all identified abnormal communication pairs and constructs a rule renegotiation signal message for each abnormal communication pair. The central control module extracts traffic characteristics from the feature vector of the abnormal communication pairs. The traffic characteristics specifically include an anomaly type indicator and an anomaly amplitude value. The anomaly type indicator is determined by the sign of the difference between the number of data packets in the current time slot and the number of data packets in the previous adjacent time slot. When the difference sign is positive, the anomaly type indicator is 0, indicating a sudden increase in traffic; when the difference sign is negative, the anomaly type indicator is 1, indicating a sudden decrease in traffic. The anomaly amplitude value is defined as the ratio of the absolute value of the difference between the number of data packets in the current time slot and the number of data packets in the previous adjacent time slot to the average number of data packets in the sliding window. The central control module encodes the anomaly type indicator and anomaly amplitude value into extended attribute fields of the rule renegotiation signal message, and sends the rule renegotiation signal message to the receiving pipe file descriptor of the interface adaptation rule generation engine. The construction method of the remaining fields of the rule renegotiation signal message is the same as that described in Example 4.

[0065] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for dynamic interface adaptation and data interaction management in a DCS full-network architecture, characterized in that, include: Real-time snapshots of the network topology of each control node, computing node and communication node in the DCS full network architecture are collected, and node connection matrix and link quality parameters are extracted from the network topology snapshots. The node connection matrix and the link quality parameters are input into a pre-built interface adaptation rule generation engine. The interface adaptation rule generation engine performs protocol stack negotiation processing on each communication pair to generate a dynamic interface adaptation rule set. The dynamic interface adaptation rule set is distributed to the protocol stack adapters of each node, and the protocol stack adapters reorganize their local protocol stacks at runtime according to the dynamic interface adaptation rule set to form a unified channel for heterogeneous protocols. Data interaction is performed between nodes through the heterogeneous protocol unified channel, and the data interaction traffic is monitored in real time. The dynamic interface adaptation rule set is dynamically adjusted according to the data interaction traffic.

2. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The extraction of the node connectivity matrix and link quality parameters from the network topology snapshot includes: Perform node deduplication and link identification processing on the network topology snapshot to obtain a deduplicated node list and a link identifier list; Perform bidirectional latency detection and packet loss rate statistics on the link corresponding to each link identifier to generate the original quality dataset; The original quality dataset is smoothed using a Kalman filter to obtain the link quality parameters; Based on the deduplication node list and the link identifier list, a node connection matrix is ​​generated, wherein each element of the node connection matrix represents the index of whether there is a valid link between two nodes and the link quality parameter.

3. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The process of negotiating the protocol stack for each communication pair through the interface adaptation rule generation engine to generate a dynamic interface adaptation rule set includes: Extract all communication pairs from the node connection matrix, where each communication pair consists of a source node identifier and a target node identifier; For each communication pair, the protocol capability matching module in the interface adaptation rule generation engine is invoked to query the list of protocol stack versions and data formats supported by the source node and the target node respectively; Based on the protocol stack version and data format list, the longest common protocol stack matching algorithm is executed to obtain the negotiated protocol stack sequence; The negotiation protocol stack sequence is associated with the corresponding communication pair to generate the dynamic interface adaptation rule set.

4. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The step of the protocol stack adapter reorganizing the local protocol stack at runtime according to the dynamic interface adaptation rule set to form a unified channel for heterogeneous protocols includes: The protocol stack adapter parses the rule entries related to this node in the dynamic interface adaptation rule set and extracts the negotiated protocol stack sequence. According to the negotiation protocol stack sequence, start the protocol stack dynamic loader of this node and load the processing plugins of the corresponding protocol layer in sequence; The processing plugins of each protocol layer are mounted to a specified location in the kernel protocol stack through hook functions to form a unified channel for the heterogeneous protocols; The protocol stack adapter also maintains a protocol stack state hash table to record the version number of the protocol stack combination currently used by each communication pair.

5. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The process of performing data interaction between nodes through the heterogeneous protocol unified channel, monitoring data interaction traffic in real time, and dynamically adjusting the dynamic interface adaptation rule set based on the data interaction traffic includes: A traffic monitoring agent is deployed on each node. The traffic monitoring agent bypasses and captures data packets passing through the unified channel of the heterogeneous protocol, and calculates the instantaneous bandwidth and latency jitter of each communication pair. The instantaneous bandwidth and the latency jitter are uploaded to the central control module, which compares the instantaneous bandwidth with a preset bandwidth threshold. When the instantaneous bandwidth exceeds the bandwidth threshold or the latency jitter exceeds the jitter tolerance, the central control module triggers a rule renegotiation signal and sends the rule renegotiation signal to the interface adaptation rule generation engine. The interface adaptation rule generation engine updates the negotiation protocol stack sequence of the corresponding communication pair according to the rule renegotiation signal, and generates a new dynamic interface adaptation rule set.

6. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The protocol stack adapter that distributes the dynamic interface adaptation rule set to each node includes: A distributed configuration distribution bus is constructed, which adopts a publish-subscribe pattern and encapsulates the dynamic interface adaptation rule set into a rule change notification. The rule change notification carries the rule effective timestamp and the rule version number, and the rule change notification is broadcast to all nodes via the distributed configuration distribution bus; Each node's protocol stack adapter subscribes to the distributed configuration distribution bus. Upon receiving the rule change notification, it determines whether an update is needed based on the rule's effective timestamp and the rule's version number. If an update is required, the protocol stack adapter locks the write operation of the local protocol stack, loads the new rules, and updates the protocol stack state hash table.

7. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The process of performing data interaction between nodes through the heterogeneous protocol unified channel includes: A unified data interaction proxy is constructed on each node. The unified data interaction proxy encapsulates data sending and receiving interfaces and selects the data packet format according to the corresponding negotiation protocol stack sequence of the current communication pair. For sending data, the unified data interaction proxy calls the sending hook of the heterogeneous protocol unified channel to sequentially execute the packetization and encryption operations of each layer of the protocol stack to generate a protocol-adapted data frame. For received data, the unified data interaction proxy obtains the original data frame from the receiving hook of the heterogeneous protocol unified channel, and sequentially performs unpacking and decryption operations at each layer of the protocol stack to extract application layer data. The unified data interaction agent also maintains a data interaction log, recording the sending timestamp and receiving confirmation timestamp for each data frame.

8. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The real-time monitoring of data interaction traffic includes: A sliding window counter is set in the traffic monitoring agent of each node. The sliding window counter records the number of data packets and bytes of each communication pair at a preset time granularity. The traffic monitoring agent periodically reports the contents of the sliding window counter to the central control module, and the central control module merges the reported data from each node into a global traffic matrix. The central control module performs anomaly detection on the global traffic matrix. The anomaly detection uses the isolated forest algorithm to identify communication pairs with sudden increases or decreases in traffic. The identified abnormal communication pairs are marked as objects to be adjusted, and the central control module generates the rule renegotiation signal based on the traffic characteristics of the abnormal communication pairs.

9. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 1, characterized in that, The protocol stack adapter performs runtime reassembly of the local protocol stack, including: The protocol stack adapter preloads a protocol stack component library, which contains a variety of protocol processing modules, each of which has a unique identifier and an interface signature. The protocol stack adapter selects the corresponding protocol processing module from the protocol stack component library according to the negotiated protocol stack sequence, and checks whether the interface signature matches the hook function signature of the current kernel protocol stack. If a match is found, the protocol stack adapter injects the code segment of the protocol processing module into the address space of the kernel protocol stack via memory mapping. If they do not match, the protocol stack adapter starts the interface adaptation and conversion module to generate a thin encapsulation layer, making the interface signature of the protocol processing module compatible with the hook function signature.

10. The dynamic interface adaptation and data interaction management method for the DCS full network architecture according to claim 5, characterized in that, The bandwidth threshold is automatically updated at preset intervals based on historical traffic statistics, and the jitter tolerance is defined as twice the root mean square value of the delay jitter.

Images