OPCUA communication method and system supporting dcs bus flow analysis prediction

By constructing the OPCUA communication method in the integrated power monitoring system of thermal power plants, data format unification and load balancing were achieved, solving the problems of protocol heterogeneity, security and load imbalance, and improving system efficiency and user experience.

CN122160442APending Publication Date: 2026-06-05GUODIAN NANJING AUTOMATION

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
GUODIAN NANJING AUTOMATION
Filing Date
2026-04-20
Publication Date
2026-06-05

AI Technical Summary

Technical Problem

In the integrated power monitoring system of thermal power plants, there are problems such as protocol heterogeneity, insufficient security, unbalanced load and inconsistent information models, resulting in high development costs, complex operation and maintenance and poor user experience.

Method used

By constructing an OPCUA communication method that supports DCS bus traffic analysis and prediction, and employing protocol conversion, AI traffic monitoring, and load balancing strategies, data format unification and load balancing are achieved, and data forwarding and storage are performed using an OPC UA server.

Benefits of technology

It has achieved the unification of data formats across different devices, reduced protocol differences, improved system efficiency, solved the problem of unbalanced load, and enhanced data processing speed and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122160442A_ABST
    Figure CN122160442A_ABST
Patent Text Reader

Abstract

The application provides an OPCUA communication method and system supporting DCS bus flow analysis and prediction, relates to the field of industrial distributed control integrated monitoring systems, and comprises the following steps: constructing a sensing layer device access interface for writing collected data into a subscription interface after completing protocol conversion of the collected data through a preconfigured communication protocol format; starting a server and a client of a message bus respectively in a sensing layer and a control layer of a distributed control system; dynamically acquiring message bus data; based on a model mapping mechanism, mapping the message bus data to an OPC UA server, and forwarding the message bus data to a client of a third-party system through the OPC UA server for storage; and after protocol conversion of the sensing layer device, uniformly writing data into a standardized subscription interface, realizing uniformity of data writing formats of different devices, and reducing communication protocol differences.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of industrial distributed control integrated monitoring systems, and more specifically, to an OPCUA communication method and system that supports DCS bus traffic analysis and prediction. Background Technology

[0002] In the development of a comprehensive power monitoring system for thermal power plants, it is necessary to effectively collect, analyze, summarize, and process the load data of the entire power system. However, in reality, there are various types of field devices with different data interfaces. Based on the OPC UA technology framework, various field devices are connected through its general platform, and the field data provided by the devices is obtained through software ports.

[0003] Traditional distributed control systems have the following problems and limitations:

[0004] 1. Protocol heterogeneity: Sensing layer devices use different physical connection methods such as serial ports and networks, and communication protocols such as Modbus, Modbus TCP, Profibus-DT, and OPC DA, which are highly different and have different communication rates. Custom development is usually required, which results in high development costs and complex operation and maintenance.

[0005] 2. Insufficient security: Traditional OPC relies on DCOM technology, which has technical security vulnerabilities and lacks end-to-end encryption mechanisms.

[0006] 3. Uneven load: When the DCS message bus server processes large amounts of data from the OPC UA server, it will experience problems such as high instantaneous load, long data processing latency, and poor user experience.

[0007] 4. Inconsistent Information Models: Common OPC UA server address spaces consist of "nodes," which can be types, objects, or components of objects. Nodes can possess attributes and other properties. As mentioned above, there are many types of sensing layer devices using different communication protocol specifications. In traditional distributed industrial control systems, the model describing device information—from the device terminal to the message bus and then to the OPC UA server—requires multiple static models to meet the access requirements of different types of sensing layer devices.

[0008] No effective solutions have yet been proposed to address the problems in the relevant technologies. Summary of the Invention

[0009] In view of this, the present invention provides an OPCUA communication method and system that supports DCS bus traffic analysis and prediction, in order to solve the aforementioned problems.

[0010] To solve the above problems, the specific technical solution adopted by the present invention is as follows:

[0011] According to a first aspect of the present invention, an OPCUA communication method supporting DCS bus traffic analysis and prediction is provided, the method comprising the following steps:

[0012] S1. Construct a perception layer device access interface for converting the collected data into a protocol using a pre-configured communication protocol format and writing the collected data into the subscription interface.

[0013] S2. Construct a message bus for the distributed control system that includes a server and a client, and start the server and client of the message bus in the perception layer and control layer of the distributed control system respectively; use the access interface of the perception layer device and combine AI traffic monitoring and analysis methods to dynamically obtain message bus data.

[0014] S3. Based on the model mapping mechanism, the message bus data is mapped to the OPC UA server, and the message bus data is forwarded to the client of the third-party system for storage through the OPC UA server.

[0015] Preferably, the construction of a message bus for a distributed control system including a server and a client, and the startup of the message bus server and client at the perception layer and control layer of the distributed control system respectively; dynamically acquiring message bus data using the perception layer device access interface and combined with AI traffic monitoring and analysis methods includes the following steps:

[0016] S21. In the distributed control system architecture, establish a multi-layer message bus structure;

[0017] S22. Deploy the message bus server on the perception layer node in the distributed control system architecture, deploy the message bus client on the control layer node in the distributed control system architecture, and start the message bus server and message bus client respectively.

[0018] S23. Based on the AI ​​traffic monitoring and analysis method, obtain message bus data generated by the message bus server and message bus client in the message bus through the access interface of the perception layer device.

[0019] Preferably, the AI-based traffic monitoring and analysis method, which obtains message bus data generated by the message bus server and message bus client through the access interface of the perception layer device, includes the following steps:

[0020] S231. When obtaining message bus data generated by the message bus server and message bus client in the message bus through the access interface of the perception layer device, the communication traffic data of the message bus is obtained in real time.

[0021] S232. Convert communication traffic data into multidimensional time series format data, extract statistical features from the multidimensional time series format data, preprocess the statistical features, and obtain real-time preprocessed feature data.

[0022] S233. Collect preprocessed feature data from historical normal operation phases, construct a feature library of normal flow patterns, and generate historical baseline curves representing steady-state behavior through seasonal time series decomposition methods.

[0023] S234. Using historical baseline curves, perform preliminary comparisons on the feature data after real-time preprocessing, identify and mark them as preliminary abnormal data, remove the preliminary abnormal data, and obtain the preliminary processed data.

[0024] S235. Based on the isolated forest algorithm and change point detection method, perform secondary anomaly detection on the pre-processed data, and determine whether abnormal traffic events have occurred in the message bus communication based on the results of the secondary anomaly detection.

[0025] S236. If an abnormal traffic event occurs, perform load balancing adjustments; otherwise, return to step S231.

[0026] Preferably, the step of performing secondary anomaly detection on the pre-processed data based on the isolated forest algorithm and change point detection method, and determining whether an abnormal traffic event has occurred in the message bus communication based on the results of the secondary anomaly detection, includes the following steps:

[0027] S2351. Use the isolated forest algorithm to detect sudden traffic anomalies in the pre-processed data and obtain the first anomaly detection result;

[0028] S2352. Using the Pelt algorithm and the Bayesian online change point detection method, silent period anomaly detection is performed on the pre-processed data to obtain the second anomaly detection result;

[0029] S2353. The first and second anomaly detection results are fused to generate a comprehensive anomaly confidence score.

[0030] S2354. Based on the comprehensive anomaly confidence level and the preset confidence level threshold, determine whether an abnormal traffic event has occurred in the message bus communication; if the comprehensive anomaly confidence level is greater than the preset confidence level threshold, it is determined that an abnormal traffic event has occurred, otherwise it is determined that no abnormal traffic event has occurred.

[0031] Preferably, the step of using the Pelt algorithm and Bayesian online change point detection method to perform silent period anomaly detection on the pre-processed data to obtain the second anomaly detection result includes the following steps:

[0032] S23521. Arrange the preliminary processed data in chronological order according to their timestamp information to obtain the traffic characteristic time series;

[0033] S23522. Based on the sliding window mechanism, the time series of traffic characteristics is segmented to form multiple continuous subsequences;

[0034] S23523. Based on the Gaussian distribution assumption, construct and calculate the Pelt algorithm cost function for quantifying the degree of difference between adjacent subsequences;

[0035] S23524. Combine the preset penalty term to control the number of change points, use dynamic programming to solve for the set of change points that minimize the cost function of the Pelt algorithm, and identify the structural transition locations of the decline in traffic in the traffic characteristic time series.

[0036] S23525. Using the Bayesian online change point detection method, the probability confidence level of the structural transition location is evaluated. If the decrease in traffic exceeds the preset threshold and the confidence level is higher than the set level, it is determined to be an abnormal event during the silent period, and a second abnormality detection result is generated.

[0037] Preferably, the Pelt algorithm cost function, based on the Gaussian distribution assumption, for constructing and calculating the degree of difference in statistical summary quantities between adjacent subsequences includes the following steps:

[0038] For all subsequences, determine the average value of all data points within each subsequence;

[0039] For each data point in each subsequence, calculate the difference between that data point and the mean of that subsequence;

[0040] Squaring each difference and summing all the squared differences yields the cost function value for each subsequence.

[0041] Preferably, the method of forwarding message bus data to the client of a third-party system for storage via the OPC UA server includes a data caching strategy and a load balancing transmission strategy based on the subscribed content topic;

[0042] The data caching strategy includes third-party system client caching and OPC UA server caching;

[0043] The third-party system client cache is used to set up a caching mechanism locally on the third-party system client, cache data that has been obtained, and when the third-party system client requests the same data again, it first retrieves it from the local cache, and when the cached data expires or changes, it sends a request to the OPC UA server to obtain the latest data;

[0044] The OPC UA server cache is used to cache frequently accessed data points. When a client request is received, it first checks if the required data is in the cache. If it is, it reads the data directly from the cache and returns it to the third-party system client.

[0045] The load balancing transmission strategy based on subscription content topics is used to distribute the subscription requests of third-party system clients to different OPC UA server nodes according to the topic of the requested data, so that each OPC UA server node is responsible for handling data subscription and transmission tasks for different topics.

[0046] According to a second aspect of the present invention, an OPCUA communication system supporting DCS bus traffic analysis and prediction is provided, the system comprising:

[0047] The interface construction module is used to build a perception layer device access interface that converts the collected data into a protocol using a pre-configured communication protocol format and writes the collected data into the subscription interface.

[0048] The data acquisition module is used to construct a message bus for a distributed control system that includes a server and a client, and to start the server and client of the message bus in the perception layer and control layer of the distributed control system, respectively; and to dynamically acquire message bus data by using the access interface of the perception layer device and combining AI traffic monitoring and analysis methods.

[0049] The data mapping module is used to map message bus data to the OPC UA server based on the model mapping mechanism, and then forward the message bus data to the client of the third-party system for storage through the OPC UA server.

[0050] According to a third aspect of the present invention, an electronic device is provided, the electronic device comprising: one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the programs to implement the steps of the above-described method.

[0051] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored therein, wherein the steps of the above-described method are implemented when the computer program controls the device in which the computer-readable storage medium is located to execute during runtime.

[0052] The beneficial effects of this invention are as follows:

[0053] 1. This invention uses a sensing layer device to complete the protocol conversion and then uniformly writes the data into a standardized subscription interface, thereby achieving a unified data format for different devices and reducing differences in communication protocols.

[0054] 2. This invention adopts a unified data format, so that when different types of devices in the device perception layer use different data formats to write to the DCS message bus data interface, a unified data model is used to solve the protocol differences and improve system efficiency.

[0055] 3. This invention uses AI traffic monitoring and dynamic switching of bus servers to handle situations where data traffic is concentrated on individual message bus servers under big data pressure.

[0056] 4. This invention solves the data bottleneck problem encountered when forwarding content from the traditional server to the client by using a load balancing method for forwarding and subscribing to content from the OPC UA server to a third-party system. Attached Figure Description

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

[0058] Figure 1 This is a flowchart of an OPCUA communication method supporting DCS bus traffic analysis and prediction according to an embodiment of the present invention;

[0059] Figure 2 This is a block diagram of an OPCUA communication system supporting DCS bus traffic analysis and prediction according to an embodiment of the present invention.

[0060] Figure 3 This is a diagram of the distributed control system architecture in the OPCUA communication method supporting DCS bus traffic analysis and prediction according to an embodiment of the present invention.

[0061] Figure 4 This is a schematic diagram of the AI ​​traffic analysis and prediction and dynamic load adjustment process of the OPCUA communication method supporting DCS bus traffic analysis and prediction according to an embodiment of the present invention.

[0062] Figure 5 This is a schematic diagram of the access process of the sensing layer device in the OPCUA communication method supporting DCS bus traffic analysis and prediction according to an embodiment of the present invention.

[0063] Figure 6 This is a block diagram of the hardware structure of the host device in the OPCUA communication method and system that supports DCS bus traffic analysis and prediction according to an embodiment of the present invention.

[0064] In the picture:

[0065] 1. Interface construction module; 2. Data acquisition module; 3. Data mapping module. Detailed Implementation

[0066] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0067] The methods and embodiments provided in this application can be executed on a host device or a similar computing device. Taking running on a host device as an example, such as... Figure 6 As shown, the host device may include one or more ( Figure 6 Only one is shown in the diagram. The processor (which may include, but is not limited to, a microprocessor (MCU) or programmable logic device (FPGA), etc.) and storage for storing data are also shown. The host device may further include transmission devices for communication functions and input / output devices. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the host device described above. For example, the host device may also include components that are larger than... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0068] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the exception handling method in this embodiment. The processor executes various functional applications and data processing by running the computer program stored in the memory, thus implementing the above-described method. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the host device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0069] Transmission devices are used to receive or send data over a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the host device. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0070] According to embodiments of the present invention, an OPCUA communication method and system supporting DCS bus traffic analysis and prediction are provided.

[0071] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments, such as... Figure 1 As shown, according to a first embodiment of the present invention, an OPCUA communication method supporting DCS bus traffic analysis and prediction is provided, the method comprising the following steps:

[0072] S1. Construct a perception layer device access interface for converting the collected data into a protocol using a pre-configured communication protocol format and writing the collected data into the subscription interface.

[0073] It should be noted that when constructing the access interface for the perception layer devices, a publish / subscribe interface needs to be defined. After the perception layer devices complete the protocol conversion, they uniformly write the data to the standardized subscription interface, such as... Figure 5 As shown; specifically including:

[0074] (1) Static identification: Based on the protocol format provided by the equipment manufacturer, a dedicated conversion module is developed. For example, for Modbus TCP devices, a pre-defined register mapping table is used, including address range, data type, and verification method. For example, the address range 40001-40010 corresponds to temperature values, the data type is floating-point, and the verification method is set to CRC. During system initialization, the configuration file, such as XML format, is loaded, and the device ID is automatically matched and the conversion logic is applied. For example, when a Modbus temperature sensor is connected, the system reads its protocol document and generates mapping rules to avoid manual coding.

[0075] (2) Dynamic identification: Using tools such as Wireshark to listen to and identify initial packets, extracting features including packet headers, ports, and checksums. Then, matching common protocols using a preset feature library, such as IEC 104 start code 0x68 and Modbus function code 0x03. The feature library is stored in a database, such as SQLite, containing signatures for hundreds of protocols. After a successful match, the plugin DLL or .so is called to perform identification, for example, loading the Modbus plugin to parse register values. For example, for an unknown Profibus device, the system listens to the first packet, extracts the device address and data length, matches Profibus-DP features in the library, such as master-slave mode, and dynamically loads the conversion plugin. The entire process is completed within 1-5 seconds and supports hot-swappable devices.

[0076] (3) Gateway protocol conversion; For non-standard devices, use industrial edge gateways to convert the protocol into a unified JSONSchema format, such as ARM-based embedded devices.

[0077] (4) Protocol field mapping; establish a mapping table between protocol fields and standard data models. For example, map the Modbus address 40001 register to the "temperature" field, use a hash table to store the mapping relationship, and support fast lookup.

[0078] (5) Semantic interpretation; transforming raw data through regular expressions. For example, parsing the code "0x01" into a "normal" state, using Python's re module to implement pattern matching, and handling exceptions such as overflow values, for example, if the temperature is >100℃, marking it as "abnormal".

[0079] (6) Context-aware extension; optimize conversion logic by combining device metadata such as model "Sensor-X", installation location "Boiler Room", and communication method "TCP / IP". For example, adjust units according to location, such as Celsius vs. Fahrenheit. Gateway hardware includes Ethernet ports and serial ports, supporting multi-threaded processing of concurrent access.

[0080] (7) Use a gateway for protocol conversion; For uncommon manufacturer equipment in distributed systems, we can configure an industrial edge gateway, such as a protocol converter, to support access to non-standard protocol devices and convert non-standard communication protocols into a unified data format protocol. In this example, JSON Schema is used.

[0081] (8) Register the device management platform / module and define the publish / subscribe interface. The device management platform / module is responsible for the unified management of all access devices and maintaining the protocols, interface methods, data formats, communication parameters supported by the devices, such as serial port / network communication methods. It supports automatic registration and protocol identification of access devices; it can also forward device configuration updates from the distributed control system message bus through this module, such as changes in OPC UA node addresses, reducing manual modification of configuration files.

[0082] (9) Unify data format. Different types of devices in the device perception layer use different data formats for communication protocols. Before data is written to the DCS message bus interface, a unified data model needs to be defined in the system. We recommend using the currently commonly used JSON Schema to ensure that all device data is converted into a unified format before entering the system core. For example:

[0083] When a temperature sensor is connected to the device layer using the MODBUS TCP protocol, the following three steps are required to convert the data reflected by the communication protocol into a unified data format:

[0084] Protocol field mapping; establishing a mapping table between protocol fields and standard data models, for example: mapping the MODBUS register at address 40001 to temperature;

[0085] Semantic interpretation; transforming raw data using regular expressions, for example: parsing the value "0x01" of the code "code" into normal data;

[0086] Context-aware extension; combining common metadata from the device layer, such as device model, installation location, and physical communication method, to optimize the conversion format logic.

[0087] The unified JSON Schema format data model fragment is shown below:

[0088] {

[0089] "device_id": "string",

[0090] "timestamp": "ISO8601",

[0091] "metrics": {

[0092] "temperature": {"value": 25.5, "unit": "℃"},

[0093] "status": {"code": 0x01, "desc": "normal"}

[0094] }

[0095] }".

[0096] The device management platform is responsible for automatic registration and configuration updates, and maintaining the device list, such as sending device parameters via POST / register. Example of a unified data format (expanded to a complete schema):

[0097] {

[0098] "type": "object",

[0099] "properties":

[0100] {

[0101] "device_id": {"type": "string", "description": "Unique deviceidentifier"},

[0102] "timestamp": {"type": "string", "format": "date-time", "description":"ISO8601 timestamp"},

[0103] "metrics": {"type": "object","properties":

[0104] {

[0105] "temperature": {"type": "object","properties": {"value": {"type": "number"},

[0106] "unit": {"type": "string", "enum": ["℃", "℉"]}

[0107] }

[0108] },

[0109] "status": {"type": "object","properties": {"code": {"type": "integer"},

[0110] "desc": {"type": "string"}

[0111] }

[0112] }

[0113] }

[0114] },

[0115] "metadata": {"type": "object","properties": {"model": {"type": "string"},

[0116] "location": {"type": "string"},

[0117] "protocol": {"type": "string"}

[0118] }

[0119] }

[0120] },

[0121] "required": ["device_id", "timestamp", "metrics"]

[0122] }".

[0123] Furthermore, data is written to the subscription interface in a polling or threshold-triggered manner, such as querying every second or triggering writing when the temperature change exceeds 5%. The interface uses the MQTT protocol to implement publish / subscribe, ensuring low latency.

[0124] (10) Write to the subscription interface. After completing the unified operation of data access and conversion of the perception layer device, write to the data interface API published by the message bus. The interface writing method can be polling or write to the publish / subscribe interface with the threshold of data change as the trigger condition.

[0125] S2. Construct a message bus for the distributed control system that includes a server and a client, and start the server and client of the message bus in the perception layer and control layer of the distributed control system respectively; use the access interface of the perception layer device and combine AI traffic monitoring and analysis methods to dynamically obtain message bus data.

[0126] In a preferred embodiment, the construction of a message bus for a distributed control system comprising a server and a client, and the activation of the message bus server and client at the perception layer and control layer of the distributed control system respectively; and the dynamic acquisition of message bus data using the perception layer device access interface and in conjunction with AI traffic monitoring and analysis methods, includes the following steps:

[0127] S21. In a distributed control system architecture, establish a multi-layer message bus structure; such as... Figure 3 As shown;

[0128] It should be noted that the message bus in this invention primarily handles message reception and unified access between servers and terminals within the system, message format conversion and protocol adaptation, and message priority management—setting priorities for different message types to ensure the real-time performance of critical instructions. Specifically, it includes:

[0129] In order to access all data sources within the SCADA system, including remote terminal units (RTUs), programmable logic controllers (PLCs), smart meters, sensors and other field devices, as well as the monitoring software, historical databases, alarm systems and other applications in the dispatch center, it is necessary to convert messages of different formats, such as telemetry, remote signaling and remote control commands, into a unified bus standard format.

[0130] To address the issue of protocol differences between different devices / applications, it is necessary to support mainstream power industry protocols such as IEC61850, Modbus, and DNP3, and automatically complete protocol parsing and format conversion to avoid data silos caused by protocol incompatibility.

[0131] To implement message priority management, for example, the "remote control tripping" command has a higher priority than ordinary telemetry data, ensuring that emergency control commands are transmitted first and avoiding delays.

[0132] The message management module allows for the definition of multiple different types of topics, each corresponding to a different general data type, such as: ordinary measurement values, high-frequency acquisition measurement values, accident signal points, process parameters, etc. The data model mapping will reflect the categories of different message topics, corresponding to OPC UA data groups.

[0133] S22. Deploy the message bus server on the perception layer node in the distributed control system architecture, deploy the message bus client on the control layer node in the distributed control system architecture, and start the message bus server and message bus client respectively.

[0134] It should be noted that, as Figure 3 As shown, the message bus server and client are started in the device perception layer and system control layer respectively. However, the application mode of the C / S service architecture is not limited to the message server being in the device perception layer and the message client being in the system control layer. Their deployment positions can be interchanged.

[0135] Common problems in message bus applications include high communication latency, uneven load distribution during high-pressure data processing, and poor protocol compatibility. This invention proposes a method combining AI traffic monitoring and dynamic switching of the bus server to address situations where data traffic is concentrated on a few message bus servers under heavy data pressure.

[0136] Each message bus server stores a server node table. When a message bus server joins the bus, it registers its own MAC address, physical network card usage, and access device perception layer information in the table. The server node table is sorted in order of the online timestamp of each message bus server. The prerequisite is that the distributed control system (DCS) used in the application must have a unified time source and use an SNTP network server for time synchronization. The server node table is managed in a sequential linked list manner.

[0137] S23. Based on AI traffic monitoring and analysis methods, message bus data generated by the message bus server and message bus client is obtained through the access interface of the perception layer device. Specifically, a publish / subscribe model can be used to realize data flow. This model allows the perception layer device (data producer) to asynchronously publish data to specific subjects, while a preset control layer or OPC UA server (data consumer) obtains data by subscribing to these subjects, such as... Figure 4 As shown, the details of "data preprocessing" are as follows:

[0138] 1. Data preparation: The perception layer devices generate a unified JSON Schema data model through protocol identification and transformation;

[0139] 2. Client initialization and connection: The perception layer starts the message bus client and connects to the bus server;

[0140] 3. Topic selection and priority management: The topic structure is split according to business function, region, voltage level, data type, and device ID; high-priority topics such as "scada / huadong / shanghai / 220kV / telemetry / device001" telemetry are prioritized by topic prefixes;

[0141] 4. Data publishing operation: Data publishing can be triggered by polling or threshold-based API calls.

[0142] 5. Exception handling and feedback should also take into account the situation of abnormal data publishing. If publishing fails, such as when the network is disconnected, the message bus client should buffer the data and retry multiple times.

[0143] It's important to note that AI traffic monitoring can be performed by configuring an AI traffic monitoring module. This module monitors the real-time status of each message bus server, including metrics such as CPU usage, memory usage, network bandwidth, message queue length, number of connected devices, and the number of device data points showing changes. It records peak values ​​for device data point changes and can optionally utilize deep learning algorithms to build traffic prediction and anomaly detection models. The traffic prediction model, based on historical traffic data and system operating parameters, predicts the future trend of communication traffic between nodes over a given period. The anomaly detection model analyzes the collected traffic data in real-time, identifies abnormal traffic patterns such as traffic bursts and abnormal fluctuations, and then predicts future traffic trends or detects anomalies. By establishing a data model to process monitoring data in real-time, problems can be identified promptly.

[0144] The message bus server dynamically adjusts the load balancing strategy for each server on the message bus based on the results of AI traffic monitoring and prediction, as follows:

[0145] Traffic monitoring and analysis: The data acquisition layer continuously collects communication traffic data from terminal devices, specifically the traffic data generated during message bus communication, such as byte count, packet count, and connection duration, and transmits it to the AI ​​traffic monitoring module. In the AI ​​traffic monitoring module, the data first undergoes advanced transformation processing, converting the raw traffic data into a multi-dimensional time series format. For example, a sliding window is used to segment continuous data into fixed-length sequence segments, extracting non-obvious statistical features such as kurtosis (to capture the "tail" extreme events of traffic distribution), skewness (to identify traffic asymmetry), wavelet transform coefficients (to decompose the signal at multiple scales to capture local bursts of change), and entropy (to quantify the degree of disorder in traffic patterns). After feature extraction, preprocessing is performed, including noise removal and outlier removal. For example, a Kalman filter is used to smooth the signal to suppress random fluctuations, and the DBSCAN clustering algorithm is used to identify and isolate outliers, rather than simply using a Z-score threshold.

[0146] In a preferred embodiment, the AI-based traffic monitoring and analysis method, which obtains message bus data generated by the message bus server and message bus client through the access interface of the perception layer device, includes the following steps:

[0147] S231. When obtaining message bus data generated by the message bus server and message bus client in the message bus through the access interface of the perception layer device, the communication traffic data of the message bus is obtained in real time.

[0148] S232. Convert communication traffic data into multidimensional time series format data, extract statistical features from the multidimensional time series format data, preprocess the statistical features, and obtain real-time preprocessed feature data.

[0149] S233. Collect preprocessed feature data from historical normal operation phases, construct a feature library of normal flow patterns, and generate historical baseline curves representing steady-state behavior through seasonal time series decomposition methods.

[0150] S234. Using historical baseline curves, perform preliminary comparisons on the feature data after real-time preprocessing, identify and mark them as preliminary abnormal data, remove the preliminary abnormal data, and obtain the preliminary processed data.

[0151] Specifically, the preprocessed feature data in real time is matched against historical benchmark curves dimension by dimension, such as flow rate corresponding to the flow rate benchmark and error rate corresponding to the error rate benchmark. The deviation between the real-time value of each feature dimension and the normal fluctuation range of the benchmark curve at the corresponding time is calculated. The deviation is calculated using the relative deviation formula: relative deviation = |real-time feature value - mean of benchmark feature| / standard deviation of benchmark feature. Then, based on the statistical characteristics of the normal flow pattern feature library, a differentiated primary threshold is set for each feature dimension. For example, the primary threshold for flow rate is set to 3 times the standard deviation of the benchmark, and the primary threshold for error rate is set to 2.5 times the standard deviation of the benchmark. If the relative deviation of at least one feature dimension in the multi-dimensional features at a certain time exceeds the corresponding primary threshold, the feature data at that time is marked as an "abnormal candidate point". If the relative deviation of all feature dimensions is within the threshold, it is marked as a "normal point". For the feature data of the abnormal candidate point, it is determined that an abnormal flow event has occurred, and subsequent load balancing processing is performed.

[0152] S235. Based on the isolated forest algorithm and change point detection method, perform secondary anomaly detection on the pre-processed data, and determine whether abnormal traffic events have occurred in the message bus communication based on the results of the secondary anomaly detection.

[0153] It should be noted that the data after initial processing undergoes further anomaly analysis. In addition to basic deviation comparison, non-obvious algorithms are introduced to enhance anomaly detection: for example, the Isolation Forest algorithm is used to detect burst traffic, quickly isolating anomalies by randomly segmenting the data space, suitable for unsupervised anomaly detection in high-dimensional feature spaces; for silent periods, i.e., abnormally low traffic phases, change point detection algorithms such as Pelt (Pruned Exact LinearTime) combined with Bayesian Online Change Point Detection (BOCPD) are used to dynamically identify structural shifts in traffic patterns, rather than relying solely on static thresholds; furthermore, a Variational Autoencoder (VAE) is integrated as an auxiliary module, quantifying the deviation between real-time data and normal patterns through error reconstruction, thereby capturing hidden anomaly patterns, such as gradual traffic decay or periodic interference. Once a server-side device data acquisition deviation exceeds a set threshold, abnormal traffic is determined by calculating confidence levels, triggering load balancing adjustments.

[0154] The principle behind Isolation Forest is based on the assumption that outliers are more easily isolated. It constructs multiple isolation trees (iTrees) by randomly selecting features and randomly splitting the data within the feature value range. Normal points require more splits to be isolated, while outliers have shorter average path lengths. Due to the high dimensionality (multiple statistical features) of traffic data, high real-time requirements, and typically low outlier ratios, Isolation Forest does not require assumptions about data distribution, large amounts of labeled data, and is extremely efficient in high-dimensional spaces (near-linear time complexity). The implementation process includes:

[0155] Use the extracted feature vectors as input, such as kurtosis, skewness, wavelet coefficients, entropy, etc.

[0156] Build 100–200 trees with a subsampling size of 256 (a classic empirical value).

[0157] Anomaly score is calculated as s = 2^(-E(h(x)) / c(n)), where E(h(x)) is the average path length and c(n) is the average path length normalization factor. A score close to 1 indicates a significant anomaly.

[0158] It is particularly suitable for detecting burst traffic, such as during the initialization phase of DTU equipment or sudden equipment reporting.

[0159] The following is a Python code snippet:

[0160] import numpy as np

[0161] from sklearn.ensemble import IsolationForest

[0162] from sklearn.preprocessing import StandardScaler

[0163] # Assume traffic_data is a 1D time series

[0164] # First, extract features: sliding window statistical features (simplified example here)

[0165] def extract_features(traffic_data, window_size=30):

[0166] features = []

[0167] for i in range(len(traffic_data) - window_size + 1):

[0168] window = traffic_data[i:i+window_size]

[0169] feat = [

[0170] np.mean(window),

[0171] np.std(window),

[0172] np.max(window) - np.min(window), # Peak-to-peak value

[0173] scipy.stats.kurtosis(window), #Kurtosis

[0174] scipy.stats.skew(window), # Skewness

[0175] -np.sum(window * np.log(window + 1e-10)) # Approximate entropy ]

[0177] features.append(feat)

[0178] return np.array(features)

[0179] # Sample data (replace with real data)

[0180] traffic_data = np.random.normal(1000, 200, 1000) # Normal traffic

[0181] traffic_data[400:450] += 3000 # Simulate a sudden data burst

[0182] X = extract_features(traffic_data)

[0183] scaler = StandardScaler()

[0184] X_scaled = scaler.fit_transform(X)

[0185] # Training an isolated forest (unsupervised training is better with only normal data)

[0186] model = IsolationForest(

[0187] n_estimators=200,

[0188] contamination=0.05, # Expected abnormality rate

[0189] random_state=42 )

[0191] model.fit(X_scaled)

[0192] # Prediction (-1 indicates abnormality, 1 indicates normality)

[0193] anomaly_scores = model.decision_function(X_scaled) # The more negative the score, the more abnormal the score.

[0194] predictions = model.predict(X_scaled) # -1 indicates an exception

[0195] # Index of outliers

[0196] anomaly_indices = np.where(predictions == -1)[0]

[0197] print("Initial index of the window where an anomaly was detected:", anomaly_indices) ".

[0198] As a preferred embodiment, the step of performing secondary anomaly detection on the pre-processed data based on the isolated forest algorithm and change point detection method, and determining whether an abnormal traffic event has occurred in the message bus communication based on the results of the secondary anomaly detection, includes the following steps:

[0199] S2351. Use the isolated forest algorithm to detect sudden traffic anomalies in the pre-processed data and obtain the first anomaly detection result;

[0200] It should be noted that, taking the pre-processed data as input, corresponding statistical features are extracted based on a preset sliding window size, including core features such as kurtosis, skewness, wavelet transform coefficients, and entropy. At the same time, basic statistical quantities such as mean, standard deviation, and peak-to-peak value are added to form a high-dimensional feature vector. Then, the difference in feature dimensions is eliminated through standardization, and an isolated forest model containing 100-200 isolated trees is constructed. The model is trained using a classic subsampling size of 256 samples. After training, the high-dimensional feature vector is input into the model. By calculating the average path length of each sample and combining it with a normalization factor, an anomaly score is obtained. The closer the score is to 1, the higher the degree of anomaly. At the same time, a predicted label is output, marking it as abnormal or normal. Finally, the anomaly score, anomaly label, and the timestamp and feature dimension information of the corresponding sample are integrated to form the first anomaly detection result.

[0201] S2352. Using the Pelt algorithm and the Bayesian online change point detection method, silent period anomaly detection is performed on the pre-processed data to obtain the second anomaly detection result;

[0202] As a preferred embodiment, the step of using the Pelt algorithm and Bayesian online change point detection method to perform silent period anomaly detection on the pre-processed data and obtain the second anomaly detection result includes the following steps:

[0203] S23521. Arrange the preliminary processed data in chronological order according to their timestamp information to obtain the traffic characteristic time series;

[0204] S23522. Based on the sliding window mechanism, the time series of traffic characteristics is segmented to form multiple continuous subsequences;

[0205] S23523. Based on the Gaussian distribution assumption, construct and calculate the Pelt algorithm cost function for quantifying the degree of difference between adjacent subsequences;

[0206] As a preferred embodiment, the Pelt algorithm cost function, based on the Gaussian distribution assumption, for constructing and calculating the degree of difference in statistical summary quantities between adjacent subsequences, includes the following steps:

[0207] For all subsequences, determine the average value of all data points within each subsequence;

[0208] For each data point in each subsequence, calculate the difference between that data point and the mean of that subsequence;

[0209] Squaring each difference and summing all the squared differences yields the cost function value for each subsequence.

[0210] Specifically, the construction of this cost function is entirely based on the Gaussian distribution (normal distribution) assumption, that is, the normal traffic data of the default message bus follows an approximately normal distribution, which is highly consistent with the statistical characteristics of steady-state traffic in industrial scenarios. The role of this cost function is to provide a basis for judging the merits of segmentation for the Pelt algorithm. The Pelt algorithm calculates the total cost under different segmentation methods by traversing all possible change point positions, that is, the sum of the cost function values ​​of each subsequence plus the change point penalty term, and finally selects the segmentation scheme with the minimum total cost.

[0211] S23524. Combine the preset penalty term to control the number of change points, use dynamic programming to solve for the set of change points that minimize the cost function of the Pelt algorithm, and identify the structural transition locations of the decline in traffic in the traffic characteristic time series.

[0212] S23525. Using the Bayesian online change point detection method, the probability confidence level of the structural transition location is evaluated. If the decrease in traffic exceeds the preset threshold and the confidence level is higher than the set level, it is determined to be an abnormal event during the silent period, and a second abnormality detection result is generated.

[0213] It should be noted that the Bayesian online change point detection model identifies the structural transition position of traffic data from a normal steady state to a low steady state by updating the posterior probability of the change point at each time point in real time. That is, when the traffic data shows a non-instantaneous and continuous decline, the model calculates the probability that the time point is a change point. When the probability shows a sudden peak, the time point corresponding to the peak is the structural transition position to be evaluated. The confidence level is the normalized value of the posterior probability of the change point output by the model, ranging from [0,1], and the set level is usually 0.8~0.95. The preset amplitude threshold needs to be calibrated based on the constructed historical benchmark curve, usually set at 50%~80% of the normal traffic average, and this threshold can be dynamically adjusted according to the industrial production cycle. The calculation of the traffic decline amplitude is the ratio of "the traffic average of the steady-state subsequence before the structural transition position - the traffic average of the subsequence after the transition position" to "the steady-state traffic average before the transition", which quantifies the relative degree of traffic decline and avoids the scenario adaptability problem caused by absolute value judgment.

[0214] S2353. The first and second anomaly detection results are fused to generate a comprehensive anomaly confidence score.

[0215] S2354. Based on the comprehensive anomaly confidence level and the preset confidence level threshold, determine whether an abnormal traffic event has occurred in the message bus communication; if the comprehensive anomaly confidence level is greater than the preset confidence level threshold, it is determined that an abnormal traffic event has occurred, otherwise it is determined that no abnormal traffic event has occurred.

[0216] S236. If an abnormal traffic event occurs, perform load balancing adjustments; otherwise, return to step S231.

[0217] It should be noted that the bus server generates control decisions based on the results of abnormal traffic analysis and the real-time operating status of the servers on the DCS system message bus. Each server on the message bus acts as an independent entity, optimizing its control strategy based on its own node information and interactions with other server nodes, taking into account the scale, quality, and characteristics of the data traffic on the message bus, to achieve optimal overall performance of the distributed control system. The main decision-making criteria are as follows:

[0218] 1. Determine if the server issue is caused by traffic congestion. If the server CPU / memory is under high load, and the communication traffic on the corresponding port suddenly increases, such as an RTU abnormally sending a large amount of repetitive telemetry data, the root cause is abnormal traffic consuming server resources. If the server resources are normal, but specific messages have high latency and high packet loss rates, such as remote control commands, further investigation of the bus network is needed, such as a switch port failure, or the target device, such as an offline DPU.

[0219] 2. Determine if the abnormal traffic is caused by a server issue. If the server process crashes, causing message queue accumulation, and downstream devices cannot receive data, the traffic will appear as "normal sending traffic, zero receiving traffic," because the server service is interrupted. If the server disk I / O is saturated, such as if logs are not cleaned up in time, causing a decrease in message processing speed, the traffic will appear as "continuously increasing queue accumulation and increased latency," because "server storage resources are exhausted."

[0220] When locating the cause of an anomaly, the bus master server combines traffic data with server status cross-analysis to avoid misjudgment based on a single indicator.

[0221] Control Execution and Feedback: A communication mechanism is established between the servers on the message bus. The real-time communication content is the server node table, reflecting the real-time status of its own operation. Then, based on the real-time load, new requests or messages are routed to servers with lower load. Through the service discovery mechanism of the message bus or the support of an API gateway, the server node list on the message bus can be dynamically updated. Simultaneously, the execution results of the power equipment and the real-time operating status of the system are fed back to the data acquisition layer, forming a closed-loop control circuit. This ensures that the system can continuously adjust its control strategy according to actual operating conditions and maintain stable operation.

[0222] In addition, the servers in the list need to consider session persistence. Necessary heartbeat frames should be used to avoid interrupting established connections during switching, which would lead to dynamic policy adjustments, frequent switching between servers causing system oscillations, and consequently affecting the data acquisition and dynamic load decision-making of the DCS system.

[0223] Furthermore, the bus server uses a weighted round-robin method for dynamic switching. Traditional static weighted round-robin allocates tasks based on fixed weights of nodes, such as hardware performance, with higher-weighted nodes handling more requests, but it cannot adapt to dynamic load changes. This invention uses dynamic weighted round-robin to solve the problem of balancing server load.

[0224] A computing service process is deployed on the bus server, responsible for real-time evaluation of the load of each server on the message bus and dynamic adjustments. The computing service evaluates the real-time load of the current server based on several factors, including CPU utilization, memory usage, message queue length, and network bandwidth utilization. It uses a reverse mapping rule, where lower loads are assigned higher weights, to adjust the number of terminal connections on the server, aiming to achieve load balancing across the entire system.

[0225] The dynamic weight calculation formula needs to comprehensively consider multiple indicators. This invention adopts a linear weighting method:

[0226] ;

[0227] In the formula, α, β, and γ represent the weighting coefficients of each indicator, which need to be adjusted according to the scenario; W i Represents the overall dynamic weight of the i-th node, CPU i Represents the CPU utilization of the i-th node, Memory i Latency represents the memory utilization of the i-th node. i This represents the communication delay of the i-th node.

[0228] Normalization: After normalizing each indicator to the [0,1] interval, a weighted sum is calculated. Server-side task allocation uses heuristic rules: for example, if a server node's CPU usage is >80%, its weight is reduced to 0, and no tasks are assigned to it temporarily.

[0229] The request allocation strategy employs the following two methods:

[0230] 1. Probability allocation: Server nodes are randomly selected according to weight ratios, with higher weights having a greater probability of being selected.

[0231] 2. Deterministic polling; maintain a dynamic polling table to generate server node sequences according to weight ratios, such as the sequence [A,A,A,B,B,C] corresponding to weights 3:2:1.

[0232] S3. Based on the model mapping mechanism, the message bus data is mapped to the OPC UA server, and the message bus data is forwarded to the client of the third-party system for storage through the OPC UA server.

[0233] It should be noted that the data on the distributed control system bus is mapped to the OPC UA server in the same model format, namely the data format JSON Schema.

[0234] The OPC UA information model is built upon perception layer device nodes and reference device data items, and describes the system through the following core components:

[0235] Node types: Object, Variable, Method, View, etc.

[0236] Address Space: The logical collection of all nodes, forming a hierarchical or networked data model.

[0237] Type Definitions: Define the node structure and semantics through object type (ObjectType) and variable type (VariableType).

[0238] Since the perception layer devices have already connected the data to the message bus through the data subscription interface, the next step is to map the real-time data to the information model. The specific steps are as follows:

[0239] (1) Define a namespace and assign a unique namespace URI to the dynamic device model;

[0240] (2) Type hierarchy design: create device-defined object types and variable types, such as DynamicDeviceType and AdaptiveParameterType; extend existing types using inheritance, such as deriving subtypes from BaseObjectType.

[0241] (3) Metadata modeling: Reference the metadata required for additional dynamic configuration through HasProperty, such as data refresh frequency and data source URL.

[0242] Furthermore, the above three steps complete the modeling operation of the perception layer devices. In the operation of industrial distributed systems, it is often necessary to dynamically manage device nodes, change model mappings, and realize dynamic expansion of device-model. The specific steps are as follows:

[0243] 1. Dynamic node management; programmatic operation: Nodes can be dynamically created and deleted using the OPC UA server SDK. The OPC UA server SDK includes Python's opcua-asyncio and C++'s open62541, etc.

[0244] 2. Method Invocation: Expose methods such as AddDynamicNode or UpdateConfiguration to allow clients to trigger model changes.

[0245] 3. Dynamically update references; dynamically add HasComponent or Organizations references to integrate new nodes into the existing hierarchy. Use HasTypeDefinition references to dynamically bind type definitions.

[0246] 4. Real-time data binding; variable subscription and data source integration:

[0247] 5. Bind the value attribute of the variable to a real-time data source, such as DCS bus messages, database queries, or PLC registers.

[0248] 6. Use the OPC UA subscription / publish mechanism (Subscription) to implement data change notifications (MonitoredItem).

[0249] 7. Dynamic data source switching; modifying the data source of variables through method calls or configuration parameters, such as switching the register address of the PLC.

[0250] As a preferred implementation, the method of forwarding message bus data to the client of a third-party system for storage via the OPC UA server includes a data caching strategy and a load balancing transmission strategy based on the subscribed content topic;

[0251] The data caching strategy includes third-party system client caching and OPC UA server caching;

[0252] The third-party system client cache is used to set up a caching mechanism locally on the third-party system client, cache data that has been obtained, and when the third-party system client requests the same data again, it first retrieves it from the local cache, and when the cached data expires or changes, it sends a request to the OPC UA server to obtain the latest data;

[0253] The OPC UA server cache is used to cache frequently accessed data points. When a client request is received, it first checks if the required data is in the cache. If it is, it reads the data directly from the cache and returns it to the third-party system client.

[0254] The load balancing transmission strategy based on subscription content topics is used to distribute the subscription requests of third-party system clients to different OPC UA server nodes according to the topic of the requested data, so that each OPC UA server node is responsible for handling data subscription and transmission tasks for different topics.

[0255] It should be noted that after the OPC UA server receives data from the message bus, there is a need for a third-party backend to forward the data. Therefore, the collected data needs to be forwarded through the OPC UA server.

[0256] Specifically, the message bus client and the OPC UA server obtain device data on the bus through a custom interface, and then the OPC UA server forwards the data to the third-party system platform.

[0257] In an OPC UA architecture, clients obtain data through a subscription mechanism. If multiple clients subscribe to the same large number of data nodes, the server needs to repeatedly process these subscription requests and send the same data to multiple clients, leading to a significant increase in data transmission volume and increased communication load. Furthermore, unreasonable subscription period settings, such as too short a subscription period, can result in excessively high data update frequencies, further increasing the load. Therefore, this invention addresses the problems encountered in traditional architectures from two aspects:

[0258] (1) Adopt a data caching strategy; including client-side caching and server-side caching;

[0259] Client-side caching involves setting up a caching mechanism locally on the third-party system client to cache data that has already been retrieved. When the client requests the same data again, it first retrieves it from the local cache. Only when the cached data expires or changes will a request be sent to the OPC UA server to obtain the latest data. This reduces duplicate requests from the client to the server, lowering the server's processing load and network traffic.

[0260] Server-side caching involves the OPC UA server caching frequently accessed data points. When a client request is received, the server first checks if the required data exists in the cache. If so, it reads the data directly from the cache and returns it to the client, avoiding repeated retrieval of data from the data source (such as field devices) and improving response speed. Furthermore, the cache's expiration period and update strategy can be configured to ensure the timeliness of cached data.

[0261] (2) Load balancing based on subscription topics is adopted. In the data subscription scenario, the client's subscription requests are distributed to different server nodes according to the data topic, such as device type and data type. Each server node is responsible for handling data subscription and transmission tasks for a specific topic, thereby reducing the number of subscriptions handled by a single node and reducing the load. The basic logic of data topic subscription is explained from three aspects below:

[0262] 1) Segmentation by Business Function: The SCADA system includes functions such as data acquisition (remote signaling / telemetry), control commands (remote control / remote adjustment), alarm processing, and historical data storage. Each functional module has an independent theme. The format is as follows: scada / <area> / <substation> / <voltage level> / <data type> / <device ID>.

[0263] For example, the server responsible for alarm processing only subscribes to scada / alarm / event and does not need to receive real-time data and control commands. scada / huadong / shanghai / 220kV / telemetry / device001 is used for telemetry data. This allows regional servers to subscribe only to scada / huadong / # (using multi-level wildcards #), naturally achieving load balancing split by region.

[0264] 2) Splitting by data location: Power systems typically divide management areas by substation, region (e.g., East China / North China), or voltage level (110kV / 220kV). Topics are split according to this dimension. For example, a monitoring server for a certain region only subscribes to topics within that region, avoiding redundant load caused by cross-regional data.

[0265] 3) Data Priority Segmentation: In SCADA systems, different data have different real-time requirements (e.g., remote control commands have higher priority than historical data uploads). High-priority data can be assigned to separate topics, allowing core servers to process them first. For example, high-priority topics can be subscribed to only by the core control server, preventing low-priority data from consuming its resources and ensuring the real-time performance of critical business operations.

[0266] 4) Split by device type or source, i.e. expand by business function; In power SCADA, there are various devices, such as RTU, PMU and protection devices, which can be further split into topics by device type or data source to achieve more granular load balancing.

[0267] 5) Segmentation by Equipment Type: Different equipment generates significantly different amounts and frequencies of data, such as PMU high-frequency sampling versus conventional telemetry. For example, DTU data uses scada / dtu / high-frequency / # and is subscribed to by dedicated high-performance nodes; conventional telemetry uses scada / telemetry / standard / #.

[0268] 6) Data splitting by source: When edge gateways or sub-sites upload data, they use source identifiers. For example, edge nodes only publish to topics with a specific prefix, and servers subscribe based on the source, reducing cross-node data transmission.

[0269] Specifically, shared subscriptions can be used to achieve client-side load balancing; the message bus supports shared subscriptions, which can distribute messages on the same topic to multiple subscribers within a group to achieve automatic load balancing without the need for additional topic splitting.

[0270] Mechanism: Using $share / <group_name> / <topic_filter> Formatted subscriptions allow the broker to distribute messages to clients within a group via round-robin, random, or hash distribution. For example, multiple processing nodes can share a subscription to `$share / alarm-group / scada / alarm / event`, automatically and evenly distributing messages for high-load alarm topics. This is suitable for hot topics, such as network-wide alarms, preventing overload on individual nodes. It also supports high availability, such as automatic redistribution in case of node failure, making it suitable for backend processing nodes subscribing to high-throughput topics, such as historical storage or analytics servers.

[0271] It should be further noted that the security mechanisms supported by OPC UA can ensure the confidentiality, integrity, and availability of communication through multi-layered protection. It requires both communicating parties (client and server) to perform two-way authentication before establishing a connection to prevent unauthorized access. This patent employs the following three methods to enhance data security and reliability:

[0272] 1. X.509 Certificate: By default, it uses digital certificates based on PKI (Public Key Infrastructure) for authentication. The server and client need to exchange certificates and verify each other's legitimacy through a trusted Certificate Authority (CA).

[0273] 2. User authentication: Supports multiple methods to verify user identity, including username / password, X.509 certificate, and token, such as JWT.

[0274] 3. Anonymous access control: Allows configuring anonymous access permissions, but it is recommended to disable it in a distributed control system environment.

[0275] Through the aforementioned multi-layered security mechanisms, enterprise-level security is provided for the distributed control system (DCS). Its design complies with industrial safety standards such as IEC 62443 and NIST SP 800-82, and is suitable for the high security requirements of critical infrastructure (such as energy and manufacturing).

[0276] like Figure 2As shown, according to a second embodiment of the present invention, an OPCUA communication system supporting DCS bus traffic analysis and prediction is provided, the system comprising:

[0277] Interface construction module 1 is used to construct a perception layer device access interface that, after completing protocol conversion of the collected data through a pre-configured communication protocol format, writes the collected data into the subscription interface.

[0278] Data acquisition module 2 is used to construct a message bus for a distributed control system that includes a server and a client, and to start the server and client of the message bus in the perception layer and control layer of the distributed control system, respectively; using the access interface of the perception layer device and combined with AI traffic monitoring and analysis methods, the message bus data is dynamically acquired.

[0279] Data mapping module 3 is used to map message bus data to the OPC UA server based on the model mapping mechanism, and then forward the message bus data to the client of the third-party system for storage through the OPC UA server.

[0280] According to a third embodiment of the present invention, an electronic device is provided, the electronic device comprising: one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the steps in any of the above method embodiments.

[0281] According to a fourth embodiment of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to perform the steps in any of the above method embodiments.

[0282] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0283] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0284] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An OPCUA communication method supporting DCS bus traffic analysis and prediction, characterized in that, The method includes the following steps: S1. Construct a perception layer device access interface for converting the collected data into a protocol using a pre-configured communication protocol format and writing the collected data into the subscription interface. S2. Construct a message bus for the distributed control system that includes a server and a client, and start the server and client of the message bus in the perception layer and control layer of the distributed control system respectively; use the access interface of the perception layer device and combine AI traffic monitoring and analysis methods to dynamically obtain message bus data. S3. Based on the model mapping mechanism, the message bus data is mapped to the OPC UA server, and the message bus data is forwarded to the client of the third-party system for storage through the OPC UA server.

2. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 1, characterized in that, The construction of a message bus for a distributed control system, comprising a server and a client, and the startup of the message bus server and client at the perception layer and control layer of the distributed control system, respectively; and the dynamic acquisition of message bus data using the perception layer device access interface and AI traffic monitoring and analysis methods, includes the following steps: S21. In the distributed control system architecture, establish a multi-layer message bus structure; S22. Deploy the message bus server on the perception layer node in the distributed control system architecture, deploy the message bus client on the control layer node in the distributed control system architecture, and start the message bus server and message bus client respectively. S23. Based on the AI ​​traffic monitoring and analysis method, obtain message bus data generated by the message bus server and message bus client in the message bus through the access interface of the perception layer device.

3. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 2, characterized in that, The AI-based traffic monitoring and analysis method, which obtains message bus data generated by the message bus server and message bus client through the access interface of the perception layer device, includes the following steps: S231. When obtaining message bus data generated by the message bus server and message bus client in the message bus through the access interface of the perception layer device, the communication traffic data of the message bus is obtained in real time. S232. Convert communication traffic data into multidimensional time series format data, extract statistical features from the multidimensional time series format data, preprocess the statistical features, and obtain real-time preprocessed feature data. S233. Collect preprocessed feature data from historical normal operation phases, construct a feature library of normal flow patterns, and generate historical baseline curves representing steady-state behavior through seasonal time series decomposition methods. S234. Using historical baseline curves, perform preliminary comparisons on the feature data after real-time preprocessing, identify and mark them as preliminary abnormal data, remove the preliminary abnormal data, and obtain the preliminary processed data. S235. Based on the isolated forest algorithm and change point detection method, perform secondary anomaly detection on the pre-processed data, and determine whether abnormal traffic events have occurred in the message bus communication based on the results of the secondary anomaly detection. S236. If an abnormal traffic event occurs, perform load balancing adjustments; otherwise, return to step S231.

4. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 3, characterized in that, The method based on the isolated forest algorithm and change point detection performs secondary anomaly detection on the pre-processed data, and determines whether abnormal traffic events have occurred in the message bus communication based on the results of the secondary anomaly detection, including the following steps: S2351. Use the isolated forest algorithm to detect sudden traffic anomalies in the pre-processed data and obtain the first anomaly detection result; S2352. Using the Pelt algorithm and the Bayesian online change point detection method, silent period anomaly detection is performed on the pre-processed data to obtain the second anomaly detection result; S2353. The first and second anomaly detection results are fused to generate a comprehensive anomaly confidence score. S2354. Based on the comprehensive anomaly confidence level and the preset confidence level threshold, determine whether an abnormal traffic event has occurred in the message bus communication; if the comprehensive anomaly confidence level is greater than the preset confidence level threshold, it is determined that an abnormal traffic event has occurred, otherwise it is determined that no abnormal traffic event has occurred.

5. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 4, characterized in that, The process of using the Pelt algorithm and Bayesian online change point detection method to perform silent period anomaly detection on the pre-processed data to obtain the second anomaly detection result includes the following steps: S23521. Arrange the preliminary processed data in chronological order according to their timestamp information to obtain the traffic characteristic time series; S23522. Based on the sliding window mechanism, the time series of traffic characteristics is segmented to form multiple continuous subsequences; S23523. Based on the Gaussian distribution assumption, construct and calculate the Pelt algorithm cost function for quantifying the degree of difference between adjacent subsequences; S23524. Combine the preset penalty term to control the number of change points, use dynamic programming to solve for the set of change points that minimize the cost function of the Pelt algorithm, and identify the structural transition locations of the decline in traffic in the traffic characteristic time series. S23525. Using the Bayesian online change point detection method, the probability confidence level of the structural transition location is evaluated. If the decrease in traffic exceeds the preset threshold and the confidence level is higher than the set level, it is determined to be an abnormal event during the silent period, and a second abnormality detection result is generated.

6. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 5, characterized in that, The Pelt algorithm cost function, which is constructed and calculated based on the Gaussian distribution assumption to quantify the difference in statistical summary quantities between adjacent subsequences, includes the following steps: For all subsequences, determine the average value of all data points within each subsequence; For each data point in each subsequence, calculate the difference between that data point and the mean of that subsequence; Squaring each difference and summing all the squared differences yields the cost function value for each subsequence.

7. The OPCUA communication method supporting DCS bus traffic analysis and prediction according to claim 1, characterized in that, The method of forwarding message bus data to the client of a third-party system for storage via the OPC UA server includes data caching strategies and load balancing transmission strategies based on subscribed content topics; The data caching strategy includes third-party system client caching and OPC UA server caching; The third-party system client cache is used to set up a caching mechanism locally on the third-party system client, cache data that has been obtained, and when the third-party system client requests the same data again, it first retrieves it from the local cache, and when the cached data expires or changes, it sends a request to the OPC UA server to obtain the latest data; The OPC UA server cache is used to cache frequently accessed data points. When a client request is received, it first checks if the required data is in the cache. If it is, it reads the data directly from the cache and returns it to the third-party system client. The load balancing transmission strategy based on subscription content topics is used to distribute the subscription requests of third-party system clients to different OPC UA server nodes according to the topic of the requested data, so that each OPC UA server node is responsible for handling data subscription and transmission tasks for different topics.

8. An OPCUA communication system supporting DCS bus traffic analysis and prediction, used to implement the OPCUA communication method supporting DCS bus traffic analysis and prediction as described in any one of claims 1-7, characterized in that, The system includes: The interface construction module is used to build a perception layer device access interface that converts the collected data into a protocol using a pre-configured communication protocol format and writes the collected data into the subscription interface. The data acquisition module is used to construct a message bus for a distributed control system that includes a server and a client, and to start the server and client of the message bus in the perception layer and control layer of the distributed control system, respectively; and to dynamically acquire message bus data by using the access interface of the perception layer device and combining AI traffic monitoring and analysis methods. The data mapping module is used to map message bus data to the OPC UA server based on the model mapping mechanism, and then forward the message bus data to the client of the third-party system for storage through the OPC UA server.

9. An electronic device, characterized in that, The electronic device includes: one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the steps of the method according to any one of claims 1 to 7 are implemented when the computer program controls the device containing the computer-readable storage medium to execute during runtime.