An industrial edge data acquisition gateway system and implementation method

Abstract

This application relates to an industrial edge data acquisition gateway system and its implementation method, solving the technical problems of poor multi-protocol compatibility, low acquisition efficiency, lack of state-adaptive scheduling, and insufficient remote security in traditional industrial data acquisition gateways. The system includes: a protocol management module, which identifies protocols and dynamically loads plugins; a data acquisition module, which reuses connection pools and performs batch acquisition at differentiated frequencies; a data processing module, which standardizes data; a data upload module, which uses binary protocol heartbeat reconnection; a status monitoring module, which predicts congestion trends, adaptively switches channels, adjusts frequencies, clears idle connections, and performs integrated uploads; and a remote management module, which provides secure access via reverse proxy long connections and distributes configurations. This application achieves the following effects: dynamic protocol expansion and efficient acquisition; an adaptive scheduling mechanism based on trend prediction effectively reduces network load; ensures real-time and reliable transmission of critical data; and significantly improves gateway stability and remote operation and maintenance security.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and in particular to an industrial edge data acquisition gateway system and its implementation method. Background Technology

[0002] With the deep integration of the Industrial Internet and intelligent manufacturing, industrial production systems are rapidly evolving towards digitalization, networking, and intelligence. As the core hub connecting the physical production site and the digital cloud platform, the real-time performance and processing reliability of industrial edge data acquisition gateways directly determine the efficiency of upper-layer intelligent applications. Faced with complex scenarios such as diverse heterogeneous protocols, varied equipment types, and dynamically fluctuating network environments in industrial settings, these gateways must possess efficient data acquisition, processing, and transmission capabilities. They are a crucial link in breaking down industrial data barriers, unlocking the value of production data, and ensuring system collaborative optimization.

[0003] Currently, data acquisition gateways widely used in the industrial sector often employ relatively fixed technical architectures in their functional implementation. Specifically, in terms of protocol access, device interfacing is typically based on pre-defined static protocol libraries; in terms of data acquisition, parameters such as acquisition frequency and batch size are fixed and difficult to dynamically adjust according to changes in on-site operating conditions; in terms of data processing and transmission, fixed-period reporting mechanisms are commonly used, alarm strategies are relatively simple, and there is a lack of proactive response capabilities to network fluctuations; in terms of network and connection management, most rely on simple connectivity monitoring or load assessment based on the current network status, lacking a forward-looking scheduling mechanism; and in terms of remote operation and maintenance, virtual private networks or port mapping technologies are often used to achieve remote access and configuration of devices, resulting in complex configurations and high security risks.

[0004] However, the aforementioned relatively rigid technical architecture faces numerous challenges in practical applications. Because protocol access relies on static libraries and acquisition and transmission parameters are fixed, existing solutions typically rely on manual intervention or simple on / off monitoring and fixed retries when faced with unknown protocols, changing operating conditions, or network fluctuations. They lack dynamic protocol expansion, adaptive parameter adjustment, and forward-looking network scheduling capabilities. This results in limitations in system flexibility, real-time performance, and reliability, leading to problems such as access difficulties, resource waste, and data loss. Consequently, it fails to fully meet the high standards of industrial production regarding real-time data acquisition, system reliability, and functional evolvability. Summary of the Invention

[0005] To achieve dynamic protocol expansion and efficient data acquisition, an adaptive scheduling mechanism based on trend prediction effectively reduces network load, ensures real-time and reliable transmission of critical data, and significantly improves gateway stability and remote operation and maintenance security. This application provides an industrial edge data acquisition gateway system and its implementation method.

[0006] Firstly, this application provides an industrial edge data acquisition gateway system, which adopts the following technical solution:

[0007] An industrial edge data acquisition gateway system includes:

[0008] The protocol management module acquires communication data from industrial equipment, extracts protocol feature vectors, identifies protocol types through a two-layer mechanism of automatic similarity matching and rule base fallback matching, and dynamically loads corresponding protocol plugins.

[0009] The data acquisition module establishes a connection with industrial equipment through a protocol plugin, configures the connection pool differently based on the protocol identification results, and reuses the connections in the pool. Based on the protocol type, its corresponding equipment type, and the importance level of the data, it allocates different acquisition frequencies to different industrial equipment with a preset frequency benchmark and step size, and reads and writes data points in batches according to a preset batch size to obtain raw data.

[0010] The data processing module performs standardization processing on the raw data to generate standardized equipment data;

[0011] The data upload module receives standardized device data and transmits it asynchronously to the cloud platform via a binary protocol, automatically reconnecting when the connection is interrupted.

[0012] The status monitoring module collects gateway operating status parameters, performs time-series analysis on the operating status parameters based on a preset trend analysis strategy to obtain the trend prediction value of each parameter in the next time window, and when the trend prediction value exceeds the preset congestion threshold, the congestion degree is quantified according to the magnitude of the exceedance. When the congestion degree exceeds the preset switching threshold, the corresponding channel data is switched to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type. The module adjusts the differentiated collection frequency according to the congestion degree gradient and cleans up timed-out idle connections in the connection pool. The operating status parameters are then merged with standardized device data and uploaded to the cloud platform.

[0013] The remote management module establishes a long connection with the remote management server of the cloud platform through a reverse proxy, forwards remote requests to the local service, receives protocol configuration data issued by the remote management server and forwards it to the protocol management module.

[0014] Secondly, this application provides a method for implementing an industrial edge data acquisition gateway system, which adopts the following technical solution:

[0015] A method for implementing an industrial edge data acquisition gateway system, applied to the industrial edge data acquisition gateway system as described in the first aspect, includes the following steps:

[0016] Acquire communication data from industrial equipment, identify the protocol type through protocol identification, and dynamically load the corresponding protocol plugin;

[0017] The system establishes a communication connection with industrial equipment by loading a protocol plugin, reuses connections in a preset capacity connection pool, and allocates differentiated acquisition frequencies to different industrial equipment based on the protocol type, the corresponding equipment type, and the data importance level, using a preset frequency benchmark and step size. It also uses a preset batch size to read and write multiple data points in batches to obtain raw data.

[0018] The raw data is standardized to generate standardized equipment data;

[0019] It receives standardized equipment data, asynchronously transmits it to the cloud platform via a binary protocol with a preset heartbeat cycle and heartbeat mechanism, and automatically reconnects when the connection is interrupted;

[0020] The system collects gateway operation status parameters and performs time-series analysis on these parameters based on a preset trend analysis strategy to obtain the trend prediction values ​​for each parameter in the next time window. When the trend prediction value exceeds the preset congestion threshold, the congestion level is quantified based on the magnitude of the excess of the trend prediction value relative to the congestion threshold. When the congestion level exceeds the preset switching threshold, the system switches the corresponding channel data to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type. The system adjusts the differentiated collection frequency according to the congestion level gradient and cleans up timed-out idle connections in the connection pool. The operation status parameters are then sent to the data upload step to be integrated with standardized device data before being uploaded to the cloud platform.

[0021] By establishing a long connection with the remote management server in the cloud platform through a reverse HTTP proxy, receiving remote HTTP requests and forwarding them to the local service on a preset port, and receiving protocol configuration data issued by the remote management server and forwarding it to the protocol identification step, remote secure access to the gateway is achieved. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall process of implementing an industrial edge data acquisition gateway system according to an embodiment of this application. Detailed Implementation

[0023] The present application will be further described in detail below with reference to the accompanying drawings.

[0024] This application discloses an industrial edge data acquisition gateway system, comprising:

[0025] The protocol management module acquires communication data from industrial equipment, extracts protocol feature vectors, identifies protocol types through a two-layer mechanism of automatic similarity matching and rule base back-matching, and dynamically loads corresponding protocol plugins.

[0026] The two-layer mechanism of automatic similarity matching and rule base fallback matching forms the core architecture of the protocol management module for protocol identification. The two mechanisms are executed in a fixed order: the first level is automatic similarity matching, which calculates the similarity between the extracted protocol feature vector and the standard protocol fingerprint feature library to accurately identify general standard industrial protocols with high confidence; the second level is rule base fallback matching, which is only activated after the first level of automatic matching fails. It calculates the matching degree of the feature vector through the preset protocol expert rule library to perform fault-tolerant identification of non-standard and manufacturer-customized variant industrial protocols. This balances the recognition accuracy of standard protocols with the adaptability of non-standard protocols, and solves the problem of device access in industrial scenarios with multiple heterogeneous devices and multiple types of protocols. The complete execution process of this mechanism is detailed in steps S11 to S16 below.

[0027] Communication data refers to the raw data bitstream transmitted between industrial equipment and the gateway, including device identification, function commands, and service data payloads. Protocol type indicates the type of communication protocol used by the industrial equipment, such as Modbus, OPCUA, MQTT, or a vendor-defined protocol. Protocol plugins are parsing program units developed for specific protocol types, used to implement data encapsulation / decapsulation, register mapping, and communication control for that protocol.

[0028] The necessary process is as follows: The protocol management module listens to the communication port of the industrial equipment to obtain the communication data of the industrial equipment in real time; it identifies the protocol of the received communication data and determines the protocol type used by the equipment by parsing the message structure characteristics and communication timing characteristics; according to the determined protocol type, it dynamically loads the corresponding protocol plugin from the local plugin library so that subsequent modules can establish correct communication with the industrial equipment based on the plugin.

[0029] The data acquisition module establishes a connection with industrial equipment through a protocol plugin, configures the connection pool differently based on the protocol identification results, and reuses the connections within the pool. Based on the protocol type, its corresponding equipment type, and the importance level of the data, it assigns differentiated acquisition frequencies to different industrial equipment with a preset frequency benchmark and step size, and reads and writes data points in batches according to a preset batch size to obtain raw data.

[0030] The system includes the following components: Connection Pool: A pre-allocated buffer pool of fixed-number connection resources used to manage communication connections between the gateway and multiple industrial devices, supporting connection reuse and allocation. Protocol Type: The type of industrial device communication protocol identified by the protocol management module, affecting connection establishment methods and data parsing rules. Device Type: Characterizes the physical attributes and functional classification of industrial devices, such as sensors, actuators, and PLC controllers. Data Importance Level: A priority identifier based on device type and business requirements, used to distinguish between critical, important, and general data. Preset Frequency Baseline: An initial acquisition rate reference value set for devices of different importance levels. Step Size: The quantitative unit for adjusting the acquisition frequency, used to increase or decrease the frequency. Differentiated Acquisition Frequency: A personalized acquisition rate determined based on protocol type, device type, and data importance level, including a base frequency, a maximum frequency, and a minimum frequency boundary. Preset Batch Size: The threshold for the number of data points allowed to be acquired in a single batch read / write operation. Raw Data: Unstandardized binary or hexadecimal data acquired from industrial devices.

[0031] The necessary procedures are as follows:

[0032] Protocol plugin loading and connection establishment: The data acquisition module receives the protocol plugins (such as libmodbus.so or opcua_client.dll) loaded by the protocol management module, calls the plugin interface to establish a TCP or serial communication connection with the industrial equipment; initializes the connection parameters (timeout, number of retries, keep-alive period) according to the protocol type (standard configuration is used when automatic matching is successful, and conservative configuration is used when fallback matching is successful), and includes the connection in a preset capacity connection pool (such as a maximum number of connections of 256) for unified management, so as to realize the reuse and dynamic allocation of multi-device connections.

[0033] Differentiated acquisition frequency allocation: Based on protocol type (e.g., Modbus high reliability, custom protocol low reliability), device type (e.g., PLC controller, temperature and humidity sensor), and data importance level (critical / important / general), frequency boundaries (base frequency, maximum frequency, minimum frequency) are set for each industrial device; the rate of change and fluctuation amplitude of data points of each device are calculated in real time. When the rate of change continuously exceeds the preset upper limit threshold (e.g., 10% / s) and reaches the frequency increase counting threshold (e.g., 5 times), the acquisition frequency is gradually increased according to the preset frequency increase step size (e.g., 0.5Hz) until the maximum frequency is reached; when the rate of change is continuously lower than the lower limit threshold and the fluctuation amplitude is lower than the fluctuation threshold (e.g., when the rate of change is lower than 1% / s for 10 consecutive times and the standard deviation of the fluctuation amplitude is less than 0.5), the acquisition frequency is gradually decreased according to the preset frequency decrease step size (e.g., 1Hz) until the minimum frequency is reached, realizing differentiated dynamic adjustment.

[0034] Batch data acquisition and raw data acquisition: Multiple data points are read and written in batches using a preset batch size (initial value 50 points); when the rate of change exceeds the upper limit threshold, the batch size is reduced by a decreasing step size (e.g., 20 points each time) to improve real-time density, with a minimum limit of 1 point (single point acquisition); when the rate of change is lower than the lower limit threshold and the fluctuation amplitude is lower than the threshold, the batch size is increased by an incremental step size (e.g., 50 points each time) to improve compression efficiency, with a maximum limit of 500 points; multiple data points are acquired from the industrial equipment registers or storage area through batch read and write operations to obtain raw binary or hexadecimal data, which is then stored in the raw data buffer for subsequent processing.

[0035] The calculation of change rate and fluctuation amplitude for differentiated acquisition frequency adjustment, as well as the preset step size mechanism for batch size adjustment in the data acquisition module of this application, are all strictly based on the numerical change characteristics of physical data points of industrial equipment. The change rate is defined as the ratio of the absolute change in data point values ​​within adjacent acquisition cycles to the previous cycle, and the fluctuation amplitude is defined as the maximum absolute deviation of data point values ​​from the mean within a sliding time window. Both are standard statistical quantities used in the field of industrial data acquisition to characterize data stability and do not contain any commercial logic or subjective evaluation. The frequency increase and decrease counting thresholds, and the upper and lower limits of the change rate thresholds in frequency adjustment, as well as the decrease and increase step sizes in batch adjustment, are all determined through pre-experiments or equipment manufacturer specifications based on different protocol types, equipment types, and data importance levels, forming a fixed mapping relationship. This dynamic adjustment mechanism fully serves the technical objective of "optimizing acquisition density and network resource utilization while ensuring the real-time performance of key data." Its algorithm parameters do not change with external commercial factors, and those skilled in the art can reproduce this dynamic adjustment process based on the operating characteristics of industrial equipment according to the above-disclosed content.

[0036] The data processing module is used to standardize the raw data and generate standardized equipment data.

[0037] Raw data: Unprocessed data collected in batches from industrial equipment by the data acquisition module, containing equipment-specific protocol formats. Standardization processing: The data conversion process that transforms raw data from different protocols and equipment types into data with a unified format specification. Standardized equipment data: Output data that conforms to a unified data schema after standardization processing.

[0038] The necessary procedures are as follows:

[0039] The gateway receives the raw data reported by the data acquisition module, parses the device identification information in the raw data, and determines the data source device and its corresponding protocol type (such as Modbus TCP, OPC UA) and device type (such as temperature sensor, pressure transmitter).

[0040] Based on the protocol type, the corresponding data transformation rule is called from the preset standardization rule base to standardize the raw data. A linear mapping algorithm is used to convert the raw register value into an engineering unit value. The specific process is as follows: subtract the lower limit of the range from the raw value, multiply it by the engineering range width, divide it by the raw range width, and finally add the lower limit of the engineering range to obtain the standardized engineering value.

[0041] The converted values ​​are standardized in terms of units, converting heterogeneous units reported by different devices (such as Celsius / Fahrenheit, Pascal / Megapascal) into standard units. Data quality markers (such as valid marker 0, suspected anomaly marker 1, invalid marker 2) are added based on the anomaly detection results during the data conversion process.

[0042] Standardized device data is generated by encapsulating standardized numerical values, standard timestamps (converted to UTC time), unique device identifiers, data quality tags, and metadata information including protocol type and device type.

[0043] The data upload module is used to receive standardized device data and transmit it asynchronously to the cloud platform via a binary protocol with a heartbeat mechanism. It automatically reconnects when the connection is interrupted.

[0044] Specifically, this includes: Standardized equipment data: Data output by the data processing module that conforms to a unified format specification. Heartbeat mechanism: A mechanism that periodically sends detection messages to maintain connection activity and detect connection availability. Binary protocol: A data transmission protocol using binary encoding, featuring efficient and compact transmission characteristics.

[0045] The necessary procedures are as follows:

[0046] The gateway receives standardized device data reported by the data processing module and serializes the data into binary format. It then initializes the network connection with the cloud platform and establishes a transmission channel.

[0047] To maintain the connection, a heartbeat mechanism is initiated: Heartbeat messages are sent periodically according to a preset heartbeat period (e.g., 30 seconds). The heartbeat messages contain the gateway identifier, timestamp, and connection status information. Data is encapsulated in a binary protocol frame format. The frame structure includes a frame header (e.g., 0xAA55), payload length, data payload, and checksum (e.g., CRC16).

[0048] Standardized device data is sent using an asynchronous transmission mode: the serialized data is placed in a transmission buffer, and an independent transmission thread reads the data from the buffer and sends it, while the main thread continues to execute data acquisition and processing. A sliding window algorithm is used to manage the transmission buffer, and the specific process is as follows: by maintaining the transmission window size (e.g., 16 frames) and the sequence number of the acknowledged frames, flow control and retransmission management are achieved, and the window slides forward as the acknowledged frames arrive.

[0049] The system monitors the connection status in real time. When the number of consecutive heartbeat responses not received exceeds a preset heartbeat timeout threshold (e.g., 3 times), the connection is considered interrupted. Upon detecting a connection interruption, an automatic reconnection mechanism is initiated: the failed connection handle is closed, and after waiting for a preset reconnection interval (e.g., 5 seconds), a new connection establishment request is initiated with the cloud platform to restore the transmission channel and continue sending the standardized device data backed up in the buffer.

[0050] The status monitoring module is used to collect gateway operating status parameters and perform the following operations:

[0051] Based on a preset trend analysis strategy, time series analysis is performed on the operating status parameters to obtain the trend prediction values ​​of each parameter in the next time window.

[0052] When the trend prediction value exceeds the preset congestion threshold, the degree of congestion is quantitatively determined based on the extent to which the trend prediction value exceeds the congestion threshold.

[0053] When the congestion level exceeds the preset switching threshold, the corresponding channel data will be switched to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type.

[0054] Adjust the sampling frequency according to the congestion level and clear timed-out idle connections in the connection pool;

[0055] The operating status parameters are sent to the data upload module so that they can be integrated with the standardized equipment data and then uploaded to the cloud platform.

[0056] The system includes the following parameters: **Operating Status Parameters:** A set of quantitative indicators characterizing the real-time operating status of the gateway, including CPU utilization, memory usage, network latency, connection pool utilization, and data queue depth. **Trend Analysis Strategy:** An analysis method that predicts future parameter trends based on historical time-series data. **Trend Prediction Value:** The predicted result of the operating status parameters within the next time window, calculated using the trend analysis strategy. **Congestion Threshold:** The critical value for determining if the gateway's operating status enters a congested state. **Excess Amount:** The proportion by which the trend prediction value exceeds the congestion threshold. **Congestion Severity:** The level of congestion severity quantified based on the excess amount. **Switching Threshold:** The critical value for congestion severity that triggers a channel switching operation. **Scheduling Strategy:** Pre-defined data channel selection rules based on the protocol type. **Low-Load Channel:** Alternative transmission channels where the current network load is below average.

[0057] The necessary procedures are as follows:

[0058] The gateway collects operational status parameters in real time and constructs a sliding time window data sequence (e.g., window length 30 seconds) for each operational status parameter. The length of each sliding time window is determined from the preset window length configuration based on the protocol type (e.g., MQTT, HTTP), and the corresponding exponential smoothing coefficient (e.g., 0.3-0.9) is determined from the preset smoothing coefficient configuration based on the device type (e.g., high-frequency sensor, low-frequency sensor).

[0059] An exponential smoothing algorithm is used to calculate the smoothing value for the sliding time window data sequence. The specific process is as follows: The current observed value is multiplied by a smoothing coefficient, and the smoothed value from the previous time step is multiplied by (1 - smoothing coefficient) to obtain the smoothed value for the current time step. The smoothed value at the end of the window is then used as the initial trend prediction value. Based on the data importance level (e.g., critical, important, normal), a compensation coefficient (e.g., -0.1, 0, 0.1) is determined from a preset compensation coefficient configuration. This compensation coefficient is then linearly corrected to the initial trend prediction value (e.g., multiplied by 1 + compensation coefficient) to obtain the trend prediction value for each operating state parameter in the next time window.

[0060] When the predicted trend value exceeds the preset congestion threshold (e.g., CPU utilization of 80%, network latency of 500ms), the congestion level is quantified and determined based on the extent of the exceedance (e.g., exceeding the threshold by 20%) (e.g., divided into levels 1-4). When the congestion level exceeds the preset switching threshold (e.g., level 3), the corresponding channel data is switched to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type (e.g., MQTT protocol prioritizes the backup MQTT Broker, HTTP protocol switches to the CDN node).

[0061] Adjust the differentiated collection frequency according to the congestion level gradient: Determine the step size correction coefficient based on the congestion level and data importance level (e.g., the coefficient is 3.0 when the congestion level is 4 and the normal level is 3). Amplify the preset frequency reduction step size (e.g., 0.5Hz) to obtain the corrected frequency reduction step size, and gradually reduce the collection frequency of devices with data importance level lower than the preset importance threshold (e.g., important).

[0062] Set the idle connection timeout based on the congestion level and data importance level (e.g., 75 seconds for congestion level 4 and normal level, and 300 seconds for level 1 and critical level), and clean up idle connections in the connection pool, prioritizing the cleanup of idle connections corresponding to devices with low data importance levels.

[0063] The operating status parameters are sent to the data upload module, and after being merged with the standardized equipment data, they are asynchronously transmitted to the cloud platform via a binary protocol.

[0064] The trend prediction, channel switching, and congestion handling mechanisms employed in the status monitoring module of this application are all based on the time-series characteristics of the gateway's physical operating status parameters (CPU utilization, memory usage, network latency, and data queue depth), serving the technical objective of "ensuring the stable operation of the gateway and the reliability of critical data transmission in a dynamic network environment." Specifically:

[0065] 1. Trend Prediction: An exponential smoothing algorithm is used to predict the sliding time window data sequence of various operating state parameters. The exponential smoothing coefficient is determined from a preset smoothing coefficient configuration based on the equipment type. This coefficient is preset solely based on the response characteristics of the equipment's physical attributes (such as sensors, controllers, and actuators) and does not involve commercial or subjective factors. The compensation coefficient is determined based on the data importance level (critical / important / general). This level is based on the functional role of industrial equipment in the process flow and has objective industrial semantics.

[0066] 2. Channel Switching: The weighted expected load value is calculated by combining the predicted network latency trend with the current load status of the channel. The corrected load sensitivity coefficient is linearly scaled based only on the importance level of the data. Its core decision logic is to "direct the data to the channel with the lowest expected load and the lowest sensitivity". This logic is entirely based on network resource optimization and does not contain any non-technical strategies.

[0067] 3. Congestion Handling: The step size correction coefficient and idle connection timeout are both determined based on a two-dimensional mapping table between congestion level and data importance level. The congestion level is quantified by the extent to which the trend prediction value exceeds the congestion threshold; this quantification process is a pure numerical comparison. The idle connection timeout shortening strategy prioritizes low-importance devices, aiming to ensure core business connections when resources are limited, which is a standard technical means of system resource management. None of the above algorithms incorporate decision-making logic that violates laws or social ethics; all parameter configurations and adjustments serve the purely technical purpose of gateway system stability and data transmission efficiency.

[0068] The remote management module is used to establish a long connection with the remote management server in the cloud platform through a reverse HTTP proxy, receive remote HTTP requests and forward them to the local service on a preset port, and receive protocol configuration data issued by the remote management server and forward it to the protocol management module. The protocol configuration data includes protocol plugins, protocol fingerprint feature library or protocol rule updates, so as to realize remote secure access to the gateway and dynamic expansion of protocol capabilities.

[0069] Among them, the reverse HTTP proxy is an intermediate proxy service deployed on the cloud platform, responsible for receiving external HTTP requests and forwarding them to the internal gateway. The persistent connection is a TCP connection that remains open after establishment. The remote management server is a server-side component in the cloud platform that provides remote management functionality for the gateway. The protocol configuration data includes protocol rule update packets, fingerprint database extension data, and connection parameter configuration information issued by the remote management platform. The local service is the internal management interface running on a preset port on the gateway.

[0070] The necessary procedures are as follows:

[0071] When the gateway starts, it initiates a connection establishment request to the reverse HTTP proxy deployed on the cloud platform, negotiates an encrypted channel through a TLS handshake (such as using the TLS 1.3 protocol with two-way certificate authentication), and establishes a long connection with the remote management server (such as using the HTTP / 2 protocol with multiplexing enabled).

[0072] The reverse HTTP proxy receives remote HTTP requests from the remote management server and forwards them to the gateway through an established long-connection tunnel. The gateway parses the target path of the request, uses a regular expression matching algorithm to extract the local service port number (such as 8080, 9090), and forwards the request to the local service on the preset port. The specific process is as follows: by matching the service identifier in the URL path, the routing table is queried to determine the target port, a local socket connection is established, and the HTTP message is transparently transmitted.

[0073] After the local service processes the request and returns a response, the gateway sends the response back to the reverse HTTP proxy through a long connection tunnel. The proxy then forwards the response to the remote management server, completing the request-response loop.

[0074] When the remote management server distributes protocol configuration data, the gateway receives the configuration update packet via a long connection and parses the configuration data type identifier (such as rule updates, fingerprint database expansion, and connection parameters). A message routing algorithm is then used to forward the protocol configuration data to the protocol management module. The specific process is as follows: based on the target module field in the message header, the module registry is queried to determine the entry address of the protocol management module. The configuration data is then delivered through the internal message bus, enabling secure remote access and dynamic configuration management of the gateway.

[0075] In one embodiment, when the above-mentioned protocol management module is configured to perform protocol identification and dynamic loading functions, it acquires communication data of industrial equipment, extracts protocol feature vectors, and identifies protocol types through a two-layer mechanism of automatic similarity matching and rule base back-off matching, including:

[0076] Step S11: Obtain communication data from industrial equipment and extract protocol feature fields to construct a communication protocol feature vector. The protocol feature fields include message format features, register address features, and communication timing features.

[0077] The message format characteristics include: structural identification information of the protocol data frame, including the frame header identifier, frame length field position, and byte order mode. Register address characteristics include: addressing information of the industrial equipment's data storage area, including the default register start address and address encoding bit length. Communication timing characteristics include: timing parameters during protocol interaction, including request-response interval and inter-byte timeout threshold.

[0078] The necessary procedures are as follows:

[0079] The gateway captures communication data from industrial devices through physical interfaces (such as RS-485 and Ethernet ports). It then performs layer-by-layer parsing to extract protocol feature fields: identifying the frame start position to determine the frame header identifier (e.g., Modbus RTU is 0x01-0xFF device address); parsing the frame length field position and byte order mode (e.g., big-endian / little-endian) as message format features; scanning the data field to locate the register addressing field; extracting the default register start address (e.g., 0x0000) and address encoding bits (e.g., 16 bits) as register address features; and measuring the time interval between the sending of the request message and the receiving of the response message (e.g., a typical value of 10-100ms) as communication timing features.

[0080] After the feature fields are extracted, a feature vectorization algorithm is used to construct the communication protocol feature vector. The specific process is as follows: the three types of extracted feature fields are numerically encoded (e.g., the frame header identifier is mapped to discrete code 0-255, and the timing feature is normalized to millisecond value), and combined according to fixed dimensions to form a multi-dimensional feature vector (e.g., [message format encoding, register address encoding, timing normalized value]), which is used as the input for subsequent protocol identification and matching.

[0081] Step S12: Calculate the similarity between the communication protocol feature vector and the features of each standard protocol in the preset protocol fingerprint feature library to obtain multiple similarity values.

[0082] Among them, the protocol fingerprint feature library is a structured database that pre-stores feature vectors of standard industrial protocols. The similarity value is a quantitative indicator representing the degree of matching between observed feature vectors and standard protocol feature vectors.

[0083] The necessary procedures are as follows:

[0084] The gateway loads the protocol fingerprint feature library from the storage medium and obtains the feature vectors of each standard protocol in the library (such as Modbus RTU feature vector [0.85, 0.12, 0.45], Modbus TCP feature vector [0.92, 0.34, 0.67]). The similarity between the communication protocol feature vector constructed in step S11 and the feature vectors of each standard protocol in the library is calculated.

[0085] The cosine similarity algorithm is used to calculate the similarity value. The specific process is as follows: Calculate the dot product of the two vectors and divide it by the product of their respective Euclidean norms to obtain a similarity value in the range [0,1]. The closer the value is to 1, the higher the degree of matching. Traverse all standard protocol records in the protocol fingerprint feature library to obtain a set of similarity values ​​(such as {0.92, 0.45, 0.23, ...}), which serves as the basis for automatic matching determination in step S13.

[0086] Step S13: When any similarity value is greater than or equal to the preset first matching threshold, automatic matching is determined to be successful, and the protocol type determined by the standard protocol feature corresponding to the similarity value is used as the matching result; when all similarity values ​​are less than the first matching threshold, automatic matching is determined to be unsuccessful.

[0087] The first matching threshold is the similarity threshold (e.g., 0.85) used to determine successful matching during the automatic matching phase. Automatic matching success is defined as a state where the observed features highly match the standard protocol features. Automatic matching failure is defined as a state where the similarity between the observed features and all standard protocol features is below the threshold.

[0088] The necessary procedures are as follows:

[0089] The gateway extracts the maximum value (e.g., 0.92) from the similarity value set obtained in step S12. A first matching threshold (e.g., 0.85) is set, and the maximum value is compared with the threshold to determine the match: if the maximum value is greater than or equal to the first matching threshold, automatic matching is considered successful, and the protocol type (e.g., Modbus TCP) determined by the standard protocol characteristics corresponding to the maximum value is used as the matching result; if the maximum value is less than the first matching threshold, automatic matching is considered unsuccessful, triggering the fallback matching process in step S15.

[0090] Step S14: If the automatic matching is successful, the corresponding protocol plugin is dynamically loaded from the protocol plugin library based on the matching result.

[0091] Step S15: If automatic matching fails, start the protocol fallback matching algorithm based on the rule base. Calculate the matching degree between the communication protocol feature vector and each protocol rule in the preset rule base. When any matching degree value is greater than or equal to the preset second matching threshold, the fallback matching is determined to be successful, and the protocol type determined by the protocol rule corresponding to the matching degree value is used as the matching result; the second matching threshold is less than the first matching threshold.

[0092] The system comprises: a rule base containing a set of rules based on protocol expert knowledge, using a condition-action format to describe protocol feature discrimination logic; a matching degree calculation based on a comprehensive score of rule weights and condition satisfaction; and a second matching threshold, a critical value for determining successful matching during the fallback matching phase, set below the first matching threshold to relax matching conditions.

[0093] The necessary procedures are as follows:

[0094] The gateway loads a preset rule base, which contains multiple protocol rules (e.g., rule R1: conditions are frame header range 0x01-0xF0 and function code 0x03, action is to determine Modbus RTU, weight 0.8). The communication protocol feature vector is matched against each rule condition, and a weighted condition satisfaction algorithm is used to calculate the matching degree. The specific process is as follows:

[0095] Calculate the degree of satisfaction of the conditions :

[0096] ;

[0097] In the formula, For the first The condition satisfaction degree of the rule (dimensionless, value range [0,1]). For the first The total number of conditions for the rule. For the first The weights of each condition (dimensionless, value range [0,1]). This is an indicator function that satisfies the condition (1 if satisfied, 0 if not satisfied, dimensionless).

[0098] Calculate matching degree :

[0099] ;

[0100] In the formula, For the first The matching degree of each rule (dimensionless, value range [0,1]). For the first The weight of each rule (dimensionless, value range [0,1]).

[0101] Iterate through all rules to obtain a matching score set and extract the maximum value (e.g., 0.72). Set a second matching threshold (e.g., 0.60, where 0.60 < 0.85), and compare the maximum value with the second matching threshold: if the maximum value is greater than or equal to the second matching threshold, the fallback matching is considered successful, and the protocol type determined by the protocol rule corresponding to the matching score is taken as the matching result, and the fallback matching success processing in step S16 is executed; if the maximum value is less than the second matching threshold, the fallback matching is considered unsuccessful, a protocol exception log is generated, and the unknown protocol processing flow is executed.

[0102] Step S16: If the rollback matching is successful, the corresponding protocol plugin is dynamically loaded from the protocol plugin library based on the matching result, and the protocol feature corresponding to the matching result is added to the protocol fingerprint feature library as a new standard protocol feature; if the rollback matching fails, a protocol exception log is generated, the communication protocol feature vector is uploaded to the remote management platform as an unknown protocol feature, and a preset protocol update package is received from the remote management platform to update the protocol fingerprint feature library according to the new protocol feature in the update package.

[0103] The protocol plugin library stores a collection of files representing the dynamic link libraries of various protocol parsing engines. New standard protocol features are protocol features that have been verified as valid through fallback matching, used to expand the protocol fingerprint feature library. Protocol exception logs are diagnostic files that record matching failure events and feature information. Protocol update packages are data packets containing new protocol features and rules issued by the remote management platform.

[0104] The necessary procedures are as follows:

[0105] If the fallback match is successful, the gateway, based on the protocol type determined by the matching result (e.g., Profinet), locates the corresponding protocol plugin file (e.g., profinet_parser.so) from the protocol plugin library and performs a dynamic loading operation: calling the operating system's dynamic link library loading API, initializing the parsing handle, and registering it with the protocol management engine. Simultaneously, the protocol feature vector and protocol type of the successfully matched protocol are encapsulated as a new record and added to the protocol fingerprint feature library using a database insertion operation, enabling the feature library to expand self-sustainingly.

[0106] If the fallback matching fails, the gateway generates a protocol exception log, recording the timestamp of the matching failure, the device identifier, and the communication protocol feature vector. This communication protocol feature vector is treated as an unknown protocol feature, encapsulated using JSON serialization, and then encrypted and transmitted to the remote management platform via an HTTPS POST request. The gateway receives protocol update packets from the remote management platform, parses the new protocol feature vector and corresponding protocol type within the packet, and updates the protocol fingerprint feature database using a database insertion operation, thus achieving remote dynamic upgrades to the gateway's protocol recognition capabilities.

[0107] In one embodiment, based on the aforementioned protocol identification results, when the data acquisition module is configured to perform differentiated connection and batch acquisition functions, it establishes a connection with the industrial equipment through the loaded protocol plugin, and configures the connection pool differently according to the protocol identification results and reuses the connections within the pool, including:

[0108] Step S211: Based on the matching results identified by the protocol, assign differentiated connection pool configurations to different industrial devices.

[0109] Among them, the differentiated connection pool configuration is a set of differentiated connection parameters set for different protocol matching results.

[0110] The necessary procedures are as follows:

[0111] The gateway queries the matching result records of the protocol identification output to obtain the protocol matching method identifier (e.g., auto for automatic matching, fallback for fallback matching) and protocol type of each industrial device. Based on the protocol matching method identifier, it assigns the corresponding connection pool configuration template to the device: when the matching method is auto, a standard connection configuration template is assigned (connection timeout 5 seconds, 3 retries, 10 concurrent connections, heartbeat interval 30 seconds); when the matching method is fallback, a conservative connection configuration template is assigned (connection timeout 15 seconds, 5 retries, 3 concurrent connections, heartbeat interval 10 seconds). A mapping table is established between device identifiers and connection pool configurations to achieve differentiated connection pool configuration allocation and management.

[0112] Step S212: When the protocol type is successfully determined through automatic matching, the connection in the connection pool is reused using the preset standard connection configuration.

[0113] Among them, the standard connection configuration is an optimized connection parameter set for high-confidence protocol identification results.

[0114] The necessary procedures are as follows:

[0115] When the protocol matching mode is set to "auto" in step S211, the gateway loads the standard connection configuration template. It obtains an available connection handle from the connection pool, using a first-in-first-out (FIFO) algorithm to retrieve a connection from the head of the queue. A TCP session is established with the industrial device using this connection handle, and socket options are set (e.g., enabling TCP_NODELAY to disable the Nagle algorithm and reduce latency, and setting SO_KEEPALIVE to enable system-level heartbeat detection). A protocol handshake is performed: a protocol identification frame is sent, and the device's response is awaited, verifying that the response frame format matches the protocol type. After a successful handshake, the connection status is marked as "active," and data acquisition operations are performed.

[0116] Step S213: When the protocol type is successfully determined through fallback matching, the connection in the connection pool is reused using the preset conservative connection configuration.

[0117] Among them, conservative connection configuration: robust connection parameters set for low-confidence protocol identification results, including extending connection timeout, increasing the number of retries, limiting the number of concurrent connections, and shortening the heartbeat detection interval.

[0118] The necessary procedures are as follows:

[0119] When the protocol matching method in step S211 is marked as fallback, the gateway loads the conservative connection configuration template (connection timeout 15 seconds, maximum number of retries 5, number of concurrent connections 3, heartbeat detection interval 10 seconds).

[0120] Available connection handles are obtained from the connection pool, and a last-in-first-out (LIFO) algorithm is used to obtain connections from the tail of the queue, prioritizing connections with shorter creation times to reduce potential timeout risks.

[0121] Establish a TCP session with industrial equipment using this connection handle, and set socket options: enable the Nagle algorithm (disable TCP_NODELAY) to merge small packets, reduce the number of transmissions, and improve stability; set SO_KEEPALIVE to enable system-level keep-alive detection, and configure a custom heartbeat detection interval of 10 seconds to detect connection anomalies more quickly.

[0122] Perform a protocol handshake: Send a protocol identification frame and wait for a device response. If the response times out, retry according to the conservatively configured number of retries (5 times). The interval between each retry increases exponentially using a backoff algorithm (e.g., 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds). Verify that the response frame format matches the protocol type. After a successful handshake, mark the connection status as active but add a fallback flag.

[0123] Perform data acquisition operations and simultaneously start a connection quality monitoring thread to periodically record connection response time and protocol plugin response time, providing a time-series data basis for anomaly determination in step S214.

[0124] Step S214: Monitor the connection response time and protocol plugin response time of devices using conservative connection configuration in real time. When the connection response time exceeds the preset response threshold or the number of consecutive failures exceeds the preset failure threshold, trigger the protocol adaptation update mechanism, upload the communication protocol feature vector corresponding to the device to the remote management platform for protocol rule correction, and switch the connection configuration of the device to the standard connection configuration. Use the connection in the connection pool for verification and collection to confirm the effect of protocol rule correction.

[0125] Among them, connection response time: the time interval from sending a connection request to establishing a complete TCP session. Protocol plugin response time: the time interval from sending an identification frame to receiving a complete response frame during the protocol handshake phase. Preset response threshold: the critical value for response time used to determine connection anomalies. Preset failure threshold: the critical value for the number of consecutive failures used to determine connection instability. Protocol adaptation and update mechanism: a closed-loop processing flow for rule optimization and verification of the fallback matching protocol.

[0126] The necessary procedures are as follows:

[0127] The gateway establishes an independent monitoring thread for each device using a conservative connection configuration, periodically collecting connection response time and protocol plugin response time. A sliding window statistical algorithm is used to calculate connection quality metrics, specifically as follows: a fixed-length (e.g., the most recent 10 responses) response time sequence is maintained, and the arithmetic mean of this sequence is calculated as the current connection response time baseline. Simultaneously, the percentage of timeouts within the window is statistically analyzed. When this baseline exceeds a preset response threshold (5000 milliseconds) or the consecutive failure count reaches a preset failure threshold (3 times), a protocol adaptation update mechanism is triggered.

[0128] Upon triggering, the gateway encapsulates the device's communication protocol feature vector using JSON serialization and transmits it to the remote management platform via an encrypted HTTPS POST request. The request content includes the device identifier, current protocol type, historical response time sequence, and failure event logs. The remote management platform corrects the protocol rules based on the uploaded feature vector, generates a protocol rule update package, and sends it to the gateway.

[0129] After receiving the update packet, the gateway switches the device's connection configuration from conservative to standard. It then uses a first-in, first-out (FIFO) algorithm to retrieve a new connection handle from the head of the connection pool queue and re-establishes a communication session with the device based on standard connection parameters (5-second connection timeout, 3 retries). Verification data collection is then performed: data points are continuously collected within a preset verification period (e.g., 5 minutes). The protocol parsing success rate and average response time are calculated. When the success rate reaches a preset verification threshold (e.g., 98%) and the average response time is lower than a preset response threshold, the protocol rule correction is confirmed as effective. The device's protocol matching method identifier is updated to "auto," and the protocol fingerprint feature library is updated synchronously. If verification fails, the gateway reverts to the conservative connection configuration and triggers the protocol adaptation update mechanism again.

[0130] In one embodiment, when the data acquisition module is configured to perform differentiated connection and batch acquisition functions, it allocates differentiated acquisition frequencies to different industrial devices based on the protocol type, its corresponding device type, and data importance level, using a preset frequency reference and step size, including:

[0131] Step S221: Based on the protocol type, its corresponding device type, and data importance level, set the basic acquisition frequency, maximum acquisition frequency, and minimum acquisition frequency for each industrial device, and initially set the acquisition frequency to the basic acquisition frequency.

[0132] The base sampling frequency is the default sampling frequency under normal operating conditions. The maximum sampling frequency is the highest sampling frequency allowed when the device data changes drastically. The minimum sampling frequency is the lowest sampling frequency allowed when the device data is stable.

[0133] The necessary procedures are as follows:

[0134] The gateway loads a preset frequency configuration table, which uses protocol type, device type, and data importance level as three-dimensional index keys. A multi-dimensional lookup algorithm is used to determine the frequency parameters of each device. The specific process is as follows: Based on the protocol type determined in step S13 or S14, the protocol family configuration block is located. Within this block, the device category sub-table is filtered according to device type (e.g., sensor, actuator, controller). Then, the corresponding record is extracted from the sub-table according to the data importance level (e.g., critical, important, general). This record contains three field values: basic acquisition frequency, maximum acquisition frequency, and minimum acquisition frequency (e.g., for a critical temperature sensor, the basic frequency is 1Hz, the maximum frequency is 5Hz, and the minimum frequency is 0.2Hz).

[0135] After determining the frequency parameters, the three extracted frequency values ​​are written into the device configuration register to establish a mapping relationship between the device identifier and the frequency parameters, thus completing the differentiated frequency reference setting.

[0136] Step S222: Collect data points from each industrial device in real time and calculate their rate of change and fluctuation amplitude.

[0137] Among them, the rate of change is the relative change in the data point values ​​between two adjacent collection periods. The fluctuation range is the maximum absolute deviation of the data point values ​​from their mean within a set time window.

[0138] The necessary procedures are as follows:

[0139] The gateway triggers the acquisition task based on the basic acquisition frequency set in step S221, and reads the data points from the device registers through the established communication connection. The rate of change is calculated using a differential algorithm, and the specific process is as follows: obtain the data point value at the current acquisition time and the data point value in the previous acquisition cycle, calculate the absolute value of the difference between the two and divide it by the value of the previous cycle (if the value of the previous cycle is zero, use the current value as the denominator), and obtain the quantized value of the rate of change.

[0140] The sliding window extreme value algorithm is used to calculate the fluctuation amplitude. The specific process is as follows: Maintain a numerical sequence of fixed length (e.g., the most recent 20 data points), calculate the arithmetic mean of the sequence as the baseline mean, iterate through the absolute values ​​of the differences between each value in the sequence and the baseline mean, and extract the maximum value as the current fluctuation amplitude. The calculated rate of change and fluctuation amplitude are temporarily stored in the device status buffer for subsequent frequency adjustment decisions.

[0141] Step S223: When the rate of change exceeds the preset upper limit threshold of the rate of change based on the protocol type and device type for a number of consecutive times, and reaches the preset up-frequency counting threshold, the sampling frequency is gradually increased according to the preset up-frequency step size until the highest sampling frequency is reached.

[0142] Among them, the upper limit threshold for rate of change is the critical rate of change value for determining drastic data changes. The preset upsampling count threshold is the number of consecutive exceedances required to trigger an increase in the acquisition frequency. The preset upsampling step size is the amount by which the acquisition cycle is shortened during a single frequency adjustment.

[0143] The necessary procedures are as follows:

[0144] The gateway reads the current rate of change sequence from the device status buffer and uses a continuous counting algorithm to determine the frequency increase condition. The specific process is as follows: Initialize the continuous exceedance counter to zero, traverse the rate of change records in the most recent collection period, and increment the counter when the rate of change value is greater than the upper limit threshold of the rate of change obtained from the preset threshold table based on the protocol type and device type (e.g., 15% for Modbus RTU protocol temperature sensors); otherwise, clear the counter to zero. When the counter value reaches the preset frequency increase counting threshold (e.g., 3 times), it is determined that the frequency increase condition is met.

[0145] Once the upsampling conditions are met, the gateway reads the current sampling frequency and the highest sampling frequency from the device configuration register, and adjusts the sampling frequency using a step-decreasing algorithm. The specific process is as follows: the current sampling period is shortened by a preset upsampling step size (e.g., 0.5Hz), that is, the new sampling frequency is equal to the current sampling frequency plus the preset upsampling step size, the device configuration register is updated and takes effect immediately; the above judgment and adjustment process is repeated until the current sampling frequency reaches the highest sampling frequency set in step S221 or the upsampling conditions are no longer met.

[0146] Step S224: When the number of times the rate of change is continuously lower than the preset lower limit threshold of the rate of change according to the protocol type and device type reaches the preset frequency reduction counting threshold, and the fluctuation amplitude is lower than the preset fluctuation threshold according to the protocol type and device type, the sampling frequency is gradually reduced according to the preset frequency reduction step size until the minimum sampling frequency is reached.

[0147] Among them, the lower limit threshold for rate of change is the critical rate of change value for determining that the data change is gradual. The preset frequency reduction count threshold is the number of consecutive low rate of change required to trigger a reduction in the acquisition frequency. The fluctuation threshold is the critical fluctuation amplitude value for determining data stability. The preset frequency reduction step size is the amount by which the acquisition period is extended during a single frequency adjustment.

[0148] The necessary procedures are as follows:

[0149] The gateway reads the current rate of change sequence and fluctuation amplitude value from the device status buffer and uses a dual-condition joint judgment algorithm to detect the frequency reduction condition. The specific process is as follows: Initialize the continuous low rate of change counter to zero, traverse the rate of change records in the most recent collection period, and increment the counter when the rate of change value is less than the lower limit threshold of the rate of change obtained from the preset threshold table based on the protocol type and device type (e.g., 5% for Modbus RTU protocol temperature sensors); otherwise, reset the counter to zero. At the same time, determine whether the current fluctuation amplitude is lower than the preset fluctuation threshold (e.g., 2%). When the counter value reaches the preset frequency reduction counting threshold (e.g., 5 times) and the fluctuation amplitude is lower than the fluctuation threshold, the frequency reduction condition is determined to be met.

[0150] Once the frequency reduction condition is met, the gateway reads the current sampling frequency and the minimum sampling frequency from the device configuration register, and adjusts the sampling frequency using a step-increment algorithm. The specific process is as follows: the current sampling period is extended by a preset frequency reduction step size, that is, the new sampling frequency is equal to the current sampling frequency plus the preset frequency reduction step size, the device configuration register is updated and takes effect immediately; the above judgment and adjustment process is repeated until the current sampling frequency reaches the minimum sampling frequency set in step S221 or the frequency reduction condition is no longer met.

[0151] In one embodiment, when the data acquisition module is configured to perform differentiated connection and batch acquisition functions, obtaining raw data by batch reading and writing data points according to a preset batch size includes:

[0152] Step S231: Dynamically adjust the preset batch size according to the rate of change and / or fluctuation amplitude.

[0153] The preset batch size is the number of data points read in a single data acquisition operation.

[0154] The necessary procedures are as follows:

[0155] The gateway reads the current rate of change and fluctuation amplitude from the device status cache and uses a conditional branch decision algorithm to determine the batch adjustment strategy. The specific process is as follows: when the rate of change exceeds the upper limit threshold of the rate of change preset according to the protocol type and device type, it is determined that the data is changing drastically and the batch reduction strategy is executed; when the rate of change is lower than the lower limit threshold of the rate of change and the fluctuation amplitude is lower than the fluctuation threshold, it is determined that the data is stable and the batch increase strategy is executed; otherwise, the current batch size remains unchanged.

[0156] Based on the data importance level, the batch reduction step size or batch increment step size is retrieved from the preset step size configuration table (50 points for critical equipment, 100 points for increment; 20 points for general equipment, 50 points for reduction, 50 points for increment). The new batch size is calculated: when executing the batch reduction strategy, the new batch size equals the current batch size minus the batch reduction step size; when executing the batch increase strategy, the new batch size equals the current batch size plus the batch increment step size. The new batch size is written to the device configuration register, and the next acquisition cycle reads batch data according to the new batch size.

[0157] Step S232: When the rate of change exceeds the upper limit threshold of the rate of change preset according to the protocol type and device type, the preset batch size is reduced according to the preset batch reduction step size to improve the real-time response speed.

[0158] Among them, preset batch reduction step size: the amount by which the batch size is reduced in a single adjustment. Real-time acquisition density: the number of data points acquired per unit time.

[0159] The necessary procedures are as follows:

[0160] The gateway reads the current rate of change from the device status cache and uses a threshold comparison algorithm to determine the adjustment conditions. The specific process is as follows: the current rate of change is compared with the upper limit threshold of the rate of change obtained from the preset threshold table based on the protocol type and device type. When the rate of change is greater than the threshold, it is determined that the batch reduction condition is met.

[0161] Once the conditions are met, the gateway reads the current preset batch size from the device configuration register and calculates the new batch size using a reduction adjustment algorithm. The specific process is as follows: Based on the data importance level, the preset batch reduction step size is retrieved from the preset step size configuration table (50 points for critical devices, 30 points for important devices, and 20 points for general devices). The current batch size is reduced by this step size, meaning the new batch size equals the current batch size minus the preset batch reduction step size. The minimum batch size is limited to 1 point to prevent invalid configurations. The new batch size is written to the device configuration register, and the next collection cycle performs batch data reading according to the reduced batch size, shortening the single collection interval and improving real-time response speed.

[0162] Step S233: When the rate of change is lower than the lower limit threshold of the rate of change preset according to the protocol type and device type and the fluctuation amplitude is lower than the fluctuation threshold preset according to the protocol type and device type, the preset batch size is increased according to the preset batch increment step size to improve data compression efficiency.

[0163] Among them, the preset batch increment step size is the amount by which the batch size is increased in a single adjustment. Data compression efficiency is the percentage of effective data transmitted per unit of network overhead in batch acquisition mode.

[0164] The necessary procedures are as follows:

[0165] The gateway reads the current rate of change and fluctuation amplitude from the device status cache and uses a dual-condition joint judgment algorithm to detect the increase condition. The specific process is as follows: the current rate of change is compared with the lower limit threshold of the rate of change obtained from the preset threshold table based on the protocol type and device type. At the same time, the current fluctuation amplitude is compared with the preset fluctuation threshold. When the rate of change is less than the lower limit threshold of the rate of change and the fluctuation amplitude is less than the fluctuation threshold, it is determined that the batch increase condition is met.

[0166] Once the conditions are met, the gateway reads the current preset batch size from the device configuration register and calculates the new batch size using an incremental adjustment algorithm. The specific process is as follows: Based on the data importance level, the preset batch increment step size is retrieved from the preset step size configuration table (100 points for critical devices, 60 points for important devices, and 50 points for general devices). The current batch size is increased by this step size, meaning the new batch size equals the current batch size plus the preset batch increment step size. The maximum batch size is limited to the upper limit of a single read from the device register (e.g., 2000 points) to prevent memory overflow. The new batch size is written to the device configuration register. In the next collection cycle, batch data is read according to the increased batch size, reducing the protocol overhead per unit data volume to improve data compression efficiency.

[0167] In one embodiment, when the aforementioned status monitoring module is configured to perform trend prediction and congestion handling functions, the trend prediction values ​​of each parameter in the next time window are obtained by time-series analysis of the operating status parameters based on a preset trend analysis strategy, including:

[0168] Step S511: Obtain the running status parameters collected in real time by the status monitoring module, construct a sliding time window data sequence for each running status parameter, and determine the length of each sliding time window from the preset window length configuration according to the protocol type.

[0169] Among them, the operating status parameters are quantitative indicators characterizing the operating status of the gateway system, including CPU utilization, memory utilization, network latency, and data queue depth. The sliding time window data sequence is a fixed-length set of historical parameter values ​​arranged in chronological order.

[0170] The necessary procedures are as follows:

[0171] The gateway periodically collects running status parameters through system call interfaces and uses a circular buffer algorithm to construct a sliding time window data sequence. The specific process is as follows: allocate a fixed-length circular buffer (e.g., CPU utilization buffer length 100) for each running status parameter, write the newly collected parameter value to the head of the buffer, and overwrite the oldest written data when the buffer is full, always maintaining the parameter value sequence of the most recent N time points.

[0172] The window length is determined using a lookup table algorithm, as follows: Based on the protocol type used by the current device, the corresponding window length value is extracted from the preset window length configuration table (e.g., window length 100 for Modbus RTU protocol, 80 for Modbus TCP protocol, and 120 for Profinet protocol). This value is then set as the length of the corresponding running status parameter sliding time window data sequence, i.e., the effective data capacity of the circular buffer. When the protocol type changes, the corresponding window length is dynamically adjusted and the circular buffer is reinitialized.

[0173] Step S512: For each operating status parameter, determine the corresponding exponential smoothing coefficient from the preset smoothing coefficient configuration according to the device type, and calculate the initial trend prediction value of the parameter in the next time window based on the sliding time window data sequence of the parameter using the exponential smoothing algorithm.

[0174] Among them, the exponential smoothing coefficient is a smoothing parameter that controls the rate at which the weights of historical data decay, and its value ranges from 0 to 1. The initial trend forecast value is the trend forecast result without compensation coefficient correction.

[0175] The necessary procedures are as follows:

[0176] The gateway reads the device type identifier from the device configuration register and uses a lookup table algorithm to determine the exponential smoothing coefficient. The specific process is as follows: Based on the device type, the corresponding exponential smoothing coefficient is extracted from the preset smoothing coefficient configuration table (0.3 for sensors, 0.5 for actuators, and 0.4 for controllers).

[0177] The initial trend forecast value is calculated using the exponential smoothing algorithm. The specific process is as follows: The first data value of the sliding time window data sequence is used as the initial smoothing value, and the smoothing values ​​at each time point are calculated sequentially according to the exponential smoothing recursion rule.

[0178] ;

[0179] In the formula, for The exponentially smoothed value at time 1, is the exponential smoothing coefficient (dimensionless, value range [0,1]). The actual observed value at time t (the units are consistent with the parameter type, such as CPU utilization as a percentage and network latency in milliseconds). for Exponential smoothing value at time (dimensions and) Consistent).

[0180] Traverse to the end of the sequence and take the final smoothed value as the initial trend prediction value for this parameter in the next time window:

[0181] ;

[0182] In the formula, This is the initial trend forecast value (with dimensions consistent with the original parameters). For the end of the window (the first) The exponentially smoothed value at time ( ), The length of the sliding window is dimensionless.

[0183] The calculation results are written to the trend prediction cache for subsequent compensation and correction.

[0184] Step S513: Determine the compensation coefficient from the preset compensation coefficient configuration according to the data importance level, correct the initial trend prediction value of each operating status parameter, and obtain the trend prediction value of each operating status parameter in the next time window.

[0185] Among them, the compensation coefficient is an adjustment parameter used to weight and correct the initial trend forecast value according to the importance level of the data.

[0186] The necessary procedures are as follows:

[0187] The gateway reads the data importance level identifier from the device configuration register and uses a lookup table algorithm to determine the compensation coefficient. The specific process is as follows: Based on the data importance level (critical, important, and general), the corresponding compensation coefficient is extracted from the preset compensation coefficient configuration table (critical level corresponds to 1.2, important level corresponds to 1.0, and general level corresponds to 0.8).

[0188] The weighted correction algorithm is used to calculate the trend prediction value. The specific process is as follows: The initial trend prediction value obtained in step S512 is multiplied by the compensation coefficient to obtain the corrected trend prediction value, that is, the trend prediction value is equal to the product of the initial trend prediction value and the compensation coefficient. The corrected trend prediction values ​​of each operating state parameter are written into the trend prediction result register as input data for subsequent congestion determination and channel switching decisions.

[0189] In one embodiment, when the aforementioned status monitoring module is configured to perform trend prediction and congestion handling functions, when the congestion level exceeds a preset switching threshold, switching the corresponding channel data to a preset low-load channel for uploading based on a preset scheduling strategy corresponding to the protocol type includes:

[0190] Step S521: Based on the preset parameter type identifier, extract the trend prediction value corresponding to the network latency from the trend prediction value of each running status parameter in the next time window.

[0191] Among them, the preset parameter type identifier is a coded identifier that distinguishes different operating status parameter types.

[0192] The necessary procedures are as follows:

[0193] The gateway loads a preset parameter type identifier mapping table, which defines the correspondence between various operating status parameters and type identifiers (e.g., CPU utilization is identified as 0x01, memory utilization as 0x02, network latency as 0x03, and data queue depth as 0x04). A identifier matching algorithm is used to extract target parameters. The specific process is as follows: Each record in the trend prediction result register is traversed, and the parameter type identifier field in the record is compared with the preset parameter type identifier 0x03 corresponding to network latency. When a match is successful, the trend prediction value field in that record is extracted, and the extracted result is temporarily stored as the trend prediction value corresponding to network latency in the channel selection decision cache.

[0194] Step S522: Determine the list of candidate channels from the preset channel configuration according to the protocol type, and preset the basic load threshold and initial load sensitivity coefficient for each candidate channel.

[0195] The optional channel list is a set of data transmission channels available for a specific protocol type. The basic load threshold is the load threshold used to determine a channel's high load state. The initial load sensitivity coefficient is a benchmark parameter characterizing the channel's sensitivity to load changes; a higher coefficient indicates a faster performance degradation (worse stability) as the load increases, while a lower coefficient indicates a less sensitive channel (better stability).

[0196] The necessary procedures are as follows:

[0197] The gateway reads the current protocol type from the device configuration register and uses a lookup table algorithm to determine the list of candidate channels. The specific process is as follows: Based on the protocol type, the corresponding record is extracted from the preset channel configuration table. This record contains a list of candidate channel identifiers supported by the protocol (such as channel A, channel B, and channel C for the Modbus TCP protocol).

[0198] The channel parameters are configured using an initialization assignment algorithm. The specific process is as follows: Iterate through each channel identifier in the candidate channel list, extract the basic load threshold (e.g., 80% for channel A, 75% for channel B, and 85% for channel C) and the initial load sensitivity coefficient (e.g., 0.5 for channel A, 0.6 for channel B, and 0.4 for channel C) from the preset channel configuration table, write the extracted parameter values ​​into the configuration register of the corresponding channel, and establish a mapping relationship between the channel identifier and the basic load threshold and the initial load sensitivity coefficient.

[0199] Step S523: Based on the data importance level, the initial load sensitivity coefficient is corrected using a preset correction coefficient, wherein the higher the data importance level, the lower the corrected load sensitivity coefficient.

[0200] Among them, the preset correction coefficient is a multiplicative factor that adjusts the initial load sensitivity coefficient according to the importance level of the data.

[0201] The necessary procedures are as follows:

[0202] The gateway reads the data importance level identifier from the device configuration register and calculates the corrected load sensitivity coefficient using a reverse correction algorithm. The specific process is as follows: Based on the data importance level, the gateway extracts the corresponding preset correction coefficient from the preset correction coefficient configuration table (0.6 for critical level, 0.8 for important level, and 1.0 for general level). It then iterates through each channel in the candidate channel list, multiplying the initial load sensitivity coefficient of that channel by the preset correction coefficient to obtain the corrected load sensitivity coefficient. In other words, the corrected load sensitivity coefficient equals the initial load sensitivity coefficient multiplied by the preset correction coefficient. The correction result is then updated to the configuration register of the corresponding channel. Critical level data, due to its smallest correction coefficient, receives the lowest load sensitivity coefficient, and high-load channels are prioritized to ensure real-time transmission.

[0203] Step S524: Based on the trend prediction of network latency, the current load status of each candidate channel, and the corrected load sensitivity coefficient, calculate the weighted expected load value of each candidate channel in the next time window.

[0204] Among them, the current load status is the real-time load percentage of the candidate channels. The weighted expected load value is a channel load prediction indicator that comprehensively considers the impact of network latency and load sensitivity.

[0205] The necessary procedures are as follows:

[0206] The gateway collects the current load status of each candidate channel through the channel monitoring interface and calculates the weighted expected load value using a weighted prediction algorithm. The specific process is as follows: For each candidate channel, its current load status and corrected load sensitivity coefficient are read, the network latency trend prediction value obtained in step S521 is obtained, and the weighted expected load value is calculated according to the formula, that is, the weighted expected load value is equal to the current load status plus the corrected load sensitivity coefficient multiplied by the network latency trend prediction value divided by the baseline network latency. The weighted expected load value of each candidate channel is written into the channel evaluation result register as the decision basis for channel selection.

[0207] Step S525: Compare the weighted expected load value with the basic load threshold of the corresponding candidate channel, and filter out candidate channels whose weighted expected load value is lower than the basic load threshold.

[0208] Candidate channels: A subset of alternative channels that meet the load conditions and can be used for data switching.

[0209] The necessary procedures are as follows:

[0210] In gateway traversal step S524, each candidate channel record is written to the channel evaluation result register. A threshold comparison filtering algorithm is used to extract candidate channels. The specific process is as follows: For each candidate channel, its weighted expected load value and basic load threshold are read. The weighted expected load value is compared with the basic load threshold. When the weighted expected load value is less than the basic load threshold, the channel is determined to meet the load condition, and the channel is added to the candidate channel list. When the weighted expected load value is greater than or equal to the basic load threshold, the channel is determined not to meet the load condition and is removed. After traversal, the candidate channel list is written to the channel filtering result register. If the candidate channel list is empty, an alarm is triggered and the current channel is maintained.

[0211] Step S526: Select the channel with the lowest modified load sensitivity coefficient from the candidate channels as the target upload channel, and switch the data to the target upload channel.

[0212] Among them, the target upload channel is the optimal channel for data transmission determined after screening.

[0213] The necessary procedures are as follows:

[0214] The gateway reads the candidate channel list generated in step S525 and uses the minimum value selection algorithm to determine the target upload channel. The specific process is as follows: traverse each channel identifier in the candidate channel list, read the corrected load sensitivity coefficient of the channel from the channel configuration register, compare the corrected load sensitivity coefficient values ​​of each channel, and select the channel with the smallest value as the target upload channel.

[0215] The channel switching is performed using an atomic switching algorithm. The specific process is as follows: After the currently transmitting data frame is sent, new data enqueueing is paused, the transmit buffer is cleared, the channel routing table is updated to map the data stream of the target protocol type to the target upload channel, data enqueueing and transmission are resumed, and the switching event and target channel identifier are recorded in the operation log. After the switching is completed, subsequent standardized device data of this protocol type will be asynchronously transmitted to the cloud platform through the target upload channel.

[0216] In one embodiment, when the aforementioned status monitoring module is configured to perform trend prediction and congestion handling functions, adjusting the differentiated collection frequency according to the congestion level gradient and clearing timed-out idle connections in the connection pool includes:

[0217] Step S531: Obtain the congestion level determined by the status monitoring module, and divide the congestion level into multiple congestion levels according to the preset congestion level classification rules.

[0218] Among them, congestion level: a quantified value of the extent to which the trend prediction value exceeds the congestion threshold. Congestion grade: a discrete hierarchical identifier representing the severity of system congestion.

[0219] The necessary procedures are as follows:

[0220] The gateway reads congestion levels from the status monitoring module and uses an interval mapping algorithm to determine the congestion level. The specific process is as follows: A preset congestion level classification rule is loaded, which defines the correspondence between congestion level ranges and congestion levels (e.g., 0% to 20% congestion corresponds to smooth flow, 20% to 50% to light congestion, 50% to 80% to moderate congestion, 80% to 100% to heavy congestion, and above 100% to severe congestion). The read congestion level values ​​are compared with the boundaries of each interval to determine the interval to which it belongs, and the corresponding congestion level identifier is extracted. The determined congestion level is written to the system status register for subsequent step size adjustments and connection cleanup decisions.

[0221] Step S532: Based on the congestion level and data importance level, determine the corresponding step size correction coefficient from the preset step size correction mapping relationship, wherein the higher the congestion level and the lower the data importance level, the larger the step size correction coefficient.

[0222] Among them, the step size correction coefficient is a multiplicative factor that amplifies and adjusts the preset frequency reduction step size.

[0223] The necessary procedures are as follows:

[0224] The gateway reads the congestion level from the system status register and the data importance level from the device configuration register. A two-dimensional lookup table algorithm is used to determine the step size correction coefficient. The specific process is as follows: using the congestion level as the row index and the data importance level as the column index, a pre-defined step size correction mapping table is consulted (e.g., 1.0 for critical level, 1.2 for general level, 1.5 for critical level, and 2.5 for general level). The step size correction coefficient value corresponding to the intersection of the row and column is extracted. The determined step size correction coefficient is written to the frequency adjustment parameter register for subsequent calculation of the frequency reduction step size.

[0225] Step S533: The preset down-frequency step size is corrected using the step size correction coefficient to obtain the corrected down-frequency step size.

[0226] Among them, the corrected frequency reduction step size is the actual frequency reduction adjustment range after being weighted by the degree of congestion and the importance level of the data.

[0227] The necessary procedures are as follows:

[0228] The gateway reads the step size correction coefficient from the frequency adjustment parameter register and the preset frequency reduction step size from the device configuration register. It then calculates the corrected frequency reduction step size using a multiplication correction algorithm. Specifically, the step size correction coefficient is multiplied by the preset frequency reduction step size to obtain the corrected frequency reduction step size; that is, the corrected frequency reduction step size equals the step size correction coefficient multiplied by the preset frequency reduction step size. The calculated corrected frequency reduction step size is written to the frequency adjustment execution register as the execution parameter for subsequent differentiated acquisition frequency gradient adjustment.

[0229] Step S534: Based on the corrected frequency reduction step size, the differentiated acquisition frequency of devices whose data importance level is lower than the preset importance threshold is gradually reduced towards their corresponding lowest acquisition frequency according to the corrected frequency reduction step size.

[0230] Among them, the preset importance threshold is the critical value for determining the importance level of whether a device should participate in the congestion reduction adjustment.

[0231] The necessary procedures are as follows:

[0232] The gateway reads a preset importance threshold (such as importance level) from the system configuration register, traverses each industrial device, and uses an importance screening algorithm to determine the devices to be downgraded. The specific process is as follows: compare the data importance level of the device with the preset importance threshold. When the data importance level is lower than the preset importance threshold (i.e., the general level is lower than the important level), the device is determined to be a device to be downgraded; when the data importance level is higher than or equal to the preset importance threshold, the device is skipped.

[0233] For the device whose frequency is reduced, a step-decreasing algorithm is used to adjust the sampling frequency. The specific process is as follows: The current differentiated sampling frequency and the lowest sampling frequency are read from the device configuration register. The corrected frequency reduction step size obtained in step S533 is obtained. This corrected step size is used to extend the sampling period; that is, the new sampling frequency equals the current sampling frequency plus the corrected frequency reduction step size. The device configuration register is updated and takes effect immediately. This adjustment process is repeated until the current sampling frequency reaches the lowest sampling frequency corresponding to the device. The adjustment record is written to the operation log, including the device identifier, the frequency values ​​before and after adjustment, and the number of adjustments.

[0234] Step S535: Based on the congestion level and data importance level, set the corresponding idle connection timeout for each device. The higher the congestion level and the lower the data importance level, the shorter the idle connection timeout.

[0235] Among them, idle connection timeout: the time threshold at which connections in the connection pool that have not engaged in data interaction are deemed invalid and recycled.

[0236] The necessary procedures are as follows:

[0237] The gateway reads the congestion level from the system status register and the data importance level of each device from the device configuration register. It then uses a two-dimensional lookup table algorithm to determine the idle connection timeout. The specific process is as follows: Using the congestion level as the row index and the data importance level as the column index, it queries a pre-defined idle connection timeout table (e.g., 300 seconds for critical level, 180 seconds for moderate level, 120 seconds for critical level, and 30 seconds for moderate level). The idle connection timeout value corresponding to the intersection of the row and column is extracted. The determined idle connection timeout is written to the connection configuration register of the corresponding device, updating the timeout judgment parameters of the connections associated with that device in the connection pool.

[0238] Step S536: Clean up the idle connections in the connection pool according to the idle connection timeout time corresponding to each device; wherein, during the cleanup, idle connections are cleaned up in order of data importance from low to high until there are no more idle connections to clean up.

[0239] The necessary procedures are as follows:

[0240] The gateway repeatedly performs the cleanup operation until there are no idle connections in the connection pool that meet the timeout conditions. Each cleanup operation includes:

[0241] First, iterate through the idle connections in the connection pool, read the device identifier associated with each idle connection, query the data importance level of the device, and determine the cleanup priority based on the data importance level. The idle connections of devices with lower data importance levels have higher cleanup priority.

[0242] Then, according to the cleanup priority from high to low, each idle connection is timed out in turn: the last active timestamp of the connection and the idle connection timeout time set in step S535 are read, the difference between the current time and the last active timestamp is calculated to obtain the idle duration, the idle duration is compared with the idle connection timeout time, when the idle duration is greater than the idle connection timeout time, the connection is determined to have timed out, the connection is closed and the connection handle is removed from the connection pool; when the idle duration is less than or equal to the idle connection timeout time, the connection is retained.

[0243] After the traversal is complete, record the cleanup operation log.

[0244] This application also provides a method for implementing an industrial edge data acquisition gateway system, applicable to the aforementioned industrial edge data acquisition gateway system. For example... Figure 1 As shown, the method includes the following steps:

[0245] Step S101: Obtain communication data from industrial equipment, identify the protocol type through protocol identification, and dynamically load the corresponding protocol plugin.

[0246] Specifically, this step can be executed by the aforementioned protocol management module. Its detailed implementation process can be found in the description of protocol identification and dynamic loading in the system embodiment, including protocol feature field extraction, communication protocol feature vector construction, similarity calculation with the preset protocol fingerprint feature library, a two-layer mechanism of automatic similarity matching and rule base rollback matching, and processing procedures such as unknown protocol reporting and library update.

[0247] Step S102: Establish a communication connection with the industrial equipment through the loaded protocol plugin, reuse the connection in the preset capacity connection pool, allocate differentiated acquisition frequencies to different industrial equipment based on the protocol type, its corresponding equipment type and data importance level, and use a preset frequency reference and step size to batch read and write multiple data points to obtain raw data.

[0248] Specifically, this step can be performed by the aforementioned data acquisition module. The detailed implementation process can be found in the system embodiment regarding connection pool differentiation configuration, frequency dynamic adjustment based on the rate of change, and batch size dynamic adjustment based on the rate of change.

[0249] Step S103: Standardize the raw data to generate standardized equipment data.

[0250] Specifically, this step can be performed by the aforementioned data processing module, and its detailed implementation process can be found in the descriptions of unit conversion, data quality marking, and unified format encapsulation in the system embodiment.

[0251] Step S104: Receive standardized device data, asynchronously transmit it to the cloud platform via a binary protocol containing a preset heartbeat cycle and heartbeat mechanism, and automatically reconnect if the connection is interrupted.

[0252] Specifically, this step can be performed by the aforementioned data upload module. For details of its implementation, please refer to the descriptions of binary protocol frame format, sliding window buffer management, heartbeat detection and automatic reconnection mechanism in the system embodiment.

[0253] Step S105: Collect gateway operating status parameters. Based on a preset trend analysis strategy, perform time-series analysis on the operating status parameters to obtain the trend prediction value of each parameter in the next time window. When the trend prediction value exceeds the preset congestion threshold, quantify and determine the congestion level based on the magnitude of the excess of the trend prediction value relative to the congestion threshold. When the congestion level exceeds the preset switching threshold, switch the corresponding channel data to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type. Adjust the differentiated collection frequency according to the congestion level gradient and clean up timed-out idle connections in the connection pool. Send the operating status parameters to the data upload step to be integrated with the standardized device data and then uploaded to the cloud platform.

[0254] Specifically, this step can be executed by the aforementioned status monitoring module. Its detailed implementation process can be found in the system embodiment regarding the construction of sliding time windows, exponential smoothing prediction, weighted expected load calculation, channel switching decision, congestion level classification and gradient adjustment, and idle connection cleanup.

[0255] Step S106: Establish a long connection with the remote management server in the cloud platform through a reverse HTTP proxy, receive remote HTTP requests and forward them to the local service on the preset port, and receive protocol configuration data issued by the remote management server and forward it to the protocol identification step to achieve secure remote access to the gateway.

[0256] Specifically, this step can be performed by the aforementioned remote management module, and its detailed implementation process can be found in the descriptions of reverse proxy long connection establishment, TLS encrypted channel, request routing and forwarding, configuration data parsing and distribution in the system embodiment.

[0257] The specific implementation details of each step in the above method embodiments have been fully disclosed in the system embodiments. After reading the description of the system embodiments, those skilled in the art can completely implement all the technical solutions of this method embodiment. Therefore, this method embodiment and the foregoing system embodiments belong to the same inventive concept and have the same beneficial effects.

[0258] The industrial equipment communication data, operating status parameters, and processed standardized equipment data collected by the industrial edge data acquisition gateway system in this application are all industrial field production data or equipment operating condition data, and do not involve any personal information (such as name, ID number, biometrics, etc.) or sensitive information. All data acquisition activities are carried out in an industrial intranet or controlled industrial network environment. The data upload process to the cloud platform is encrypted through binary protocol transmission, and the remote management channel between the gateway and the cloud platform adopts TLS encryption and two-way authentication. The scope of data use is strictly limited to industrial equipment monitoring, production optimization, and the gateway's own operation and maintenance. For uploads with unknown protocol characteristics, only the protocol message structure feature vector is included, not the device business data payload, and the upload behavior is only used for protocol library updates and system capability expansion, and does not involve the secondary use of non-technical data.

[0259] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. An industrial edge data acquisition gateway system, characterized in that, include: The protocol management module acquires communication data from industrial equipment, extracts protocol feature vectors, identifies protocol types through a two-layer mechanism of automatic similarity matching and rule base fallback matching, and dynamically loads corresponding protocol plugins. The data acquisition module establishes a connection with industrial equipment through a protocol plugin, configures the connection pool differently based on the protocol identification results, and reuses the connections in the pool. Based on the protocol type, its corresponding equipment type, and the importance level of the data, it allocates different acquisition frequencies to different industrial equipment with a preset frequency benchmark and step size, and reads and writes data points in batches according to a preset batch size to obtain raw data. The data processing module performs standardization processing on the raw data to generate standardized equipment data; The data upload module receives standardized device data and transmits it asynchronously to the cloud platform via a binary protocol, automatically reconnecting when the connection is interrupted. The status monitoring module collects gateway operating status parameters, performs time-series analysis on the operating status parameters based on a preset trend analysis strategy to obtain the trend prediction value of each parameter in the next time window, and when the trend prediction value exceeds the preset congestion threshold, the congestion degree is quantified according to the magnitude of the exceedance. When the congestion degree exceeds the preset switching threshold, the corresponding channel data is switched to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type. The module adjusts the differentiated collection frequency according to the congestion degree gradient and cleans up timed-out idle connections in the connection pool. The operating status parameters are then merged with standardized device data and uploaded to the cloud platform. The remote management module establishes a long connection with the remote management server of the cloud platform through a reverse proxy, forwards remote requests to the local service, receives protocol configuration data issued by the remote management server and forwards it to the protocol management module; Based on a preset trend analysis strategy, time-series analysis of the operating status parameters yields the predicted trend values ​​of each parameter in the next time window, including: The system acquires various operating status parameters collected in real time by the status monitoring module, constructs a sliding time window data sequence for each operating status parameter, and determines the length of each sliding time window from the preset window length configuration according to the protocol type. For each operating status parameter, the corresponding exponential smoothing coefficient is determined from the preset smoothing coefficient configuration according to the device type, and the initial trend prediction value of the parameter in the next time window is obtained by calculating the sliding time window data sequence of the parameter based on the exponential smoothing algorithm. The compensation coefficient is determined from the preset compensation coefficient configuration based on the importance level of the data, and the initial trend prediction value of each operating status parameter is corrected to obtain the trend prediction value of each operating status parameter in the next time window. When congestion exceeds a preset switching threshold, the corresponding channel data will be switched to a preset low-load channel for uploading based on a preset scheduling strategy corresponding to the protocol type, including: Based on the preset parameter type identifier, extract the trend prediction value corresponding to network latency from the trend prediction value of each operating status parameter in the next time window; The list of candidate channels is determined from the preset channel configuration based on the protocol type, and a basic load threshold and an initial load sensitivity coefficient are preset for each candidate channel; Based on the importance level of the data, the initial load sensitivity coefficient is corrected using a preset correction factor. The higher the importance level of the data, the lower the corrected load sensitivity coefficient. Based on the trend prediction of network latency, the current load status of each candidate channel, and the corrected load sensitivity coefficient, calculate the weighted expected load value of each candidate channel in the next time window. The weighted expected load value is compared with the basic load threshold of the corresponding candidate channel to filter out candidate channels whose weighted expected load value is lower than the basic load threshold; Select the channel with the lowest adjusted load sensitivity coefficient from the candidate channels as the target upload channel, and switch the data to the target upload channel.

2. The industrial edge data acquisition gateway system according to claim 1, characterized in that, The process involves acquiring communication data from industrial equipment, extracting protocol feature vectors, and identifying protocol types through a two-layer mechanism of automatic similarity matching and rule-based back-matching. Acquire communication data from industrial equipment and extract protocol feature fields to construct a communication protocol feature vector. The protocol feature fields include message format features, register address features, and communication timing features. The similarity between the communication protocol feature vector and the features of each standard protocol in the preset protocol fingerprint feature library is calculated to obtain multiple similarity values; When any similarity value is greater than or equal to the preset first matching threshold, the automatic matching is determined to be successful, and the protocol type determined by the standard protocol feature corresponding to the similarity value is used as the matching result; when all similarity values ​​are less than the first matching threshold, the automatic matching is determined to be unsuccessful. If the automatic matching is successful, the corresponding protocol plugin will be dynamically loaded from the protocol plugin library based on the matching result; If automatic matching fails, a rule-based protocol fallback matching algorithm is activated. The communication protocol feature vector is compared with each protocol rule in the preset rule base to calculate the matching degree. When any matching degree value is greater than or equal to the preset second matching threshold, the fallback matching is considered successful, and the protocol type determined by the protocol rule corresponding to the matching degree value is used as the matching result. The second matching threshold is less than the first matching threshold. If the fallback match is successful, the corresponding protocol plugin is dynamically loaded from the protocol plugin library based on the matching result, and the protocol feature corresponding to the matching result is added to the protocol fingerprint feature library as a new standard protocol feature. If the rollback matching fails, a protocol exception log is generated, the communication protocol feature vector is uploaded to the remote management platform as an unknown protocol feature, and a preset protocol update package is received from the remote management platform to update the protocol fingerprint feature library according to the new protocol features in the update package.

3. The industrial edge data acquisition gateway system according to claim 2, characterized in that, Differentiated configuration of the connection pool based on protocol identification results and reuse of connections within the pool include: Based on the matching results identified by the protocol, differentiated connection pool configurations are assigned to different industrial devices; When the protocol type is successfully determined through automatic matching, the connection in the connection pool is reused using the preset standard connection configuration. When the protocol type is successfully determined through fallback matching, the connection in the connection pool is reused using the preset conservative connection configuration; The system monitors the connection response time and protocol plugin response time of devices using conservative connection configurations in real time. When the connection response time exceeds a preset response threshold or the number of consecutive failures exceeds a preset failure threshold, it triggers the protocol adaptation update mechanism. The system uploads the communication protocol feature vector corresponding to the device to the remote management platform for protocol rule correction and switches the device's connection configuration to the standard connection configuration. It then reuses connections in the connection pool for verification and collection to confirm the effect of the protocol rule correction.

4. The industrial edge data acquisition gateway system according to claim 1, characterized in that, Based on the protocol type, its corresponding device type, and the data importance level, differentiated acquisition frequencies are assigned to different industrial devices using preset frequency benchmarks and step sizes, including: Based on the protocol type, its corresponding device type, and the data importance level, a basic acquisition frequency, a maximum acquisition frequency, and a minimum acquisition frequency are set for each industrial device, and the acquisition frequency is initially set to the basic acquisition frequency. Real-time data collection of various industrial equipment, and calculation of their rate of change and fluctuation amplitude; When the rate of change exceeds the preset upper limit threshold of the rate of change based on the protocol type and device type for a number of consecutive times, and reaches the preset up-frequency counting threshold, the sampling frequency is gradually increased according to the preset up-frequency step size until the highest sampling frequency is reached. When the number of times the rate of change is continuously lower than the preset lower limit threshold of the rate of change based on the protocol type and device type reaches the preset frequency reduction counting threshold, and the fluctuation amplitude is lower than the preset fluctuation threshold based on the protocol type and device type, the sampling frequency is gradually reduced according to the preset frequency reduction step size until the lowest sampling frequency is reached.

5. The industrial edge data acquisition gateway system according to claim 4, characterized in that, Obtaining raw data by reading and writing data points in batches according to a preset batch size includes: The preset batch size is dynamically adjusted based on the rate of change and / or the amplitude of fluctuation. When the rate of change exceeds the upper limit threshold of the rate of change preset according to the protocol type and device type, the preset batch size is reduced according to the preset batch reduction step size to improve the real-time response speed. When the rate of change is lower than the preset lower limit threshold for the rate of change based on the protocol type and device type, and the fluctuation amplitude is lower than the preset fluctuation threshold based on the protocol type and device type, the preset batch size is increased according to the preset batch increment step to improve data compression efficiency. The preset batch reduction step size and preset batch increment step size are determined according to the protocol type, device type and data importance level, and the higher the data importance level, the larger the corresponding adjustment step size.

6. The industrial edge data acquisition gateway system according to claim 4, characterized in that, Adjusting the differential collection frequency based on congestion levels and clearing timed-out idle connections from the connection pool includes: The congestion level is determined by the status monitoring module and is divided into multiple congestion levels according to the preset congestion level classification rules. Based on the congestion level and the data importance level, the corresponding step size correction coefficient is determined from the preset step size correction mapping relationship. The higher the congestion level and the lower the data importance level, the larger the step size correction coefficient. The preset down-frequency step size is corrected using a step size correction factor to obtain the corrected down-frequency step size; Based on the corrected frequency reduction step size, the differentiated acquisition frequency of devices whose data importance level is lower than the preset importance threshold is gradually reduced towards their corresponding lowest acquisition frequency according to the corrected frequency reduction step size. Based on the congestion level and data importance level, set corresponding idle connection timeout times for each device. The higher the congestion level and the lower the data importance level, the shorter the idle connection timeout time. Based on the idle connection timeout time for each device, idle connections in the connection pool are cleaned up. During the cleanup, idle connections are cleaned up in order of data importance from low to high until there are no more idle connections to clean up.

7. A method for implementing an industrial edge data acquisition gateway system, characterized in that, An industrial edge data acquisition gateway system as described in any one of claims 1 to 6 is comprising the following steps: Acquire communication data from industrial equipment, identify the protocol type through protocol identification, and dynamically load the corresponding protocol plugin; The system establishes a communication connection with industrial equipment by loading a protocol plugin, reuses connections in a preset capacity connection pool, and allocates differentiated acquisition frequencies to different industrial equipment based on the protocol type, the corresponding equipment type, and the data importance level, using a preset frequency benchmark and step size. It also uses a preset batch size to read and write multiple data points in batches to obtain raw data. The raw data is standardized to generate standardized equipment data; It receives standardized equipment data, asynchronously transmits it to the cloud platform via a binary protocol with a preset heartbeat cycle and heartbeat mechanism, and automatically reconnects when the connection is interrupted; The system collects gateway operation status parameters and performs time-series analysis on these parameters based on a preset trend analysis strategy to obtain the trend prediction values ​​for each parameter in the next time window. When the trend prediction value exceeds the preset congestion threshold, the congestion level is quantified based on the magnitude of the excess of the trend prediction value relative to the congestion threshold. When the congestion level exceeds the preset switching threshold, the system switches the corresponding channel data to the preset low-load channel for uploading based on the preset scheduling strategy corresponding to the protocol type. The system adjusts the differentiated collection frequency according to the congestion level gradient and cleans up timed-out idle connections in the connection pool. The operation status parameters are then sent to the data upload step to be integrated with standardized device data before being uploaded to the cloud platform. By establishing a long connection with the remote management server in the cloud platform through a reverse HTTP proxy, receiving remote HTTP requests and forwarding them to the local service on a preset port, and receiving protocol configuration data issued by the remote management server and forwarding it to the protocol identification step, remote secure access to the gateway is achieved.

Images