Industrial IO data acquisition system and industrial IO data acquisition method

Abstract

The invention provides an industrial IO data acquisition system and an industrial IO data acquisition method, and relates to the technical field of industrial control, the system comprises clouded controllers deployed in each physical server node and IO virtual network cards, the number of which is the same as that of physical network cards; the IO virtual network card comprises a data receiving module, a protocol processing module and a memory management module; the data receiving module is used for acquiring IO multicast data of the corresponding physical network card; the protocol processing module is used for performing protocol analysis on the IO multicast data to obtain structured IO data when a kernel soft interrupt is received, and storing the structured IO data to a corresponding target memory area; the memory management module is used for performing region division on a storage memory when a service process is started to obtain a plurality of memory regions; and the clouding controller is used for reading the structured IO data in the corresponding memory region according to the global configuration. According to the invention, the network bandwidth consumption and the invalid resource occupation of the cloud controller are reduced.

Description

Technical Field

[0001] This invention relates to the field of industrial control technology, and more specifically, to an industrial I / O data acquisition system and an industrial I / O data acquisition method. Background Technology

[0002] In the field of industrial automation, with the widespread application of cloud-based control platforms, real-time acquisition and efficient transmission of industrial I / O data have become core requirements for ensuring stable system operation. Currently, in cloud-based control platforms, real-time I / O data from the field side (such as sensor detection data and actuator status data) is typically acquired via communication cards or gateways and then distributed to various cloud controllers via multicast communication through switches, thus achieving initial data sharing.

[0003] However, existing multicast communication solutions have significant technical drawbacks: On the one hand, each cloud controller receives the complete multicast data stream regardless of actual data requirements. Even if only a small amount of I / O data from a few devices or channels is needed, the entire data stream still needs to be processed. This not only results in a significant waste of network bandwidth but also causes a surge in the memory usage of the cloud controller. Furthermore, frequent multicast data reception and parsing operations trigger frequent CPU interruptions and context switching, significantly increasing CPU load and causing a serious waste of computing resources. On the other hand, each cloud controller receives and parses multicast data independently, lacking a unified data source management and data processing standard. This can easily lead to inconsistent data reception delays and deviations in data parsing results, increasing the risk of data loss or inconsistent processing. This seriously affects the real-time computing performance of the cloud controller and the overall reliability of the system, making it difficult to meet the stringent requirements of industrial scenarios for low latency, high stability, and high throughput in I / O data acquisition. Summary of the Invention

[0004] The problem solved by this invention is one or more of the aforementioned related technical problems.

[0005] To address the aforementioned problems, this invention provides an industrial I / O data acquisition system and an industrial I / O data acquisition method.

[0006] In a first aspect, the present invention provides an industrial IO data acquisition system, including a cloud controller deployed in each physical server node and an IO virtual network interface card (NIC) with the same number of physical NICs; the IO virtual NIC includes a data receiving module, a protocol processing module, and a memory management module. The data receiving module is used to acquire the corresponding IO multicast data of the physical network card; The protocol processing module is used to perform protocol parsing on the IO multicast data to obtain structured IO data when it receives a kernel soft interrupt triggered by the data receiving module, and to store the structured IO data in the corresponding target memory area. The memory management module is used to divide the storage memory into regions according to the preset global configuration when the service process starts, so as to obtain multiple memory regions. The memory regions are used by the protocol processing module to query and locate the target memory region. The cloud controller is used to read the structured I / O data in the corresponding memory region according to the global configuration of the configuration.

[0007] Optionally, the storage memory includes shared memory and RDMA memory, and the global configuration includes basic device information and corresponding channel information; the memory management module is specifically used for: The storage memory is initialized to obtain the initialized shared memory and the RDMA memory; Based on the device basic information and the corresponding channel information, the initialized shared memory and RDMA memory are divided into regions to obtain multiple corresponding memory regions. The memory region is in the form of an array of structures, and each structure includes a header area and a data storage area.

[0008] Optionally, the memory region includes an index table; the memory management module is further configured to: The basic information of each device and the corresponding channel information are extracted from the global configuration and combined to determine the data combination; Each data combination is labeled according to the preset order in the global configuration to obtain the corresponding index table.

[0009] Optionally, the shared memory is used for direct memory access by the cloud controller of the current physical server node, and the RDMA memory is used for remote memory access by the cloud controller of other physical server nodes besides the current physical server node.

[0010] Optionally, the protocol processing module is specifically used for: When the kernel soft interrupt is received, the protocol parsing of the IO multicast data is performed to obtain the structured IO data, and the device basic information and the channel information in the structured IO data are extracted; Based on the device basic information and the channel information, query the index tables in the shared memory and RDMA memory respectively; When the query result matches, the structured IO data is stored in the corresponding target memory area; When the query result does not match, the corresponding structured IO data is discarded and an alarm log is triggered.

[0011] Optionally, storing the structured I / O data in the corresponding target memory region when the query result matches includes: When the query result matches, the annotation information corresponding to the data combination in the index table is obtained, and the corresponding target memory region is determined based on the annotation information; According to the preset write lock mechanism, the data status flag bit of the data header area in the target memory area is changed to the data write state, and the corresponding structured IO data is written into the storage data area in the target memory area. Once the data writing is complete, change the data status flag bit in the data header area of ​​the target memory region to the data read state.

[0012] Optionally, the cloud controller is specifically used for: Based on the association between the cloud controller and the IO virtual network interface card in the global configuration, obtain the target IO virtual network interface card corresponding to the cloud controller, and detect the online status of the target IO virtual network interface card; When the target IO virtual network card is online, the structured IO data corresponding to the memory region is read from the shared memory of the physical server node to which the cloud controller belongs.

[0013] Optionally, the cloud controller is further configured to: When the target IO virtual network interface card is offline, according to the node redundancy topology in the global configuration, the backup IO virtual network interface cards corresponding to other physical server nodes are obtained, and the online status of the backup IO virtual network interface cards is detected. If the backup IO virtual network interface card is in the offline state; obtain the next backup IO virtual network interface card according to the preset selection rules, and repeat the backup IO virtual network interface card acquisition and status detection steps until the backup IO virtual network interface card in the online state is located; The corresponding structured IO data is read from the RDMA memory of the physical server node to which the online standby IO virtual network interface card belongs.

[0014] Optionally, the preset selection rules include node priority or redundancy strategies.

[0015] Secondly, the present invention provides an industrial I / O data acquisition method, applied to the aforementioned industrial I / O data acquisition system, the industrial I / O data acquisition method comprising: When the service process starts, the storage memory is divided into regions according to the preset global configuration to obtain multiple memory regions. These memory regions are used by the protocol processing module in the industrial IO data acquisition system to query and locate the target memory region. Acquire the IO multicast data of the corresponding physical network card in the industrial IO data acquisition system; When the protocol processing module in the industrial IO data acquisition system receives a kernel soft interrupt triggered by the data receiving module, it performs protocol parsing on the IO multicast data to obtain structured IO data, and stores the structured IO data in the corresponding target memory area. The structured I / O data is read from the corresponding memory region according to the global configuration of the configuration.

[0016] The beneficial effects of the industrial I / O data acquisition system and method of the present invention are: By deploying an architecture design that matches the number of physical network interface cards (NICs) on each physical server node, along with redundantly deployed cloud controllers, and combining the collaborative working mechanism of the three modules within the NICs—data reception, protocol processing, and memory management—multiple beneficial effects can be achieved: Firstly, the data reception module selectively acquires NIC IO multicast data, and the protocol processing module precisely initiates the parsing process through a kernel soft interrupt triggered by the data reception module. This avoids the redundant operation of each cloud controller independently receiving the complete data stream in traditional multicast communication, significantly reducing network bandwidth consumption and the ineffective resource occupation of the cloud controllers. Secondly, the memory management module divides the storage memory area based on a preset global configuration, enabling the protocol processing module to quickly locate the target memory area to store structured IO data. The cloud controller directly reads the memory data according to the configuration, eliminating the network reception and parsing overhead in traditional data transmission, significantly reducing data acquisition latency. At the same time, through a standardized memory sharing mechanism and module collaboration logic, the risk of data loss and processing inconsistencies is reduced, effectively improving the real-time computing performance of the cloud controller and the overall reliability and stability of the industrial IO data acquisition system. Attached Figure Description

[0017] Figure 1 This is one of the structural schematic diagrams of an industrial I / O data acquisition system according to an embodiment of the present invention; Figure 2 This is a second schematic diagram of the structure of an industrial IO data acquisition system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an I / O virtual network interface card according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a conventional cloud-based control platform according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a shared memory / RDMA memory according to an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the process of the cloud-based controller reading industrial I / O data according to an embodiment of the present invention; Figure 7 This is a flowchart illustrating an industrial I / O data acquisition method according to an embodiment of the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Although some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the accompanying drawings and embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0019] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0020] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to"; the term "based on" means "at least partially based on"; the term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments"; and the term "optionally" means "optional embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first," "second," etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0021] It should be noted that the one or more modifications mentioned in this invention are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise expressly indicated in the context, they should be understood as one or more.

[0022] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0023] In existing solutions, the cloud controller and data acquisition process lack an efficient interaction mechanism. Data transmission requires multiple network protocol stack processing and data copying, which further increases data acquisition latency. This makes it unsuitable for scenarios with high real-time requirements in industrial control (such as precision manufacturing and process control), thus restricting the application expansion of cloud control platforms in the field of industrial automation.

[0024] To address the problems existing in the aforementioned related technologies, embodiments of the present invention provide an industrial IO data acquisition system and an industrial IO data acquisition method.

[0025] like Figures 1-3 As shown in the figure, an industrial IO data acquisition system provided by an embodiment of the present invention includes a cloud controller deployed in each physical server node and IO virtual network cards with the same number as physical network cards; the IO virtual network card includes a data receiving module, a protocol processing module and a memory management module; The data receiving module is used to acquire the corresponding IO multicast data of the physical network card.

[0026] Specifically, such as Figure 4 As shown, in traditional cloud-based control platforms (current cloud-based control platforms), real-time data from the field side is collected via communication cards or gateways and distributed to various cloud controllers via switches in a multicast manner, thereby achieving efficient and low-latency data communication. However, a major problem with multicast communication is that each cloud controller receives the complete multicast data stream, even if they only need a small portion of it. This leads to unnecessary network bandwidth consumption and significantly increases the memory and CPU usage of the cloud controllers, resulting in resource waste. Figure 2 Each node in the table represents a physical server node.

[0027] In this embodiment, such as Figure 1 and Figure 2 In Kubernetes, the same number of virtual IO network interfaces (NICs) as physical NICs are deployed on each physical server node. That is, each virtual IO NIC (Pod) corresponds one-to-one with a physical NIC on the physical server node, and the virtual IO NICs are deployed in the form of Pods. This deployment relationship ensures that the data receiving module only interfaces with one physical NIC, avoiding data mixing across multiple NICs. In Kubernetes, a Pod is the smallest unit of scheduling and deployment that can be created and managed. It represents one or more closely related containers (usually one). These containers share network, storage, and other runtime environment resources and are scheduled as a whole to run on a node in the cluster.

[0028] The IO virtual network interface card includes a data receiving module. The data receiving module uses CPU core binding technology to exclusively occupy an independent CPU core. This core is only used to perform data receiving tasks and does not participate in the resource scheduling of other modules (such as protocol processing and cloud controller computing), thus ensuring the real-time performance and stability of data reception from the hardware level.

[0029] Industrial field-side IO data (such as temperature and pressure data detected by sensors, and actuator operating status data) are collected by communication cards or gateways and transmitted in the form of multicast data streams through switches to the corresponding physical network cards of physical server nodes. The data receiving module listens to the multicast data port of the bound physical network card in real time. When a multicast data stream is detected, it uses DMA (Direct Memory Access) technology to bypass the CPU and directly transfer the multicast data from the physical network card to the memory buffer without the CPU participating in the data copy operation. After the data is written to the memory buffer, the data receiving module immediately triggers the kernel soft interrupt mechanism to send a data ready signal to the protocol processing module, completing the acquisition and handover of IO multicast data.

[0030] Since the IO virtual network interface Pod corresponds one-to-one with the physical network interface card, and the data receiving module only listens to the multicast data of the corresponding physical network interface card, the acquired IO multicast data are all real-time data generated by the industrial field devices (such as sensors and actuators in specific areas) connected to the physical network interface card. This ensures the correlation between the data source and the physical network interface card, laying the foundation for subsequent memory storage partitioning by device and channel.

[0031] The data receiving module acquires IO multicast data through a one-to-one binding of physical network cards, dedicated CPU core allocation, and direct DMA data transfer, which brings multiple key benefits: Firstly, the module's one-to-one deployment with physical network cards enables targeted reception of multicast data, avoiding subsequent processing chaos caused by data mixing from different physical network cards. Secondly, the CPU core binding technology ensures that the data receiving task has independent, non-preemptive computing resources, effectively reducing the impact of multi-task switching on data reception latency. Thirdly, the application of DMA technology bypasses the CPU to complete the data transfer from the physical network card to the memory buffer, significantly reducing CPU resource consumption during data copying and preventing the CPU from consuming the cloud controller's computing resources due to frequent data reception. It also shortens the data transmission path, reducing latency during transmission. Ultimately, this achieves low-latency, low-power, targeted acquisition of industrial IO multicast data, providing high-quality raw data input for subsequent protocol processing modules to quickly parse data and for the cloud controller to efficiently read data, ensuring the real-time performance and resource utilization efficiency of the entire industrial IO data acquisition system from the data acquisition source.

[0032] The protocol processing module is used to perform protocol parsing on the IO multicast data when it receives a kernel soft interrupt triggered by the data receiving module, obtain structured IO data, and store the structured IO data in the corresponding target memory area.

[0033] Specifically, the kernel soft interrupt is triggered by the data receiving module. This triggering occurs when the data receiving module writes the I / O multicast data from the physical network card to the memory buffer using DMA technology. The protocol processing module listens for kernel soft interrupt signals in real time. Upon receiving the signal, it immediately pauses low-priority tasks (if any) and starts the I / O multicast data processing flow. This triggering logic ensures that the protocol processing module only starts working when data is ready, avoiding idle waiting when there is no data or invalid processing when data is not fully written, thus improving module operating efficiency.

[0034] After reading the IO multicast data from the memory buffer, the protocol processing module parses the data according to the industrial communication protocol. This parsing may include a "header" and a "body" of the multicast data packet. The head contains metadata such as device identifiers (e.g., sensor ID, actuator ID) and channel numbers (e.g., temperature acquisition channel, pressure acquisition channel under the device). The body contains the raw acquired values ​​(e.g., temperature data in binary format). The module then performs format conversion on the body, transforming the raw binary data into structured data that the cloud controller can directly recognize. After the protocol processing module completes the parsing, it needs to store the structured I / O data into the corresponding target memory area in the storage memory (such as shared memory and RDMA memory).

[0035] The protocol processing module, through its design of soft interrupt-triggered response, standardized protocol parsing, and dual-memory synchronous storage, offers significant advantages: It uses a kernel soft interrupt triggered by the data receiving module as its startup signal, ensuring seamless integration between data processing and data reception, preventing data backlog or delayed processing. Simultaneously, standardized protocol parsing converts raw multicast data into structured data, eliminating redundant data parsing operations by each cloud controller and reducing CPU repetitive computation overhead. Furthermore, it reduces the overall latency of industrial I / O data acquisition from the data parsing to storage stage, minimizing wasted computing resources and providing crucial support for cloud controllers to efficiently read data and ensure system real-time performance and reliability.

[0036] The memory management module is used to divide the storage memory into regions according to the preset global configuration when the service process starts, so as to obtain multiple memory regions. The memory regions are used by the protocol processing module to query and locate the target memory region.

[0037] Specifically, after the service process starts, the module loads the preset global configuration (which may include fields such as "device ID, device IP address, whether the device is redundant, channel ID, memory offset address corresponding to the channel, and data offset address corresponding to the channel," and its core function is to establish the correspondence between "IO data - data channel - industrial equipment"), and performs fully synchronized area division of the initialized storage memory (such as shared memory and RDMA memory) based on the global configuration, resulting in multiple memory areas.

[0038] After the protocol processing module parses the IO multicast data, it can query and locate the corresponding memory region through information such as device ID + channel number. This located memory region is the target memory region.

[0039] The memory management module significantly improves the performance and reliability of industrial I / O data acquisition systems by pre-initializing memory when the service process starts and precisely dividing regions according to configuration. It completes memory preprocessing during the service startup phase, avoiding delays caused by temporary memory allocation after data reception.

[0040] The cloud controller is used to read the structured I / O data in the corresponding memory region according to the global configuration of the configuration.

[0041] Specifically, when the cloud controller completes its startup initialization, it first loads the global configuration required for system operation (which includes the correspondence between devices and I / O channels, such as device ID, channel ID, channel corresponding memory offset address, and core information such as physical server node topology and virtual network card deployment relationship), and initializes its own operating environment (such as binding an independent CPU core and opening a data temporary storage cache area) to ensure that it has the basic conditions to read memory data.

[0042] The cloud-based controller determines the type of structured I / O data to be read based on the device-channel combinations corresponding to its own computing needs in the global configuration. For example, if the cloud-based controller needs to execute temperature control logic, it only needs to read the I / O data of specific "device-channel" combinations such as temperature sensor T001-temperature channel Ch01 and temperature sensor T002-temperature channel Ch01. Subsequently, the controller directly locates the physical address of the corresponding memory region (such as the starting address 0x2000-0x200F corresponding to "sensor T001-Ch01" in the memory) based on the mapping relationship between device-channel combinations and memory regions in the configuration (this relationship is pre-built by the memory management module according to the configuration and stored in memory in the form of a hash table), without having to traverse the entire memory.

[0043] The cloud-based controller reads structured I / O data through configuration-guided positioning, which brings significant benefits: the controller accurately locates the target memory region based on global configuration, avoiding the redundant operation of filtering the required data after receiving the full multicast data in traditional solutions, greatly reducing network bandwidth consumption and CPU and memory resource usage; and the unified configuration provides standardized rules for data reading, avoiding reading logic confusion or data deviation caused by different controllers processing data independently, effectively improving the real-time computing performance of the cloud-based controller, ensuring the overall reliability and stability of the industrial I / O data acquisition system, and meeting the industrial scenario's requirements for "low latency, high accuracy, and high adaptability" in data reading.

[0044] In this embodiment, the industrial IO data acquisition system employs an architecture design where each physical server node deploys IO virtual network cards matching the number of physical network cards, along with redundantly deployed cloud controllers. Combined with the collaborative working mechanism of the three modules within the IO virtual network cards—data reception, protocol processing, and memory management—it achieves multiple beneficial effects: Firstly, the data reception module selectively acquires IO multicast data from the physical network cards, while the protocol processing module precisely initiates the parsing process through a kernel soft interrupt triggered by the data reception module. This avoids the redundant operation of each cloud controller independently receiving the complete data stream in traditional multicast communication, significantly reducing network bandwidth consumption and the ineffective resource occupation of the cloud controllers. Secondly, the memory management module divides storage memory areas based on a preset global configuration, enabling the protocol processing module to quickly locate the target memory area to store structured IO data. The cloud controller directly reads the memory data according to the configuration, eliminating the network reception and parsing overhead of traditional data transmission, significantly reducing data acquisition latency. Simultaneously, through a standardized memory sharing mechanism and module collaboration logic, it reduces the risk of data loss and processing inconsistencies, effectively improving the real-time computing performance of the cloud controller and the overall reliability and stability of the industrial IO data acquisition system.

[0045] Optionally, the storage memory includes shared memory and RDMA memory, and the global configuration includes basic device information and corresponding channel information; the memory management module is specifically used for: The storage memory is initialized to obtain the initialized shared memory and the RDMA memory; Based on the device basic information and the corresponding channel information, the initialized shared memory and RDMA memory are divided into regions to obtain multiple corresponding memory regions. The memory region is in the form of an array of structures, and each structure includes a header area and a data storage area.

[0046] Optionally, the memory region includes an index table; the memory management module is further configured to: The basic information of each device and the corresponding channel information are extracted from the global configuration and combined to determine the data combination; Each data combination is labeled according to the preset order in the global configuration to obtain the corresponding index table.

[0047] Optionally, the shared memory is used for direct memory access by the cloud controller of the current physical server node, and the RDMA memory is used for remote memory access by the cloud controller of other physical server nodes besides the current physical server node.

[0048] Specifically, the storage memory comprises two independent memory blocks: shared memory and RDMA memory. Both are initialized by the memory management module when the service process starts. The module first requests sufficient memory resources from the system (e.g., the capacity of each memory block is adapted to the total data requirements of the industrial field equipment and channels), and simultaneously performs memory space zeroing (eliminating residual historical dirty data) and read / write permission configuration (allowing only the protocol processing module to write and the cloud controller to read). The RDMA memory also needs to be additionally bound to the RDMA network card resources of the physical server (e.g., registered as an RDMA-accessible memory area MR) to ensure subsequent support for cross-node remote access, laying the hardware foundation for data storage. RDMA (Remote Direct Memory Access) is a remote direct memory access mechanism.

[0049] The global configuration presets basic device information (such as the unique device ID and device type of industrial field sensors and actuators) and corresponding channel information (such as the acquisition channel ID, channel data length, and corresponding memory offset address under the device). After the memory management module loads this configuration, it performs a fully synchronized area division of the initialized shared memory and RDMA memory according to the device-channel dimension: both memory blocks are organized into a structure array. Each structure in the array corresponds to a dedicated storage unit for a device-channel combination. Each structure is fixed to include a data header area (storing metadata such as device ID, channel number, and data status flags for data identification and status control) and a storage data area (for storing structured IO data parsed by the protocol processing module), ensuring that the data storage structure and division rules of the dual memory are completely consistent.

[0050] To enable the protocol processing module to quickly locate the target memory region, the memory management module extracts the basic device information and channel information of each group from the global configuration and combines them to form a unique data combination (such as temperature sensor T001 - temperature acquisition channel Ch01). Then, according to the preset order in the configuration (such as ascending order by device ID or ascending order by channel ID), it marks the corresponding structure array subscript for each data combination (the annotation information, i.e., the position identifier of the data combination in the memory structure array), and stores the correspondence between data combination and array subscript in the form of an index table in shared memory and RDMA memory for subsequent querying.

[0051] Although shared memory and RDMA memory have the same storage structure, their access scenarios are clearly defined. Shared memory is only for cloud controllers deployed on the current physical server node, and supports the controller to perform local direct memory access through memory direct addressing technology without network transmission. RDMA memory, on the other hand, is for cloud controllers deployed on other physical server nodes besides the current physical server node, and supports cross-node controllers to bypass the target node's operating system kernel protocol stack through RDMA technology (remote direct memory access) to perform remote memory access. The two work together to cover the data access needs of the entire "local-cross-node" scenario.

[0052] like Figure 5 The diagram shown is a schematic of shared memory / RDMA memory. Figure 5 The leftmost shared memory / RDMA memory is part of the physical memory and serves as the physical carrier for storing I / O data (structured I / O data). As mentioned earlier, it is initialized by the memory management module when the service process starts, and it carries both the bit data block (memory area) and the HashMap index table (index table), forming the underlying support for the entire data storage architecture.

[0053] Figure 5 The "HashMap" at the top is the implementation of the index table, where each ID corresponds to a unique identifier for a device (basic device information) - channel combination (such as label information, like sensor T001 - temperature channel Ch01). Its function is to establish a mapping relationship between device-channel IDs and tag data blocks. That is, when the protocol processing module or cloud controller needs to locate a certain type of IO data, it only needs to query the HashMap by ID to quickly find the corresponding tag data block, avoiding traversing the entire memory space.

[0054] Figure 5 The middle data blocks 1-n are categorized storage units for IO data (structured IO data). Each data block corresponds to a type of device-channel combination of IO data (e.g., data block 3 specifically stores the IO data of sensor T003-pressure channel Ch01). The purpose of this hierarchical design is to isolate data according to the device-channel dimension, avoid the mixing of IO data from different devices and channels, and facilitate subsequent batch reading or management according to business needs (e.g., all channel data of a certain device).

[0055] IO Data Layer: Each tag data block stores 1400 bytes of IO data area, which is used to store structured data parsed by the protocol processing module (such as sensor temperature values, actuator status values, etc.).

[0056] Data Header: The data header area is 24 bytes long and is crucial for ensuring data consistency and identifiability. It contains the following core fields: mode: Data mode identifier (e.g., to distinguish between "real-time acquired data" and "historical archived data"); timestamp: The time when the data was generated or written to memory, used to determine data freshness; offset: The offset address of the data in memory, used to locate the specific storage location; Device ID: A unique identifier for the corresponding industrial equipment, used for data traceability and association.

[0057] The existence of the data header enables IO data to be self-descriptive. That is, when the cloud controller reads data, it can determine whether the data has expired through the timestamp of the data header, verify the integrity of the data through the checksum (implicit design, not shown in the diagram but belonging to the regular data header field), and associate business logic through the device ID, ultimately ensuring the accuracy and availability of the read data.

[0058] Figure 5 It fully presents the memory data organization logic of index positioning → classified storage → structured carrying: first, a fast mapping from ID to data block is achieved through HashMap; then, classified storage is achieved in the "device-channel" dimension through "location data block"; finally, the structured design of "data header + IO data" ensures the identifiability, consistency and integrity of the data.

[0059] This design satisfies the industrial scenario's need for low-latency data access (fast HashMap location) while also taking into account the requirements for standardized data management (layered storage + data header metadata). It is a core technical detail for achieving efficient and reliable storage of industrial I / O data using shared memory / RDMA memory.

[0060] The above design, through synchronous dual-memory construction, precise configuration partitioning, rapid index table location, and differentiated adaptation for different uses, brings multiple key benefits: synchronous initialization and partitioning of two memory blocks ensures complete consistency of data sources for local and cross-node access, avoiding asynchronous data issues; the structure array storage and index table design based on device-channel not only achieves standardized classification and storage of IO data, but also reduces the memory location time complexity to O(1), significantly improving the efficiency of data writing for the protocol processing module and data reading for the cloud controller; the distinction between shared memory and RDMA memory allows local access to achieve low latency based on local memory, while cross-node access relies on RDMA technology to overcome network transmission bottlenecks, effectively reducing data transmission latency and CPU resource consumption. At the same time, the unified configuration provides a standardized basis for memory management, avoiding confusion in data storage and access logic. Ultimately, it provides highly reliable, low-latency, and all-scenario adaptable memory storage and access support for industrial IO data acquisition systems, ensuring the real-time computing performance of the cloud controller and the overall stability of the system.

[0061] Optionally, the protocol processing module is specifically used for: When the kernel soft interrupt is received, the protocol parsing of the IO multicast data is performed to obtain the structured IO data, and the device basic information and the channel information in the structured IO data are extracted; Based on the device basic information and the channel information, query the index tables in the shared memory and the RDMA memory respectively; When the query result matches, the structured IO data is stored in the corresponding target memory area; When the query result does not match, the corresponding structured IO data is discarded and an alarm log is triggered.

[0062] Optionally, storing the structured I / O data in the corresponding target memory region when the query result matches includes: When the query result matches, the annotation information corresponding to the data combination in the index table is obtained, and the corresponding target memory region is determined based on the annotation information; According to the preset write lock mechanism, the data status flag bit of the data header area in the target memory area is changed to the data write state, and the corresponding structured IO data is written into the storage data area in the target memory area. Once the data writing is complete, change the data status flag bit in the data header area of ​​the target memory region to the data read state.

[0063] Specifically, when the protocol processing module receives a kernel soft interrupt triggered by the data receiving module (which is initiated by the data receiving module after writing IO multicast data into the memory buffer via DMA), it immediately starts the data parsing process, disassembles the IO multicast data according to industrial communication protocols (such as Modbus and Profinet), extracts basic device information (such as the unique ID of industrial equipment and device type) and channel information (such as the acquisition channel ID and channel data type under the device), and converts the raw data into structured IO data that the cloud controller can directly recognize (such as converting binary temperature values ​​into floating-point format).

[0064] The protocol processing module combines the extracted basic device information and channel information into a unique data identifier. It then queries the pre-built index tables in shared memory and RDMA memory (these index tables are generated by the memory management module according to the preset order of device-channel combinations in the global configuration and stored in the form of a hash table). If the query result matches (i.e., the device-channel combination has a corresponding memory region division in the configuration), the module obtains the label information (such as the structure array index) corresponding to the data combination in the index table, and then determines the physical address of the target memory region in shared memory and RDMA memory. If the query result does not match (i.e., the device-channel combination is not defined in the configuration), the module directly discards the structured IO data and triggers an alarm log (recording the device ID, channel information, and timestamp of the discarded data for easy maintenance and troubleshooting).

[0065] When the query result matches, the protocol processing module synchronously performs data writing to the target area of ​​shared memory and RDMA memory: First, it changes the data status flag in the data header area of ​​the target memory area to the data writing state (e.g., the flag is set to 1) to prevent the cloud controller from reading data during the data writing process and causing data inconsistency; then, it writes the structured IO data to the storage data area of ​​the target area and synchronously updates the timestamp (records the writing time), data length (identifies the valid data range) and other fields in the data header area; after the data writing is completed, it changes the data status flag to the data reading state (e.g., the flag is set to 0) and releases the memory area for the cloud controller to read.

[0066] The protocol processing module, through its functional design of protocol parsing and information extraction, dual-memory index table lookup, and write lock mechanism to ensure storage, offers significant benefits: This module uses kernel soft interrupts as trigger signals to ensure seamless connection between data parsing and data reception, avoiding data backlog or delayed processing; it quickly locates the target memory region through the index table, significantly shortening data storage addressing time and improving write efficiency; the dual-memory synchronous storage mechanism unifies the data source for both local access (shared memory) and cross-node access (RDMA memory), and the write lock mechanism ensures consistency and security during the data writing process, avoiding the risk of data loss or reading dirty data; furthermore, the design for discarding mismatched data and issuing alarms filters invalid data at the source, reducing system resource waste, ultimately providing cloud controllers with "low latency, high consistency, and high reliability" IO data storage support, effectively ensuring the overall real-time performance and stability of the industrial IO data acquisition system.

[0067] Optionally, the cloud controller is specifically used for: Based on the association between the cloud controller and the IO virtual network interface card in the global configuration, obtain the target IO virtual network interface card corresponding to the cloud controller, and detect the online status of the target IO virtual network interface card; When the target IO virtual network card is online, the structured IO data corresponding to the memory region is read from the shared memory of the physical server node to which the cloud controller belongs.

[0068] Optionally, the cloud controller is further configured to: When the target IO virtual network interface card is offline, according to the node redundancy topology in the global configuration, the backup IO virtual network interface cards corresponding to other physical server nodes are obtained, and the online status of the backup IO virtual network interface cards is detected. If the backup IO virtual network interface card is in the offline state; obtain the next backup IO virtual network interface card according to the preset selection rules, and repeat the backup IO virtual network interface card acquisition and status detection steps until the backup IO virtual network interface card in the online state is located; The corresponding structured IO data is read from the RDMA memory of the physical server node to which the online standby IO virtual network interface card belongs.

[0069] Optionally, the preset selection rules include node priority or redundancy strategies.

[0070] Specifically, after the cloud controller starts, it first loads the association between the cloud controller and the IO virtual network interface card (INIC) in the global configuration settings (this configuration specifies the INIC affiliation for each cloud controller, such as...). Figure 2 In this system, the cloud controller corresponds to two IO virtual network cards on physical server node 1. Based on this relationship, the controller locates the corresponding target IO virtual network card and monitors its online status in real time through heartbeat detection or process status query. If the target IO virtual network card is online, the controller directly accesses the shared memory of its physical server node and reads the structured IO data in the corresponding memory area according to the mapping relationship between the device-channel combination and the memory area in the configuration. This process is achieved through direct local memory addressing without network transmission, ensuring low latency in data reading.

[0071] When the target IO virtual network interface card (NIC) is offline, the cloud controller, based on the node redundancy topology in the global configuration (which defines the primary / backup relationship and priority order of physical server nodes), filters out the backup IO virtual NICs corresponding to other physical server nodes. The controller then checks the online status of the backup IO virtual NICs (the detection logic is the same as that for the target IO virtual NIC). If the backup IO virtual NIC is still offline, it sequentially obtains the next backup IO virtual NIC and repeats the detection steps according to the preset selection rules (these rules are the node priority or redundancy strategies defined in the configuration, such as sorting by node load capacity from low to high, or selecting by primary / backup node switching logic) until an online backup IO virtual NIC is located. Subsequently, the cloud controller bypasses the operating system kernel protocol stack of the physical server node to which the backup IO virtual NIC belongs through RDMA (Remote Direct Memory Access) technology, directly reading the structured IO data in the corresponding area of ​​the node's RDMA memory, thus achieving cross-node data access.

[0072] The cloud-based controller employs a dual-path design—primarily reading from local shared memory and redundant cross-node RDMA memory reading—combined with a configuration-driven node switching mechanism, resulting in significant benefits. When the local controller is online, the shared memory reading mechanism leverages the low latency of local memory access to ensure the real-time computing performance requirements of the cloud-based controller. When the local I / O virtual network interface card (NIC) is offline, based on the configured node redundancy topology and preset selection rules, it can quickly locate online backup nodes and achieve cross-node data reading via RDMA technology, avoiding data acquisition interruptions due to single-node failures and significantly improving the system's high availability and fault tolerance. Furthermore, the unified global configuration provides a standardized basis for the cloud-based controller's node association and switching logic, avoiding switching chaos or data access deviations caused by independent decisions from different controllers. Ultimately, this ensures the overall reliability, real-time performance, and stability of the industrial I / O data acquisition system from the data reading stage, meeting the stringent requirements of industrial scenarios for high availability, low latency, and uninterrupted data access.

[0073] In some embodiments, such as Figure 6 The diagram shows the process of a cloud-based controller reading industrial I / O data. This process includes: After the cloud controller starts, it first loads the global configuration (including core rules such as device-channel mapping, node redundancy topology, and IO virtual network card association) to provide a basis for subsequent data reading and node switching.

[0074] Determine if the local A / B virtual network interface cards (the corresponding IO virtual network interface cards in the physical server node to which the current cloud controller belongs) are online: If online: The cloud controller directly accesses the local shared memory, reads the structured IO data of the corresponding area in the shared memory according to the mapping relationship between device-channel and memory area in the configuration, and the process ends.

[0075] If offline: Enter the redundant node switching logic.

[0076] Obtain IO virtual network card information of other nodes (other physical server nodes) in the configuration → Loop judgment: Based on the node redundancy topology in the global configuration, the cloud controller sequentially obtains the spare IO virtual network card information of other physical server nodes (such as node B and node C) and loops to check their online status.

[0077] Determine if the topology node A-level virtual network interface is online (here, topology node A-level can be understood as the target backup node's I / O virtual network interface): If offline: continue to obtain the virtual network card information of the next backup node and repeat the detection steps.

[0078] If online: The cloud controller accesses the RDMA memory of the standby node through RDMA technology, reads the structured IO data of the corresponding area, and the process ends.

[0079] The cloud-based controller's decision-making process of reading local shared memory → cross-node RDMA memory is a direct implementation of node redundancy and high availability design for data access. It not only demonstrates the low latency advantage of shared memory, but also ensures system fault tolerance through RDMA and node switching, ultimately achieving the goal of uninterrupted and highly reliable industrial IO data acquisition.

[0080] like Figure 7 As shown, this embodiment of the invention provides an industrial I / O data acquisition method, applied to the aforementioned industrial I / O data acquisition system. The industrial I / O data acquisition method includes: When the service process starts, the storage memory is divided into regions according to the preset global configuration to obtain multiple memory regions. These memory regions are used by the protocol processing module in the industrial IO data acquisition system to query and locate the target memory region. Acquire the IO multicast data of the corresponding physical network card in the industrial IO data acquisition system; When the protocol processing module in the industrial IO data acquisition system receives a kernel soft interrupt triggered by the data receiving module, it performs protocol parsing on the IO multicast data to obtain structured IO data, and stores the structured IO data in the corresponding target memory area. The structured I / O data is read from the corresponding memory region according to the global configuration of the configuration.

[0081] While the present invention has been disclosed above, its scope of protection is not limited thereto. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention, and all such changes and modifications will fall within the scope of protection of the present invention.

Claims

1. An industrial I / O data acquisition system, characterized in that, This includes a cloud-based controller deployed in each physical server node and an IO virtual network interface card (NIC) with the same number of physical NICs; the IO virtual NIC includes a data receiving module, a protocol processing module, and a memory management module. The data receiving module is used to acquire the corresponding IO multicast data of the physical network card; The protocol processing module is used to perform protocol parsing on the IO multicast data to obtain structured IO data when it receives a kernel soft interrupt triggered by the data receiving module, and to store the structured IO data in the corresponding target memory area. The memory management module is used to divide the storage memory into regions according to the preset global configuration when the service process starts, so as to obtain multiple memory regions. The memory regions are used by the protocol processing module to query and locate the target memory region. The cloud controller is used to read the structured I / O data in the corresponding memory region according to the global configuration of the configuration.

2. The industrial I / O data acquisition system according to claim 1, characterized in that, The storage memory includes shared memory and RDMA memory; the global configuration includes basic device information and corresponding channel information; the memory management module is specifically used for: The storage memory is initialized to obtain the initialized shared memory and the RDMA memory; Based on the device basic information and the corresponding channel information, the initialized shared memory and RDMA memory are divided into regions to obtain multiple corresponding memory regions. The memory region is in the form of an array of structures, and each structure includes a header area and a data storage area.

3. The industrial I / O data acquisition system according to claim 2, characterized in that, The memory region includes an index table; the memory management module is also used for: The basic information of each device and the corresponding channel information are extracted from the global configuration and combined to determine the data combination; Each data combination is labeled according to the preset order in the global configuration to obtain the corresponding index table.

4. The industrial I / O data acquisition system according to claim 2, characterized in that, The shared memory is used for direct memory access by the cloud controller of the current physical server node, and the RDMA memory is used for remote memory access by the cloud controller of other physical server nodes besides the current physical server node.

5. The industrial I / O data acquisition system according to claim 3, characterized in that, The protocol processing module is specifically used for: When the kernel soft interrupt is received, the protocol parsing of the IO multicast data is performed to obtain the structured IO data, and the device basic information and the channel information in the structured IO data are extracted; Based on the device basic information and the channel information, query the index tables in the shared memory and the RDMA memory respectively; When the query result matches, the structured IO data is stored in the corresponding target memory area; When the query result does not match, the corresponding structured IO data is discarded and an alarm log is triggered.

6. The industrial I / O data acquisition system according to claim 5, characterized in that, When the query result matches, storing the structured IO data in the corresponding target memory region includes: When the query result matches, the annotation information corresponding to the data combination in the index table is obtained, and the corresponding target memory region is determined based on the annotation information; According to the preset write lock mechanism, the data status flag bit of the data header area in the target memory area is changed to the data write state, and the corresponding structured IO data is written into the storage data area in the target memory area. Once the data writing is complete, change the data status flag bit in the data header area of ​​the target memory region to the data read state.

7. The industrial I / O data acquisition system according to claim 2, characterized in that, The cloud-based controller is specifically used for: Based on the association between the cloud controller and the IO virtual network interface card in the global configuration, obtain the target IO virtual network interface card corresponding to the cloud controller, and detect the online status of the target IO virtual network interface card; When the target IO virtual network card is online, the structured IO data corresponding to the memory region is read from the shared memory of the physical server node to which the cloud controller belongs.

8. The industrial I / O data acquisition system according to claim 7, characterized in that, The cloud-based controller is also used for: When the target IO virtual network interface card is offline, according to the node redundancy topology in the global configuration, the backup IO virtual network interface cards corresponding to other physical server nodes are obtained, and the online status of the backup IO virtual network interface cards is detected. If the backup IO virtual network interface card is in the offline state; obtain the next backup IO virtual network interface card according to the preset selection rules, and repeat the backup IO virtual network interface card acquisition and status detection steps until the backup IO virtual network interface card in the online state is located; The corresponding structured IO data is read from the RDMA memory of the physical server node to which the online standby IO virtual network interface card belongs.

9. The industrial I / O data acquisition system according to claim 8, characterized in that, The preset selection rules include node priority or redundancy strategies.

10. An industrial I / O data acquisition method, characterized in that, The industrial I / O data acquisition method, applied to the industrial I / O data acquisition system as described in any one of claims 1 to 9, comprises: When the service process starts, the storage memory is divided into regions according to the preset global configuration to obtain multiple memory regions. These memory regions are used by the protocol processing module in the industrial IO data acquisition system to query and locate the target memory region. Acquire the IO multicast data of the corresponding physical network card in the industrial IO data acquisition system; When the protocol processing module in the industrial IO data acquisition system receives a kernel soft interrupt triggered by the data receiving module, it performs protocol parsing on the IO multicast data to obtain structured IO data, and stores the structured IO data in the corresponding target memory area. The structured I / O data is read from the corresponding memory region according to the global configuration of the configuration.

Images