Multi-serial-port equipment identification method and system and terminal equipment

Abstract

The invention relates to the technical field of Internet of Things, and discloses a multi-serial-port equipment identification method and system and terminal equipment. The multi-serial-port equipment identification method comprises the following steps: sending a monitoring instruction to a monitoring module, triggering the monitoring module to identify a plurality of effective serial ports in a main control system, and obtaining an effective serial port list; based on the effective serial port list, creating a plurality of serial port channels running in parallel, and for each serial port channel, sending a test command to the to-be-identified equipment through the serial port channel; sending a test verification instruction to the protocol module, triggering the protocol module to receive test response data of the to-be-identified equipment, and analyzing the test response data; and if the equipment type and the equipment number of the to-be-identified equipment are obtained through analysis, establishing communication connection between the to-be-identified equipment and the serial port channel. By adopting the method, equipment identification operations on a plurality of serial ports can be performed at the same time, and the matching speed in a multi-equipment scene is greatly improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a method, system, and terminal device for identifying multi-serial-port devices. Background Technology

[0002] With the rapid development of industrial automation, intelligent manufacturing, and the Internet of Things (IoT) technologies, various serial port devices are widely used in industrial control systems, data acquisition systems, and embedded devices. These devices typically connect to the main control system via a serial-to-serial adapter and rely on serial communication protocols for data exchange.

[0003] Traditional multi-serial-port device management methods require users to manually configure the serial port number connected to each device and specify the corresponding communication parameters in the host computer software. When multiple devices are connected to the system, the physical connection relationship of the serial ports is not intuitive. Users often need to try different serial ports one by one and combine the device feedback information to determine the actual connection location. The operation process is cumbersome and prone to errors, which seriously affects the availability and maintenance efficiency of the system. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a method, system and terminal device for identifying multi-serial-port devices, which can effectively solve the technical problems of cumbersome operation and easy error in traditional multi-serial-port device management methods.

[0005] In a first aspect, embodiments of this application provide a method for identifying multi-serial-port devices, the method comprising: Send a listening command to the listening module to trigger the listening module to identify multiple valid serial ports in the main control system and obtain a list of valid serial ports; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. Send a test verification command to the protocol module to trigger the protocol module to receive the test response data of the device to be identified and parse the test response data; If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

[0006] Secondly, embodiments of this application provide a multi-serial-port device identification system, the system comprising: The monitoring module is used to receive monitoring commands and identify multiple valid serial ports in the main control system based on the monitoring commands to obtain a list of valid serial ports. The protocol module is used to receive test verification instructions, receive test response data of the device to be identified based on the test verification instructions, and parse the test response data; The management module is used to send the listening command and the test verification command; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

[0007] Thirdly, this application also provides a terminal device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: Send a listening command to the listening module to trigger the listening module to identify multiple valid serial ports in the main control system and obtain a list of valid serial ports; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. Send a test verification command to the protocol module to trigger the protocol module to receive the test response data of the device to be identified and parse the test response data; If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

[0008] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps: Send a listening command to the listening module to trigger the listening module to identify multiple valid serial ports in the main control system and obtain a list of valid serial ports; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. Send a test verification command to the protocol module to trigger the protocol module to receive the test response data of the device to be identified and parse the test response data; If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

[0009] The embodiments of this application have the following beneficial effects: First, it breaks through the performance bottleneck of traditional single-threaded serial scanning and adopts a multi-threaded parallel processing mechanism, which enables device identification operations on multiple serial ports to be performed simultaneously, greatly improving the matching speed in multi-device scenarios.

[0010] Secondly, by automatically detecting valid serial ports in the main control system through the monitoring module and intelligently parsing the response data through the protocol module, the entire process from serial port discovery and device testing to type identification is automated, which greatly reduces operation and maintenance costs and the probability of errors. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This paper shows a schematic diagram of a multi-serial-port device identification system according to an embodiment of this application; Figure 2 This paper illustrates a flowchart of a multi-serial-port device identification method according to an embodiment of this application. Figure 3 This paper illustrates another flowchart of the multi-serial-port device identification method according to an embodiment of this application. Detailed Implementation

[0013] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0014] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0016] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0017] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0018] The following describes the multi-serial-port device identification system using specific embodiments.

[0019] Figure 1 A schematic diagram of a multi-serial-port device identification system according to an embodiment of this application is shown. Exemplarily, the multi-serial-port device identification system includes: The monitoring module is used to receive monitoring commands and identify multiple valid serial ports in the main control system based on the monitoring commands to obtain a list of valid serial ports. The protocol module is used to receive test verification instructions, receive test response data from the device to be identified based on the test verification instructions, and parse the test response data. The management module is used to send listening commands and test verification commands; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each serial port channel, a test command is sent to the device to be identified through the corresponding serial port channel. If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

[0020] The monitoring module is a functional module used for serial port resource detection and management. Specifically, it receives monitoring commands from the management module, calls the operating system interface to control all serial port devices in the main system, and verifies the availability of each serial port (e.g., whether it is occupied or if there are communication anomalies), thereby filtering out valid serial ports available for communication and generating a list of valid serial ports.

[0021] The main control system refers to the central control equipment or computing platform that runs a multi-serial port device identification method. Optionally, the main control system can be an industrial computer, embedded controller, industrial PC, or a general-purpose computer with serial communication capabilities. The main control system has multiple physical or virtual serial ports for connecting external serial port devices and runs host computer software to realize device management and data interaction.

[0022] The protocol module refers to a collection of modules that handle the parsing and identification of various serial communication protocols. It includes a protocol factory and multiple protocol parsers that implement a unified interface. The protocol module's function is to, based on the received test response data, call the corresponding protocol parser to perform format matching and semantic analysis, identifying the device type and device number.

[0023] The management module serves as the scheduling center of the multi-serial-port device identification system. Its functions include: initializing system resources, sending listening commands to the listening module, creating multiple parallel serial port channels based on the list of valid serial ports, triggering the test command sending process, coordinating the protocol module to complete verification, establishing the final communication connection, and further performing maintenance operations such as heartbeat detection and anomaly handling.

[0024] The device to be identified refers to an external hardware device that is connected to the main control system via a serial port but whose type, serial number, and corresponding serial port location have not yet been determined. Examples include various sensors, industrial controllers, testing instruments, actuators, and other terminal devices with serial communication capabilities. These devices typically follow a specific communication protocol and require sending test commands and parsing their returned responses to complete identification.

[0025] In one embodiment, the multi-serial port device identification system runs in the host computer software environment of the main control system. This host computer software serves as the control center of the entire system, integrating multiple functional modules to achieve automatic discovery, intelligent scheduling, protocol adaptation, and stable communication with external serial port devices (i.e., devices to be identified). The host computer software includes multiple user interface units, such as "Window 123," to provide users with a visual human-computer interaction interface, displaying the current connection status of each serial port channel, device identification progress, and alarm information. It also supports user configuration of parameters, initiation of the identification process, and viewing of log records.

[0026] After the multi-serial port device identification system starts, the management module is responsible for coordinating all serial communication resources. First, it calls the monitoring module to scan the physical or virtual serial ports in the main control system, identify the list of currently available valid serial ports, and create an independent serial port channel for each valid port, such as channel 1. Each serial port channel is equipped with a data receiving queue, namely the channel 1 queue, to buffer the raw data stream received in real time from the corresponding serial port, prevent data loss, and enable asynchronous processing.

[0027] Once a serial port channel successfully establishes communication with the device to be identified, the multi-serial port device identification system dynamically selects and loads the appropriate communication protocol module through the protocol module. The protocol module automatically matches the corresponding protocol parser based on the test response data returned by the device to be identified, ensuring that it can correctly decode the data formats of different manufacturers and types of devices to be identified, thereby achieving a flexible architecture of "one platform with multiple protocols compatible".

[0028] Taking device 001 to be identified as an example: After device 001 is connected to a serial port, the multi-serial-port device identification system sends a test command through serial port channel 1; device 001 to be identified returns test response data containing device type and device number. After the test response data is temporarily stored in the channel 1 queue, it is handed over to the protocol parser selected by the protocol module for semantic parsing; after successful parsing, the device identity is confirmed, matching is completed, and a stable connection is established.

[0029] Through the above embodiments, the multi-serial port device identification system is uniformly coordinated by the host computer software, driven by the management module, realizes port discovery with the help of the monitoring module, ensures reliable data transmission by using the serial port channel, and realizes intelligent adaptation of multiple protocols by relying on the protocol module and protocol parser. Finally, it completes the automated identification and long-term stable communication of the device to be identified, significantly improving the level of intelligent management and operation and maintenance efficiency of devices in a multi-serial port environment.

[0030] Figure 2 A schematic flowchart of a multi-serial-port device identification method according to an embodiment of this application is shown. Exemplarily, the multi-serial-port device identification method includes: Step S202: Send a listening command to the listening module to trigger the listening module to identify multiple valid serial ports in the main control system and obtain a list of valid serial ports.

[0031] The listening command refers to a control signal or function call command issued by the management module to initiate the serial port resource probing process. Once received by the listening module, this command triggers it to perform a scan and availability verification of all serial communication ports of the main control system.

[0032] A valid serial port refers to a serial communication interface that is currently available, not exclusively occupied by other processes, and has basic communication capabilities. In other words, it is a serial port in the main control system that can be identified by multiple serial port devices, securely accessed by the system, and used for communication.

[0033] The valid serial port list is a data structure generated by the monitoring module after completing serial port scanning and validity verification. It records all currently available valid serial port identifiers. Understandably, this valid serial port list serves as the basic input data for subsequent serial port channel creation and device matching. During multi-threaded scheduling, the allocation status is dynamically updated to prevent reuse.

[0034] Specifically, when the multi-serial-port device identification system starts or detects an external device access event, the serial port manager first initializes and starts the serial port listening service, loading the serial port configuration information. Then, the management module sends a listening command to the listening module. In response to this listening command, the listening module periodically scans all serial ports in the main control system, verifies the validity of the serial ports through the Windows API (Application Programming Interface), filters out invalid or occupied serial ports, and obtains a list of valid serial ports.

[0035] The above embodiments pre-build an accurate list of valid serial ports, reducing the search space for device identification and avoiding wasting testing time on unavailable ports. Compared to the traditional method of blindly polling all serial ports, this significantly speeds up the overall matching process.

[0036] Step S204: Based on the list of valid serial ports, create multiple serial port channels that run in parallel, and send test commands to the device to be identified through the corresponding serial port channel for each channel.

[0037] In this context, a serial port channel refers to a communication entity created by a multi-serial-port device identification system to manage a single serial communication connection, corresponding to a valid physical or virtual serial port. Each serial port channel encapsulates the communication parameters (baud rate, data bits, stop bits, parity, etc.), input / output buffers, thread context, and status flags (idle, busy, exception, etc.) of the serial port, and supports independent data transmission and reception and protocol interaction operations. In essence, a serial port channel is an independent communication instance bound to a specific valid serial port, used to carry out data interaction tasks with the device to be identified.

[0038] A test command is a specific formatted instruction sent from a serial port channel to a connected device to be identified. It is used to detect the presence of the device, determine its communication protocol type, and obtain its identification information (such as device ID). Optionally, test commands can be generated based on various preset protocol templates.

[0039] In one embodiment, after the monitoring module completes a validity scan of all serial ports in the main control system, the management module receives a list of valid serial ports returned by the monitoring module. Subsequently, the management module initiates a resource initialization process, creating an independent serial port channel based on each serial port number in the list of valid serial ports.

[0040] Each serial port channel maintains an independent worker thread internally, capable of autonomously performing data transmission, reception monitoring, timeout control, and error handling. Optionally, these serial port channels are uniformly registered with the channel manager of the multi-serial port device identification system, forming a parallel channel pool to provide an execution environment for subsequent high-concurrency device identification.

[0041] The multi-serial-port device identification system maintains multiple pre-created serial channels. Each channel enters a "standby" state, waiting for the scheduler to match the channel with the device to be identified, and then initiate a test command transmission operation. Optionally, the serial channels also support dynamic reconfiguration: when a test command generated using a standard protocol template for the first time on a particular serial channel does not receive a valid response, it can automatically switch to another protocol template (such as a vendor's proprietary protocol) to resend the test command, improving the identification success rate.

[0042] Through the parallel operation mechanism of multiple serial port channels in the above embodiments, the system can process device identification tasks on multiple serial ports at the same time, completely getting rid of the time accumulation problem of the traditional single-threaded polling mode, and greatly improving the system response speed in multi-device scenarios.

[0043] In one embodiment, for each device to be identified, the device configuration file stored locally is read to determine the serial port historical matching record corresponding to the device to be identified; if a serial port historical matching record exists, a first matching pair is created based on the serial port channel corresponding to the serial port number stored in the serial port historical matching record and the device to be identified; an unassigned valid serial port is randomly selected from the list of valid serial ports, and a second matching pair is created based on the selected valid serial port and the device to be identified.

[0044] The device configuration file is a locally stored structured data file used to persistently store the matching relationship between historical devices and serial ports. Optionally, the device configuration file should at least include the following fields: device number, device type, serial port number, and last connection timestamp. Understandably, this device configuration file is automatically updated after each successful device identification and stable connection establishment, and is read when the multi-serial port device identification system restarts to accelerate the initialization process.

[0045] Serial port history matching records refer to the latest matching record saved in the device configuration file for a specific device to be identified. Specifically, this includes the serial port numbers that the device has successfully connected to in the past, along with their corresponding communication parameters (baud rate, data bits, parity check, etc.). When the multi-serial port device identification system starts up or detects a new access event, the management module will query whether a corresponding serial port history matching record exists based on the identification characteristics of the current device to be identified (such as device number), serving as the input basis for the intelligent matching strategy.

[0046] If a device has no serial port history matching record, it is considered to be accessing the system for the first time or in a new host environment, and a full serial port polling identification process needs to be started; if there is a serial port history matching record (only one latest record is retained), the connection will be established first by trying to establish a connection through the serial port number associated with the serial port history matching record.

[0047] A serial port number is a unique identifier assigned by the operating system to each physical or virtual serial communication interface, used by applications to access the serial port resource. In this application, it specifically refers to a serial port name that has been verified as valid by the monitoring module and is not currently exclusively occupied by another process.

[0048] The first matching pair refers to the test combination created by prioritizing the serial port number saved in the serial port history matching record for a certain device to be identified during the construction of a multi-threaded identification task. That is, a known historical serial port channel + the corresponding historical device.

[0049] The second matching pair refers to randomly selecting an unassigned idle serial port from the current list of valid serial ports when the first matching fails or the historical record cannot be reused, and forming a new test combination with the same device to be identified, namely, a newly selected valid serial port channel + device to be identified.

[0050] Specifically, taking device 001 as an example, the multi-serial-port device identification system detects an external device access event, with device number 001. The management module reads the device configuration file and finds a historical configuration record V1 for serial port channel C1. Therefore, a first matching pair (001-C1) is first created based on this historical configuration record. Simultaneously, the multi-serial-port device identification system randomly selects an unallocated serial port from the remaining valid serial ports and assigns it to other devices to be identified, creating multiple second matching pairs. Each second matching pair includes a remaining valid serial port and another device to be identified. Furthermore, the first and second matching pairs are respectively executed concurrently by different identification threads for protocol testing.

[0051] Through the above embodiments, prioritizing the use of the first matching pair (based on the serial port's historical configuration records) can achieve a one-time hit in most scenarios, significantly reducing recognition time. Furthermore, the entire process requires no manual specification of the serial port number or manual selection of the protocol type, truly achieving "plug and play" automated management.

[0052] In one embodiment, for each device to be identified, the device configuration file stored locally is read to determine the serial port historical matching record corresponding to the device to be identified; if there is no serial port historical matching record, an unassigned valid serial port is randomly selected from the list of valid serial ports, and a third matching pair is created based on the selected valid serial port and the device to be identified.

[0053] The third matching pair refers to the protocol test combination formed by the multi-serial port device identification system randomly selecting an unallocated idle serial port channel from the current list of valid serial ports for a device to be identified that is accessing for the first time or has no historical connection record during the multi-serial port device identification process. This combination consists of a valid serial port channel and a device to be identified with no historical connection record.

[0054] Specifically, for the third matching pair construction and identification process of the device 005 being connected for the first time, the management module performs the following operations: For one of the newly connected devices, namely device 005 to be identified, the management module first reads the locally stored device configuration file and performs a search operation. The search result is 0, therefore it is determined that device 005 has no historical serial port matching record. Then, an idle channel C5 is randomly selected from the unallocated valid serial ports; this idle channel and device 005 are combined to form a test pair, creating a corresponding third matching pair (005-C5). Understandably, the number of third matching pairs created through the above process corresponds to the number of newly connected devices. Furthermore, the multi-serial port device identification system creates an independent identification thread based on the above third matching pair and adds this identification thread to the multi-threaded scheduling pool.

[0055] The above embodiments employ a strategy of randomly selecting unallocated serial ports to avoid multiple identification threads competing for the same serial port resource, reducing conflicts and blocking, ensuring that each idle channel can participate in the detection process, and maximizing the utilization of available hardware interfaces. Furthermore, it supports seamless integration of future new device types.

[0056] Figure 3 A schematic flowchart of a multi-threaded identification method according to an embodiment of this application is shown. Exemplarily, the multi-threaded identification method includes: Step S302: Create multiple recognition threads, each recognition thread corresponding to a serial port channel and a device to be recognized; Step S304: In the first round of scheduling, multiple first-round identification threads are executed concurrently, and test commands are sent to the device to be identified through the serial port channel corresponding to each first-round identification thread. Step S306: Identify the failed serial port channels that failed to be identified in the first round of scheduling, and create multiple second-round identification threads in the second round of scheduling, with each second-round identification thread corresponding to a failed serial port channel; Step S308: In the second round of scheduling, multiple second-round identification threads are executed concurrently. Test commands are sent to the unidentified devices to be identified through the serial port channel corresponding to each second-round identification thread until all devices to be identified reach the preset maximum number of retries. The second round of scheduling includes each subsequent round of scheduling except for the first round of scheduling.

[0057] In this context, the identification thread refers to an independently running program thread created to perform protocol testing tasks between a specific serial port channel and the device to be identified. Each identification thread is responsible for: sending a preset test command to the connected device through the specified serial port channel; receiving and buffering the response data returned by the device; triggering the protocol module to parse the response data; and determining whether the device type and number have been successfully identified.

[0058] The first round of scheduling refers to the large-scale parallel identification process initiated by the system upon startup or detection of a device access event. Understandably, the goal of the first round of scheduling is to utilize historical information and resource redundancy as much as possible to complete the identification task for most devices in the shortest possible time.

[0059] The first round of identification threads refers to all identification threads created and put into operation in the first round of scheduling. The first round of identification threads are created when the matching process is first triggered after the multi-serial port device identification initialization; each thread corresponds to one currently available serial port channel and one device to be identified; the scheduling strategy prioritizes using the "first matching pair" (based on historical records) to build threads, improving the hit rate; and a standardized multi-protocol probe command sequence is uniformly sent. These first-round identification threads together constitute the first-round high-concurrency probe network, significantly shortening the initial identification time.

[0060] A failed serial port channel refers to a serial port channel in which the corresponding identification thread fails to receive valid response data from the connected device or where protocol parsing fails during a certain round of identification scheduling. The criteria for determination include: no response received after a timeout following the sending of the test command; received data format not conforming to any known protocol specification; response verification error; device returning a negative response or exception code.

[0061] Second-round scheduling refers to a series of progressive retry scheduling processes initiated after the first round of scheduling for devices that have not yet been successfully identified or for failed serial port channels. Each round of second-round scheduling includes: reallocating failed serial port channels to other unidentified devices to be identified; creating a new identification thread (i.e., the second-round identification thread); and concurrently executing test command sending and response parsing again. It can be understood that second-round scheduling is a broad concept, including the second round, the third round, and so on, up to the maximum number of retries.

[0062] The next-round identification thread refers to the identification thread recreated for the failed serial port channel in the next round of scheduling. The creation of the next-round identification thread is premised on the original identification thread failing in the previous round of scheduling; the allocation strategy is that the serial port channel corresponding to this thread is rebound to another device to be identified that has not yet been successfully identified (to avoid repeatedly trying the same invalid combination); the next-round identification thread still executes the same test command sending and response listening process, but the device to be identified changes; the purpose is to improve the final identification success rate by dynamically reorganizing the matching relationship.

[0063] The preset maximum number of retries refers to the upper limit of retries set in the multi-serial port device identification system to prevent wireless loop identification. It can be configured by the user or set by system default (e.g., 3 or 5 times). When a device to be identified fails to be identified after multiple rounds of scheduling: if the number of connection attempts to the device is greater than or equal to the preset maximum number of retries, further detection will stop. Furthermore, the multi-serial port device identification system generates an alarm log, indicating that the device to be identified may have hardware failures, protocol incompatibility, or abnormal physical connections.

[0064] Specifically, taking a main control system containing 6 valid physical serial ports and corresponding serial channels (C1, C2, C3, C4, C5, C6) as an example, connecting 4 different types of devices to be identified (001, 002, 003, 004).

[0065] The multi-serial-port device identification system creates six first-round identification threads (T1~T5), each corresponding to a matching pair, and concurrently executes and sends test commands: T1: Sends test command 1 to device 001 to be identified via serial port channel C1; T2: Sends test command 2 to device 002 to be identified via serial port channel C2; T3: Sends test command 3 to device 003 to be identified via serial port channel C3; T4: Sends test command 4 to device 004 to be identified via serial port channel C4; T5: Sends test command 5 to device 005 to be identified via serial port channel C5.

[0066] T1, T2, T3, T4, and T6 successfully received responses, parsed the device type and number, and established a stable connection. T5 did not respond, indicating that the serial port channel corresponding to T5 failed to be identified. At this point, only device 005 remains to be identified, and serial port channel C5 is a failed serial port channel.

[0067] In the second round of scheduling, the failed serial channel C5 is reassigned to the still unidentified device 005, and a new second-round identification thread T6 is created. T6 is executed concurrently, sending test command 6 to the device 005 via serial channel C5 and successfully receiving response data. The protocol module parses the device type and device number of the device 005. Finally, a persistent connection is established between the device 005 and serial channel C5, and the device configuration file is updated. Once all devices have been identified, the scheduling process terminates. If the second round fails again, a third round of scheduling is initiated, using other idle channels to try again, until the preset maximum number of retries (e.g., 3) is reached, at which point the process is abandoned and an offline alarm is issued.

[0068] Through the above embodiments, even if the first round of matching fails (such as due to incorrect device insertion, response delay, noise interference, etc.), the system can still automatically switch channels and re-probe through the second round of scheduling, avoiding the problem of a single failure causing the device to be unrecognizable. Furthermore, by executing multiple rounds of recognition threads concurrently through multi-threading, the time complexity of traditional serial scanning is reduced, significantly improving recognition efficiency.

[0069] Step S206: Send a test verification command to the protocol module to trigger the protocol module to receive the test response data of the device to be identified and parse the test response data.

[0070] The test verification command is a control signal or command message sent by the management module to the protocol module to trigger the protocol module to start the parsing process of the received data stream. Understandably, the test verification command does not contain actual communication data; instead, it serves as an enable signal for a function call, instructing the protocol module to prepare to receive and semantically parse the received data packets from the device to be identified using a preset communication protocol format to extract identification information such as device type and device number.

[0071] Test response data refers to the data message with a specific structure returned by the device under test after receiving a test command sent by the management module through a serial port channel. This data message contains at least information fields that can identify the device, including but not limited to device type identifier, device unique number, and optional version number, manufacturer code or checksum, etc.

[0072] Specifically, the management module sends test verification commands to the protocol module, which then creates a protocol parser upon receiving the commands. The serial port channel sends test commands to the device to be identified via the protocol parser and receives test response data from the device. The device type and device number of the device to be identified are determined based on the format and content of the test response data. Different protocol parsers implement a unified interface, supporting multiple device protocols.

[0073] Through the above embodiments, a collaborative mechanism of "test verification command and test response data parsing" is introduced, which realizes efficient and reliable automatic device identification in a multi-serial port environment, significantly improving identification efficiency compared with the traditional manual configuration scheme.

[0074] Step S208: If the device type and device number of the device to be identified are obtained by parsing, then a communication connection is established between the device to be identified and the corresponding serial port channel.

[0075] The device type refers to an identifier used to characterize the functional category or device family to which the device to be identified belongs. This identifier is preset by the device manufacturer in the firmware and returned in the form of structured data when responding to test commands. The device type is used to distinguish external devices for different purposes, such as sensors, actuators, and monitoring instruments.

[0076] A device number is a unique hardware identifier assigned to each device to be identified. It is used for individual-level differentiation and tracking management of devices in a multi-serial-port device identification system. The device number is globally unique or locally unique (it will not be repeated within the same network / control system) and is burned into non-volatile memory by the device at the factory.

[0077] In one embodiment, a heartbeat request message is sent to the connected device to be identified at preset time intervals through an established serial port channel; the heartbeat response message returned by the device to be identified is detected; if no heartbeat response message is received for a preset number of consecutive times, it is determined that the connection of the device to be identified is abnormal, and a reconnection and an offline alarm signal are triggered.

[0078] The preset time interval refers to the periodic heartbeat request period set by the multi-serial port device identification system to detect the online status of serial port devices. It is usually a fixed value (such as 10 seconds or 30 seconds).

[0079] A heartbeat request message is a lightweight probe message sent by the master control system to the device to be identified through an established serial port channel. It does not carry business data and is only used to verify link connectivity.

[0080] A heartbeat response message is an acknowledgment message returned by the device to be identified to the main control system after receiving a heartbeat request message, indicating that it is in normal working condition; if no response is returned, it is considered that the link is abnormal or the device is offline.

[0081] The preset number of consecutive attempts refers to the maximum number of consecutive times (e.g., 3 times) that a multi-serial port device identification system is allowed to fail to receive a heartbeat response message. Exceeding this preset number of consecutive attempts is considered a connection interruption, triggering subsequent processing mechanisms. This is used to avoid misjudgments caused by momentary interference.

[0082] Offline alarm signals refer to the notification signals generated by the multi-serial port device identification system when the device to be identified is confirmed to be offline. They can be used for local log recording, interface prompts, remote push to the cloud platform, or linkage with other control logic to realize fault warning and operation and maintenance support.

[0083] Specifically, after completing the parsing of the device type and device number and successfully establishing a communication connection, the management module starts the operation status monitoring mechanism of the device to be identified, including: periodically sending heartbeat request messages to the device to be identified through the serial port channel bound to the device to be identified at a preset time interval.

[0084] The multi-serial port device identification system then checks whether the device to be identified returns a corresponding heartbeat response message. Under normal circumstances, upon receiving a heartbeat request, the device to be identified will immediately send back a heartbeat response message conforming to the protocol format, indicating that its current communication link is open and the device is operating normally. The multi-serial port device identification system starts a short waiting window after each request is sent to receive and identify the response message.

[0085] If no response message is received after a heartbeat request is sent, the multi-serial port device identification system will record this as a "no response". When the number of consecutive times no heartbeat response messages are received reaches the system's preset "number of consecutive times" (e.g., 3 consecutive times), the multi-serial port device identification system determines that the device to be identified has a connection abnormality and considers it to be offline or communication interrupted.

[0086] Once a connection anomaly is confirmed, the multi-serial-port device identification system immediately performs two operations: the first is to trigger a reconnection mechanism, attempting to resend the test command through the original serial port channel to restore communication with the device to be identified; the second is to generate an offline alarm signal, which can be used for local recording, interface prompts, or uploaded to a remote monitoring platform to remind users or maintenance personnel to pay attention to the device status, thereby achieving fault early warning and rapid response.

[0087] The above embodiments effectively improve the operational stability and intelligent management level of multi-serial port device systems, enabling them to automatically detect faults, proactively restore connections, and promptly report abnormal events in unattended environments, thus ensuring the reliable operation of the entire system.

[0088] It is understood that the system in this embodiment corresponds to the multi-serial port device identification method in the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0089] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described multi-serial-port device identification method or the above-described multi-serial-port device identification system.

[0090] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0091] Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Memory is used to store computer programs, and the processor can execute these programs upon receiving execution instructions.

[0092] This application also provides a computer-readable storage medium for storing computer programs used in the aforementioned terminal devices. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0093] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can also be implemented in other ways. The system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0094] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0095] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0096] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for identifying multi-serial-port devices, characterized in that, An application is provided in a multi-serial-port device identification system. The system includes a management module, a monitoring module, and a protocol module. The management module executes the following identification method: Send a listening command to the listening module to trigger the listening module to identify multiple valid serial ports in the main control system and obtain a list of valid serial ports; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. Send a test verification command to the protocol module to trigger the protocol module to receive the test response data of the device to be identified and parse the test response data; If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

2. The method according to claim 1, characterized in that, The step of sending a test command to the device to be identified through the corresponding serial port channel for each of the aforementioned serial port channels includes: Multiple matching pairs are created based on the multiple serial port channels and the multiple devices to be identified; For each matching pair, an identification thread is created, and a test command is sent to the corresponding device to be identified through the serial port channel corresponding to each identification thread.

3. The method according to claim 2, characterized in that, The step of creating an identification thread based on each matching pair and sending test commands to the corresponding device to be identified through the serial port channel corresponding to each identification thread includes: Multiple identification threads are created, each of which corresponds to a serial port channel and a device to be identified. In each round of identification scheduling, multiple identification threads are executed concurrently, and test commands are sent to the corresponding device to be identified through the serial port channel corresponding to each identification thread.

4. The method according to claim 3, characterized in that, In each round of identification scheduling, multiple identification threads are executed concurrently, and test commands are sent to the device to be identified through the serial port channel corresponding to each identification thread, including: In the first round of scheduling, multiple first-round identification threads are executed concurrently, and test commands are sent to the device to be identified through the serial port channel corresponding to each first-round identification thread. The failed serial port channels that failed to be identified in the first round of scheduling are determined, and multiple secondary round identification threads are created again in the second round of scheduling, with each secondary round identification thread corresponding to one of the failed serial port channels; In the second round of scheduling, multiple second-round identification threads are executed concurrently. Test commands are sent to the unidentified devices to be identified through the serial port channel corresponding to each second-round identification thread until all devices to be identified reach the preset maximum number of retries. The second round of scheduling includes each next round of scheduling other than the first round of scheduling.

5. The method according to claim 2, characterized in that, The process of creating multiple matching pairs based on multiple serial port channels and multiple devices to be identified includes: For each device to be identified, read the device configuration file stored locally to determine the serial port historical matching record corresponding to the device to be identified; If the serial port historical matching record exists, a first matching pair is created based on the serial port channel corresponding to the serial port number and the target device to be identified stored in the serial port historical matching record; Randomly select an unassigned valid serial port from the list of valid serial ports, and create a second matching pair based on the selected valid serial port and the target device to be identified.

6. The method according to claim 2, characterized in that, The process of creating multiple matching pairs based on multiple serial port channels and multiple devices to be identified includes: For each device to be identified, read the device configuration file stored locally to determine the serial port historical matching record corresponding to the device to be identified; If no historical matching record for the serial port exists, an unassigned valid serial port is randomly selected from the list of valid serial ports, and a third matching pair is created based on the selected valid serial port and the target device to be identified.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Send heartbeat request messages to the connected device to be identified at preset time intervals through the established serial port channel. The system detects the heartbeat response message returned by the device to be identified. If the heartbeat response message is not received for a preset number of consecutive times, it determines that the device to be identified is abnormally connected and triggers reconnection and generation of an offline alarm signal.

8. A multi-serial-port device identification system, characterized in that, include: The monitoring module is used to receive monitoring commands and identify multiple valid serial ports in the main control system based on the monitoring commands to obtain a list of valid serial ports. The protocol module is used to receive test verification instructions, receive test response data of the device to be identified based on the test verification instructions, and parse the test response data; The management module is used to send the listening command and the test verification command; Based on the list of valid serial ports, multiple serial port channels are created to run in parallel, and for each of the serial port channels, a test command is sent to the device to be identified through the corresponding serial port channel. If the device type and device number of the device to be identified are obtained through parsing, a communication connection is established between the device to be identified and the corresponding serial port channel.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the multi-serial port device identification method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the multi-serial-port device identification method according to any one of claims 1-7.

Images