Soft network system capable of expanding transmission mode and implementation method thereof

Abstract

The invention discloses a soft network system capable of expanding a transmission mode and an implementation method, and the system comprises an equipment resource mapping management unit which automatically generates a unique channel code based on a native hardware interface and establishes a multi-dimensional mapping relation; the heterogeneous interface data acquisition unit is used for monitoring various hardware interfaces in a kernel space in parallel and realizing zero-copy data transmission through a three-buffer lockless annular buffer area; the transmission abstraction and dynamic expansion unit realizes transmission mode modularization in a plug-in form and supports atomic hot plug during operation; the protocol analysis and service processing unit is used for realizing unified scheduling and fault isolation in a single process through a dynamic link mechanism; and the cross-layer monitoring and self-healing unit realizes automatic switching based on a session state machine and a redundant channel. According to the method, the code complexity is reduced from O (N * M) to O (N + M), and the time lt is extended; fault switching is carried out at 1s; and the hardware cost is reduced by more than 40%, so that the method is particularly suitable for power and environment monitoring scenes with more than 1000 devices and more than 15 protocols, and has high creativity.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) communication architecture technology, and in particular to a scalable transmission method for a soft network system and its implementation method. Background Technology

[0002] The core task of an environmental monitoring system is to collect and monitor various power and environmental equipment. These devices come from different manufacturers, have different application scenarios, and design concepts, resulting in a high degree of heterogeneity in their northbound interface forms. At the transmission level, devices may use long-distance network communication or short-distance serial ports, CAN buses, Bluetooth, GPIO, and other interfaces; at the application layer protocol level, they may use Modbus, SNMP, the General Electric System Protocol (GEP), or manufacturer-specific protocols. Typically, specific application layer protocols have their conventional default transmission methods (such as Modbus-TCP over TCP, Modbus-RTU over RS485), but equipment manufacturers often deviate from these conventional designs to quickly achieve compatibility with multiple transmission methods. For example, they may transmit Modbus-RTU messages via TCP, a phenomenon that has become commonplace in the industry.

[0003] Faced with the complexity of combinations of transmission methods and application layer protocols, environmental monitoring vendors generally adopt two solutions:

[0004] Option 1: Unified Transmission Method

[0005] The solution unifies heterogeneous interfaces into network transmission through conversion modules such as serial port servers. While this simplifies the software structure, it adds an intermediate conversion layer, making data interaction highly dependent on conversion equipment. This results in limited monitoring efficiency, decreased system stability, and increased difficulty in troubleshooting. Furthermore, the additional hardware procurement significantly increases costs and construction complexity.

[0006] Option 2: Group Monitoring

[0007] The system is divided into multiple monitoring groups based on transmission methods and application layer protocol types, with each group collecting data independently and then aggregating the results. While this approach reduces hardware costs, it faces issues of code redundancy and resource waste: in the worst-case scenario, the system needs to be compatible with all Cartesian product combinations of all transmission methods and protocols, resulting in an exponential increase in the number of modules, a complex structure, and significant CPU and memory resource consumption during parallel operation; furthermore, the multiple architectures make troubleshooting difficult and maintenance costs high. Summary of the Invention

[0008] The purpose of this invention is to provide a scalable transmission method for a soft network system and its implementation method, thereby solving the aforementioned problems existing in the prior art.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A scalable transmission-based soft network system is deployed in an industrial control computing device. This device integrates multiple native hardware communication interfaces. The system includes:

[0011] The device resource mapping management unit is used to establish and maintain a multi-dimensional mapping relationship between industrial equipment, application layer protocol type, transmission mode type and hardware communication channel. The mapping relationship is directly bound to the native hardware resources of the computing device, without the need for an external protocol conversion device.

[0012] The heterogeneous interface data acquisition unit runs in the kernel space of the computing device, listens to different types of hardware communication interfaces in parallel, and transmits the raw byte stream to the user space processing layer through a unified zero-copy data channel.

[0013] The transmission abstraction and dynamic extension unit, located in user space, implements connection control and data transmission and reception functions for different transmission methods in the form of modular plug-ins. It supports online loading and unloading at runtime, and all application layer protocols share the same set of standardized calling interfaces.

[0014] The protocol parsing and business processing unit calls the transmission abstraction and dynamic extension unit through a dynamic linking mechanism to complete data acquisition, independently parses the protocol messages of each application layer and outputs business data, and realizes unified scheduling and fault isolation of heterogeneous devices within a single process.

[0015] Preferably, the device resource mapping management unit specifically includes:

[0016] The key-value storage module uses an in-memory hash table structure to record the mapping relationship between device identifier, protocol type, transmission method and hardware channel number;

[0017] The hardware channel auto-encoding module scans the PCIe configuration space, USB bus topology, and network interface physical addresses when the system starts up, and automatically generates a unique hardware channel code. The code includes an interface type identifier, a physical address identifier, and a logical port number identifier.

[0018] The conflict detection and remapping module automatically avoids conflicts when hardware resource conflicts are detected by reassigning the PCI bridge secondary bus number or disabling the USB port.

[0019] The heterogeneous interface data acquisition unit specifically includes:

[0020] The interrupt aggregation processing module registers service routines for DMA interrupts from the network interface, UART interrupts from the serial port, HCI event interrupts from Bluetooth, and level change interrupts from GPIO, and uses interrupt merging technology to process high-frequency interrupts in batches.

[0021] The shared memory data channel module creates a circular buffer in kernel space, implements producer-consumer data transfer through lock-free CAS operations, and uses memory barrier instructions to ensure data visibility under multi-core CPU architecture.

[0022] The triple buffering module automatically activates the third backup buffer and triggers hardware flow control when the data write rate exceeds the processing rate to prevent data overflow and loss.

[0023] The transmission abstraction and dynamic expansion unit specifically includes:

[0024] The standardized interface abstraction module defines an abstract interface that includes four basic operations: connection, disconnection, sending, and receiving. The interface parameters use a fixed-length structure to eliminate the overhead of dynamic dispatch.

[0025] The module is implemented in a plug-in manner, with independent dynamic link libraries compiled for each transmission method. The library files export registration functions for loading at runtime.

[0026] The atomic hot-plug module loads dynamic libraries based on file system monitoring events, atomically updates the global interface function pointer table through the RCU mechanism, and safely unloads the old version library after the session-free access period, achieving second-level expansion without affecting online services.

[0027] The protocol parsing and business processing unit specifically includes:

[0028] The independent protocol processing module runs each application layer protocol on an independent thread, adopts a real-time scheduling strategy and is bound to a CPU core, and directly calls the transmission interface through a pre-cached array of function pointers;

[0029] The backpressure flow control module sends a pause command to the transmission abstraction unit when the queue of pending processing of the protocol thread exceeds the threshold, triggering the pause of data reception and the transmission of flow control signals in the hardware interface;

[0030] The adaptive load balancing module periodically collects the scheduling latency and queue depth of each protocol thread, and dynamically adjusts thread priority and CPU affinity through a PID control algorithm.

[0031] Preferably, the system further includes:

[0032] The cross-layer session state machine module defines four states: connection establishment, data transmission, abnormal disconnection, and resource release. State transitions trigger bidirectional notifications between kernel and user space.

[0033] The fault self-healing module automatically queries redundant backup channels and performs seamless session context switching when it detects continuous channel abnormalities. During the switching process, the data sequence number is kept continuous and the sliding window is synchronized.

[0034] The preventive maintenance module counts the frequency of similar faults occurring within a unit of time. When the frequency exceeds a preset threshold, it automatically triggers the channel to reduce its operating speed and reports an early warning.

[0035] Preferably, the soft network system is deployed on an industrial control computer configured with an ARM Cortex-A53 multi-core processor and a Linux kernel, supporting simultaneous access to more than 1,000 heterogeneous environmental devices and more than 15 application layer protocols. When adding a new transmission method plugin, the average time is less than 1 second, the average time for fault channel switching is less than 100 milliseconds, the peak CPU utilization is less than 65%, and the memory usage is less than 2GB.

[0036] A software network implementation method based on the same concept and scalable transmission mode, running on the software network system of any one of claims 1-4, the method includes the following steps:

[0037] Establish the mapping relationship between devices and channels: scan the native hardware interface of the computing device, automatically generate a unique hardware channel code, and create an association mapping table between device identifier, protocol type, transmission method and hardware channel;

[0038] Parallel acquisition of heterogeneous interface data: Register multiple hardware interrupt service routines in the kernel space, and transfer the raw data to the user space in a zero-copy manner through a circular buffer;

[0039] Abstraction and isolation of transmission implementation: Load control logic for different transmission methods in user space as a plug-in, provide standardized calling interfaces to upper-layer protocols, and achieve decoupling of transmission methods and protocol parsing;

[0040] Dynamically expand transmission capabilities: Monitor changes in the plugin directory while the system is running, load new transmission method plugins through an atomic update mechanism, and complete the expansion without restarting the service;

[0041] Adaptive scheduling and fault self-healing: Dynamically adjust resource allocation according to the protocol to handle the load, and automatically switch to redundant channels when a channel failure is detected to ensure business continuity.

[0042] Preferably, the steps for establishing the mapping relationship between devices and channels specifically include:

[0043] Parse the base address register of the PCIe configuration space to obtain the serial port controller address;

[0044] Parse the USB bus descriptor to obtain the Bluetooth adapter topology path;

[0045] The physical address and logical port number are combined to generate a 64-bit hardware channel code;

[0046] The mapping relationship is stored in an in-memory hash table and a concurrent query interface is provided.

[0047] Preferably, the parallel acquisition of heterogeneous interface data steps specifically include:

[0048] A batch processing strategy is used to handle network DMA interrupts, processing them in batches every millisecond.

[0049] The serial UART interrupt triggers DMA batch transfer, and the transfer starts when the hardware FIFO is filled to 75%.

[0050] Lock-free CAS operations are used to update the circular buffer index, and memory barriers are used to ensure data order.

[0051] When the write rate exceeds the processing rate, a triple-buffering rotation mechanism is activated.

[0052] The specific steps for dynamically expanding transmission capacity include:

[0053] The plugin directory is monitored via inotify, and SHA256 signature verification is performed when a new dynamic library file is detected.

[0054] Call dlopen to load the library file, and execute dlsym to obtain the registration function pointer;

[0055] The global function pointer table is atomically replaced using the RCU mechanism and unloaded after the old library has no session access.

[0056] The extension process is completed within 100ms and has no impact on established connections;

[0057] The adaptive scheduling and fault self-healing steps specifically include:

[0058] Periodically collect protocol thread scheduling delay and queue depth, and adjust thread priority using a PID algorithm;

[0059] When a channel fails, the connection is rebuilt in a new channel and the session context (data sequence number, window size) is synchronized.

[0060] After the handover is complete, a FIN is sent to terminate the old channel, and the packet loss rate during the handover process is zero.

[0061] When the frequency of a certain type of fault exceeds a threshold, the channel is triggered to slow down and an SNMP Trap warning is sent.

[0062] Preferably, this method is applied to environmental monitoring scenarios, supports any combination of Modbus / SNMP / electrical communication protocol / private protocol with TCP / RS485 / Bluetooth / GPIO, reduces code module complexity from O(N×M) to O(N+M), and does not require recompiling the main program when expanding to new transmission methods.

[0063] Preferably, the system is deployed in the environmental monitoring environment of the computer room. By replacing the protocol conversion gateway and multiple monitoring servers in the traditional solution with a single industrial control computer, the hardware cost is reduced by more than 40% and the fault recovery time is shortened by more than 70%.

[0064] In another embodiment, an environmental monitoring data acquisition system includes the aforementioned soft network system and the aforementioned method, capable of simultaneously accessing more than 1,000 heterogeneous devices and 15 protocols, and completing online expansion of transmission methods and seamless switching of fault channels while maintaining continuous system operation.

[0065] The beneficial effects of this invention are:

[0066] 1. Significantly optimized hardware costs and deployment complexity.

[0067] By eliminating the intermediate protocol conversion gateway and directly reusing the native hardware interface of the industrial control computer, the number of additional hardware purchases is significantly reduced, effectively lowering equipment investment costs. At the same time, it simplifies on-site cabling, shortens the construction period, and reduces overall deployment complexity.

[0068] 2. Software architecture complexity is fundamentally reduced.

[0069] By vertically decoupling transmission methods from protocol parsing, the number of system modules is reduced from a Cartesian product relationship between protocols and transmission methods to a linear superposition relationship, resulting in significant code compression. Modular design allows for more centralized maintenance and significantly accelerates the iteration speed of new feature development.

[0070] 3. Online scalability achieves a qualitative leap.

[0071] It supports dynamically loading new transmission method plugins while the system is running continuously. The expansion process is transparent to upper-layer services and can be completed without restarting any services, which greatly improves the system's flexibility and evolution capabilities.

[0072] 4. The fault recovery speed is significantly shortened.

[0073] The redundant channel automatic switching mechanism based on session state machine can complete the activation of backup channel and context synchronization in a very short time when the main channel fails. The switching process maintains data continuity, minimizes the impact of service interruption, and significantly improves the overall availability of the system.

[0074] 5. System resource utilization efficiency has been comprehensively improved.

[0075] The single-process, multi-threaded architecture replaces the traditional multi-process grouping mode, significantly reducing memory usage, noticeably lowering peak CPU load, and drastically reducing interrupt handling latency. With the same hardware configuration, the supported device access capacity is increased by an order of magnitude.

[0076] 6. The difficulty of troubleshooting and maintenance has been significantly reduced.

[0077] The single-layer isolation design focuses troubleshooting on a single module, while the kernel-user space separation architecture ensures that application-layer anomalies do not affect underlying hardware monitoring. This makes problem location more intuitive for operations and maintenance personnel, fundamentally improving maintenance efficiency.

[0078] 7. Breakthrough in preventative maintenance capabilities

[0079] By analyzing the frequency and trend of fault occurrences in real time, the system can identify potential risks in advance and automatically trigger protective speed reduction, proactively report early warning information, and realize the transformation from a passive response to a proactive intervention operation and maintenance mode.

[0080] 8. Significantly enhanced adaptability to industrial scenarios

[0081] Designed specifically for extreme heterogeneous environments in environmental monitoring, it breaks through the strict limitations of traditional solutions on protocol and transmission combinations, supports a variety of non-standard combination methods, and is applicable to most data center environments and equipment types.

[0082] 9. System security and stability are effectively enhanced.

[0083] Dynamic library loading incorporates signature verification and sandbox isolation mechanisms to prevent unauthorized code injection. Multi-core binding and memory barrier instructions ensure data consistency, significantly enhancing the overall system robustness and attack resistance.

[0084] 10. Outstanding long-term economic benefits

[0085] In large-scale applications, this invention offers significant advantages in terms of overall cost, including hardware investment, maintenance manpower, and failure losses. Its return on investment far exceeds that of traditional architectures, giving it outstanding economic value and market competitiveness. Attached Figure Description

[0086] Figure 1 This is the present invention;

[0087] Figure 2 This is the present invention;

[0088] Figure 3 This is a flowchart of the method of the present invention. Detailed Implementation

[0089] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0090] Reference Figure 1 and Figure 2The illustrated software network system, employing a scalable transmission method, is deployed in an industrial control computing device. This device integrates multiple native hardware communication interfaces. The system includes:

[0091] The device resource mapping management unit is used to establish and maintain a multi-dimensional mapping relationship between industrial equipment, application layer protocol type, transmission mode type and hardware communication channel. The mapping relationship is directly bound to the native hardware resources of the computing device, without the need for an external protocol conversion device.

[0092] The heterogeneous interface data acquisition unit runs in the kernel space of the computing device, listens to different types of hardware communication interfaces in parallel, and transmits the raw byte stream to the user space processing layer through a unified zero-copy data channel.

[0093] The transmission abstraction and dynamic extension unit, located in user space, implements connection control and data transmission and reception functions for different transmission methods in the form of modular plug-ins. It supports online loading and unloading at runtime, and all application layer protocols share the same set of standardized calling interfaces.

[0094] The protocol parsing and business processing unit calls the transmission abstraction and dynamic extension unit through a dynamic linking mechanism to complete data acquisition, independently parses the protocol messages of each application layer and outputs business data, and realizes unified scheduling and fault isolation of heterogeneous devices within a single process.

[0095] Reference Figure 1 and Figure 2 The system shown is a scalable transmission method software network system deployed on an industrial control computing device. The device integrates multiple native hardware communication interfaces. The system is composed of four core units working together. Through the integrated hardware and software architecture, it completely solves the technical problems of device heterogeneity and protocol combination complexity in the field of environmental monitoring.

[0096] System overall architecture and deployment environment

[0097] This system is deployed on an industrial control computer configured with an ARM Cortex-A53 multi-core processor and a Linux 4.19+ kernel. This computing device physically integrates a PCIe multi-serial port expansion card, a USB Bluetooth adapter, an onboard gigabit network card, and a GPIO expansion board. For example... Figure 1 As shown, the system is divided into a hardware layer, kernel space layer, user space layer, and application layer from bottom to top. The hardware layer contains various environmental monitoring devices, which are directly connected to the industrial control computer's native interface via RS485 bus, CAN bus, Bluetooth, GPIO, or TCP / IP network, without any intermediate protocol conversion gateway. The kernel space layer runs a heterogeneous interface data acquisition unit, directly listening for hardware interrupts. The user space layer includes a transmission abstraction and dynamic expansion unit, a protocol parsing and business processing unit. The top layer is the business application, which outputs monitoring data to a time-series database.

[0098] Device Resource Mapping Management Unit

[0099] This unit is the system's global resource directory center, and its structure is as follows: Figure 2 The left side shows a module consisting of three sub-modules. First is the key-value storage module, employing a hybrid skip list hash structure in memory. The device ID is used as the key, and each key maps to a composite structure containing the application layer protocol type, transmission mode type, hardware channel number, and last heartbeat timestamp. This hybrid structure allows for an average query latency of less than 10 microseconds even with 5000 devices. Second is the hardware channel auto-encoding module, which performs a complete hardware scan during system startup: for PCIe multi-serial port cards, it obtains the controller's physical address by reading the BAR0 base address register in the PCI configuration space; for USB Bluetooth adapters, it obtains their path information by parsing the USB bus topology descriptor; and for network cards, it reads the MAC address. The system encodes these three types of physical address information into a unified 64-bit hardware channel code. The high 8 bits identify the interface type (e.g., 0x01 for PCIe, 0x02 for USB, 0x03 for Network), the middle 24 bits store the physical address, and the low 32 bits identify the logical port number. For example, the 5th port of the serial card located in PCIe slot 2 will be encoded as 0x010000001400000005. Finally, there is the conflict detection and remapping module. When the automatic encoding process detects that two devices are assigned the same hardware channel number, the module will trigger the ACPI_CRS method to reassign the secondary bus number of the PCI bridge, or isolate the conflicting USB device through the hub port disable command. All remapping operations are recorded in the system log for auditing.

[0100] Heterogeneous interface data acquisition unit

[0101] This unit runs entirely in kernel space and is a critical path for system data access. For example... Figure 2As shown in the lower middle section, it contains four sub-modules that operate in parallel. The interrupt aggregation and processing module registers dedicated interrupt service routines for different hardware interfaces: the network interface uses the NAPI mechanism to process DMA interrupts in batches every millisecond, rather than triggering an interrupt for each data packet; the serial port card is configured with a 256-byte deep hardware FIFO, triggering a UART DMA interrupt when the fill level exceeds 75%; Bluetooth HCI events are received through the USB URB batch transfer mechanism; GPIO is configured for edge-triggered interrupts and has a built-in software debouncing algorithm to filter repetitive level changes within 50 milliseconds, recording only stable state transitions. The shared memory data channel module reserves 2MB of contiguous physical memory in the kernel space, divided into 1024 equal-length slots, each slot consisting of a 2048-byte data area, an 8-byte hardware channel number, and an 8-byte nanosecond-level hardware timestamp. The producer (i.e., the interrupt service routine) writes data to the slot and updates the producer index through the atomic operation `smp_store_release`, while the consumer (user-space process) reads the consumer index and retrieves data through the operation `smp_load_acquire`. The entire process achieves zero-copy transfer, avoiding data copying between kernel and user space. A triple-buffered switching module serves as an emergency mechanism. When the producer's write rate consistently exceeds the consumer's processing rate by more than 50%, a third backup buffer is automatically activated. Hardware flow control is triggered via the GPIO RTS signal or TCP window closure, with the activation and switching time less than 5 microseconds.

[0102] Transmission Abstraction and Dynamic Extension Unit

[0103] Located in user space, it is the core of the system's ability to flexibly expand transmission methods. For example... Figure 2 As shown in the middle section, the standardized interface abstraction module defines four pure virtual functions: `connect` for establishing a connection, `disconnect` for disconnecting, `send` for sending data, and `receive` for receiving data. All interface parameters use fixed-length structures, eliminating virtual table pointer overhead. The pluggable implementation module compiles each transport method into an independent `.so` library file, stored in the ` / opt / softnet / transports / ` directory. Each library file exports the `register_transport` function, which returns a structure containing a pointer to the virtual function table and a version number. The atomic hot-plug module monitors the pluggable directory based on the `inotify` mechanism. When a new `.so` file is detected, it first performs SHA256 signature verification. After successful verification, it calls `dlopen` to load the file, obtains the registered functions via `dlsym`, and then uses the RCU mechanism to atomically replace the global `g_transport_table` pointer table. The old version of the library is safely unloaded after a 100-millisecond graceperiod (no session access period). The entire extension process is completed within 1 second, without affecting established session connections.

[0104] Protocol parsing and business processing unit

[0105] Running at the top level of user space, such as Figure 2 As shown on the right. The independent protocol processing module implements each application layer protocol (such as Modbus, SNMP, and the UPS) as an independent thread, employing the SCHED_FIFO real-time scheduling strategy with a priority range of 40 to 60. It binds to a specific CPU core via pthread_setaffinity_np and directly calls the transport interface through a pre-cached array of function pointers, avoiding the overhead of repeated dlsym calls. The backpressure flow control module continuously monitors the protocol thread queue. When the queue length exceeds 128 entries, it sends a TRANSPORT_PAUSE command to the transport abstraction unit, triggering the kernel module's tty_throttle or tcp_set_cork, causing the hardware to automatically send the XOFF flow control character or close the TCP window. Resumption employs an exponential backoff strategy, with an initial pause of 1 second, and subsequent pauses doubling in length up to a maximum of 32 seconds. The adaptive load balancing module collects the scheduling delay and queue depth of each protocol thread every 10 seconds, and runs a PID controller to dynamically adjust the thread priority. The controller parameters are Kp=0.1, Ki=0.01, Kd=0.05, the target queue depth is 64, and the overshoot is controlled within 20%. These parameters were found to be optimal on the ARM Cortex-A53 platform through Ziegler-Nichols tuning.

[0106] Cross-layer monitoring and self-healing unit

[0107] To ensure high system reliability, the system is deployed across kernel and user space. The session state machine module maintains five states for each device connection: IDLE, CONNECTING, CONNECTED, DISCONNECTING, and ERROR. Any state transition triggers a netlink message to notify the kernel, allowing for the reclamation or reallocation of hardware resources. The fault self-healing module, upon detecting 10 consecutive CRC check failures or a response timeout exceeding 5 seconds on a channel, first marks the channel as DEGRADED. Then, it queries the protocol registration module to obtain the device's backup redundant channel (e.g., the same device simultaneously supports RS485 and TCP dual channels). It atomically switches the session context using the RCU mechanism, maintaining data sequence number continuity and sliding window synchronization during the switchover. After the switchover is complete, a FIN packet is sent to the old channel. The entire process takes less than 100 milliseconds with a zero packet loss rate. The preventive maintenance module counts the frequency of similar faults occurring within a unit of time. When the frequency exceeds 100 times in one hour, it automatically triggers the channel to reduce its operating speed (e.g., the RS485 baud rate is reduced from 115200 to 9600). It also reports an alert to the operation and maintenance system via SNMP Trap. The Trap's OID is set to 1.3.6.1.4.1.50271.1.1.1, and the variable binding includes the channel code, fault type statistics, and suggested speed reduction parameters, thus realizing closed-loop management of fault prediction and proactive intervention.

[0108] Preferably, the device resource mapping management unit specifically includes:

[0109] The key-value storage module uses an in-memory hash table structure to record the mapping relationship between device identifier, protocol type, transmission method and hardware channel number;

[0110] The hardware channel auto-encoding module scans the PCIe configuration space, USB bus topology, and network interface physical addresses when the system starts up, and automatically generates a unique hardware channel code. The code includes an interface type identifier, a physical address identifier, and a logical port number identifier.

[0111] The conflict detection and remapping module automatically avoids conflicts when hardware resource conflicts are detected by reassigning the PCI bridge secondary bus number or disabling the USB port.

[0112] This unit serves as the global resource directory center of the system, and its structure is as follows: Figure 2The left side shows a module consisting of three sub-modules. First is the key-value storage module, employing a hybrid skip list hash structure in memory. The device ID is used as the key, and each key maps to a composite structure containing the application layer protocol type, transmission mode type, hardware channel number, and last heartbeat timestamp. This hybrid structure allows for an average query latency of less than 10 microseconds even with 5000 devices. Second is the hardware channel auto-encoding module, which performs a complete hardware scan during system startup: for PCIe multi-serial port cards, it obtains the controller's physical address by reading the BAR0 base address register in the PCI configuration space; for USB Bluetooth adapters, it obtains their path information by parsing the USB bus topology descriptor; and for network cards, it reads the MAC address. The system encodes these three types of physical address information into a unified 64-bit hardware channel code. The high 8 bits identify the interface type (e.g., 0x01 for PCIe, 0x02 for USB, 0x03 for Network), the middle 24 bits store the physical address, and the low 32 bits identify the logical port number. For example, the 5th port of a serial card located in PCIe slot 2 will be encoded as 0x010000001400000005. When the conflict detection and remapping module detects two devices assigned the same hardware channel number during the automatic encoding process, it triggers the ACPI_CRS method to reassign the secondary bus number of the PCI bridge, or isolates the conflicting USB device via a hub port disable command. All remapping operations are logged to the system log for auditing.

[0113] The heterogeneous interface data acquisition unit specifically includes:

[0114] The interrupt aggregation processing module registers service routines for DMA interrupts from the network interface, UART interrupts from the serial port, HCI event interrupts from Bluetooth, and level change interrupts from GPIO, and uses interrupt merging technology to process high-frequency interrupts in batches.

[0115] The shared memory data channel module creates a circular buffer in kernel space, implements producer-consumer data transfer through lock-free CAS operations, and uses memory barrier instructions to ensure data visibility under multi-core CPU architecture.

[0116] The triple buffering module automatically activates the third backup buffer and triggers hardware flow control when the data write rate exceeds the processing rate to prevent data overflow and loss.

[0117] This unit runs entirely in kernel space and is the critical path for system data access. It consists of three parallel sub-modules. The interrupt aggregation and processing module registers dedicated interrupt service routines for different hardware interfaces: the network interface uses the NAPI mechanism, processing DMA interrupts in batches every millisecond, rather than triggering an interrupt with each data packet; the serial port card is configured with a 256-byte deep hardware FIFO, triggering a UART DMA interrupt when the fill level exceeds 75%; Bluetooth HCI events are received via the USB URB batch transfer mechanism; GPIO is configured for edge-triggered interrupts and has a built-in software debouncing algorithm to filter repetitive level changes within 50 milliseconds, recording only stable state transitions. The shared memory data channel module reserves 2MB of contiguous physical memory in kernel space, divided into 1024 equal-length slots. Each slot consists of a 2048-byte data area, an 8-byte hardware channel number, and an 8-byte nanosecond-level hardware timestamp. The producer (i.e., the interrupt service routine) writes data to the slot and updates the producer index through the atomic operation `smp_store_release`, while the consumer (user-space process) reads the consumer index and retrieves data through the operation `smp_load_acquire`. The entire process achieves zero-copy transfer, avoiding data copying between kernel and user space. A triple-buffered switching module serves as an emergency mechanism. When the producer's write rate consistently exceeds the consumer's processing rate by more than 50%, a third backup buffer is automatically activated. Hardware flow control is triggered via the GPIO RTS signal or TCP window closure, with the activation and switching time less than 5 microseconds.

[0118] The transmission abstraction and dynamic expansion unit specifically includes:

[0119] The standardized interface abstraction module defines an abstract interface that includes four basic operations: connection, disconnection, sending, and receiving. The interface parameters use a fixed-length structure to eliminate the overhead of dynamic dispatch.

[0120] The module is implemented in a plug-in manner, with independent dynamic link libraries compiled for each transmission method. The library files export registration functions for loading at runtime.

[0121] The atomic hot-plug module loads dynamic libraries based on file system monitoring events, atomically updates the global interface function pointer table through the RCU mechanism, and safely unloads the old version library after the session-free access period, achieving second-level expansion without affecting online services.

[0122] The Transmission Abstraction and Dynamic Extension Unit, located in user space, is the core of the system for flexibly extending transmission methods and consists of three sub-modules. The Standardized Interface Abstraction module defines four pure virtual functions: `connect` for establishing a connection, `disconnect` for disconnecting, `send` for sending data, and `receive` for receiving data. All interface parameters use fixed-length structures, eliminating virtual table pointer overhead. The Plug-in Implementation module compiles each transmission method into an independent .so library file, stored in the ` / opt / softnet / transports / ` directory. Each library file exports the `register_transport` function, which returns a structure containing a pointer to the virtual function table and a version number. The Atomic Hot-plug module monitors the plugin directory based on the `inotify` mechanism. When a new .so file is detected, it first performs SHA256 signature verification. After successful verification, it calls `dlopen` to load the file, obtains the registration function via `dlsym`, and then uses the RCU mechanism to atomically replace the global `g_transport_table` pointer. The old version of the library is safely unloaded after a 100-millisecond grace period (no session access period). The entire extension process is completed within 1 second, without affecting established session connections.

[0123] The protocol parsing and business processing unit specifically includes:

[0124] The independent protocol processing module runs each application layer protocol on an independent thread, adopts a real-time scheduling strategy and is bound to a CPU core, and directly calls the transmission interface through a pre-cached array of function pointers;

[0125] The backpressure flow control module sends a pause command to the transmission abstraction unit when the queue of pending processing of the protocol thread exceeds the threshold, triggering the pause of data reception and the transmission of flow control signals in the hardware interface;

[0126] The adaptive load balancing module periodically collects the scheduling latency and queue depth of each protocol thread, and dynamically adjusts thread priority and CPU affinity through a PID control algorithm.

[0127] The protocol parsing and business processing unit runs at the top layer of user space and consists of three sub-modules. The independent protocol processing module implements each application layer protocol (such as Modbus, SNMP, and the General Electricity Protocol) as an independent thread, employing a SCHED_FIFO real-time scheduling strategy with a priority range of 40 to 60. It binds to the CPU core via pthread_setaffinity_np and directly calls the transport interface through a pre-cached array of function pointers, avoiding the overhead of repeated dlsym calls. The backpressure flow control module continuously monitors the protocol thread queue. When the queue length exceeds 128 entries, it sends a TRANSPORT_PAUSE command to the transport abstraction unit, triggering the kernel module's tty_throttle or tcp_set_cork, causing the hardware to automatically send the XOFF flow control character or close the TCP window. Resumption employs an exponential backoff strategy, with an initial pause of 1 second, and subsequent pauses doubling in length up to a maximum of 32 seconds. The adaptive load balancing module collects the scheduling delay and queue depth of each protocol thread every 10 seconds, and runs a PID controller to dynamically adjust the thread priority. The controller parameters are Kp=0.1, Ki=0.01, Kd=0.05, the target queue depth is 64, and the overshoot is controlled within 20%. These parameters were found to be optimal on the ARM Cortex-A53 platform through Ziegler-Nichols tuning.

[0128] Preferably, the system further includes:

[0129] The cross-layer session state machine module defines four states: connection establishment, data transmission, abnormal disconnection, and resource release. State transitions trigger bidirectional notifications between kernel and user space.

[0130] The fault self-healing module automatically queries redundant backup channels and performs seamless session context switching when it detects continuous channel abnormalities. During the switching process, the data sequence number is kept continuous and the sliding window is synchronized.

[0131] The preventive maintenance module counts the frequency of similar faults occurring within a unit of time. When the frequency exceeds a preset threshold, it automatically triggers the channel to reduce its operating speed and reports an early warning.

[0132] In this embodiment, the cross-layer session state machine module and the fault self-healing module, as guarantees of high system reliability, are deployed across kernel and user space and consist of three sub-modules. The session state machine module maintains five states for each device connection: IDLE, CONNECTING, CONNECTED, DISCONNECTING, and ERROR. Any state transition triggers a netlink message to notify the kernel, reclaiming or reallocating hardware resources. When the fault self-healing module detects 10 consecutive CRC check failures or a response timeout exceeding 5 seconds for a certain channel, it first marks the channel as DEGRADED, then queries the protocol registration module to obtain the device's backup redundant channel (e.g., the same device simultaneously supports RS485 and TCP dual channels), atomically switches the session context through the RCU mechanism, maintaining data sequence number continuity and sliding window synchronization during the switching process. After the switch is completed, a FIN packet is sent to the old channel. The entire process takes less than 100 milliseconds with a packet loss rate of zero. The preventive maintenance module counts the frequency of similar faults occurring within a unit of time. When the frequency exceeds 100 times in one hour, it automatically triggers the channel to reduce its operating speed (e.g., the RS485 baud rate is reduced from 115200 to 9600). It also reports an alert to the operation and maintenance system via SNMP Trap. The Trap's OID is set to 1.3.6.1.4.1.50271.1.1.1, and the variable binding includes the channel code, fault type statistics, and suggested speed reduction parameters, thus realizing closed-loop management of fault prediction and proactive intervention.

[0133] Preferably, the soft network system is deployed on an industrial control computer configured with an ARM Cortex-A53 multi-core processor and a Linux kernel, supporting simultaneous access to more than 1,000 heterogeneous environmental devices and more than 15 application layer protocols. When adding a new transmission method plugin, the average time is less than 1 second, the average time for fault channel switching is less than 100 milliseconds, the peak CPU utilization is less than 65%, and the memory usage is less than 2GB.

[0134] Reference Figure 3 The illustrated method for implementing a scalable transmission mode in a software network, running on the aforementioned software network system, includes the following steps:

[0135] S1. Establish the mapping relationship between devices and channels: Scan the native hardware interface of the computing device, automatically generate a unique hardware channel code, and create an association mapping table between device identifier, protocol type, transmission method and hardware channel;

[0136] This step is specifically executed once during system startup initialization, laying the foundation for resource addressing for all subsequent data interactions. First, the system calls the `pci_scan_bus` function provided by the Linux kernel to traverse the PCIe bus and read the configuration space header of each bridge and endpoint device. For detected multi-serial port cards (such as the OXPCIe958 chip), the `Base Address Register 0` (BAR0) field in its Type 0 configuration header is parsed to obtain the base address of the serial port controller mapped to memory space. Combined with the device's bus number, device number, and function number in the PCI topology, a 24-bit physical address identifier is generated. Next, the `libusb_get_device_list` function of the libusb library is called to enumerate the USB bus, obtaining the bus number and device path level for each Bluetooth adapter, forming a USB topology description string, which is then compressed into a 24-bit identifier through hashing. For onboard network cards, the `IFHWADDR` is obtained via the `ioctl` system call, and the 48-bit MAC address is directly extracted as a unique identifier. Finally, the physical address identifier is concatenated with the logical port number (such as ports 0-31 of a serial card, the TCP port number of a network card, and the L2CAP channel number of Bluetooth) to generate a 64-bit hardware channel code. The encoding format is: high 8 bits for interface type, middle 24 bits for physical address, and low 32 bits for logical port. For example, the encoding of port 5 of the serial card in PCIe slot 2 is 0x010000001400000005. Simultaneously, the system loads the ` / etc / softnet / devices.json` configuration file, parses the text fields for each device's ID, supported protocol (modbus-rtu / snmp / private protocol), and default transmission method (RS485 / TCP / Bluetooth), and maps the text to enumerated integer values. Then, a skip list hash hybrid structure is created in memory, with the skip list level randomly set to 1 to 4 levels. The hash function uses MurmurHash3 to hash the device ID, and the device ID, protocol enumeration value, transmission method enumeration value, and hardware channel code are combined into a quadruple and inserted into this structure. If a key conflict is detected during insertion (i.e., two device IDs hash to the same slot), the conflict detection and remapping module is triggered: for PCIe address conflicts, the pci_assign_resource function is called to reassign the bridge secondary bus number; for USB path conflicts, libusb_detach_kernel_driver is called to disable the conflicting device and generate an alarm log. After all devices have been entered, the mapping table provides a query service interface to user space. This interface is exposed through system calls for subsequent steps.

[0137] S2. Parallel acquisition of heterogeneous interface data: Register multiple hardware interrupt service routines in the kernel space, and transfer the raw data to the user space in a zero-copy manner through a circular buffer;

[0138] This step is specifically as follows: This step starts immediately after the mapping table is established and continues to run throughout the system lifecycle, responsible for converting the physical layer bit stream into a memory byte stream. The system registers independent interrupt service routines for each hardware interface: the network interface registers a DMA interrupt handler function `net_rx_isr` via `request_irq`, which disables interrupts, starts the NAPI polling mechanism, processes multiple packets in batches using the `napi_struct` structure, and finally calls `dma_sync_single_for_cpu` to ensure cache consistency before writing the `sk_buff` data pointer to shared memory; the serial port card registers `uart_isr`, which is triggered when the 256-byte FIFO fill level reaches 75%, the ISR reads the UART_USR register to confirm data readiness, and calls `dma_async_memcpy_buf_to_buf` to copy the FIFO contents in batches to the shared memory slot; Bluetooth registers an HCI event interrupt via `usb_submit_urb`, parses the event type in the urb completion callback function, and directly transfers ACL data if it is ACL data; GPIO registers an edge interrupt via `gpio_request`, reads `gpio_value` from the ISR and debouncing it. All ISRs share a single ring buffer management function, `ring_buffer_produce`. This function uses `atomic_add_return` to implement lock-free CAS operations to update the producer index and calls `smp_store_release` to ensure that the data write order is visible to multi-core CPUs. The consumer side of the shared memory ring buffer is implemented by the user-space `receive` function. This function calls `smp_load_acquire` to read the consumer index. If the index is not equal to the producer index, it directly returns the slot pointer, achieving zero-copy reading. When the producer index leads the consumer by more than 512 slots (i.e., 50% capacity), the triple-buffer rotation module is activated: it allocates a third memory page as an emergency buffer, calls `gpio_set_value` to switch the RTS flow control pin level, or calls `tcp_cork` to block TCP receive, forcing the hardware to pause transmission to prevent overflow.

[0139] S3. Abstraction and isolation of transmission implementation: Load control logic for different transmission methods in user space as a plug-in, provide standardized calling interfaces to upper-layer protocols, and decouple transmission methods from protocol parsing;

[0140] This step specifically involves initialization after receiving data in step S2, establishing the decoupling relationship between the protocol and transmission. During system startup, the ` / opt / softnet / transports / ` directory is scanned, and each `.so` file is loaded using `dlopen`. Then, `dlsym` obtains the symbol address of `register_transport`, executes this function to obtain a structure. The first member of the structure is a pointer to the virtual function table, containing pointers to four functions: `connect`, `disconnect`, `send`, and `receive`. The second member is the version number. The system stores the virtual function table pointer in the global `g_transport_table` array, with the array index being the transmission mode enumeration value. When the protocol parsing unit needs to send data, it first calls the query interface of the device resource mapping management unit to obtain the transmission mode enumeration value and hardware channel code based on the device ID. Then, using the enumeration value as the index, it retrieves the virtual function table pointer from `g_transport_table` and directly calls the `send` function, passing in the hardware channel code and data payload. Internally, the `send` function uses the JNI (Java Native Interface) mechanism or pure C function calls, ultimately interacting with the kernel driver via `ioctl` to complete the physical layer transmission. The `receive` function executes the reverse process: after reading data from shared memory, it notifies the protocol thread via a callback function. Since all transmission methods implement the same interface, the protocol thread doesn't need to know whether the underlying technology is RS485 or TCP, achieving complete decoupling.

[0141] S4. Dynamically expandable transmission capabilities: Monitor changes in the plugin directory during system operation and load new transmission method plugins through an atomic update mechanism to complete the expansion without restarting the service;

[0142] This step involves continuous background monitoring during system operation to achieve uninterrupted expansion. The atomic hot-plug module creates an inotify instance and monitors the IN_CREATE and IN_CLOSE_WRITE events in the / opt / softnet / transports / directory. When a new .so file is detected being written and closed, the event loop reads the filename, calculates its SHA256 hash value, and compares it with the value in the .sig signature file with the same filename. If they do not match, loading is rejected and a security log is recorded. After successful verification, dlopen(RTLD_NOW|RTLD_LOCAL) is called to load the library, and then dlsym is executed to obtain the register_transport function pointer. This function is then called to obtain the new virtual function table. At this point, the atomic hot-plug module allocates a new memory page, copies the contents of the original g_transport_table, updates the corresponding index with the new pointer, and then calls rcu_assign_pointer to atomically replace the global pointer. The old table enters the RCU grace period. After all CPU cores complete the quiet period through synchronize_rcu, the old table memory is released. The uninstallation process is similar: deleting the .so file triggers the IN_DELETE event, the system sets the corresponding table entry to NULL, and the library is uninstalled after the grace period. The entire loading or uninstallation process has no impact on established sessions. New sessions immediately use the new transmission method, and old sessions continue to run until they terminate naturally, achieving second-level expansion and zero service interruption.

[0143] S5. Adaptive scheduling and fault self-healing: Dynamically adjust resource allocation according to the protocol to handle the load, and automatically switch to redundant channels when a channel failure is detected to ensure business continuity.

[0144] This step is specifically as follows: This step is carried out throughout the entire system operation, continuously monitoring and optimizing resource allocation. The adaptive load balancing module creates a timer, triggering a sampling callback every 10 seconds. In the callback function, `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` is called for each protocol thread to obtain CPU time, calculate scheduling latency, and read its pending queue length. The latency error and queue depth are used as inputs to the PID controller, and the controller output is the priority adjustment amount. `pthread_setschedparam` is called to modify thread priorities, and `pthread_setaffinity_np` is called to migrate threads to CPU cores with lighter loads. IRQ affinity is adjusted simultaneously, and the interrupt number is written to ` / proc / irq / IRQ_NUMBER / smp_affinity` to make the interrupt and processing threads co-core, reducing cache synchronization overhead.

[0145] The fault self-healing module checks the CRC check result or response timeout timer after processing each packet in the `receive` function. If 10 consecutive checks fail or the timer expires after 5 seconds, the session state machine is transitioned from `CONNECTED` to `ERROR`, triggering a state change callback. The callback function queries the device resource mapping management unit to check if the device has a backup channel configured (e.g., two hardware channel codes corresponding to the same device ID in the mapping table). If so, a new session structure is created, and the receive sequence number, send sequence number, and sliding window size of the original session are copied to the new session. The `connect` function of the new channel is called to establish a connection. Upon successful connection, the data transmission and reception routes are switched to the new session. Finally, the old session is destroyed, and a `netlink` notification is sent to the kernel to release the old channel resources. The entire switching process is completed within 100 milliseconds. Data sequence number continuity is guaranteed by the copying of the session structure, and the upper-layer protocol is unaware of this.

[0146] When the preventative maintenance module detects more than 100 CRC errors on a channel within a 1-hour sliding time window, it triggers a rate reduction decision. The module calls the `set_baudrate` function (if applicable) of the channel's transmission plugin to halve the baud rate and simultaneously constructs an SNMPTrap message.

[0147] The Trap OID is fixed at 1.3.6.1.4.1.50271.1.1.1. The variable binding list varbind contains the channel code (Opaque type), error count (Counter32 type), and new rate (Integer32 type), and is sent to the operations and maintenance platform via snmp_send_trap. If the error rate still increases after the rate reduction, it is marked as a permanent fault, awaiting manual intervention.

[0148] The above five steps are seamlessly integrated through carefully designed control flow and data flow transformations. After the mapping table is constructed in step one, the mapping table handle is passed to step two via the ioctl system call. When the interrupt service routine writes to shared memory, it fills the hardware channel number field of the slot with the query result of this handle, realizing the transformation from resource discovery to data acquisition. After the producer index is updated in step two, a kernel event (such as eventfd_write) is triggered, notifying the user-space receiving function in step three that data is ready, realizing asynchronous notification from the kernel to user space. When loading the plugin in step three, the virtual function table address is registered to the global g_transport_table in step four. Step four uses atomic substitution to make the new function pointer immediately visible to step three, completing the immediate effect of the extension. After the PID controller adjusts the priority in step five, it writes the new affinity mask to shared memory. The interrupt aggregation processing module in step two reads this mask and updates the IRQ affinity, realizing closed-loop feedback from the scheduling policy to the underlying interrupt. After the fault self-healing module switches channels, it updates the active channel field in the mapping table of step one. Subsequent queries in step three are automatically routed to the new channel, forming a self-healing and adaptive complete control loop. All steps share a synchronization mechanism based on RCU and memory barriers to ensure data consistency and operational atomicity in a multi-core parallel environment.

[0149] Preferably, the steps for establishing the mapping relationship between devices and channels specifically include:

[0150] Parse the base address register of the PCIe configuration space to obtain the serial port controller address;

[0151] Parse the USB bus descriptor to obtain the Bluetooth adapter topology path;

[0152] The physical address and logical port number are combined to generate a 64-bit hardware channel code;

[0153] The mapping relationship is stored in an in-memory hash table and a concurrent query interface is provided.

[0154] In this embodiment, Example 1: Preferred implementation of establishing the mapping relationship between devices and channels

[0155] This embodiment details the complete execution flow of establishing the device-channel mapping relationship. This step, as the core of system initialization, lays the resource addressing foundation for all subsequent data interactions. The entire process is implemented through four sub-stages: hardware layer scanning, physical address extraction, encoding combination, and memory persistence. Each stage strictly adheres to the Linux kernel driver specification and the PCI / USB bus standard.

[0156] First, the PCIe configuration space resolution process is executed. During the startup phase, the system calls the `pci_scan_bus` function provided by the Linux kernel. This function performs a depth-first traversal of the PCIe bus hierarchy starting from root bus number 0, reading the configuration space for each device slot on each bus. For the detected OXPCIe958 and other multi-serial port controller chips (vendor ID 0x1415, device ID 0xC158), the system reads the Base Address Register 0 (BAR0) field from its Type 0 configuration header. Bit 0 of the BAR0 field is used to identify the mapping type (0 indicates memory mapping, 1 indicates I / O mapping), bits 2 to 1 indicate the address width (01 indicates 32 bits, 10 indicates 64 bits), and bits 3 to 31 store the most significant bits of the base address. By calling the `pci_resource_start` function, the system extracts the physical base address of the serial port controller mapped to memory space from BAR0, typically 0xE0000000. By combining the bus number (8 bits), device number (5 bits), and function number (3 bits) of the device in the PCI topology, the system generates a 24-bit physical address identifier, where the high 8 bits are the bus number, the middle 8 bits are the device number, and the low 8 bits are a combination of the function number and the BAR index, ensuring that each PCIe device has a unique address identity.

[0157] Next, the USB bus topology resolution process is executed. The system first calls the `libusb_init` function of the `libusb` library to initialize the USB context environment and obtain system USB resource handles. Then, it calls the `libusb_get_device_list` function to enumerate the entire USB bus, returning a linked list structure of all USB devices. For each Bluetooth adapter (its device class code `Class=0xE0`, subclass `SubClass=0x01`, protocol `Protocol=0x01`), the system calls `libusb_get_device_descriptor` to obtain the device descriptor, calls `libusb_get_config_descriptor` to obtain the configuration descriptor, and recursively resolves the interface descriptor and endpoint descriptor to construct the complete topology path string for the device. A typical format is "bus-1 / 2 / 3-port1-port2", indicating that the device is located on bus 1 and cascaded through ports 2 and 3 of a hub. The system inputs this topology path string into the MurmurHash3 hash algorithm for calculation, generating a 32-bit hash value, and extracts 24 bits as the physical address identifier, ensuring that Bluetooth adapters with different topology paths receive a unique code. For onboard network cards, the system creates a PF_INET protocol family socket through the socket function, calls the ioctl function and passes the SIOCGIFHWADDR parameter to obtain the ifreq structure, directly extracts the 48-bit MAC address from the ifr_hwaddr.sa_data field, and truncates the lower 24 bits as the physical identifier to ensure the unique identification of the network interface.

[0158] Then, the 64-bit hardware channel encoding generation process is executed. The system creates an encoding combination function that accepts three input parameters: an interface type enumeration value (1 for PCIe, 2 for USB, and 3 for Network), a 24-bit physical address identifier, and a 32-bit logical port number. Internally, the function performs bitwise operations: the interface type enumeration value is left-shifted by 56 bits, the physical address identifier is left-shifted by 32 bits, and the logical port number remains unchanged. These three values ​​are then ORed to generate the final 64-bit hardware channel encoding. For example, for port 5 of the serial card in PCIe slot 2, left-shifting interface type 1 by 56 bits yields 0x0100000000000000, left-shifting physical address 0x14000000 by 32 bits yields 0x0000001400000000, and logical port 5 is 0x0000000000000005. The combined encoding is 0x010000001400000005. This encoding rule ensures that each hardware interface type, each physical device instance, and each logical port number obtains a globally unique channel identifier.

[0159] Finally, the mapping relationship storage and interface exposure process is executed. The system creates a skip list hash hybrid structure in memory. The skip list level is randomly determined between levels 1 and 4 using a random number generator. The hash function uses the MurmurHash3 algorithm to hash the device ID string, and the main slot is located by modulo operation. Collisions are resolved using chaining. Each hash slot is attached to a singly linked list. The system encapsulates the device ID string, protocol enumeration value, transmission mode enumeration value, and 64-bit hardware channel code into a structure and inserts it into the hash table. To ensure data consistency in a multi-core CPU environment, the system creates a memory barrier protection zone. The smp_wmb() instruction is called before and after writing to the hash table to ensure that the write order is visible to all processor cores. The system exposes the mmap interface through the character device driver / dev / softnet_map. User-space processes can map the hash table as a read-only view by calling the mmap system call, thereby providing high-concurrency query capabilities. The query interface function receives the device ID string as an input parameter and returns a pointer to a four-tuple structure. The average query latency is controlled within 10 microseconds, which meets the real-time query requirements in high-throughput scenarios.

[0160] Preferably, the parallel acquisition of heterogeneous interface data steps specifically include:

[0161] A batch processing strategy is used to handle network DMA interrupts, processing them in batches every millisecond.

[0162] The serial UART interrupt triggers DMA batch transfer, and the transfer starts when the hardware FIFO is filled to 75%.

[0163] Lock-free CAS operations are used to update the circular buffer index, and memory barriers are used to ensure data order.

[0164] When the write rate exceeds the processing rate, a triple-buffering rotation mechanism is activated.

[0165] In this embodiment, Example 2: Preferred Implementation of Parallel Acquisition of Heterogeneous Interface Data

[0166] This embodiment describes in detail the specific technical implementation of the parallel acquisition of heterogeneous interface data steps, ensuring efficient aggregation of multi-source data without lock contention.

[0167] Network DMA interrupt handling employs the NAPI (New API) mechanism. The system registers the `net_rx_isr` interrupt service routine via the `request_irq` function. Within this routine, `__disable_irq` is first called to disable interrupts and prevent interrupt storms. Then, `napi_schedule` is called to add the pre-allocated `napi_struct` structure to the polling queue, triggering a soft interrupt. In the `napi_poll` callback function, the system repeatedly calls the `dma_rx_scan` function, processing up to 16 DMA descriptors in batches each time. It extracts the physical address from the DMA circular descriptor queue, calls `dma_sync_single_for_cpu` to ensure DMA cache data is synchronized with the CPU cache, obtains the `sk_buff` data pointer, and writes the `skb->data` pointer, data length, and hardware channel code (extracted from a custom field in the RX descriptor by the network card driver) to the shared memory slot. After processing, `napi_complete` is called to end polling and re-enable interrupts. The interrupt merging strategy is configured using the ethtool tool. Executing ethtool -C eth0 rx-usecs 1000 sets the merging time to 1000 microseconds, ensuring that interrupts are processed in batches every millisecond.

[0168] The UART interrupt handling uses a FIFO threshold triggering method. The system configures the UART_FCR register (FIFO control register) of the OXPCIe958 chip, setting the trigger threshold to 192 bytes (corresponding to 75% of a 256-byte FIFO). When the received data in the FIFO reaches the threshold, the hardware automatically triggers an IRQ interrupt. The interrupt service routine uart_isr first reads the UART_LSR register (line status register), confirming that the DR (Data Ready) bit is 1, and then reads the UART_USR register (status register), confirming that the TFF (Transmit FIFO Full) bit is 0, ensuring safe access to the receive FIFO. The system calls dma_async_memcpy_buf_to_buf to start the DMA engine, setting the source address to the I / O memory mapping address of the UART_RHR register (receive holding register), the destination address to the data area of ​​the shared memory slot, and the length register to 256 bytes, triggering batch data transfer. After the DMA transfer is completed and an interrupt is triggered, the hardware channel number field of the slot is filled with a pre-calculated encoded value in the dma_callback function, and the timestamp field is filled with the kernel nanosecond timestamp returned by kmet_get_ns().

[0169] Lock-free CAS operations are used to achieve producer-consumer synchronization. The system defines a circular buffer structure containing `producer_idx` and `consumer_idx` members of type `uint64_t`, and a slot array `slots

[1024]

[2048] `. The producer (interrupt context) calls `atomic_add_return(1, &producer_idx)` to atomically increment and return the new index value. It then uses the index value modulo 1024 to locate the target slot. After writing data, it calls `smp_store_release(&slot->ready,1)` to set the ready flag. This memory barrier instruction ensures that the data write order is visible to multi-core CPUs. The consumer (user-space process) calls `atomic_read(&consumer_idx)` to get the current index value, loops through the `slot->ready` flag, and uses the `smp_load_acquire` memory barrier instruction to ensure that the latest data is read. After processing, it calls `atomic_add_return(1, &consumer_idx)` to advance the consumer index. The entire process requires no spinlocks or semaphores and relies entirely on memory barriers to ensure sequential consistency, making it particularly suitable for high-concurrency scenarios using the ARM Cortex-A53 multi-core architecture.

[0170] The triple-buffering switching mechanism is activated when the main circular buffer utilization exceeds the 75% threshold. The system pre-allocates a third memory page as an `emergency_buffer` and creates a boolean flag `use_emergency`. When the `produce` function detects that the number of free slot bits is less than 256, it sets the `use_emergency` flag to `true`, and subsequent production operations switch to the `emergency_buffer`. Simultaneously, for the RS485 interface, `gpio_set_value(rts_gpio,1)` is called to pull the RTS flow control pin high, enabling the transmitter's DE (Driver Enable) driver, causing the receiver to enter a high-impedance state and automatically stopping transmission. For the TCP interface, `tcp_set_cork(fd,1)` is called to close the TCP sliding window, stopping transmission at the other end. After detecting that the `use_emergency` flag is `true`, the consumer reads data from the `emergency_buffer`. When the pressure on the main buffer eases, it resumes reception via `gpio_set_value(rts_gpio,0)`. The switching process takes less than 5 microseconds, effectively preventing data overflow and loss.

[0171] The specific steps for dynamically expanding transmission capacity include:

[0172] The plugin directory is monitored via inotify, and SHA256 signature verification is performed when a new dynamic library file is detected.

[0173] Call dlopen to load the library file, and execute dlsym to obtain the registration function pointer;

[0174] The global function pointer table is atomically replaced using the RCU mechanism and unloaded after the old library has no session access.

[0175] The extension process is completed within 100ms and has no impact on established connections;

[0176] In this embodiment, Example 3: Preferred Implementation of Dynamically Expanded Transmission Capability

[0177] This embodiment describes in detail the complete process of runtime hot-swappable transfer plug-in, ensuring that the extension operation has atomicity and security.

[0178] The inotify monitoring mechanism creates a non-blocking monitoring instance using the inotify_init1(IN_NONBLOCK) function and sets the monitoring path to the / opt / softnet / transports / directory using the inotify_add_watch function. The event mask is configured as IN_CREATE | IN_CLOSE_WRITE, capturing file creation and write completion events respectively. The system creates an epoll instance and adds the file descriptor returned by inotify to epoll monitoring. In the main event loop, epoll_wait waits for inotify events to be ready. When a new .so plugin file is copied to the monitoring directory, the IN_CREATE event is triggered first; the system records the filename but does not process it immediately. When the application completes the file writing and closes the file descriptor, the IN_CLOSE_WRITE event is triggered, indicating that the file content has been completely written to disk; only then does the system start the loading process.

[0179] The signature verification process ensures the plugin's origin is trustworthy. The system reads the complete content of the .so file and calculates its hash value using SHA256_Init, SHA256_Update, and SHA256_Final. Simultaneously, it searches for a signature file with the same filename and .sig extension as the plugin in the same directory and reads its binary content. The system pre-installs the RSA public key in the / etc / softnet / pubkey.pem file, parses the public key object using PEM_read_bio_RSA_PUBKEY, and calls RSA_verify to decrypt and verify the .sig file, obtaining the expected hash value. The calculated file hash value is compared byte-by-byte with the decrypted hash value. If they do not match, loading is rejected, and a security alert is logged via syslog at the LOG_AUTHPRIV level to prevent maliciously modified plugins from infiltrating the system.

[0180] The dynamic library loading and symbol resolution process is implemented through the standard API. After successful verification, the system calls the `dlopen(path, RTLD_NOW | RTLD_LOCAL)` function to immediately load the library file. The `RTLD_NOW` flag ensures that all undefined symbols are resolved immediately upon loading, while the `RTLD_LOCAL` flag limits the visibility of symbols to the current library scope, avoiding global symbol pollution. The system calls `dlsym(handle, "register_transport")` to obtain the registration function pointer. This function's prototype is `int (*register)(transport_vtable_t *vt, uint32_t *version)`, where the `transport_vtable_t` structure contains four function pointer members: `connect`, `disconnect`, `send`, and `receive`. When the registration function is called, the system allocates a structure on the stack, passes in the pointer, and the function internally assigns the function pointer for the specific transport method to the structure members and returns the version number.

[0181] Atomic hot-plug updates are implemented via RCU. The system allocates a new memory page as a copy of `g_transport_table`, and calls `memcpy` to copy all entries from the original table to the new page. At the corresponding transport mode, the newly acquired virtual function table pointer is assigned and replaced. `rcu_assign_pointer(g_transport_table, new_table)` is called to perform atomic pointer replacement. This function internally includes an `smp_wmb` write memory barrier to ensure the new table content is visible to multi-core CPUs before atomically updating the pointer. The old table is handled by a callback function scheduled via `call_rcu`. After all CPU cores have undergone a silent period (waiting via `synchronize_rcu`), the callback function executes `kfree` to release the old table memory. The unloading of the old library is controlled by the reference counting mechanism of `dlclose`. Only when all sessions have called `disconnect` to release references and the count drops to 0, is the library file truly unloaded from the process address space.

[0182] The impact of the extension process on established sessions is strictly controlled. Calling the `connect` function increments the library reference count, while calling the `disconnect` function decrements it. Unloading is only allowed if the count is zero; otherwise, unloading is delayed. New sessions use the new library immediately upon establishment. Old sessions may execute old library code on subsequent calls, but the RCU grace period ensures that old library memory pages remain valid within the grace period, preventing segmentation faults. Extension time measurement: The average time from the triggering of the `IN_CLOSE_WRITE` event to the availability of the `connect` function is 850 milliseconds, including approximately 200 milliseconds for SHA256 calculation, approximately 300 milliseconds for `dlopen` loading and symbol resolution, and approximately 350 milliseconds for the RCU grace period. During this period, the ping latency of established TCP sessions remained within 5 milliseconds, with no significant performance jitter, demonstrating that the extension process has no impact on online services.

[0183] The adaptive scheduling and fault self-healing steps specifically include:

[0184] Periodically collect protocol thread scheduling delay and queue depth, and adjust thread priority using a PID algorithm;

[0185] When a channel fails, the connection is rebuilt in a new channel and the session context (data sequence number, window size) is synchronized.

[0186] After the handover is complete, a FIN is sent to terminate the old channel, and the packet loss rate during the handover process is zero.

[0187] When the frequency of a certain type of fault exceeds a threshold, the channel is triggered to slow down and an SNMP Trap warning is sent.

[0188] In this embodiment, Example 4: Preferred Implementation of Adaptive Scheduling and Fault Self-Healing

[0189] This embodiment describes in detail the intelligent scheduling and fault recovery mechanism to ensure the stability and continuity of the system under high load and fault scenarios.

[0190] The adaptive load balancing PID controller triggers sampling and adjustment every 10 seconds. The system creates a high-precision timer with a timeout of 10 seconds, and executes the scheduling logic in the `timer_callback` function. For each protocol processing thread, `clock_gettime(CLOCK_THREAD_CPUTIME_ID, &start)` is called to obtain the thread's CPU time, and `clock_gettime(CLOCK_MONOTONIC, &now)` is called to obtain the current monotonic time. The scheduling latency is calculated as `latency = (now.tv_sec - start.tv_sec) * 1000000 + (now.tv_nsec - start.tv_nsec) / 1000`, yielding a microsecond-level latency value. The thread-private pending queue depth is read. The latency error (latency_error = latency - 50us) and queue depth error (depth_error = depth - 64) are used as inputs to the PID controller. The proportional term is calculated as Kp * error, the integral term as Ki * error * 10s, and the derivative term as Kd * (error - prev_error) / 10s. The output adjustment is calculated as: adjust = proportional + integral + derivative. If adjust is positive, pthread_setschedparam is called to increase the thread priority to SCHED_FIFO:50; if negative, the priority is decreased. pthread_setaffinity_np is called to migrate the thread to a less loaded CPU core, and the interrupt number is written to / proc / irq / IRQ_NUMBER / smp_affinity to bind the hardware interrupt to the same core, reducing cross-core cache synchronization overhead. The PID parameters Kp=0.1, Ki=0.01, Kd=0.05 were optimally measured on the ARM Cortex-A53 platform using the Ziegler-Nichols tuning method, which is suitable for the mixed load characteristics of sudden and periodic environmental monitoring data.

[0191] Self-healing session context synchronization is performed during channel switching. When the receive function returns CRC check failures 10 times consecutively or the response timeout exceeds 5 seconds, the main session structure transitions from CONNECTED to ERROR, triggering a state change callback. The callback function first queries the device resource mapping management unit to retrieve the backup channel code based on the device ID (the same device can correspond to multiple channel quadtuples in the mapping table). It then allocates a new session structure and calls memcpy(&new_sess->context, &old_sess->context, sizeof(context)) to completely copy the original session's receive sequence number rx_seq, transmit sequence number tx_seq, sliding window size window_size, MSS, and other fields. Finally, it calls the connect function of the backup channel transmission plugin, passing in the new hardware channel code, to establish a physical connection.

[0192] After a successful connection, `rcu_assign_pointer(session_ptr, new_sess)` is called to atomically replace the global session pointer, and subsequent data transmission and reception are automatically routed to the new session. The old session calls `call_rcu` for delayed release, and the old channel sends a FIN packet or disconnects the physical link. During the handover, the protocol thread calling `receive` may briefly return an `EAGAIN` error; the retry mechanism ensures this is imperceptible. Handover time measurement: From the detection of the ERROR state to the receipt of the first data packet on the new channel, the average time was 87 milliseconds, including 50 milliseconds for establishing the standby channel connection, 10 milliseconds for context copying and pointer replacement, and 27 milliseconds for sending and acknowledging the FIN packet on the old channel.

[0193] Preventative maintenance-based speed reduction early warning is implemented in the fault statistics thread. The system maintains an error counter array `error_counter`, indexed by the hardware channel code. Each detected CRC check failure increments the corresponding counter by 1. A sliding time window mechanism is used, with a window length of 1 hour. The timestamp of each error is recorded in a linked list; expired timestamps are removed and the counter is decremented as the window moves. When a channel's counter value exceeds 100, a speed reduction decision is triggered: for RS485 interfaces, the `termios` setting function is called to clear the `CBAUD` bit in `c_cflag` and reset the B9600 baud rate flag, effectively halving the baud rate; for TCP interfaces, `setsockopt` is called to set the `TCP_MAXSEG` option value to half the original MSS. An SNMPTrap alarm message is constructed, setting the version to SNMPv2c, the community string to "public", the PDU type to TRAP2, the request-id to the current Unix timestamp, and the OID to a fixed 1.3.6.1.4.1.50271.1.1.1. Add three bindings to the variable binding list: the first binding has an OID of 1.3.6.1.4.1.50271.1.1.1.1, a value of type OCTET STRING, and a content of a 64-bit byte stream encoded by the hardware channel;

[0194] The second binding OID is 1.3.6.1.4.1.50271.1.1.1.2, with a value of type Counter32 and the content being the error_counter count; the third binding OID is 1.3.6.1.4.1.50271.1.1.1.3, with a value of Integer32 and the content being the reduced baud rate or MSS value. The sendto function is called to send the Trap message to UDP port 162, completing the early warning information push and realizing closed-loop management of fault prediction and proactive intervention.

[0195] Preferably, this method is applied to environmental monitoring scenarios, supports any combination of Modbus / SNMP / electrical communication protocol / private protocol with TCP / RS485 / Bluetooth / GPIO, reduces code module complexity from O(N×M) to O(N+M), and does not require recompiling the main program when expanding to new transmission methods.

[0196] Preferably, the system is deployed in the environmental monitoring environment of the computer room. By replacing the protocol conversion gateway and multiple monitoring servers in the traditional solution with a single industrial control computer, the hardware cost is reduced by more than 40% and the fault recovery time is shortened by more than 70%.

[0197] In another embodiment, an environmental monitoring data acquisition system includes the aforementioned soft network system and the aforementioned method, capable of simultaneously accessing more than 1000 heterogeneous devices and 15 protocols.

[0198] While maintaining continuous system operation, the system can perform online expansion of transmission methods and seamless switching of faulty channels.

[0199] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0200] This invention fundamentally solves the protocol and transmission adaptation challenges of environmental monitoring systems in heterogeneous equipment environments through innovative integrated hardware and software architecture, achieving cost optimization and performance leaps throughout the system's lifecycle. First, by eliminating intermediate protocol conversion gateways and directly reusing the native hardware interfaces of industrial control computers, hardware procurement and cabling costs are significantly reduced. Simultaneously, through vertical decoupling of transmission methods and protocol parsing, the software architecture complexity is reduced from a Cartesian product relationship between protocols and transmission methods to a linear summation, drastically reducing code volume and maintenance workload, and improving development iteration efficiency. Second, the innovative runtime hot-swappable mechanism supports the dynamic loading of new transmission plugins while the system is running continuously. The expansion process is completely transparent to upper-layer services, and capability upgrades can be completed in minutes without restarting the service, giving the system unprecedented flexibility and evolution capabilities. Third, the fault self-healing and redundant channel automatic switching mechanism based on a session state machine can activate backup channels and synchronize contexts in milliseconds when the primary channel fails, maintaining data continuity throughout and minimizing the impact of business interruptions, resulting in a qualitative leap in system availability. Furthermore, the single-process multi-threaded architecture replaces the traditional multi-process grouping mode, and combined with kernel-user space zero-copy and intelligent PID load balancing, significantly reduces memory and CPU resource consumption, increasing the supported device capacity by several orders of magnitude under the same hardware configuration. Finally, through cross-layer monitoring and preventive maintenance modules, the system can proactively identify potential risks and automatically trigger protection strategies, realizing a shift from passive response to proactive intervention in operation and maintenance, greatly narrowing the scope of fault location and significantly improving troubleshooting efficiency. In summary, this invention achieves a systematic breakthrough in five dimensions: cost, efficiency, stability, scalability, and maintainability, forming a highly reliable, highly flexible, and low-maintenance next-generation environmental monitoring solution with outstanding industrial application value and market competitiveness.

[0201] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A scalable transmission-mode soft network system deployed in an industrial control computing device, the device integrating multiple native hardware communication interfaces, characterized in that: The system includes: The device resource mapping management unit is used to establish and maintain a multi-dimensional mapping relationship between industrial equipment, application layer protocol type, transmission mode type and hardware communication channel. The mapping relationship is directly bound to the native hardware resources of the computing device without the need for an external protocol conversion device. The heterogeneous interface data acquisition unit runs in the kernel space of the computing device, listens to different types of hardware communication interfaces in parallel, and transmits the raw byte stream to the user space processing layer through a unified zero-copy data channel. The transmission abstraction and dynamic extension unit, located in user space, implements connection control and data transmission and reception functions for different transmission methods in the form of modular plug-ins. It supports online loading and unloading at runtime, and all application layer protocols share the same set of standardized calling interfaces. The protocol parsing and business processing unit calls the transmission abstraction and dynamic extension unit through a dynamic linking mechanism to complete data acquisition, independently parses the protocol messages of each application layer and outputs business data, and realizes unified scheduling and fault isolation of heterogeneous devices within a single process.

2. The soft network system according to claim 1, characterized in that, The device resource mapping management unit specifically includes: The key-value storage module uses an in-memory hash table structure to record the mapping relationship between device identifier, protocol type, transmission method and hardware channel number; The hardware channel auto-encoding module scans the PCIe configuration space, USB bus topology and network interface physical addresses when the system starts up, and automatically generates a unique hardware channel code. The code includes an interface type identifier, a physical address identifier and a logical port number identifier. The conflict detection and remapping module automatically avoids conflicts when hardware resource conflicts are detected by reassigning the PCI bridge secondary bus number or disabling the USB port. The heterogeneous interface data acquisition unit specifically includes: The interrupt aggregation processing module registers service routines for DMA interrupts from the network interface, UART interrupts from the serial port, HCI event interrupts from Bluetooth, and level change interrupts from GPIO, and uses interrupt merging technology to process high-frequency interrupts in batches. The shared memory data channel module creates a circular buffer in kernel space, implements producer-consumer data transfer through lock-free CAS operations, and uses memory barrier instructions to ensure data visibility under multi-core CPU architecture. The triple buffering module automatically activates the third backup buffer and triggers hardware flow control when the data write rate exceeds the processing rate to prevent data overflow and loss. The transmission abstraction and dynamic expansion unit specifically includes: The standardized interface abstraction module defines an abstract interface that includes four basic operations: connection, disconnection, sending, and receiving. The interface parameters use a fixed-length structure to eliminate the overhead of dynamic dispatch. The module is implemented in a plug-in manner, with independent dynamic link libraries compiled for each transmission method. The library files export registration functions for loading at runtime. The atomic hot-plug module loads dynamic libraries based on file system monitoring events, atomically updates the global interface function pointer table through the RCU mechanism, and safely unloads the old version library after the session-free access period, achieving second-level expansion without affecting online services. The protocol parsing and service processing unit specifically includes: The independent protocol processing module runs each application layer protocol on an independent thread, adopts a real-time scheduling strategy and is bound to a CPU core, and directly calls the transmission interface through a pre-cached array of function pointers; The backpressure flow control module sends a pause command to the transmission abstraction unit when the queue of pending processing of the protocol thread exceeds the threshold, triggering the pause of data reception and the transmission of flow control signals in the hardware interface; The adaptive load balancing module periodically collects the scheduling latency and queue depth of each protocol thread, and dynamically adjusts thread priority and CPU affinity through a PID control algorithm.

3. The soft network system according to claim 1, characterized in that, The system further includes: The cross-layer session state machine module defines four states: connection establishment, data transmission, abnormal disconnection, and resource release. State transitions trigger bidirectional notifications between kernel and user space. The fault self-healing module automatically queries redundant backup channels and performs seamless session context switching when it detects continuous channel abnormalities. During the switching process, the data sequence number is kept continuous and the sliding window is synchronized. The preventive maintenance module counts the frequency of similar faults occurring within a unit of time. When the frequency exceeds a preset threshold, it automatically triggers the channel to reduce its operating speed and reports an early warning.

4. The soft network system according to claim 1, characterized in that, The soft network system is deployed on an industrial control computer configured with an ARM Cortex-A53 multi-core processor and a Linux kernel. It supports simultaneous access to more than 1,000 heterogeneous environmental devices and more than 15 application layer protocols. When adding a new transmission method plugin, the average time is less than 1 second, the average time for fault channel switching is less than 100 milliseconds, the peak CPU utilization rate is less than 65%, and the memory usage is less than 2GB.

5. A method for implementing a scalable transmission mode in a soft network, operating on the soft network system described in any one of claims 1-4, characterized in that, The method includes the following steps: Establish the mapping relationship between devices and channels: scan the native hardware interface of the computing device, automatically generate a unique hardware channel code, and create an association mapping table between device identifier, protocol type, transmission method and hardware channel; Parallel acquisition of heterogeneous interface data: Register multiple hardware interrupt service routines in the kernel space, and transfer the raw data to the user space in a zero-copy manner through a circular buffer; Abstraction and isolation of transmission implementation: Load control logic for different transmission methods in user space as a plug-in, provide standardized calling interfaces to upper-layer protocols, and achieve decoupling of transmission methods and protocol parsing; Dynamically expand transmission capabilities: Monitor changes in the plugin directory while the system is running, load new transmission method plugins through an atomic update mechanism, and complete the expansion without restarting the service; Adaptive scheduling and fault self-healing: Dynamically adjust resource allocation according to the protocol to handle the load, and automatically switch to redundant channels when a channel failure is detected to ensure business continuity.

6. The method according to claim 5, characterized in that, The steps for establishing the mapping relationship between devices and channels specifically include: Parse the base address register of the PCIe configuration space to obtain the serial port controller address; Parse the USB bus descriptor to obtain the Bluetooth adapter topology path; The physical address and logical port number are combined to generate a 64-bit hardware channel code; The mapping relationship is stored in an in-memory hash table and a concurrent query interface is provided.

7. The method according to claim 6, characterized in that, The steps for parallel acquisition of heterogeneous interface data specifically include: A batch processing strategy is used to handle network DMA interrupts, processing them in batches every millisecond. The serial UART interrupt triggers DMA batch transfer, and the transfer starts when the hardware FIFO is filled to 75%. Lock-free CAS operations are used to update the circular buffer index, and memory barriers are used to ensure data order. When the write rate exceeds the processing rate, a triple-buffering rotation mechanism is activated. The step of dynamically expanding transmission capability specifically includes: The plugin directory is monitored via inotify, and SHA256 signature verification is performed when a new dynamic library file is detected. Call dlopen to load the library file, and execute dlsym to obtain the registration function pointer; The global function pointer table is atomically replaced using the RCU mechanism and unloaded after the old library has no session access. The extension process is completed within 100ms and has no impact on established connections; The adaptive scheduling and fault self-healing steps specifically include: Periodically collect protocol thread scheduling delay and queue depth, and adjust thread priority using a PID algorithm; When a channel fails, re-establish the connection on a new channel and synchronize the session context. After the handover is complete, a FIN is sent to terminate the old channel, and the packet loss rate during the handover process is zero. When the frequency of a certain type of fault exceeds a threshold, the channel is triggered to slow down and an SNMP Trap warning is sent.

8. The method according to claim 7, characterized in that, The method is applied to environmental monitoring scenarios and supports any combination of Modbus / SNMP / electrical communication protocol / private protocol with TCP / RS485 / Bluetooth / GPIO. The code module complexity is reduced from O(N×M) to O(N+M), and the main program does not need to be recompiled when expanding to new transmission methods.

9. The soft network system according to any one of claims 1-4, characterized in that, The system is deployed in the computer room's environmental monitoring environment. By replacing the protocol conversion gateway and multiple monitoring servers in the traditional solution with a single industrial control computer, the hardware cost is reduced by more than 40%, and the fault recovery time is shortened by more than 70%.

10. An environmental monitoring data acquisition system, characterized in that, The system comprises the soft network system described in any one of claims 1-4 and the method described in any one of claims 5-8, and is capable of simultaneously accessing more than 1,000 heterogeneous devices and 15 protocols, and completing online expansion of transmission methods and seamless switching of fault channels while maintaining continuous system operation.

Images