Multi-protocol wired sensor plug-and-play and communication parallel processing method and system

Abstract

The invention discloses a multi-protocol wired sensor plug-and-play and communication parallel processing method and system, and the method comprises the steps: maintaining a unified message sending queue in a serial port communication thread of a gateway machine, and enabling the message sending queue to contain a service message and a management message at the same time; a message scheduling engine is constructed, when triggering conditions of a management message are met, a plug-and-play process is started preferentially, the management message is sent, and the triggering conditions of the management message comprise the steps that (1) the plug-and-play process is started, and unfound sensors exist in a white list; (2) service message communication is overtime; (3) when the white list is not set, periodically starting a plug-and-play process according to the maximum capacity of the serial port; and when the management message is triggered, inserting the management message into the head of the message sending queue. According to the method, the management message is seamlessly and dynamically inserted into the serial port communication link through the synergistic effect of the protocol abstraction layer, the intelligent message scheduling strategy and the white list mechanism, the management message is inserted only when necessary, communication of the service message is not affected as much as possible, and automatic discovery and configuration of the sensor are completed.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) device management technology, and in particular to a method and system for plug-and-play and parallel communication processing of multi-protocol wired sensors. This method addresses how a gateway can maintain compatibility with various proprietary device discovery and configuration protocols from different manufacturers while conducting regular data communication with sensors based on standard industrial protocols (such as Modbus), and how to achieve automatic sensor identification and online registration. Background Technology

[0002] With the rapid development of the Industrial Internet of Things (IIoT) and smart homes, gateway devices, as the core hub connecting underlying sensors and upper-level cloud platforms, are becoming increasingly important. In IoT scenarios such as industrial automation and smart buildings, the wired Modbus protocol is currently a widely used communication method and protocol in industrial automation. Gateway devices need to connect to various types of sensors via wired connections. Since the initial sensor connection requires a large amount of configuration and comparison tools, which is time-consuming and labor-intensive, the industry is vigorously promoting plug-and-play functionality for sensors to reduce deployment and maintenance costs. This means that the gateway needs to actively initiate and manage a process, including sending device discovery messages, address configuration messages, and device detection messages, to complete the entire process of sensor connection from physical to logical online. However, achieving this goal faces two major technological challenges: (i) Protocol fragmentation challenge: Although the management process for device online is logically highly similar, the industry lacks a unified communication standard for these processes; different regions, different manufacturers, and even different models of sensors use vastly different communication protocols (such as message format, instruction set, interaction timing, etc.); this "international brand" situation forces gateway devices to have to build a large amount of customized driver code in order to be compatible with various protocols, making the software system extremely bloated and complex, and greatly reducing the system's universality, scalability, and maintainability.

[0003] (II) Challenges in Communication Resource Competition: A more challenging aspect is that these wired sensors typically communicate via serial ports. Serial communication is inherently half-duplex, allowing only one operation at a time (read or write), and its communication speed is relatively limited. This creates a fundamental contradiction: the gateway and sensors already have normal data acquisition and control command transmission / reception services (hereinafter referred to as "service messages") requiring high real-time performance. Now, to achieve automatic discovery and management, the gateway must also insert device identification, search, and configuration commands (hereinafter referred to as "management messages"). Service messages and management messages share the same narrow serial channel. If the management message is sent at an inappropriate time, it can directly block, delay, or even interrupt the transmission of service messages, severely impacting the system's real-time performance and stability. Existing technologies typically employ simple and crude methods such as "exclusive channel access during initialization" or "fixed-period polling," which cannot achieve intelligent, adaptive channel resource sharing.

[0004] In summary, those skilled in the art have long faced a severe technical dilemma: how to design a universal mechanism in resource-constrained serial communication environments that is compatible with diverse device management protocols while intelligently coordinating the transmission of management and service messages to ensure that the auto-discovery function does not substantially interfere with core data services. Currently, there is a lack of mature solutions that can effectively address both protocol compatibility and seamless communication issues simultaneously. Summary of the Invention

[0005] Purpose of the invention: In order to overcome the shortcomings of the existing technology, the present invention provides a method and system for plug-and-play multi-protocol wired sensors and parallel communication processing. Through the synergistic effect of protocol abstraction layer, intelligent message scheduling strategy and whitelist mechanism, management messages are intelligently inserted into the serial communication link at the necessary time. Through effective scheduling management, the impact on business message communication is minimized, thereby completing the automatic discovery and configuration of sensors.

[0006] Technical solution: To achieve the above objectives, the technical solution adopted by this invention is as follows: A method for plug-and-play and parallel communication processing of multi-protocol wired sensors is proposed. In the serial communication thread of the gateway device, a unified message sending queue is maintained, which simultaneously accommodates service messages and management messages. A message scheduling engine is constructed, which prioritizes initiating the plug-and-play process and sending the management message when the triggering conditions for the management message are met. This ensures that the management message is triggered only during periods of serial channel idleness or service message intervals, thus initiating the plug-and-play process. The triggering conditions for the management message include: ① initiating the plug-and-play process, and the existence of undiscovered transmissions in the whitelist. ① Sensor; ② Service message communication timeout; ③ When no whitelist is set, the plug-and-play process is periodically started according to the maximum capacity of the serial port; when a management message is triggered, the management message is inserted at the head of the message sending queue to ensure that it is sent first; after the management messages related to the plug-and-play process are processed, the normal service message sending schedule is restored; the whitelist is used to authenticate the sensor based on the sensor SN code to determine whether the sensor is authorized to access the gateway; sensor discovery is the process of searching whether there are sensors in the whitelist connected to the serial port.

[0007] Specifically, the plug-and-play process includes four steps: device testing, device discovery, device configuration, and service access. After each step is completed, the system automatically determines whether to proceed to the next step. (1) Device test: The gateway sends a fixed device test message to the sensor. After receiving the device test message, the sensor adjusts its baud rate to synchronize with the gateway and ends the device test step. (2) Device discovery: The gateway sends a device discovery message to the sensor. After receiving the device discovery message, the sensor sends back a device discovery response message containing the communication address, device type code and sensor SN code. After receiving the device response message, the gateway takes the sensor that sent the device response message as the discovered sensor. If a whitelist is set in the gateway, for the discovered sensor, the unauthorized access sensors are first filtered out according to the whitelist, and the remaining sensors are added to the discovered device mapping table. If no whitelist is set in the gateway, the discovered sensors are added to the discovered device mapping table. When all sensors in the whitelist have been discovered, the number of sensors in the discovered device mapping table reaches the preset number, or the number of device discovery messages sent reaches the required number, the device discovery step ends. (3) Device configuration: The gateway performs communication address deduplication and communication address reallocation on the detected sensors, and sends a device configuration message about the communication address. After receiving the device configuration message, the sensor reconfigures the communication address and sends back a device configuration response message. When the gateway receives the device configuration response message, the device configuration step ends. (4) Service access: The gateway instantiates the corresponding sensor model under the corresponding serial port according to the device type code of the discovered sensor and creates the specific configuration of the sensor to be discovered; then, the gateway generates the corresponding service message according to the sensor configuration information, incorporates the service message into the normal data acquisition cycle, puts it into the message sending queue, and the serial communication thread performs the sending and receiving.

[0008] Specifically, the device testing steps, device discovery steps, and device configuration steps are abstracted into standardized interfaces. For different communication protocols, specific implementation classes derived from the standardized interfaces are used for adaptation, realizing dynamic loading and compatibility of different communication protocols. The specific implementation class of the standardized interface that adapts to a certain communication protocol is called a plug-and-play protocol.

[0009] Specifically, to achieve accurate identification and model matching of sensor devices using different Plug and Play protocols, a composite identifier is defined for each sensor. This aims to address the issue that different manufacturers' Plug and Play protocols may assign different device type codes to sensor devices of the same functional category. The uniqueness of the composite identifier is guaranteed by a combination of protocol encoding and device type encoding. The protocol encoding is a code given by the gateway for different Plug and Play protocols, used to switch to the corresponding version of the Plug and Play protocol, and can uniquely identify the Plug and Play protocol used by the sensor. The device type encoding is the sensor's built-in functional category code, derived from the device discovery response message. In the gateway, a mapping relationship is established between the composite identifier composed of the protocol encoding and the device type encoding and the sensor model to distinguish the different device type codes used by different manufacturers for sensors of the same functional category. The sensor model is a sensor configuration template defined in the gateway, with one sensor model corresponding to each type of sensor.

[0010] Specifically, a one-to-one mapping relationship between composite identifiers and sensor models is defined in the gateway. When a sensor receives a device discovery message, it organizes its own communication address, device type code, and sensor SN code into a device discovery response message. The gateway extracts the device type code from the device discovery response message, combines the protocol code with the device type code to form a composite identifier, and then identifies the corresponding sensor model.

[0011] Specifically, an enumeration value E_MSGTAG is defined in the serial communication message to distinguish the type of serial communication message. The types of serial communication messages include service messages and management messages. Service messages include query messages and control messages, while management messages include device test messages, device discovery messages, device discovery response messages, device configuration messages, and device configuration response messages.

[0012] Specifically, when the message scheduling engine receives a management message, it first determines whether the current situation meets the triggering conditions for the management message. If it does, the management message is inserted at the head of the message sending queue. In the serial communication thread, if the message sending queue is not empty, a serial communication message is taken from the head of the message sending queue and sent via the serial port. For messages that do not require waiting for an acknowledgment, they are immediately removed from the message sending queue after the serial communication message sending count is completed. For messages that require waiting for an acknowledgment, a timeout retransmission mechanism is initiated. After receiving an acknowledgment message, the message is removed from the message sending queue. If no acknowledgment message is received after retries of a specified number of times, the message is marked as failed and removed from the message sending queue.

[0013] Specifically, if a sensor communication failure occurs, the plug-and-play process is restarted, returning to the device testing steps.

[0014] A system for plug-and-play multi-protocol wired sensors and parallel communication processing includes a standardized interface module, a protocol adaptation module, a message scheduling module, a device management module, and a data communication module. The standardized interface module abstracts the device testing steps, device discovery steps, and device configuration steps into standardized interfaces, forming a device testing interface, a device discovery interface, and a device configuration interface. The device testing interface is used to synchronize the baud rate between the gateway and the sensor. The device discovery interface is used to search for sensors listed in the whitelist that are connected to the gateway's serial port. The device configuration interface is used to reconfigure the communication address of the sensor. The protocol adaptation module adapts to different communication protocols by using specific implementation classes derived from standardized interfaces, thereby enabling dynamic loading and compatibility of different communication protocols between the gateway and the sensor. The message scheduling module is used to maintain the message sending queue in the serial communication thread and insert management messages into the head of the message sending queue according to the triggering conditions of management messages. The device management module is used to manage the whitelist, execute the plug-and-play process, and maintain the communication status between the gateway and the sensor. The plug-and-play process includes a test preparation step, a device discovery step, and a device configuration step executed sequentially. After the sensor completes plug-and-play, it generates the corresponding service message according to the configuration information, incorporates the service message into the normal data acquisition cycle, puts it into the message sending queue, and realizes the communication between the gateway and the sensor. The data communication module executes a serial communication thread.

[0015] Beneficial Effects: The multi-protocol wired sensor plug-and-play and parallel communication processing method and system provided by this invention have the following advantages compared to existing technologies: 1. Strong versatility: Through the protocol abstraction layer, the gateway can support multiple heterogeneous device protocols in a unified manner, greatly improving the system's scalability and maintainability; 2. Event-driven: The sending of management messages adopts an event-driven mechanism, triggering only when device discovery, configuration, or fault recovery is required. During most of the system's stable operation without device changes, no management messages are generated, thus fundamentally avoiding interference with business message communication; 3. Efficient deployment: It achieves fully automatic sensor discovery and configuration, reducing the manual configuration work that originally took several hours to a few minutes, significantly reducing deployment and maintenance costs; 4. Secure and reliable: The whitelist mechanism ensures the legality and controllability of device access, and the address conflict resolution mechanism ensures the reasonable allocation of network resources. Attached Figure Description

[0016] Figure 1 This is a block diagram of the overall architecture of a line sensor plug-and-play and parallel communication processing system based on the present invention; Figure 2 This is a schematic diagram illustrating the workflow of the message scheduling engine in this invention; Figure 3 This is a schematic diagram of the state transition in the plug-and-play process of this invention; Figure 4 This is a schematic diagram illustrating the implementation process of the plug-and-play procedure in this invention. Detailed Implementation

[0017] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0018] Serial communication devices normally send and receive service messages. This case aims to achieve plug-and-play functionality for wired sensing devices by inserting management messages while minimizing disruption to service message transmission. The plug-and-play and parallel communication processing scheme designed in this case is primarily used to handle the following three situations: 1. Plug-and-play functionality is enabled, a whitelist is set, and some whitelisted sensors remain undiscovered; 2. Plug-and-play functionality is enabled, but there are timeouts and no responses for service message transmission; 3. Plug-and-play functionality is enabled, no whitelist is set, and each serial port performs discovery processing based on the maximum number of accessible sensors (254). If the number of sensors on a particular serial port does not meet the requirement, management messages are sent according to the reading cycle.

[0019] The design aims for automated management message transmission, following a device testing -> device discovery -> device configuration process. After the device testing message transmission count is completed, the gateway automatically switches to sending device discovery messages. Once the required number of transmissions is reached or all necessary sensors are discovered, device discovery message transmission automatically ends, and device configuration message transmission begins. This process automatically synchronizes baud rates, discovers, and configures the required sensor devices. After configuration, it automatically generates corresponding service messages based on the sensor configuration, enabling normal business data transmission and reception, meeting plug-and-play requirements. The processing time depends on the number of sensors, but typically completes the plug-and-play process in just a few minutes, significantly reducing time consumption compared to manual configuration.

[0020] like Figure 1 The diagram shows a block diagram of a plug-and-play and parallel communication processing architecture for line sensors. The system includes a standardized interface module, a protocol adaptation module, a message scheduling module, a device management module, and a data communication module. The standardized interface module abstracts the device testing, device discovery, and device configuration steps into standardized interfaces, forming a device testing interface, a device discovery interface, and a device configuration interface. The device testing interface is used to synchronize the baud rate between the gateway and the sensor; the device discovery interface is used to search for sensors listed in the whitelist connected to the gateway's serial port; and the device configuration interface is used to reconfigure the sensor's communication address. The protocol adaptation module, for different communication protocols, derives specific implementations from the standardized interfaces. The system adapts to different communication protocols between the gateway and the sensor, enabling dynamic loading and compatibility. The message scheduling module maintains the message sending queue in the serial communication thread and inserts management messages at the head of the queue based on trigger conditions. The device management module manages whitelists, executes the plug-and-play process, and maintains the communication status between the gateway and the sensor. The plug-and-play process includes sequentially executing a pre-test step, a device discovery step, and a device configuration step. After completing plug-and-play, the sensor generates corresponding service messages based on the configuration information, incorporates these messages into the normal data acquisition cycle, and places them in the message sending queue to achieve communication between the gateway and the sensor. The data communication module executes the serial communication thread.

[0021] In implementing plug-and-play functionality and parallel communication processing for multi-protocol wired sensors using the above system, a unified message sending queue needs to be maintained in the serial communication thread of the gateway device. This message sending queue simultaneously accommodates business messages and management messages; a system like... Figure 2The message scheduling engine shown prioritizes starting the plug-and-play process and sending a management message when the triggering conditions for the management message are met. The triggering conditions for the management message include: ① starting the plug-and-play process and there are undiscovered sensors in the whitelist; ② business message communication timeout; ③ when no whitelist is set, the plug-and-play process is started periodically according to the maximum capacity of the serial port; when the management message is triggered, the management message is inserted at the head of the message sending queue.

[0022] The message scheduling engine is key to achieving "event-driven" and "parallel processing" in this case. Its intelligence is reflected in: first, it checks if the message sending queue is empty; then, it checks if the triggering conditions for a management message are met. If both checks are true, the management message is inserted at the head of the message sending queue. In the serial communication thread, if the message sending queue is not empty, a serial communication message is retrieved from the head of the queue and sent via the serial port. For messages that do not require a response, they are immediately removed from the message sending queue after being sent. For messages that require a response, a timeout retransmission mechanism is initiated. Once a response message is received, the message is removed from the message sending queue. If no response message is received after a specified number of retries, the message is marked as failed and removed from the message sending queue. Figure 2 As shown, its intelligence is reflected in the following path: 1. Service message priority path: Queue not empty → Retrieve message → Send → No need to wait for acknowledgment → Remove For ordinary business messages (such as query messages and control messages), the path is very short and efficient (path: C-> F-> G-> H-> O-> B), and it is removed immediately after being sent, ensuring low latency and high real-time performance of business communication.

[0023] 2. Reliable processing path for management messages: Send management message → Wait for and process response For management messages that require a response, the message scheduling engine will initiate a timeout retransmission mechanism (path: H-> I-> J-> L-> N); only when a valid response is received is the task considered successful and the message removed (path J-> K); if multiple retries fail, the message is marked as failed and removed (path L-> M), ensuring the reliability of the device discovery and configuration process.

[0024] In the plug-and-play process, the state transition is as follows: Figure 3 As shown, the implementation process is as follows: Figure 4 As shown; the plug-and-play process includes four steps: device testing, device discovery, device configuration, and service access. After the previous step is completed, it automatically determines whether to proceed to the next step. (1) Device test: The gateway sends a fixed device test message to the sensor; the device test message will be sent continuously a fixed number of times within a set period. After the number of times is completed, the gateway will automatically end the device test step regardless of whether the sensor responds; during continuous reception, the sensor will adjust its baud rate to be synchronized with the gateway by recognizing the content of the fixed message.

[0025] (2) Device discovery: The gateway sends a device discovery message to the sensor. After receiving the device discovery message, the sensor sends back a device discovery response message containing the communication address, device type code and sensor SN code. After receiving the device response message, the gateway takes the sensor that sent the device response message as the discovered sensor. If a whitelist is set in the gateway, for the discovered sensor, the unauthorized access sensors are first filtered out according to the whitelist, and the remaining sensors are added to the discovered device mapping table. If no whitelist is set in the gateway, the discovered sensors are added to the discovered device mapping table. When all sensors in the whitelist have been discovered, the number of sensors in the discovered device mapping table reaches the preset number, or the number of device discovery messages sent reaches the required number, the device discovery step ends. (3) Device configuration: The gateway performs communication address deduplication and communication address reallocation on the detected sensors, and sends a device configuration message about the communication address. After receiving the device configuration message, the sensor reconfigures the communication address and sends back a device configuration response message. When the gateway receives the device configuration response message, the device configuration step ends. (4) Service access: The gateway generates the corresponding service message according to the sensor configuration information, incorporates the service message into the normal data acquisition cycle, puts it into the message sending queue, and executes the serial communication thread.

[0026] The device test message refers to a fixed message that the gateway continuously sends rapidly within a certain sending period. After receiving and processing the message, the sensor switches the baud rate to identify the correct message content. This is mainly to synchronize the baud rate configuration between the sensor device and the gateway.

[0027] The device discovery message refers to a message continuously sent by the gateway on one or more serial ports within a certain period. After receiving this message, the sensor on the specified serial port organizes its own communication address, device type code, and sensor SN code, etc., and notifies the gateway as a device discovery response message.

[0028] The device configuration message refers to the gateway modifying information such as the communication address and baud rate of a certain sensor device. Typically, the gateway organizes the sensor's serial number (SN), current communication address, target communication address, baud rate, and other information into a message and writes it through the serial port. After receiving this message, the sensor compares its SN. If the SN matches its own, the gateway writes the target communication address and baud rate and responds with the new communication address. This response message is called the device configuration response message.

[0029] The plug-and-play process in this case is an orderly automated process that clearly demonstrates the core pipeline of testing, discovery, configuration, and online connectivity. Once a sensor is physically connected, the gateway can automatically drive it to complete the entire online process without manual intervention, reflecting a high degree of plug-and-play capability. During the device testing phase, crucial baud rate synchronization operations were performed, laying the foundation for subsequent communication. In the device discovery phase, whitelist verification was conducted to ensure the legality and security of sensor access. In the device configuration phase, the core focus was preventing communication address conflicts and resolving this common problem. In the service access (device online) phase, the final target state, the sensor begins normal service data acquisition and executes normal serial communication threads.

[0030] This plug-and-play process can not only handle deployment but also manage maintenance. When a sensor malfunctions (communication anomaly), the system will automatically return to the device testing phase and re-initiate the plug-and-play process to try to restore it to online status. This constitutes a complete closed-loop management system, which greatly improves the system's robustness and self-healing capabilities.

[0031] Figure 2 It describes at a micro level how individual messages are intelligently scheduled by the message scheduling engine. Figure 3 The macro-level description of how individual sensors are managed automatically complements each other, forming the complete architecture of this case.

[0032] from Figure 4 As can be seen, the plug-and-play process can be divided into three distinct stages: Phase 1: Device Discovery and Filtering Starting with device discovery after baud rate synchronization, the core loop of the device discovery phase is "send-wait-judge," which ensures the reliability of device discovery. Within this process, a whitelist verification sub-process is embedded. The whitelist acts as a security gateway; only devices with sensor serial numbers within the whitelist are recorded, otherwise they are discarded. This sub-process implements mandatory authentication and security control for device access.

[0033] Phase Two: Intelligent Address Configuration Once a sufficient number of sensors are detected or a certain number of transmissions are completed, intelligent address configuration is automatically triggered. This process is crucial for resolving address conflicts. Through a device configuration sub-process, the old and new device lists are first merged to obtain a global view. Then, the communication address usage is statistically analyzed to accurately identify devices with invalid addresses (such as 0 or 255) or duplicate addresses. Next, an unused, valid address is dynamically allocated to these problematic devices, a configuration message is generated and reliably sent to the device, and confirmation is awaited. This sub-process systematically solves the most common address conflict problem in thread deployment, achieving automated and rational allocation of network resources. Finally, the sensor configuration is automatically created based on the configured sensor communication address, device type code, and sensor SN code information.

[0034] Phase 3: Service Access The gateway instantiates the corresponding sensor model under the corresponding serial port according to the device type code of the discovered sensor, and creates the specific configuration of the discovered sensor. After the sensor is successfully configured, the gateway automatically creates the service message configuration according to the sensor communication address and sensor data point information, and seamlessly integrates it into the normal data acquisition cycle, marking the successful completion of the entire plug-and-play process.

[0035] To enable plug-and-play functionality, the following global settings were implemented: management messages were added to facilitate reliable plug-and-play operation of sensor devices on the gateway device, while ensuring minimal impact on business data transmission and reception. 1. Define an enumeration value E_MSGTAG in the serial communication message to distinguish the type of serial communication message. The types of serial communication messages include service messages and management messages. Service messages include query messages and control messages, while management messages include device test messages, device discovery messages, device discovery response messages, device configuration messages, and device configuration response messages.

[0036] 2. Inside the gateway, a protocol type identifier is predefined for each plug-and-play protocol. The protocol type identifier is used as a key scheduling parameter in the protocol adaptation module. When it is necessary to process sensors with different plug-and-play protocols, the gateway dynamically selects and switches to the corresponding protocol parsing logic based on this protocol type identifier, thereby realizing the isolation and runtime loading of multiple plug-and-play protocols.

[0037] 3. Define a whitelist. Based on the globally unique serial number (SN) of wired sensors, enforce authentication on the wired sensors to determine whether they are authorized for access. The predefined whitelist serves as a list of known sensor assets within the system, allowing the gateway to clearly define the scale and scope of authorized sensors at the architecture level, providing a basis for resource allocation and topology management.

[0038] 4. Set the plug-and-play processing cycle (define how often to start the plug-and-play process) and the plug-and-play start switch (turning it on enables the plug-and-play function).

[0039] 5. Define the message information structure T_SendbufInfo to store the message content, message type, number of times the message needs to be sent, number of times the message has been sent, reading period, and last sending time of the message to be sent.

[0040] 6. Define a message queue QList in the serial communication thread.<T_SendbufInfo> Store the messages to be sent.

[0041] 7. In the Plug and Play base class, define a virtual interface for message parsing. Because different Plug and Play protocols have completely different message structures and contents, they must be implemented separately in the derived classes of the corresponding protocols. In the Plug and Play base class, define a message receive buffer mapping table and a message lock mapping table, respectively, using the serial port name as an index. When the serial port processing class reads a message from the serial port, it locks the message lock corresponding to the serial port name, appends the read message to the message receive buffer of the corresponding serial port name, and then releases the message lock.

[0042] 8. For plug-and-play protocols from different manufacturers and regions, simply derive the base class from this case and implement the corresponding protocol's interfaces for device testing, device discovery, and device configuration to achieve interoperability between different protocols.

[0043] 9. Without a whitelist configured, if the exact number of sensors connected to the serial port is unknown, sensor discovery will be performed based on the maximum number of 254. If the whitelist is known, sensor discovery can be performed based on the number of sensors in the whitelist. When the target number of sensor responses is received, the discovery process can be terminated early, greatly reducing the time spent on sensor management messages.

[0044] 10. If all sensors in the whitelist have been discovered and are communicating normally, there is no need to start the plug-and-play process for management messages. Normal sending and receiving of business messages will not affect the normal use of the sensors.

[0045] 11. When a sensor device in the whitelist fails to respond to a business message query, it may be due to a configuration error or loss of baud rate configuration. Initiate the sensor testing, discovery, and configuration process to help the gateway reconnect to the sensor device.

[0046] 12. The whitelist is managed and controlled by the gateway's uplink platform. When the whitelist changes, the gateway's data acquisition program is notified via IoT messages. After the gateway's data acquisition program is updated, if any undiscovered sensor devices are found, the sensor testing, discovery, and configuration process can be restarted to help the gateway connect to the sensor devices.

[0047] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way, and all technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A method for plug-and-play and parallel communication processing of multi-protocol wired sensors, characterized in that: In the serial communication thread of the gateway machine, a unified message sending queue is maintained, which can simultaneously hold business messages and management messages. A message scheduling engine is constructed. When the triggering conditions for a management message are met, the plug-and-play process is initiated first, and a management message is sent. The triggering conditions for the management message include: ① initiating the plug-and-play process and the whitelist contains undiscovered sensors; ② business message communication timeout; ③ when no whitelist is set, the plug-and-play process is initiated periodically according to the maximum capacity of the serial port. When a management message is triggered, it is inserted at the head of the message sending queue. The whitelist is used to authenticate sensors based on their SN codes to determine whether a sensor is authorized to access the gateway. Sensor discovery is the process of searching the serial port for sensors in the whitelist.

2. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 1, characterized in that: The plug-and-play process includes four steps: device testing, device discovery, device configuration, and service access. After each step is completed, the system automatically determines whether to proceed to the next step. (1) Device test: The gateway sends a fixed device test message to the sensor. After receiving the device test message, the sensor adjusts its baud rate to synchronize with the gateway and ends the device test step. (2) Device discovery: The gateway sends a device discovery message to the sensor. After receiving the device discovery message, the sensor sends back a device discovery response message containing the communication address, device type code and sensor SN code. After receiving the device response message, the gateway will regard the sensor that sent the device response message as the discovered sensor. If a whitelist is configured in the gateway, for any discovered sensors, unauthorized sensors are first filtered out according to the whitelist, and the remaining sensors are added to the discovered device mapping table. If no whitelist is configured in the gateway, the discovered sensors are added to the discovered device mapping table. The device discovery process ends when all sensors in the whitelist have been discovered, the number of sensors in the discovered device mapping table reaches a preset number, or the number of device discovery messages sent reaches the required number. (3) Device configuration: The gateway performs communication address deduplication and communication address reallocation on the detected sensors, and sends a device configuration message about the communication address. After receiving the device configuration message, the sensor reconfigures the communication address and sends back a device configuration response message. When the gateway receives the device configuration response message, the device configuration step ends. (4) Service access: The gateway generates the corresponding service message according to the sensor configuration information, incorporates the service message into the normal data acquisition cycle, puts it into the message sending queue, and executes the serial communication thread.

3. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 1, characterized in that: The device testing, device discovery, and device configuration steps are abstracted into standardized interfaces. For different communication protocols, specific implementation classes derived from these standardized interfaces are used for adaptation, enabling dynamic loading and compatibility of different communication protocols. A specific implementation class of a standardized interface that adapts to a certain communication protocol is called a plug-and-play protocol.

4. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 3, characterized in that: Each sensor is defined with a composite identifier. The uniqueness of the composite identifier is guaranteed by a combination of protocol encoding and device type encoding. The protocol encoding is an encoding given by the gateway for different plug-and-play protocols, used to switch to the corresponding version of the plug-and-play protocol. The device type encoding is the functional category encoding of the sensor. In the gateway, a mapping relationship is established between the composite identifier composed of protocol encoding and device type encoding and the sensor model to distinguish the different device type encodings used by different manufacturers for sensors of the same functional category.

5. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 4, characterized in that: Define a one-to-one mapping relationship between the composite identifier and the sensor model in the gateway; when the sensor receives the device discovery message, it organizes its own communication address, device type code and sensor SN code into the device discovery response message; The gateway extracts the device type code from the device discovery response message, combines the protocol code with the device type code to form a composite identifier, and then identifies the corresponding sensor model.

6. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 1, characterized in that: Define an enumeration value E_MSGTAG in the serial communication message to distinguish the type of serial communication message. The types of serial communication messages include service messages and management messages. Service messages include query messages and control messages, while management messages include device test messages, device discovery messages, device discovery response messages, device configuration messages, and device configuration response messages.

7. The method for plug-and-play multi-protocol wired sensors and parallel communication processing according to claim 1, characterized in that: When the message scheduling engine receives a management message, it first determines whether the current situation meets the triggering conditions for the management message. If it does, the management message is inserted at the head of the message sending queue. In the serial communication thread, if the message sending queue is not empty, a serial communication message is taken from the head of the message sending queue and sent through the serial port. For messages that do not need to wait for a response, they are removed from the message sending queue immediately after the serial communication message sending count is completed. For messages that require a response, a timeout retransmission mechanism is initiated. Once a response message is received, the message is removed from the message sending queue. If a response message is not received after a specified number of retries, the message is marked as failed and removed from the message sending queue.

8. The method for plug-and-play multi-protocol wired sensor and parallel communication processing according to claim 1, characterized in that: If a sensor communication failure occurs, the plug-and-play process is restarted, returning to the device test steps.

9. A system for plug-and-play multi-protocol wired sensors and parallel communication processing, characterized in that: It includes a standardized interface module, a protocol adaptation module, a message scheduling module, a device management module, and a data communication module; The standardized interface module abstracts the device testing steps, device discovery steps, and device configuration steps into standardized interfaces, forming a device testing interface, a device discovery interface, and a device configuration interface. The device testing interface is used to synchronize the baud rate between the gateway and the sensor. The device discovery interface is used to search for sensors listed in the whitelist that are connected to the gateway's serial port. The device configuration interface is used to reconfigure the communication address of the sensor. The protocol adaptation module adapts to different communication protocols by using specific implementation classes derived from standardized interfaces, thereby enabling dynamic loading and compatibility of different communication protocols between the gateway and the sensor. The message scheduling module is used to maintain the message sending queue in the serial communication thread and insert management messages into the head of the message sending queue according to the triggering conditions of management messages. The device management module is used to manage the whitelist, execute the plug-and-play process, and maintain the communication status between the gateway and the sensor. The plug-and-play process includes a test preparation step, a device discovery step, and a device configuration step executed sequentially. After the sensor completes plug-and-play, it generates the corresponding service message according to the configuration information, incorporates the service message into the normal data acquisition cycle, puts it into the message sending queue, and realizes the communication between the gateway and the sensor. The data communication module executes a serial communication thread.

Images