Lightweight EtherNet / IP protocol stack implementation method based on event-driven mechanism

Abstract

The technical scheme of the invention discloses a lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism, and the method is characterized in that all steps cooperate to construct a lightweight EtherNet / IP protocol stack which is high in reusability, low in delay and easy to transplant. According to the lightweight EtherNet / IP protocol stack based on the event-driven mechanism, on the basis of comparison with existing mainstream implementation (such as OpEner and RTA protocol stacks), through module reconstruction and mechanism innovation, actual performance improvement is achieved in the aspects of resource occupation, response delay, transplantation convenience and the like.

Description

Technical Field

[0001] This invention relates to a design and implementation method of a lightweight EtherNet / IP protocol stack suitable for open architecture industrial control systems. It belongs to the field of industrial communication and embedded network protocol stacks, and is particularly suitable for edge control devices and industrial embedded systems with high requirements for real-time IO communication. Background Technology

[0002] EtherNet / IP (Ethernet Industrial Protocol) is a communication protocol based on industrial Ethernet, developed by ODVA (Open DeviceNet Vendors Association). It uses the standard TCP / IP protocol as its communication foundation and defines application layer content through CIP (Common Industrial Protocol). It is widely used for data exchange between industrial automation devices. Currently, mainstream EtherNet / IP protocol stack implementations include OpENer, the RTA protocol stack, and the Rockwell CIP protocol module. OpENer, maintained open source by the EIPStackGroup, is large, resource-intensive, and tightly coupled between modules, primarily suitable for platforms with ample resources, but its porting and customization are complex. The RTA protocol stack is a commercial closed-source product; while functionally complete, it is closed and large, hindering lightweight deployment and customized development. The Rockwell CIP protocol module is embedded in specific controller firmware, its source code is unavailable, and it lacks open adaptability.

[0003] Meanwhile, Chinese invention patent application CN115665267A, published on January 31, 2023, entitled "A Method and Apparatus for Implementing a Lightweight Network Protocol Stack," proposes a method to optimize TCP / IP protocol stack resource usage through memory buffers and zero-copy mechanisms. While the aforementioned patent solution has some reference value in the lightweighting of general network protocol stacks, it does not involve the specific implementation of the EtherNet / IP protocol, nor does it optimize for the high real-time requirements of IO communication in industrial systems. Furthermore, it lacks an event-driven mechanism design, making it difficult to meet the requirements of response time and system decoupling in industrial control. Summary of the Invention

[0004] The technical problem this invention aims to solve is that the existing EtherNet / IP protocol stack suffers from high resource overhead, slow response, and strong platform dependence.

[0005] To address the aforementioned technical problems, the present invention discloses a lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism. The method is characterized by the synergistic action of the following steps to construct a lightweight, highly reusable, low-latency, and easily portable EtherNet / IP protocol stack:

[0006] Step 1: When the device starts up, the EtherNet / IP protocol stack loads modular components according to the user configuration file, including the CIP core module, session and connection management module, IO data processing module, event scheduler and platform abstraction layer module. During the initialization process, the callback interfaces of each module are registered and the event dispatch table is built.

[0007] Step 2: The EtherNet / IP protocol stack adopts an event-driven mechanism to replace the traditional blocking model. A lightweight event queue is built using a circular buffer. After the event scheduler starts, it enters a non-blocking main loop to listen for network reception events, upper-layer control events, and timer events in real time. The event scheduler calls the corresponding pre-registered module callback function to process the event according to the type of event it listens for, thereby achieving decoupling of asynchronous tasks.

[0008] Step 3: When the network reception event detected by the event scheduler triggers a new connection request, the connection management module is responsible for parsing the CIP connection parameters, establishing a connection context, and maintaining the communication state machine. Each connection is equipped with a timer to monitor the heartbeat and automatically release resources when the current connection fails.

[0009] Step 4: When the event scheduler detects a timer event, for the periodic IO data interaction scenario in industrial control, the protocol stack has an embedded periodic scheduler. The user sets the communication refresh cycle, and the system performs data acquisition and data update through the periodic scheduler when the communication refresh cycle is triggered. The IO processing module encapsulates the CIP I / O message and writes it to the network interface through the event scheduler. Real-time performance is guaranteed by timing accuracy and data path length.

[0010] Step 5: All platform-related calls are encapsulated in the platform abstraction layer, including memory management, timers, mutexes, and network interface calls. The interface design follows a unified specification, and all modules make transparent calls to the platform abstraction layer.

[0011] Preferably, step 2 specifically includes the following steps:

[0012] Step 201: After the EtherNet / IP protocol stack starts, initialize the event scheduler and event queue;

[0013] Step 202: After the event scheduler starts, it enters the non-blocking main loop and listens in real time for whether there are network reception events, upper-level control events or timer events in the event queue. If there are, it proceeds to the next step; otherwise, it continues to listen to the event queue.

[0014] Step 203: Determine the type of the monitored event, and call the corresponding pre-registered module callback function to process it based on the different event types, thereby achieving decoupling of asynchronous tasks.

[0015] Preferably, the states of the communication state machine include no connection, connection in progress, connected, and abnormal interruption.

[0016] Preferably, step 4 specifically includes the following steps:

[0017] Step 401: The user sets the communication refresh cycle. When the timer reaches the set cycle, the periodic timer generates a timed event and pushes it to the event scheduler for processing.

[0018] Step 402: After the event scheduler processes the timed event, it calls the IO data acquisition module to access the local IO image area or the underlying device interface to collect real-time data, and encapsulates the data processing event and writes it into the event queue, while updating the IO image buffer in the protocol stack.

[0019] Step 403: After the data processing event in the event queue is scheduled and triggered, the IO processing module encapsulates the collected data into a CIP I / O message and sends it to the upper PLC or control master station through the network interface module called by the event scheduler to realize periodic data updates.

[0020] This invention constructs a modular, lightweight protocol stack architecture on an embedded Linux platform and optimizes the communication response path through an event-driven mechanism to improve the real-time performance of I / O communication. Simultaneously, this invention achieves minimal coverage of protocol functions, balancing device compatibility and communication performance. Finally, this invention simplifies the connection management and periodic data exchange process with the main control PLC.

[0021] The lightweight EtherNet / IP protocol stack based on an event-driven mechanism proposed in this invention, compared with existing mainstream implementations (such as OpENer and RTA protocol stacks), achieves practical performance improvements in resource consumption, response latency, and portability through the aforementioned module reconstruction and mechanism innovation. Therefore, the technical solution disclosed in this invention has the following beneficial effects compared with existing technical solutions:

[0022] 1) Resource utilization optimization

[0023] In actual deployment tests, the overall code size of the protocol stack is less than 200KB, and the peak dynamic memory usage during operation is controlled within 300KB. Compared with OpENer, which requires more than 500KB of memory under typical configuration, the memory usage of this invention is reduced by more than 40%, making it especially suitable for embedded platforms with RAM limited to 512KB to 1MB.

[0024] 2) Significantly enhanced real-time performance

[0025] By replacing the traditional blocking / polling mode with an event-driven mechanism, the protocol stack exhibits a lower average response latency in actual industrial IO acquisition tests. In a 1GHz ARM Cortex-A7 environment, the average latency of periodic IO communication response is 0.7ms, while OpENer's average latency in the same environment is 2.3ms, representing a performance improvement of approximately 70%.

[0026] 3) Strong cross-platform portability

[0027] The underlying protocol stack dependencies are encapsulated in the Platform Abstraction Layer (HAL) module. In actual porting between Linux / x86 and Linux / ARM architectures, only three underlying adapter files need to be replaced, and the core code does not need to be modified. The porting cycle has been shortened from an average of two weeks to less than one person-day.

[0028] 4) The periodic data processing mechanism is more flexible.

[0029] It supports user-configurable refresh cycles (selectable from 1ms to 1000ms) and combines a built-in time scheduler to trigger IO data acquisition and processing, effectively adapting to various industrial cycle (10ms / 20ms / 50ms) scenarios and meeting the specific real-time requirements of different occasions.

[0030] 5) Compatibility and stability have been thoroughly verified.

[0031] The protocol stack has been tested in the Allen-Bradley CompactLogix physical PLC and simulation control environment, with a 100% connection establishment success rate and no packet loss during CIP periodic communication, indicating that it has the ability to stably adapt to mainstream industrial equipment. Attached Figure Description

[0032] Figure 1 This is a diagram of the overall architecture of the protocol stack.

[0033] Figure 2 The event scheduling flowchart includes timer triggering and network event response;

[0034] Figure 3 This is a diagram of a real-time data acquisition and response model for IO. Detailed Implementation

[0035] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined by the appended claims.

[0036] Combination Figure 1 The present invention discloses a lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism, which consists of the following five steps. The steps are closely connected and work together to achieve the goal of efficient, real-time and reusable communication.

[0037] Step 1: Protocol stack module initialization

[0038] During device startup, the protocol stack loads modular components based on the user configuration file, including: the CIP core module, session and connection management module, IO data processing module, event scheduler, and platform abstraction layer (HAL, Hardware Abstraction Layer). The initialization process also registers callback interfaces for each module and constructs an event dispatch table. This step requires known configuration files and basic operating system services (such as memory allocation and timers).

[0039] Step 2: Event Scheduler Configuration and Startup

[0040] The protocol stack adopts an event-driven mechanism instead of the traditional blocking model, using a circular buffer to construct a lightweight event queue. After the event scheduler starts, it enters a non-blocking main loop, monitoring three types of event sources in real time: first, network reception events (such as receiving CIP requests); second, upper-level control events (such as PLC state switching); and third, timer events (such as I / O refresh cycles). The event scheduler calls the pre-registered module callback function for processing according to the event type, achieving decoupling of asynchronous tasks.

[0041] Step 2 above is the core of the entire protocol stack and plays a decisive role in real-time performance.

[0042] Combination Figure 2 The event scheduling process implemented through the event scheduler specifically includes the following steps:

[0043] Step 201: After the protocol stack starts, initialize the event scheduler and event queue;

[0044] Step 202: After the event scheduler starts, it enters the non-blocking main loop and listens in real time for whether there are network reception events, upper-level control events or timer events in the event queue. If there are, it proceeds to the next step; otherwise, it continues to listen to the event queue.

[0045] Step 203: Determine the type of the monitored event, and call the corresponding pre-registered module callback function to process it based on the different event types, thereby achieving decoupling of asynchronous tasks.

[0046] Step 3: CIP Connection Management and State Machine Maintenance

[0047] When the network receive event detected by the event scheduler triggers a new connection request (Forward Open), the connection management module is responsible for parsing the CIP connection parameters, establishing the connection context, and maintaining the communication state machine (including states such as: no connection, connection in progress, connected, and abnormal interruption). Each connection is equipped with a timer to monitor the heartbeat (Idle Timeout), and resources are automatically released when the current connection fails.

[0048] Step 3 above ensures that the protocol stack can support multiple concurrent connections and accurately perform state transitions.

[0049] Step 4: IO Data Acquisition and Producer-Consumer Scheduling

[0050] When the event scheduler detects a timer event, a periodic scheduler is embedded in the protocol stack for periodic I / O data interaction scenarios in industrial control. Users can set the communication refresh period (e.g., 10ms, 20ms). The system executes data acquisition (Producer) and data updating (Consumer) triggered by the periodic scheduler during this refresh period. The I / O processing module encapsulates CIPI / O messages (e.g., Implicit Messaging) and writes them to the network interface via the event scheduler. Real-time performance is guaranteed by timing accuracy and data path length.

[0051] Combination Figure 3 The process of real-time IO data acquisition and response specifically includes the following steps:

[0052] Step 401: The user sets the communication refresh cycle. When the timer reaches the set cycle, the periodic timer generates a timed event and pushes it to the event scheduler for processing.

[0053] Step 402: After the event scheduler processes the timed event, it calls the IO data acquisition module to access the local IO image area or the underlying device interface to collect real-time data, and encapsulates the data processing event and writes it into the event queue, while updating the IO image buffer in the protocol stack.

[0054] Step 403: After the data processing event in the event queue is scheduled and triggered, the IO processing module encapsulates the collected data into CIPI / O messages (such as using Implicit Messaging format), and sends them to the upper PLC or control master station through the network interface module called by the event scheduler to realize periodic data updates.

[0055] Step 5: Cross-platform abstract interface call

[0056] To ensure the protocol stack can run on different platforms (such as ARM / x86, embedded Linux, etc.), all platform-related calls are encapsulated in the HAL (Hardware Access Layer), including memory management, timers, mutexes, network interface calls, etc. The interface design follows a unified specification, and all modules call the HAL transparently, achieving cross-platform portability with minimal modifications.

[0057] Step 5 above solves the problem of strong binding of existing protocol stack platforms.

[0058] Compared with the existing EtherNet / IP protocol stack, the innovation of the above technical solution lies in:

[0059] Replacing the traditional blocking and polling model with event-driven approaches reduces response latency and improves I / O real-time performance.

[0060] Separating CIP connection state management from scheduling logic results in a clearer structure and easier maintenance;

[0061] It supports customized IO refresh cycle control to adapt to different industrial acquisition and control cycle requirements. All modules are decoupled for easy customization and expansion.

[0062] The platform abstraction layer is fully encapsulated, supports mainstream embedded systems, and is easy to port.

[0063] The above steps work together to build a lightweight, highly reusable, low-latency, and easily portable EtherNet / IP protocol stack, suitable for open architecture industrial control systems with high real-time requirements for IO control.

Claims

1. A lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism, characterized in that, The following steps work together to build a lightweight, highly reusable, low-latency, and easily portable EtherNet / IP protocol stack: Step 1: When the device starts up, the EtherNet / IP protocol stack loads modular components according to the user configuration file, including the CIP core module, session and connection management module, IO data processing module, event scheduler and platform abstraction layer module. During the initialization process, the callback interfaces of each module are registered and the event dispatch table is built. Step 2: The EtherNet / IP protocol stack adopts an event-driven mechanism to replace the traditional blocking model. A lightweight event queue is built using a circular buffer. After the event scheduler starts, it enters a non-blocking main loop to listen for network reception events, upper-layer control events, and timer events in real time. The event scheduler calls the corresponding pre-registered module callback function to process the event according to the type of event it listens for, thereby achieving decoupling of asynchronous tasks. Step 3: When the network reception event detected by the event scheduler triggers a new connection request, the connection management module is responsible for parsing the CIP connection parameters, establishing a connection context, and maintaining the communication state machine. Each connection is equipped with a timer to monitor the heartbeat and automatically release resources when the current connection fails. Step 4: When the event scheduler detects a timer event, for the periodic IO data interaction scenario in industrial control, the protocol stack has an embedded periodic scheduler. The user sets the communication refresh cycle, and the system performs data acquisition and data update through the periodic scheduler when the communication refresh cycle is triggered. The IO processing module encapsulates the CIP I / O message and writes it to the network interface through the event scheduler. Real-time performance is guaranteed by timing accuracy and data path length. Step 5: All platform-related calls are encapsulated in the platform abstraction layer, including memory management, timers, mutexes, and network interface calls. The interface design follows a unified specification, and all modules make transparent calls to the platform abstraction layer.

2. The lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism as described in claim 1, characterized in that, Step 2 specifically includes the following steps: Step 201: After the EtherNet / IP protocol stack starts, initialize the event scheduler and event queue; Step 202: After the event scheduler starts, it enters the non-blocking main loop and listens in real time for whether there are network reception events, upper-level control events or timer events in the event queue. If there are, it proceeds to the next step; otherwise, it continues to listen to the event queue. Step 203: Determine the type of the monitored event, and call the corresponding pre-registered module callback function to process it based on the different event types, thereby achieving decoupling of asynchronous tasks.

3. The lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism as described in claim 1, characterized in that, The states of the communication state machine include no connection, connection in progress, connected, and abnormal interruption.

4. The lightweight EtherNet / IP protocol stack implementation method based on an event-driven mechanism as described in claim 1, characterized in that, Step 4 specifically includes the following steps: Step 401: The user sets the communication refresh cycle. When the timer reaches the set cycle, the periodic timer generates a timed event and pushes it to the event scheduler for processing. Step 402: After the event scheduler processes the timed event, it calls the IO data acquisition module to access the local IO image area or the underlying device interface to collect real-time data, and encapsulates the data processing event and writes it into the event queue, while updating the IO image buffer in the protocol stack. Step 403: After the data processing event in the event queue is scheduled and triggered, the IO processing module encapsulates the collected data into a CIP I / O message and sends it to the upper PLC or control master station through the network interface module called by the event scheduler to realize periodic data updates.

Images