Autonomous method of an industrial gateway and industrial gateway

Abstract

The application discloses an autonomous method of an industrial gateway and the industrial gateway, and belongs to the field of industrial gateways.The method comprises the following steps: constructing a data copy of a cloud at the gateway, and performing one-way data flow conversion from the cloud to the gateway and from the gateway to downstream devices based on the data copy; applying an independent and parallel acquisition mechanism at the gateway, and adopting a dynamic data uploading method based on a Survivor mode and a cluster cooperation mode to realize uploading of the acquired data to the cloud by the gateway; allocating a dedicated thread and a lock-free MPSC message queue to each device downstream of the gateway; constructing a global mapping center in the gateway to realize accurate data transmission; and executing a time division interleaved advanced buffer assembly method to reduce the interaction round trip times between the gateway and its downstream devices.The application provides a gateway autonomous method capable of realizing configuration zero maintenance, never being silent under extreme networks, eliminating single-point blocking and improving work efficiency.

Description

Technical Field

[0001] This invention belongs to the field of industrial gateways. Specifically, this invention relates to an autonomous method for an industrial gateway and an industrial gateway. Background Technology

[0002] In the context of smart manufacturing, industrial gateways play a pivotal role in connecting underlying OT devices (such as PLCs, CNC machines, and sensor terminals using various protocols) and upper-level IT platforms (such as ERP systems and cloud data centers). However, those skilled in the art face the following distinct technical challenges in existing gateway architectures: 1. The configuration of edge and cloud is fragmented and tightly coupled: Conventional edge gateways usually write table creation statements (DDL) locally. When the data format is upgraded on the cloud management platform, if the update script is not sent from the edge, it will cause a fatal parsing error. 2. Vulnerability of Distributed High-Availability Gateway Clusters: Existing gateway cluster deployments rely heavily on consistency middleware (heartbeat / distributed locks) to achieve high availability. In the high-radiation, easily disconnected electromagnetic environment of a workshop, middleware nodes are highly susceptible to brief offline events, which can cause both machines to determine that they are not the master node, resulting in a "silent shutdown" and interruption of data transmission. 3. Convoy Effect: When the system connects to dozens of downstream devices, if a single global resource pool is still used for polling, a TCP timeout blocking of several seconds caused by a loose physical network cable on one device will inevitably prevent normal devices behind the queue from receiving timely clock scheduling.

[0003] Therefore, this invention proposes an autonomous method for industrial gateways and an industrial gateway. Summary of the Invention

[0004] This invention aims to overcome the shortcomings of the prior art and proposes an autonomous method for industrial gateways and an industrial gateway to achieve the following objectives: to provide an autonomous gateway method that can achieve zero configuration maintenance, never be silent under extreme network conditions, eliminate single points of blockage, and improve work efficiency.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: An autonomous method for an industrial gateway, the method comprising: Step S1: Build a data copy in the cloud on the gateway, and perform one-way data flow from the cloud to the gateway and from the gateway to downstream devices based on the data copy; Step S2: Apply an independent parallel acquisition mechanism to the gateway and adopt a dynamic data upload method based on Survivor mode and cluster collaboration mode to enable the gateway to upload the collected data to the cloud. Step S3: Allocate a dedicated thread and lock-free MPSC message queue for each device downstream of the gateway; build a global mapping center in the gateway to achieve accurate data transmission; and execute a time-division interleaved advanced buffer assembly method to reduce the number of round trips between the gateway and its downstream devices.

[0006] Preferably, step S1 includes: Step S11: When the gateway starts up, it prioritizes connecting to the cloud L1. Step S12: After the gateway connects to L1, it queries the system table structure that L1 comes with. The system table structure will return the definition of each column in its table as the original record. Step S13: The gateway reads the original records into its own memory and organizes them into a structure list; Step S14: The gateway generates a complete copy L2 of L1 locally on the gateway using a dynamically constructed transformation function based on the structure list, including: The conversion function converts each column definition in L1 of the structure list into a type that L2 can recognize, based on a predefined type mapping table. Step S15: After the conversion is completed, the gateway generates a table creation command and executes the table creation command in L2, which actually creates the corresponding physical database file and internal tables, that is, L2, a complete copy of L1 on the local gateway. Step S16: When the gateway transfers data downstream, the dataset to be transferred is loaded from L2 into the gateway memory to form a corresponding memory instance L3, and then L3 is synchronized to all downstream devices; L3 only exists during the data transfer period and is destroyed when closed.

[0007] Preferably, in the event of a network outage, the gateway attempts to connect to L1 upon startup; if the connection fails due to a timeout, it is determined to enter a downgrade mode. In degraded mode, check if the local L2 file exists and is intact; if L2 exists and is intact, the gateway starts in degraded mode based on L2, that is, the gateway initializes entirely based on the data in L2, skipping all synchronization steps with L1; if L2 is damaged or does not exist, the startup stops and the error is logged.

[0008] Preferably, in the event of a network outage, the gateway starts a background thread to periodically attempt to reconnect to L1. Once the network is restored, this thread triggers the complete recovery process, i.e., steps S11 to S15. After execution, the gateway automatically switches from degraded mode back to normal mode without the user noticing.

[0009] Preferably, step S2 includes: Step S21: In the gateway cluster, set all gateways to an independent parallel acquisition mechanism. Each gateway collects all data from all underlying devices in full and in real time, and each holds a complete copy of the latest data. Step S22: Under normal network conditions, all gateways adopt a cluster collaboration mode, controlled by Etcd. A unique Leader is selected from all gateways and used as the sole channel to push data to the cloud. Other gateways act as Followers and stop pushing data to the cloud. Step S23: In the event of a network outage or Etcd malfunction, all gateways switch from cluster collaboration mode to Survivor mode, and each gateway directly and forcibly establishes a connection to the cloud and pushes the data it has collected. Meanwhile, the cloud filters all uploaded data.

[0010] Preferably, the filtering operation includes: After receiving a piece of data, the cloud extracts the device's unique identifier and the timestamp when the data was collected. Multiple time windows are pre-set in the cloud. The time window to which the current data belongs is determined based on the timestamp. In cloud memory, check if a record with the same device unique identifier and time window as the current data already exists; If it does not exist, this is the first data entry for the device within that time window, and it will be stored in the cloud database; if it already exists, it is considered a duplicate data entry and will be discarded.

[0011] Preferably, in step S3, constructing a global mapping center in the gateway includes: When the gateway starts, it loads the configuration information of all devices and tags. A tag represents a data point that the device can read and write. Iterate through each tag to obtain its tag_ID and the device object to which it belongs, i.e., the device memory pointer; Insert this pair (Tag_ID, device memory pointer) into a global hash table; The hash table internally calculates and stores the hash value of Tag_ID using a hash function.

[0012] Preferably, in step S3, the time-division interleaved advanced buffer assembly method includes: When the gateway reads data from its downstream devices, the dedicated thread for the corresponding device starts working. It first checks the MPSC queue, and when it finds the queue to be empty, it begins to prepare for batch reading. Obtain the target address for batch reading and fill in the gaps; After filling in the gaps, multiple target address read requests are packaged into a Protocol Data Unit (PDU) and sent to the downstream device; the downstream device receives the PDU and returns the read result.

[0013] Preferably, the time-division interleaved advanced buffer assembly method further includes: After the gateway receives the PDU read result returned by the downstream device, it immediately runs the pull verification unit before unpacking; the pull verification unit is used to check the MPSC queue of the current downstream device. If the queue is empty, the data is unpacked normally, the read data is stored in memory, and then the next PDU is prepared. If there is a write command in the queue, the read operation is immediately interrupted by a pressure plate, and this write command is processed first.

[0014] The present invention also provides an industrial gateway that uses the above-described autonomous method for an industrial gateway.

[0015] The technical effects of this invention are as follows: This invention achieves industrial gateway autonomy by combining steps S1, S2, and S3. Step S1 ensures adaptive synchronization of cloud-edge configurations, resolving data disasters caused by database version discrepancies (drift) between edge devices and the cloud, achieving zero configuration maintenance. Step S2 ensures zero data loss survival in extreme network environments, successfully transforming the complex "multi-machine negotiation high availability problem" prone to deadlocks into "extremely simplified full push and server-side deduplication," ensuring 100% data survival and feedback under the most extreme and severe conditions. Step S3 ensures zero-blocking scheduling and low-latency response in multi-device concurrent scenarios. Attached Figure Description

[0016] Figure 1 This is a flowchart of an autonomous method for an industrial gateway provided in an embodiment of the present invention. Detailed Implementation

[0017] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the present invention will be explained and illustrated through the following embodiments.

[0018] This invention provides an autonomous method for industrial gateways, such as... Figure 1 As shown, the method includes: Step S1: Build a data copy in the cloud on the gateway, and perform one-way data flow from the cloud to the gateway and from the gateway to downstream devices based on the data copy; Step S2: Apply an independent parallel acquisition mechanism to the gateway and adopt a dynamic data upload method based on Survivor mode and cluster collaboration mode to enable the gateway to upload the collected data to the cloud. Step S3: Allocate a dedicated thread and lock-free MPSC message queue for each device downstream of the gateway; build a global mapping center in the gateway to achieve accurate data transmission; and execute a time-division interleaved advanced buffer assembly method to reduce the number of round trips between the gateway and its downstream devices.

[0019] In order to completely solve the data disaster caused by the inconsistency (drift) of database versions between edge devices and the cloud, and to achieve "zero maintenance" of configuration, this embodiment designs step S1, and the specific operation of step S1 is as follows.

[0020] Step S11: When the gateway starts up, it prioritizes connecting to the cloud L1.

[0021] Step S12: After the gateway connects to L1, it queries the system table structure that L1 provides. The system table structure returns the definition of each column in the table as the original record. The table structure is the blueprint of the cloud database table. For example, the "Employee Table" has three columns: "Employee ID (integer), Name (string), and Department (string)". The purpose of the gateway querying the table structure is to abandon its own hard-coded table creation logic and obtain the latest structure from L1 in real time each time it starts, thereby completely avoiding data corruption caused by inconsistencies between local and cloud versions. After the gateway connects to L1, it does not directly read business data, but queries the system table structure that L1 provides. For example: Execute the SQL: SELECT column_name, data_type FROM system_table WHERE table_name='Employee_table'. The system table will return the definition of each column of the table (column name, type, whether it is null, etc.) as the original record.

[0022] Step S13: The gateway reads the original records into its own memory and organizes them into a structure list. The resulting structure will always be completely consistent with the current L1 structure.

[0023] Step S14: The gateway generates a complete copy L2 of L1 locally on the gateway using a dynamically constructed transformation function based on the structure list, including: The conversion function converts each column definition in L1 of the structure list into a type that L2 can recognize, based on a predefined type mapping table.

[0024] Because of differences in data types and SQL dialects between L1 (such as PostgreSQL) and L2 (such as SQLite) (for example, PostgreSQL's TIMESTAMP WITH TIME ZONE has no direct equivalent in SQLite), the structure of L1 cannot be directly copied to L2. Therefore, a conversion function is needed: it is a dynamically generated set of translation rules that, based on a predefined type mapping table (such as VARCHAR→TEXT, TIMESTAMP WITH TIME ZONE→TEXT plus format conversion logic), converts each column definition of L1 into a type recognizable by L2. This function is not hardcoded but is constructed based on the structure parsed in the previous step.

[0025] Step S15: After the conversion is completed, the gateway generates a table creation command and executes the table creation command in L2, which actually creates the corresponding physical database file and internal tables, that is, L2, a complete copy of L1 on the local gateway. Step S16: When the gateway transfers data downstream, the dataset to be transferred is loaded from L2 into the gateway memory to form a corresponding memory instance L3, and then L3 is synchronized to all downstream devices; L3 only exists during the data transfer period and is destroyed when closed.

[0026] This ultimately forms a unidirectional data flow L1→L2→L3, a three-level unidirectional data flow that prohibits any reverse write-back. L1 (Source): The only authoritative database where all data changes can only occur; L2 (Local Mirror): A complete copy of L1 located locally on the gateway. Data flows only from L1 to L2 (synchronized at startup or periodically), and the gateway never performs any operation to write L2 data back to L1; L3 (Memory Instance): A dataset (such as a Java object) loaded into memory from L2. L3 only exists during data transfer and is destroyed when closed.

[0027] If the gateway needs to modify data in L1 (e.g., update configuration), it must send a formal business request to L1, which will then complete the modification itself. This modification is then resynchronized to all downstream systems via the L1→L2→L3 flow. This way, any errors on the gateway's local end (such as memory calculation errors or temporary modifications caused by bugs) cannot contaminate the L1 source.

[0028] In addition, in the event of a network outage, the gateway in this embodiment attempts to connect to L1 upon startup. If the connection fails due to a timeout, it is determined to enter a downgrade mode. In degraded mode, check if the local L2 file exists and is intact. If L2 exists and is intact, the gateway will start in degraded mode based on L2. That is, the gateway will initialize entirely based on the data in L2, skipping all synchronization steps with L1. At this time, the functions may be limited (e.g., unable to obtain the latest cloud configuration), but the core capabilities (such as local data collection and running with existing configuration) are still available. If L2 is damaged or does not exist, the startup will stop and the error will be logged.

[0029] Meanwhile, in the event of a network outage, the gateway in this embodiment also starts a background thread to periodically attempt to reconnect to L1. Once the network is restored, this thread triggers the complete recovery process, namely steps S11 to S15. After execution, the gateway automatically switches back from degraded mode to normal mode without the user noticing. Ultimately, for the gateway in this embodiment, even a network outage will not cause the gateway to fail to start or crash, ensuring the robustness and availability of the system.

[0030] In existing technologies, when multiple gateways run simultaneously, it's necessary to determine which gateway should be responsible for sending data to the cloud to avoid network congestion or data duplication caused by simultaneous sending. The microservice consistency module Etcd is responsible for recording the current "leader" and providing a "lock-grabbing" mechanism. Gateways write a flag to Etcd; whoever successfully writes it becomes the leader, and the others become followers. Only the leader can send data. If Etcd becomes unavailable due to network failures, downtime, or other reasons, the gateways assume the cluster has lost its coordinator and cannot determine whether data needs to be sent. Therefore, as a conservative strategy, all gateways stop pushing data to the cloud, waiting for Etcd to recover. This results in a collective silent shutdown: although the equipment in the workshop is running normally and the gateways can collect data, no gateway sends data to the cloud, leading to complete data loss. Therefore, this embodiment designs step S2, the specific operation of which is as follows.

[0031] Step S21: In the gateway cluster, configure all gateways to use an independent parallel acquisition mechanism. Each gateway node works independently and in parallel, without depending on the state of the others or sharing data. Each gateway collects data from all underlying devices in full and in real time, and each holds a complete copy of the latest data.

[0032] Traditional clustering models often assign tasks to gateways, such as gateway A collecting data from devices 1-10, gateway B collecting data from devices 11-20, or a master gateway collecting data and then distributing it to others. This model creates dependencies, and chaos ensues if coordination fails. This invention, however, employs an independent parallel data acquisition mechanism. For example, in a workshop with 3 gateways and 10 PLCs, each gateway independently reads data from all 10 PLCs at the highest frequency. This means that the same data (e.g., the temperature value of PLC-1 at 10:00:00) will be collected by each of the 3 gateways. While this may seem redundant, the advantage is that if any gateway fails, the others still have all the data; and if any coordinator fails, each gateway can continue operating independently.

[0033] Step S22: Under normal network conditions, all gateways adopt a cluster collaboration mode, controlled by Etcd. A unique Leader is selected from all gateways and serves as the sole channel for pushing data to the cloud. Other gateways act as Followers, silently refreshing their own memory data but ceasing data pushes to the cloud. This is done to avoid redundant pushes that waste bandwidth and cloud resources. This mode relies on Etcd working properly; if Etcd disconnects, there is no Leader to select, and the traditional system will freeze.

[0034] Step S23: In the event of a network outage or Etcd malfunction, all gateways switch from cluster collaboration mode to Survivor mode. Each gateway directly and forcefully establishes a connection to the cloud and pushes the data it has collected. At this time, the worse the network conditions, the more aggressive the push becomes, and the data survival rate actually increases, rather than collective silence.

[0035] Meanwhile, in Survivor mode, multiple gateways will push the exact same data (redundancy caused by independent parallel collection). Therefore, in this embodiment, the cloud also filters all uploaded data; otherwise, the cloud would receive a large amount of duplicate data, wasting storage and bandwidth.

[0036] The filtering operation includes: After receiving a piece of data, the cloud extracts the device's unique identifier and the timestamp when the data was collected. Multiple time windows are pre-set in the cloud. The time window to which the current data belongs is determined based on the timestamp. In cloud memory, check if a record with the same device unique identifier and time window as the current data already exists; If it does not exist, this is the first data entry for the device within that time window, and it will be stored in the cloud database; if it already exists, it is considered a duplicate data entry and will be discarded.

[0037] Based on the Survivor model and filtering operations, the gateway side no longer needs complex negotiation and interlocking; it can simply push data forward. The cloud side easily deduplicates data. Even in extreme network conditions, as long as data from one gateway reaches the cloud, the data will not be lost, achieving "100% survival feedback."

[0038] Suppose a gateway needs to communicate with 100 PLCs simultaneously. Traditionally, a single thread would poll all PLCs in turn, or a shared thread pool would be used. If one PLC experiences network congestion or disconnection, the entire thread is blocked, delaying communication for all other PLCs – this is the "escort effect." Therefore, referring to step S3, this embodiment allocates a dedicated thread to each downstream device (PLC), much like assigning a dedicated customer service representative to each customer, rather than having everyone queue up for a single representative.

[0039] This thread is dedicated to all communication (reading data, writing instructions, etc.) with its corresponding downstream device (PLC). Threads are isolated from each other and do not interfere with one another. For example, if PLC-1's thread gets stuck due to a network problem, it will only affect that thread; the threads of PLC-2 and PLC-3 will continue to operate normally, completely unaffected. This physically eliminates the risk of a single bottleneck dragging down the entire bus.

[0040] The lock-free MPSC message queue is attached to a dedicated thread for each downstream device. Its function is to receive write commands from the outside (such as a command from the cloud via a RESTful interface to "modify a register value of PLC-1"). Lock-free means that the queue implementation does not use mutex locks (such as synchronized, mutex), but achieves high-efficiency concurrency through atomic operations, avoiding latency caused by thread contention.

[0041] In practice, multiple external entry points (such as REST API threads and configuration update threads) may simultaneously issue write commands to the same downstream device (PLC). They can all safely place the commands into the downstream device's (PLC) MPSC queue without waiting for each other. The downstream device's (PLC) dedicated thread will retrieve the commands from this queue and execute them when idle. The lock-free MPSC message queue acts as a buffer, ensuring that external write requests do not directly interrupt the read process from the downstream device (PLC), but instead queue for processing, while guaranteeing that no write requests are lost.

[0042] In summary, each downstream device (PLC) has an independent thread and an independent MPSC queue, achieving complete resource privatization. Problems in any one downstream device (PLC) will not propagate, and external write instructions can be efficiently enqueued, waiting for their dedicated thread to process them at the appropriate time. Even if a downstream device (PLC) malfunctions, the blocking of its independent thread will not affect other downstream devices (PLCs).

[0043] Furthermore, when the cloud sends a command via a RESTful API to "write the value of Tag_ID as Factory1.Line2.Temperature to 100", traditional gateways need to traverse all tags to find which downstream device contains this tag, resulting in low efficiency. Here, a "Tag" represents a readable and writable data point, such as "temperature sensor for production line 1" or "speed of motor 3". Each tag has a globally unique identifier, which is Tag_ID.

[0044] In order to improve work efficiency and accurately write data to the corresponding devices, this embodiment constructs a global mapping center, and the specific operation is as follows.

[0045] When the gateway starts, it loads the configuration information of all devices and tags. A tag represents a data point that the device can read and write. Iterate through each tag to obtain its tag_ID and the device object to which it belongs, i.e., the device memory pointer; Insert this pair (Tag_ID, device memory pointer) into a global hash table; The hash table internally calculates and stores the hash value of Tag_ID using a hash function.

[0046] In practical use, when the cloud sends a command via a RESTful API to "write the value of Tag_ID as Factory1.Line2.Temperature as 100", the gateway does not need to traverse all tags to find which downstream device contains this tag. Instead, it directly uses Tag_ID as the key to find the corresponding device memory pointer in the hash dictionary, locates the downstream device object directly through the pointer, and finally puts the write command into the MPSC queue of that downstream device. Therefore, based on the global mapping center, regardless of whether there are 10,000 or 1 million tags in the system, the lookup time remains essentially constant and extremely fast, greatly improving work efficiency.

[0047] Communication between gateways and downstream devices typically uses protocols such as Modbus or Siemens Snap7. For efficiency, instead of reading one data point at a time, multiple read requests are packaged into a Protocol Data Unit (PDU) and sent to the downstream device all at once. The downstream device then returns all read results at once. In existing technologies, assuming addresses 1, 2, 3, 5, 6, and 9 need to be read, with addresses 4, 7, and 8 missing (these missing addresses are "gaps"), the traditional approach is to break them down into multiple non-contiguous blocks: for example, reading 1-3 (contiguous), reading 5-6 (contiguous), and reading 9 (separately). This requires multiple PDUs, resulting in low efficiency. Furthermore, assuming the gateway divides 50 read requests into 3 PDUs (each with a maximum of 20 read requests), sends them sequentially, and waits for a response, if the operator clicks "stop" after the second PDU is sent, the write command must wait until all 3 PDUs are completed (potentially taking hundreds of milliseconds or even seconds) before it can be executed. For scenarios requiring emergency shutdown, this latency is unacceptable.

[0048] Therefore, referring to step S3, this embodiment adopts a time-division interleaved advanced buffer assembly method, the specific operation of which is as follows: When the gateway reads data from its downstream devices, the dedicated thread for the corresponding device starts working. It first checks the MPSC queue, and if it finds the queue to be empty, it begins to prepare for batch reading.

[0049] Obtain the target address for batch reading and perform hole padding; hole padding means: allow automatic filling of empty addresses within a certain threshold interval (even if the application does not request these addresses), forcibly concatenating discontinuous addresses into a continuous address range, so that it can be read in one PDU. The cost is that some unnecessary data may be read, but the number of PDUs is greatly reduced. After filling in the gaps, multiple target address read requests are packaged into a Protocol Data Unit (PDU) and sent to the downstream device. While waiting for the downstream device to respond, its dedicated thread is in an I / O wait state. After receiving the PDU, the downstream device returns the read result.

[0050] For example, the address to be read is: [1,2,3,5,6,8,9,10,12,13,14,15,16,18,19,20,22,23,24,25] (20 in total, as one PDU).

[0051] These addresses contain gaps (4, 7, 11, 17, 21 are missing). A threshold gap of 2 is set (meaning if the gap between two addresses is ≤2, the gap will be automatically filled). Gap filling begins: Addresses 3 and 5 are separated by 2 (missing 4) → fill in 4; Addresses 6 and 8 are separated by 2 (missing 7) → fill in 7; Addresses 10 and 12 are separated by 2 (missing 11) → fill in 11; Addresses 16 and 18 are separated by 2 (missing 17) → fill in 17; Addresses 20 and 22 are separated by 2 (missing 21) → fill in 21; After padding, the actual addresses read became consecutive numbers from 1 to 25. What would have required multiple PDUs can now be done with a single PDU. While some unnecessary addresses (4, 7, 11, 17, 21) were read, this resulted in a significantly reduced number of round trips.

[0052] The time-division interleaved advanced buffer assembly method further includes: After the gateway receives the PDU read result returned by the downstream device, it immediately runs the pull verification unit before unpacking; the pull verification unit is used to check the MPSC queue of the current downstream device. If the queue is empty, the data is unpacked normally, the read data is stored in memory, and then the next PDU is prepared. If a write command is in the queue, the read operation is immediately interrupted by a diode press, and this write command is processed first. After the write operation is completed, a decision is made on whether to continue reading or re-plan the process based on the situation.

[0053] For example, suppose we need to process 3 PDUs. The traditional method is: PDU1 sends → waits → receives packet → unpacks → PDU2 sends → waits → receives packet → unpacks → PDU3 sends → waits → receives packet → unpacks → then checks the queue.

[0054] The method in this embodiment is as follows: PDU1 sends → waits → receives packets → pulls and checks (no write found) → unpacks → PDU2 sends → waits → receives packets → pulls and checks (an urgent write is found) → immediately interrupts, processes the write → after the write is completed, decides whether to send PDU3. Thus, the response time for the write command is shortened from "all batch reads completed" to "millisecond intervals after the current PDU completes," achieving near-zero latency feedback.

[0055] In summary, based on the time-division interleaving advanced buffer assembly method of this embodiment, a read operation that originally required 50 round trips may only require 3 round trips, reducing RTT by more than 95%. The response time of write commands on the control interface is reduced from seconds to milliseconds, completely eliminating any lag.

[0056] This embodiment combines steps S1, S2, and S3 to achieve autonomy for the industrial gateway. Step S1 ensures adaptive synchronization of cloud-edge configurations, resolving data disasters caused by version discrepancies (drifting) between edge devices and the cloud database, achieving zero configuration maintenance. Step S2 ensures zero data loss survival in extreme network environments, successfully transforming the complex "multi-machine negotiation high availability problem" that easily leads to deadlocks into "extremely simplified full push and server-side deduplication," ensuring 100% data survival and feedback under the most extreme and severe conditions. Step S3 ensures zero-blocking scheduling and low-latency response in multi-device concurrent scenarios.

[0057] This embodiment also provides an industrial gateway, which uses the above-described autonomous method for an industrial gateway.

[0058] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. An autonomous method for an industrial gateway, characterized in that: The method includes: Step S1, constructing a data copy in the cloud on the gateway, and performing unidirectional data flow from the cloud to the gateway and from the gateway to downstream devices based on the data copy; Step S2, applying an independent parallel acquisition mechanism on the gateway, and adopting a dynamic data upload method based on Survivor mode and cluster collaboration mode to enable the gateway to upload the collected data to the cloud; Step S3, allocating a dedicated thread and a lock-free MPSC message queue to each device downstream of the gateway; constructing a global mapping center in the gateway to achieve accurate data transmission; and executing a time-division interleaved advanced buffer assembly method to reduce the number of round trips between the gateway and its downstream devices.

2. The autonomous method for an industrial gateway according to claim 1, characterized in that: Step S1 includes: Step S11: When the gateway starts up, it prioritizes connecting to the cloud L1; Step S12: After connecting to L1, the gateway queries the system table structure of L1, which returns the definition of each column as the original record; Step S13: The gateway reads the original record into its own memory and organizes it into a structure list; Step S14: The gateway generates a complete copy L2 of L1 on the gateway's local machine based on the structure list using a dynamically constructed conversion function, including: the conversion function converts each column definition of L1 in the structure list into a type that L2 can recognize, according to a predefined type mapping table; Step S15: After the conversion is completed, the gateway generates a table creation instruction and executes this instruction in L2, actually creating the corresponding physical database file and internal table, i.e., the complete copy L2 of L1 on the gateway's local machine; Step S16: When the gateway transfers data downstream, the dataset to be transferred is loaded from L2 into the gateway's memory to form a corresponding memory instance L3, which is then synchronized to all downstream machines; L3 only exists during data transfer and is destroyed when closed.

3. The autonomous method for an industrial gateway according to claim 2, characterized in that: In the event of a network outage, the gateway attempts to connect to L1 upon startup. If the connection fails due to a timeout, it enters a degraded mode. In degraded mode, it checks whether the local L2 file exists and is intact. If L2 exists and is intact, the gateway starts up based on L2, meaning it initializes entirely based on the data in L2, skipping all synchronization steps with L1. If L2 is corrupted or does not exist, the gateway stops starting and records the error.

4. The autonomous method for an industrial gateway according to claim 3, characterized in that: In the event of a network outage, the gateway starts a background thread that periodically attempts to reconnect to L1. Once the network is restored, this thread triggers the complete recovery process, namely steps S11 to S15. After the process is completed, the gateway automatically switches back from degraded mode to normal mode without the user noticing.

5. The autonomous method for an industrial gateway according to claim 1, characterized in that: Step S2 includes: Step S21: In the gateway cluster, all gateways are set to an independent parallel acquisition mechanism. Each gateway collects all data from all underlying devices in full and in real time, and each holds a complete copy of the latest data. Step S22: Under normal network conditions, all gateways adopt a cluster collaboration mode, controlled by Etcd. A unique Leader is selected from all gateways and serves as the sole channel to push data to the cloud. Other gateways act as Followers and stop pushing data to the cloud. Step S23: In the event of a network outage or Etcd malfunction, all gateways switch from cluster collaboration mode to Survivor mode. Each gateway directly and forcibly establishes a connection to the cloud and pushes the data it has collected. At the same time, the cloud filters all uploaded data.

6. The autonomous method for an industrial gateway according to claim 5, characterized in that: The filtering operation includes: after receiving a piece of data in the cloud, extracting the device unique identifier and the timestamp of the data collection; the cloud has multiple time windows pre-set, and the time window to which the current data belongs is determined based on the timestamp; in the cloud memory, it is checked whether a record with the same device unique identifier and time window as the current data already exists; if it does not exist, this is the first piece of data for this device in the time window, and it is stored in the cloud database; if it already exists, it is considered to indicate that the data is duplicated and is directly discarded.

7. The autonomous method for an industrial gateway according to claim 1, characterized in that: In step S3, building a global mapping center in the gateway includes: when the gateway starts, loading the configuration information of all devices and tags, where a tag represents a data point that a device can read and write; traversing each tag, obtaining its tag_ID and the device object to which it belongs, i.e., the device memory pointer; inserting this pair (tag_ID, device memory pointer) into a global hash table; the hash table internally calculates and stores the hash value of tag_ID using a hash function.

8. The autonomous method for an industrial gateway according to claim 1, characterized in that: In step S3, the time-division interleaved advanced buffer assembly method includes: when the gateway reads data from its downstream devices, the dedicated thread of the corresponding device starts working. It first checks the MPSC queue, and after finding that the queue is empty, it starts preparing for batch reading; obtains the target address for batch reading and performs hole filling; packages the multiple target address read requests after hole filling into a Protocol Data Unit (PDU) and sends it to the downstream device; after receiving the PDU, the downstream device returns the reading result.

9. The autonomous method for an industrial gateway according to claim 8, characterized in that: The time-division interleaved advanced buffer assembly method further includes: when the gateway receives the PDU read result returned by the downstream device, it immediately runs the pull verification unit before unpacking; the pull verification unit is used to check the MPSC queue of the current downstream device; if the queue is empty, it unpacks normally, stores the read data in memory, and then continues to prepare the next PDU; if there is a write instruction in the queue, it immediately interrupts the read and processes the write instruction first.

10. An industrial gateway, characterized in that: The gateway uses an autonomous method for an industrial gateway according to any one of claims 1-9.

Images