Multi-protocol adaptive slave station control method and equipment

Abstract

The invention belongs to the technical field of industrial control, provides a multi-protocol adaptive slave station control method and equipment, and is used for solving the problems of high protocol switching delay, complicated configuration and high hardware cost in the prior art. Comprising the following steps: capturing a data frame sent by an upper computer, and executing a hierarchical analysis strategy to identify a protocol ID corresponding to the data frame; switching to a corresponding protocol stack based on the protocol ID, and loading a protocol analyzer; analyzing the data frame to obtain a slave station control instruction; and executing the slave station control instruction and returning a response frame to the upper computer. According to the method, the rapid adaptive switching of the slave station to multiple protocols such as EtherCAT, PROFINET and Omron FINS is realized through the layered analysis and the rapid matching of the hash table in combination with dynamic switching, the protocol switching time is shortened to be within 200 milliseconds from the minute level, and the method can be used for controlling multiple scenes such as a slave station light source.

Description

Technical Field

[0001] This invention relates to the field of industrial control technology, and in particular to a multi-protocol adaptive slave control method and device. Background Technology

[0002] Distributed control system architecture is widely used in industrial control. This architecture consists of a master station as the control core and multiple slave stations distributed in the field. The master station is typically a programmable logic controller (PLC) or an industrial personal computer, while the slave stations include execution units such as I / O modules, sensors, drivers, and light source controllers. Communication and data exchange between the master and slave stations are achieved through various industrial Ethernet protocols such as EtherCAT, PROFINET, and Omron FINS. However, in actual production, due to differences in equipment origin and production line generations, different control systems employ different protocols.

[0003] Most existing industrial slave stations are designed for only one or a few specific protocols. This necessitates hardware replacement or software reconfiguration when integrating them into control systems using different protocols. This switching process can take minutes, is time-consuming and labor-intensive, relies on specialized personnel, severely restricts production line efficiency, and affects system flexibility.

[0004] To address the aforementioned multi-protocol compatibility issues, existing technologies employ two main solutions: First, a protocol conversion device is used, connecting an independent protocol conversion gateway between the master and slave stations. For example, Chinese invention patent CN104104684A discloses a fieldbus multi-protocol converter capable of mutual conversion between five fieldbus protocols, including CAN. Second, a multi-protocol stack redundancy scheme integrates multiple protocol stacks within the slave station. However, while these solutions improve compatibility to some extent, the former involves data packet format conversion, introducing additional communication latency and increasing hardware costs and system complexity. The latter typically requires manual selection of the active protocol and fails to address the dynamic decision-making problem when different protocol instructions conflict, resulting in switching delays and wasted hardware resources. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-protocol adaptive slave control method and device to solve the problem that the requirements for multi-protocol compatibility, communication latency, and hardware configuration cannot be simultaneously met in the prior art.

[0006] To achieve the above objectives, this application proposes the following technical solution:

[0007] This technical solution provides a multi-protocol adaptive slave control method, the steps of which are as follows:

[0008] S1: Capture the data frame sent by the host computer and execute a hierarchical parsing strategy to identify the protocol ID corresponding to the data frame; wherein, the hierarchical parsing strategy executes the following steps in sequence:

[0009] Parse the protocol type field in the link layer header of the data frame; if the protocol type field matches a predefined link layer protocol feature value, then map the data frame to a protocol ID;

[0010] If the protocol type field does not match the predefined link layer protocol feature value, the transport layer header of the data frame is parsed to obtain the target port number; if the target port number matches the predefined port number, the data frame is mapped to a protocol ID.

[0011] If the target port number does not match the predefined port number, the structure and length characteristics of the application layer payload of the data frame are parsed; if the structure and length characteristics of the application layer payload match the predefined application layer payload characteristics, the data frame is mapped to a protocol ID; if the structure and length characteristics of the application layer payload do not match the predefined application layer payload characteristics, a protocol identification failure indication message is generated.

[0012] S2: Based on the protocol ID, switch to the protocol stack associated with the protocol ID, load the protocol parser corresponding to the protocol stack, and trigger a protocol ready notification;

[0013] S3: Use the protocol parser to parse the data frame to obtain slave control commands;

[0014] S4: Execute the slave control command, collect the execution result and hardware status data to construct a response frame, and send the response frame to the host computer.

[0015] In this method, S1 uses a hierarchical parsing strategy to solve the problems of traditional controllers having a single protocol and requiring manual pre-configuration, laying the foundation for achieving fast switching within 200ms and greatly improving the device's adaptability and deployment efficiency in different protocol environments.

[0016] S2 enables on-demand invocation and millisecond-level switching of the protocol stack, thereby overcoming the shortcomings of traditional multi-protocol controllers that require restarting or undergoing long-delay switching. It achieves fast switching within 200ms, reducing protocol switching time from minutes to milliseconds, thus meeting the requirements for high real-time performance and continuous stable operation in industrial automation scenarios.

[0017] S3 effectively avoids communication interruptions, malfunctions, or control failures caused by protocol mismatches or parsing errors by combining precise layered protocol parsing based on S1 with protocol conflict handling methods. This ensures the accuracy of control and the reliability of the system, and broadens the compatibility with complex and heterogeneous industrial networks.

[0018] S4 constructs a response frame containing the slave station's execution results and hardware status data and sends it to the host computer, forming a complete and standardized communication interaction loop between the slave station and the host computer. This enables the host computer to clearly understand the slave station's status, achieves adaptive control, and improves the transparency of data interaction and the maintainability of the entire industrial automation production line.

[0019] Specifically, the protocols include: EtherCAT, PROFINET, ModbusTCP, EtherNet / IP, and Omron FINS. By being compatible with mainstream and specific vendor protocols, this method ensures broad applicability and integration capabilities in complex industrial environments, solving the problem of equipment incompatibility due to protocol barriers.

[0020] Specifically, the features parsed by the layered parsing strategy include: predefined link layer protocol feature values, target port numbers in the network layer and transport layer headers, and the structure and length characteristics of the application layer payload. By comprehensively judging these multi-dimensional features, the accuracy and reliability of protocol identification are significantly improved, avoiding misjudgments that might result from a single feature.

[0021] Specifically, in the method, the industrial Ethernet protocols based on link layer protocol feature value mapping protocol ID include EtherCAT and PROFINET protocols; the industrial Ethernet protocols based on target port number mapping protocol ID include ModbusTCP and EtherNet / IP protocols; and the protocols based on application layer load feature mapping protocol ID include Omron FINS protocol.

[0022] Specifically, the hierarchical parsing strategy is as follows:

[0023] Parse the protocol type field in the data frame link layer. If the field matches a predefined link layer protocol feature value, then map the data frame to a protocol ID, such as the ID of the EtherCAT protocol or the PROFINET protocol.

[0024] If the field indicates an Internet protocol, the transport layer header is parsed to obtain the target port number; if the target port number matches a predefined port number, the data frame is mapped to a protocol ID, such as the ID of the Modbus TCP protocol or the EtherNet / IP protocol.

[0025] If the target port number does not belong to the predefined port number, the application layer load is further parsed. Based on the structure and length characteristics of the application layer data, if it matches the preset application layer load characteristics, the data frame is mapped to a non-standard protocol ID, such as the ID of the Omron FINS protocol. If the structure and length characteristics of the application layer load fail to match the predefined application layer load characteristics, a protocol identification failure indication message is generated.

[0026] Specifically, the step of capturing data frames sent by the host computer and executing a hierarchical parsing strategy to identify the protocol ID corresponding to the data frame includes: when the protocol ID identification fails, sending an error response indicating that the protocol cannot be identified to the host computer and discarding the data frame.

[0027] The advantage of the layered parsing strategy is that it greatly optimizes processing efficiency through progressive identification. It can quickly identify protocols with protocol type identifiers at the link layer, such as EtherCAT and PROFINET, or protocols with dedicated port numbers at the transport layer, such as ModbusTCP and EtherNet / IP. At the same time, it ensures accurate identification of non-standard protocols without dedicated port numbers, such as Omron FINS, and achieves fast switching within 200ms.

[0028] Furthermore, the identification of the Omron FINS protocol includes: extracting the first N bytes of the application layer data payload of the data frame and comparing them with the fixed frame header structure of the FINS protocol; wherein, the frame header structure includes a fixed padding byte of 0x00 and a 2-byte field indicating the length of the FINS instruction. The key of the hash table used to match the FINS protocol is composed of the target port number and a fixed characteristic byte at a specific offset position in the application layer payload of the data frame. The advantage of this approach is that by verifying the fixed frame header structure and the instruction length field, the FINS protocol can be uniquely identified, avoiding potential conflicts and errors caused by identification based on non-unique port numbers.

[0029] Specifically, the predefined link layer protocol feature values, target port numbers, and predefined application layer load features are stored in the protocol feature library.

[0030] Specifically, the protocol feature database is stored using a hash table, where the key is the protocol feature value and the value is the corresponding protocol ID or protocol stack pointer. Further, the key of the hash table is a combination of one or more protocol feature values ​​extracted from the data frame, and the value of the hash table is the corresponding protocol ID and protocol stack entry address.

[0031] Furthermore, the matching process involves using the parsed feature value as a query key to search the hash table. If a match is found, the corresponding protocol ID is returned, completing the protocol identification. Utilizing the direct addressing characteristic of hash tables, extremely high matching efficiency is achieved, and this matching speed does not decrease with the increase in the protocol feature database size, thus ensuring the real-time performance of protocol identification.

[0032] Specifically, the triggering conditions for switching to the protocol stack associated with the protocol ID include active switching and passive switching, wherein:

[0033] Active switching is triggered by the initial connection or by a protocol switching command sent by the host computer;

[0034] Passive switching is triggered by three consecutive CRC check errors or a response timeout greater than 50ms.

[0035] When a connection is established for the first time or a protocol switching instruction is received from the host computer, the slave station directly triggers and executes the step of switching to the protocol stack associated with the protocol ID, according to the instruction content or pre-configuration.

[0036] When three consecutive CRC check errors are detected or the response delay is greater than the preset delay threshold of 50ms, the slave station sequentially traverses or selects the preset candidate protocol IDs according to the strategy, and executes the step of switching to the protocol stack associated with the protocol ID, until communication is restored to normal or all candidate protocols have been tried.

[0037] By using a dynamic switching condition of "active + passive", the system not only ensures automated operation under normal circumstances, but also gives it the ability to autonomously correct and recover when communication is abnormal, which significantly improves the robustness and availability of the system.

[0038] Specifically, the slave control command is used to control at least one slave device, and the slave control command includes: switch control command and parameter adjustment command; wherein, the slave device includes: IO module, sensor, driver or light source controller.

[0039] Specifically, the method also includes an interactive verification mode, as follows:

[0040] When a protocol conflict is detected, the conflict time, conflict protocol ID, and original data frame are recorded as a protocol conflict log.

[0041] The protocol conflict log is output through the human-machine interface, and manual decision-making instructions input through the human-machine interface are received to determine the priority order of the protocols to be executed.

[0042] Specifically, the protocol conflict satisfies at least one of the following conditions:

[0043] The features of a single data frame can be successfully matched with the features of multiple different protocols in the protocol feature library.

[0044] Multiple data frames using different protocols have their parsed slave control commands pointing to the same logical address in the slave.

[0045] Specifically, when the extracted features of a single data frame match multiple key-value pairs in the protocol feature library, it is identified as a protocol conflict. The conflict log is then recorded and an alarm is issued through the human-machine interface, awaiting human decision-making instructions to determine the final protocol to be executed.

[0046] When protocols conflict, the above-mentioned logging and manual judgment avoid system failures that may result from blind execution, ensuring the final correctness of control logic and production safety, and demonstrating the intelligence of human-machine collaboration.

[0047] Specifically, the protocol readiness notification is used to trigger the reconfiguration of the slave hardware interface to adapt to the communication timing or electrical characteristics required by the protocol ID.

[0048] The present invention also provides a multi-protocol adaptive slave control device, comprising:

[0049] A processing unit, wherein the processing unit is configured to implement each step of the multi-protocol adaptive slave control method described in any of the preceding claims;

[0050] A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-protocol adaptive slave control method described in any of the preceding claims.

[0051] Since the processing unit and readable storage medium are both built based on the method and used to implement the method, in practical applications, the additional latency and hardware cost problems caused by the protocol conversion gateway scheme can be effectively solved, and the compatibility of a single hardware platform with multiple protocols can be achieved. The defects of relying on manual configuration and slow switching speed in the multi-protocol stack redundancy scheme can be overcome, and millisecond-level, fully automatic protocol switching can be achieved. Finally, the slave device can be plug-and-play, which greatly reduces the integration complexity and maintenance cost of industrial automation system.

[0052] Beneficial effects:

[0053] As can be seen from the above technical solutions, the technical solution of the present invention provides a multi-protocol adaptive slave control method and device to solve the problems of switching delay, complicated configuration and high hardware cost in the prior art.

[0054] The technical effects brought about by the technical solution described in this invention are as follows:

[0055] 1. Regarding switching latency, traditional methods, such as protocol conversion gateways, require packet format conversion, resulting in forwarding latency exceeding 200ms; while multi-protocol stack redundancy solutions require manual intervention, with switching times exceeding 30 seconds. This invention achieves rapid switching within 200ms through layered parsing and hash table matching, combined with dynamic switching, reducing protocol switching time from minutes to milliseconds, significantly improving production line efficiency and system real-time performance.

[0056] 2. Regarding the control process, traditional methods rely on professionals to manually configure settings via DIP switches, jumpers, or software. Multi-protocol stack redundancy schemes require manual intervention when switching protocols, a cumbersome and error-prone process. This invention automatically identifies and adaptively switches the host computer's protocol, achieving plug-and-play and one-click configuration for the slave station, completely eliminating the need for manual pre-configuration and reducing operational barriers and maintenance costs. Simultaneously, by constructing response frames containing slave station execution results and hardware status data and sending them to the host computer, a complete and standardized communication interaction loop is established between the slave station and the host computer, enabling the host computer to clearly understand the slave station's status and achieving adaptive control.

[0057] 3. Regarding hardware costs, traditional solutions require dedicated hardware or additional conversion gateways for different protocols, increasing system complexity and cost. This invention integrates multi-protocol adaptive capabilities on a single slave station, compatible with various mainstream and non-standard protocols from the link layer to the application layer. It replaces multiple dedicated devices with a single hardware platform, significantly reducing hardware costs while greatly enhancing the device's versatility and integration flexibility.

[0058] It should be understood that all combinations of the foregoing concepts and the additional concepts described in more detail below can be considered part of the inventive subject matter of this disclosure, provided that such concepts do not contradict each other.

[0059] The foregoing and other aspects, embodiments, and features of the teachings of the present invention will be more fully understood from the following description in conjunction with the accompanying drawings. Other additional aspects of the invention, such as features and / or beneficial effects of exemplary embodiments, will become apparent from the following description or may be learned through practice of specific embodiments according to the teachings of the present invention. Attached Figure Description

[0060] The accompanying drawings are not drawn to scale. In the drawings, each identical or nearly identical component shown in the various figures may be denoted by the same reference numeral. For clarity, not every component is labeled in each figure. Embodiments of various aspects of the invention will now be described by way of example and with reference to the accompanying drawings, wherein:

[0061] Figure 1This is a schematic diagram of the system composition of a slave control method based on multi-protocol adaptive control disclosed in an embodiment of this application;

[0062] Figure 2 This is a flowchart of a slave control method based on multi-protocol adaptive control disclosed in an embodiment of this application;

[0063] Figure 3 This is a data flow diagram of a slave control method based on multi-protocol adaptive control disclosed in an embodiment of this application. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the scope of protection of the present invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art to which this invention pertains.

[0065] The terms "first," "second," and similar words used in the specification and claims of this patent application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, unless the context clearly indicates otherwise, the singular forms of "an," "a," or "the," etc., do not indicate a quantity limitation, but rather indicate the presence of at least one. Terms such as "comprising" or "including" mean that the element or object preceding "comprising" encompasses the features, integrals, steps, operations, elements, and / or components listed following "comprising" or "including," and do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; these relative positional relationships may change accordingly when the absolute position of the described object changes.

[0066] Before introducing this application, the relevant technologies of this application will be introduced first.

[0067] Industrial Ethernet protocols are a class of communication protocols developed on top of standard Ethernet to meet the high real-time, high reliability, and deterministic communication requirements of industrial control systems. Common industrial Ethernet protocols include EtherCAT, PROFINET, ModbusTCP, EtherNet / IP, and Omron FINS. Differences in frame structure, communication mechanisms, and application-layer semantics among these protocols make direct interoperability between devices difficult.

[0068] Industrial Ethernet protocols exhibit a distinct hierarchical design: some protocols, such as EtherCAT and PROFINET, are clearly identified at the link layer; others, like ModbusTCP and EtherNet / IP, are distinguished by port numbers at the transport layer; and some non-standard protocols, such as FINS, require in-depth analysis of the application layer structure. The layered resolution strategy balances efficiency and accuracy by identifying each layer sequentially.

[0069] Slave stations are field-based execution units in distributed control systems, such as I / O modules, sensors, drivers, and light source controllers. They receive control commands from the host computer (master station), execute specific operations, and provide status feedback. Traditional slave stations typically support only a single protocol, limiting their flexible deployment in heterogeneous networks.

[0070] The following detailed description of a multi-protocol adaptive slave control method and device disclosed in this invention, with reference to the specific structure of the embodiments shown in the accompanying drawings, will provide a further detailed introduction.

[0071] Figure 1 This is a schematic diagram of the system composition of a slave control method based on multi-protocol adaptive control disclosed in an embodiment of this application, including a host computer, a protocol sniffing module, a dynamic switching module, a control execution module, and slave stations. Wherein:

[0072] The host computer, typically an industrial control host or PC, is used to send data frames to the protocol sniffing module and receive response frames from the control execution module.

[0073] A protocol sniffing module, connected to the host computer, captures data frames sent by the host computer, analyzes the features of the data frames using a hierarchical parsing strategy, and matches them with a protocol feature library to identify the protocol ID. The protocol ID is then sent to the dynamic switching module. The protocol sniffing module supports parsing frame structures for protocols such as EtherCAT, PROFINET, ModbusTCP, and EtherNet / IP. Specifically, the protocol sniffing module can be implemented using a Field-Programmable Gate Array (FPGA), such as the Fudan Microelectronics JFM7K series FPGA chip. Utilizing its hardware parallel processing capabilities, integrated high-speed serial transceiver, and abundant logic resources, it can achieve line-speed data frame capture, hierarchical parsing pipeline, and fast hash table matching, ensuring deterministic low latency and high reliability in the protocol identification process. Furthermore, other FPGA chips with hard real-time processing cores and hardware acceleration capabilities are also under consideration.

[0074] The dynamic switching module, constructed using the method, is connected to the protocol sniffing module and the control execution module, respectively. It is used to switch to the protocol stack associated with the protocol ID based on the protocol ID sent by the protocol sniffing module and according to the dynamic switching conditions, and load the protocol parser corresponding to the protocol stack in the control execution module, while notifying the control execution module that the protocol is ready.

[0075] The control execution module, constructed using the method, is connected to the protocol sniffing module, the dynamic switching module, and the slave station. It is used to obtain the data frame from the protocol sniffing module and parse the data frame using the protocol parser loaded by the dynamic switching module to obtain slave station control instructions. It is also used to drive the slave station to execute the slave station control instructions, collect the execution results and hardware status data from the slave station, and then construct a response frame containing both data and send it to the host computer.

[0076] The slave station, connected to the control execution module, executes control commands driven by the control execution module and feeds back its execution results and hardware status data to the control execution module. Specifically, the slave station includes: an I / O module, a sensor, a driver, or a light source controller. The slave station control commands include: controlling the I / O module or sensor to switch on and off, adjusting the light source brightness, or adjusting the light source switching speed.

[0077] The advantage of this approach is that slave devices no longer need manual configuration for different host computer protocols, such as DIP switches, jumpers, or software settings. As long as the network is connected, the system can automatically identify the protocol and complete self-configuration, greatly simplifying installation and integration. Through the rapid feature matching of the protocol sniffing module and the on-demand loading of the dynamic switching module, the entire protocol identification and switching process is compressed to within 200 milliseconds. Compared to traditional minute-level manual switching or gateway conversion, this significantly improves production line efficiency. Furthermore, the system enables a single hardware platform to be compatible with multiple protocols, directly reducing hardware costs, inventory types, and the overall system complexity.

[0078] Figure 2 This is a flowchart of a multi-protocol adaptive slave control method disclosed in an embodiment of this application. The steps are as follows:

[0079] S1: Capture the data frame sent by the host computer and execute a hierarchical parsing strategy to identify the protocol ID corresponding to the data frame; wherein, the hierarchical parsing strategy executes the following steps in sequence:

[0080] Parse the protocol type field in the link layer header of the data frame; if the protocol type field matches a predefined link layer protocol feature value, then map the data frame to a protocol ID;

[0081] If the protocol type field does not match the predefined link layer protocol feature value, the transport layer header of the data frame is parsed to obtain the target port number; if the target port number matches the predefined port number, the data frame is mapped to a protocol ID.

[0082] If the target port number does not match the predefined port number, the structure and length characteristics of the application layer payload of the data frame are parsed; if the structure and length characteristics of the application layer payload match the predefined application layer payload characteristics, the data frame is mapped to a protocol ID; if the structure and length characteristics of the application layer payload do not match the predefined application layer payload characteristics, a protocol identification failure indication message is generated.

[0083] S2: Based on the protocol ID, switch to the protocol stack associated with the protocol ID, load the protocol parser corresponding to the protocol stack, and trigger a protocol ready notification;

[0084] S3: Use the protocol parser to parse the data frame to obtain slave control commands;

[0085] S4: Execute the slave control command, collect the execution result and hardware status data to construct a response frame, and send the response frame to the host computer.

[0086] Specifically, the hierarchical parsing strategy is as follows:

[0087] First, parse the Ethernet type field in the data frame link layer. If the field is 0x88A4 or 0x8892, it is mapped to EtherCAT protocol ID or PROFINET protocol ID.

[0088] If the field is 0x0800, continue parsing the network layer and transport layer packet headers to obtain the destination port number; if the destination port number is 502 or 44818, it is mapped to the Modbus TCP protocol ID or EtherNet / IP protocol ID.

[0089] If the target port number is a value other than 502 or 44818, the application layer load is further parsed, and non-standard protocols are identified based on the application layer data structure and length characteristics; if the protocol type field matches the predefined link layer protocol characteristic value, it is mapped to the Omron FINS protocol ID.

[0090] Furthermore, the process of identifying the Omron FINS protocol includes:

[0091] The first N bytes of the application layer data payload of the data frame are extracted and compared with the fixed frame header structure of the FINS protocol. The frame header structure includes a fixed padding byte of 0x00 and a 2-byte field indicating the length of the FINS instruction. The key of the hash table used to match the FINS protocol is composed of the target port number and a fixed characteristic byte at a specific offset position in the application layer payload of the data frame. This approach uniquely identifies the FINS protocol by verifying the fixed frame header structure and instruction length field, avoiding potential conflicts and errors caused by identification based on non-unique port numbers.

[0092] Specifically, the predefined link layer protocol feature values, target port numbers, and predefined application layer load features are stored in the protocol feature library.

[0093] Specifically, the protocol feature database is stored using a hash table, where the key is the protocol feature value and the value is the corresponding protocol ID or protocol stack pointer. Further, the key of the hash table is a combination of one or more protocol feature values ​​extracted from the data frame, and the value of the hash table is the corresponding protocol ID and protocol stack entry address.

[0094] Furthermore, taking the EtherCAT protocol as an example, the matching process is as follows: The EtherType field value is parsed from the data frame as a key feature and combined into a query key; this query key is input into a hash table, and through the direct addressing capability of the hash table, the traversal search is bypassed to directly locate the corresponding storage location. If a completely matching key is found at this location, its corresponding protocol ID is immediately returned, and the identification is complete. If no match is found, a parsing and learning mechanism is initiated: First, a full-message deep feature scan is performed on the data frame, and a secondary match is performed with the backup protocol feature library; if a match is successful, the hash table is dynamically updated and the identification is completed; if no match is found, an unknown protocol event is recorded and an alarm is triggered, while maintaining the existing communication state or entering a safe mode. This process utilizes the direct addressing characteristic of the hash table, achieving extremely high matching efficiency under normal conditions, and this matching speed does not decrease with the increase of the protocol feature library capacity. Combined with the aforementioned hierarchical processing mechanism, this ensures the real-time performance, learning ability, and system robustness of the protocol identification process.

[0095] Specifically, the triggering adjustment for switching to the protocol stack associated with the protocol ID based on the protocol ID includes active switching and passive switching, wherein:

[0096] Active switching is triggered by the initial connection or by a protocol switching command sent by the host computer;

[0097] Passive switching is triggered by three consecutive CRC check errors or a response timeout greater than 50ms.

[0098] When a connection is established for the first time or a protocol switching instruction is received from the host computer, the slave station directly triggers and executes the step of switching to the protocol stack associated with the protocol ID, according to the instruction content or pre-configuration.

[0099] When three consecutive CRC check errors are detected or the response delay is greater than the preset delay threshold of 50ms, the slave station sequentially traverses or selects the preset candidate protocol IDs according to the strategy, and executes the step of switching to the protocol stack associated with the protocol ID, until communication is restored to normal or all candidate protocols have been tried.

[0100] By using a dynamic switching condition of "active + passive", the system not only ensures automated operation under normal circumstances, but also gives it the ability to autonomously correct and recover when communication is abnormal, which significantly improves the robustness and availability of the system.

[0101] Furthermore, taking the welding station scenario in an automobile manufacturing production line as an example, the working process of the passive switching mechanism is as follows:

[0102] In the welding station of an automobile manufacturing production line, the network environment is complex and intermittent electromagnetic interference exists. The master station is a Siemens S7-1500 PLC using the PROFINET protocol, and the slave station is the multi-protocol adaptive IO module described in this invention, used to control the welding torch.

[0103] Initially, the protocol sniffing module successfully identified the PROFINET protocol, the dynamic switching module had loaded the PROFINET protocol stack, and the control execution module normally received and executed the "start welding" command, indicating good communication. However, when a large motor on the production line started, it generated strong electromagnetic interference, causing CRC check errors in the PROFINET data frames.

[0104] The passive switching mechanism is as follows:

[0105] The error counter in the dynamic switching module is activated, and the passive switching condition is triggered after three consecutive CRC errors occur.

[0106] The dynamic switching module immediately sends a re-identification command to the protocol sniffing module.

[0107] The protocol sniffing module completes the capture and analysis of the current chaotic data frames within 15ms. The module extracts PROFINET features from some valid frames, including the frame ID, and outputs the protocol ID as PROFINET again.

[0108] The dynamic switching module determined that the protocol had not changed, performed a protocol stack reset, reloaded the PROFINET protocol parser, and cleared the communication buffer.

[0109] The control execution module resumed normal communication with the master station after 35ms, and received and executed the interrupted "welding" command.

[0110] In the above process, the total interruption time from the first communication error to the restoration of normal communication is less than 50ms, which avoids the disconnection or crash problems that occur when using traditional methods and improves the stability of the system.

[0111] Specifically, the method also includes an interactive verification mode, as follows:

[0112] When the protocol sniffing module detects a protocol conflict, it records the conflict time, conflict protocol ID, and original data frame as a protocol conflict log.

[0113] The protocol conflict log is output through the human-machine interface, and manual decision-making instructions input through the human-machine interface are received to determine the priority order of the protocols to be executed.

[0114] Specifically, the protocol conflict satisfies at least one of the following conditions:

[0115] The features of a single data frame can be successfully matched with the features of multiple different protocols in the protocol feature library.

[0116] Multiple data frames using different protocols have their parsed slave control commands pointing to the same logical address in the slave.

[0117] Specifically, when the extracted features of a single data frame match multiple key-value pairs in the protocol feature library, it is identified as a protocol conflict. The conflict log is then recorded and an alarm is issued through the human-machine interface, awaiting human decision-making instructions to determine the final protocol to be executed.

[0118] When protocols conflict, the above-mentioned logging and manual judgment avoid system failures that may result from blind execution, ensuring the final correctness of control logic and production safety, and demonstrating the intelligence of human-machine collaboration.

[0119] Furthermore, taking a multi-protocol command conflict scenario as an example, the process of handling protocol conflicts through dynamic switching conditions and interactive verification mode is as follows:

[0120] The flexible testing production line integrates devices from multiple suppliers using different protocols. Host computer A is an Omron PLC using the FINS protocol, while host computer B is a Beckhoff IPC using the EtherCAT protocol. Due to a network configuration error, host computer A and host computer B simultaneously send commands to the same slave station of this invention's multi-protocol adaptive light source control system.

[0121] Within a very short time, the protocol sniffing module captured FINS protocol data frames from host computer A and EtherCAT protocol data frames from host computer B. Upon parsing, both data frames pointed to the target logical address of "Channel 1 Brightness". The FINS instruction was "Brightness 100%", and the EtherCAT instruction was "Brightness 50%". Based on the conflict determination rule for multiple protocol instructions pointing to the same logical address, the protocol sniffing module immediately identified this as a protocol conflict.

[0122] The system records conflict events in a protocol conflict log, including timestamps, conflict protocol IDs, and original data frame hash values. Alarm information and conflict log summaries are output to the field engineer via the human-machine interface on the slave device, i.e., flashing LED indicators and a miniature display screen. The field engineer can then input manual decision-making instructions via physical buttons on the device: prioritize executing EtherCAT protocol instructions.

[0123] Upon receiving this instruction, the dynamic switching module immediately locks the protocol to EtherCAT and ignores subsequent FINS instructions for the same address for a period of time.

[0124] The control execution module correctly parses and executes the EtherCAT "brightness 50%" command, and the light source brightness is correctly adjusted.

[0125] The system sends a success response to host computer B, and simultaneously sends an error code "instruction conflict - execution refused" to host computer A.

[0126] In this embodiment, the method avoids hardware damage and prevents light source overload or flickering problems that may be caused by brightness command conflicts. Through a human-machine collaboration mechanism, final decision-making power is entrusted to professionals, ensuring production safety and logical correctness. Detailed conflict logs provide data support for subsequent network troubleshooting and optimization.

[0127] Figure 3 This is a data flow diagram of a multi-protocol adaptive slave control method disclosed in an embodiment of this application; this diagram is based on this method and Figure 1 The system setup described above.

[0128] In this embodiment, taking the slave station as an intelligent light source as an example, the steps are as follows:

[0129] The host computer sends data frames to the protocol sniffing module; the protocol sniffing module listens for and captures data frames from the industrial Ethernet port, analyzes the frame header and structural features, including EtherType, EtherCAT register address, etc., matches them with the built-in protocol feature library, i.e., hash table, and outputs the protocol ID as EtherCAT; the protocol ID is then sent to the dynamic switching module.

[0130] The dynamic switching module receives the protocol ID, determines the switching conditions, actively switches to the EtherCAT protocol stack, and outputs and notifies the control execution module: the current protocol has been switched to EtherCAT and is ready.

[0131] The control execution module requests a complete data frame from the protocol sniffing module, which then transmits the data frame to the control execution module. The control execution module uses the EtherCAT protocol stack to parse control commands, such as brightness and flash frequency.

[0132] The control execution module converts control commands into PWM hardware drive signals to control the slave station's light source hardware to perform actions such as brightness adjustment and flash frequency adjustment.

[0133] The control execution module collects the execution results and hardware status data of the slave station, and replies to the host computer with a response frame containing both data in EtherCAT format.

[0134] In this step, the protocol sniffing module, dynamic switching module, and control execution module are all based on the method and Figure 1 The system setup described above is used to implement each step of the multi-protocol adaptive slave control method described in any of the above-mentioned embodiments.

[0135] In this embodiment, through protocol identification and switching, the slave station can also access different industrial control protocols, such as PROFINET, ModbusTCP, EtherNet / IP, and Omron FINS, without requiring hardware replacement or manual reconfiguration. The "dynamic switching module" and "protocol stack loading" achieve hardware and protocol decoupling. Once protocol identification and switching are complete, subsequent communication fully adheres to the efficient mechanism of the EtherCAT protocol, without introducing additional latency or overhead, ensuring the real-time performance required for industrial control.

[0136] In addition, this embodiment also includes a multi-protocol adaptive slave control device, comprising:

[0137] A processing unit, wherein the processing unit is configured to implement each step of the multi-protocol adaptive slave control method described in any of the preceding claims;

[0138] A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-protocol adaptive slave control method described in any of the preceding claims.

[0139] Since the processing unit and readable storage medium are both built based on the method and used to implement the method, in practical applications, the additional latency and hardware cost problems caused by the protocol conversion gateway scheme can be effectively solved, and the compatibility of a single hardware platform with multiple protocols can be achieved. The defects of relying on manual configuration and slow switching speed in the multi-protocol stack redundancy scheme can be overcome, and millisecond-level, fully automatic protocol switching can be achieved. Finally, the slave device can be plug-and-play, which greatly reduces the integration complexity and maintenance cost of industrial automation system.

[0140] In addition, we conducted comparative tests on the proposed method and two existing mainstream solutions: protocol conversion gateway and multi-protocol stack redundancy + manual switching.

[0141] Test subjects: slave stations based on the method of this invention; Shanghai Sibo TEC-380 gateway, supporting EtherCAT and PROFINET conversion; traditional multi-protocol stack slave stations, with protocols manually selected via DIP switches.

[0142] Test network: Standard industrial Ethernet, including EtherCAT master, PROFINET controller, and Modbus TCP client.

[0143] Test protocols: EtherCAT, PROFINET, ModbusTCP.

[0144] Test methods and steps:

[0145] (1) Initialization: First, connect all devices under test to the test network. The initial protocol is EtherCAT.

[0146] (2) For the first switching test, the network main protocol was switched from EtherCAT to PROFINET. The switching time of the three schemes was recorded using a Keysight DSOV254A high-speed oscilloscope and a Keysight N5245B network analyzer. The operation steps of the manual scheme were also recorded.

[0147] (3) Second switching test: After stabilization, switch the main protocol from PROFINET to ModbusTCP again and repeat the measurement.

[0148] (4) Stability test: Simulate on-site interference for 8 consecutive hours, randomly trigger 200 protocol switching, and record the number of failures of each scheme, including communication interruption or response error.

[0149] (5) Resource monitoring: Throughout the process, the CPU load of the slave station of this invention is monitored, and the CPU adopts Bosch Rexroth VCP2050 processor.

[0150] Test results:

[0151]

[0152] The protocol switching time is the time from sending the first new protocol data frame to receiving the first correct response frame; the configuration operation steps are the number of manual operation steps required to complete a protocol switch; and the average CPU load is the processor utilization rate during the protocol identification and switching process.

[0153] From the above experiments, we can see that:

[0154] Regarding protocol switching speed, the present invention reduces the switching time from >30 seconds in the traditional manual solution and 300-500 milliseconds in the gateway solution to 85-180 milliseconds. This is because the present invention employs fast hash matching in the protocol sniffing module and hot loading of the protocol stack in the dynamic switching module, avoiding data conversion delays in the gateway and time consumption from manual operations.

[0155] In terms of configuration operation steps, the switching process of the present invention requires no manual intervention, achieving zero steps and eliminating the difficulties in system integration and maintenance costs caused by complex configuration and human operation errors, which is significantly better than the other two solutions.

[0156] In terms of resource consumption and stability, the average CPU load of this invention remains at a low level of <15% when handling dynamic switching, demonstrating the efficiency of its algorithm. The system's failure rate was 0.5% under a 48-hour stress test, verifying the high reliability and robustness of its passive switching mechanism in dealing with network anomalies.

[0157] While the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Those skilled in the art can make various modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A multi-protocol adaptive slave control method, characterized in that, The steps are as follows: S1: Capture the data frame sent by the host computer and execute a hierarchical parsing strategy to identify the protocol ID corresponding to the data frame; wherein, the hierarchical parsing strategy executes the following steps in sequence: Parse the protocol type field in the link layer header of the data frame; If the protocol type field matches a predefined link layer protocol feature value, the data frame is mapped to a protocol ID; If the protocol type field does not match the predefined link layer protocol feature value, the transport layer header of the data frame is parsed to obtain the target port number; if the target port number matches the predefined port number, the data frame is mapped to a protocol ID. If the target port number does not match the predefined port number, the structure and length characteristics of the application layer payload of the data frame are parsed; if the structure and length characteristics of the application layer payload match the predefined application layer payload characteristics, the data frame is mapped to a protocol ID. If the structure and length characteristics of the application layer load do not match the predefined application layer load characteristics, an indication message indicating protocol identification failure will be generated. S2: Based on the protocol ID, switch to the protocol stack associated with the protocol ID, load the protocol parser corresponding to the protocol stack, and trigger a protocol ready notification; S3: Use the protocol parser to parse the data frame to obtain slave control commands; S4: Execute the slave control command, collect the execution result and hardware status data to construct a response frame, and send the response frame to the host computer.

2. The multi-protocol adaptive slave control method according to claim 1, characterized in that, In the method, the industrial Ethernet protocols based on the link layer protocol feature value mapping protocol ID include EtherCAT protocol and PROFINET protocol; the industrial Ethernet protocols based on the target port number mapping protocol ID include ModbusTCP protocol and EtherNet / IP protocol. Protocols based on application layer load feature mapping protocol IDs, including the Omron FINS protocol.

3. The multi-protocol adaptive slave control method according to claim 1, characterized in that, The predefined link layer protocol feature values, target port numbers, and predefined application layer load features are stored in the protocol feature library.

4. The multi-protocol adaptive slave control method according to claim 3, characterized in that, The protocol feature database is stored using a hash table, where the key is the protocol feature value and the value is the corresponding protocol ID or protocol stack pointer.

5. The multi-protocol adaptive slave control method according to claim 1, characterized in that, The process of switching to the protocol stack associated with the protocol ID based on the protocol ID specifically includes: When a connection is established for the first time or a protocol switching instruction is received from the host computer, the slave station directly switches to the associated protocol stack based on the protocol ID according to the instruction content or pre-configuration. When a preset number of consecutive CRC check errors are detected or the response delay is greater than a preset delay threshold, the slave station sequentially traverses or selects preset candidate protocol IDs according to a strategy, and executes the step of switching to the protocol stack associated with the protocol ID, until communication is restored to normal or all candidate protocols have been tried.

6. The multi-protocol adaptive slave control method according to claim 1, characterized in that, The slave control commands are used to control at least one slave device, and the slave control commands include: switch control commands and parameter adjustment commands; wherein, the slave device includes: IO module, sensor, driver or light source controller.

7. The multi-protocol adaptive slave control method according to claim 1, characterized in that, The step of capturing data frames sent by the host computer and executing a hierarchical parsing strategy to identify the protocol ID corresponding to the data frame includes: when the protocol ID identification fails, sending an error response indicating that the protocol cannot be identified to the host computer and discarding the data frame.

8. The multi-protocol adaptive slave control method according to claim 1, characterized in that, The method also includes an interactive verification mode, specifically: When a protocol conflict is detected, a protocol conflict log is recorded and output to the human-machine interface; wherein, the protocol conflict log includes: conflict time, conflict protocol ID and each data frame corresponding to the protocol conflict; Receive human decision-making instructions input through the human-machine interface to determine the protocol ID to be executed.

9. The multi-protocol adaptive slave control method according to claim 8, characterized in that, The protocol conflicts include: the data frame features of a single data frame simultaneously match the features of multiple different protocols in the protocol feature library; and / or the slave control instructions obtained after parsing multiple data frames from different protocols point to the same logical address in the slave.

10. A multi-protocol adaptive slave control device, characterized in that, Include: A processing unit, wherein the processing unit is configured to implement each step of a multi-protocol adaptive slave control method as described in any one of claims 1 to 9; A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a multi-protocol adaptive slave control method as described in any one of claims 1 to 9.

Images