Abstract: This paper introduces the design concept of a process control system and its network application layer protocol using industrial Ethernet technology. The network architecture of the control system is divided into two layers; the hardware of the Ethernet nodes is based on an ARM7 core processor; the software is based on the uClinux embedded operating system; the network application layer protocol is self-defined and implemented in C language. After field operation and debugging, both the control system and the Ethernet nodes can operate stably, and the real-time performance and fault tolerance of the application layer protocol can be guaranteed.
Keywords: Industrial Ethernet, control system, network architecture, communication, application layer protocol
introduction
In recent years, with the development of information technologies such as computers, communications, and networks, the scope of information exchange has expanded to include factories, enterprises, and even markets worldwide. Therefore, it is necessary to establish a comprehensive automated network platform encompassing all levels, from industrial field equipment to control and management layers, and to build an enterprise information system based on industrial control network technology.
Ethernet is quietly entering the control field. Recently, Ethernet has taken center stage and is developing rapidly. It has become one of the most popular communication networks on the market, widely used in upper-level network communications such as management and control layers in industrial control, and is trending towards direct downward application in communication between industrial field devices.
Traditional Ethernet is built on IEEE 802.3 and TCP/IP. However, due to the specific nature of industrial applications, industrial Ethernet has high requirements for real-time performance, interference resistance, and environmental factors, which existing commercial Ethernet technologies cannot meet. This necessitates the development of an effective application layer protocol to meet the specific industrial environment. Internationally, there are already various industrial Ethernet application layer protocols, such as Ethernet/IP, Modbus-IDA, and Profinet. my country's standard EPA, supported by the National "863" Program, has been jointly developed by several authoritative departments.
While the aforementioned standard technologies are mature and backed by large companies, their technology is relatively complex, has a certain barrier to entry, and requires costly supporting equipment. This places high demands on practical application and maintenance, making them suitable for large-scale systems. However, some control systems do not require complex network architectures, are simple to apply, and require low costs. For these systems, a simple, efficient, and cost-effective solution can be designed. Below, we introduce the industrial Ethernet control system and its application layer protocol designed by the author.
1 Control System Architecture
1.1 Control System Network Architecture
The network architecture of the control system is shown in Figure 1. Control layer devices communicate with each other via Ethernet, while device layer devices communicate with each other via serial ports. The monitoring station can be a PC, and field devices can be valves, sensors, etc.
1.2 Hardware Structure of Ethernet Nodes
Ethernet nodes enable field devices to communicate with the monitoring station, and they can parse application layer protocols. Their hardware structure is shown in Figure 2. The CPU is a Samsung S3C44B0X processor based on the ARM7TDMI core, and the RTL8019AS handles Ethernet communication functions.
1.3 Software Structure of Ethernet Nodes
The software architecture of an Ethernet node is shown in Figure 3. The lowest-level bootloader is a program written in a mix of assembly and C, which completes the system initialization and hands over system control to the operating system. uClinux is an embedded operating system that is compact and inherits the excellent features of the Linux system. Because it has built-in network functionality, applications can easily be developed on this basis to create network applications.
2. Design of Application Layer Protocols
2.1 Overview
This protocol is an application layer protocol for industrial Ethernet control systems, based on the TCP/IP protocol. Industrial Ethernet nodes act as parsers for this protocol. Field devices can connect to Ethernet nodes to enable network communication. When field devices, nodes, and the upper-level monitoring system communicate, the information frame format must conform to the requirements of the application layer protocol.
2.2 Basic Concepts
2.2.1 Class
A control system may contain more than one type of device, which requires them to be categorized so that the monitoring system can easily identify and control them, and so that the various field devices can communicate with each other.
In this protocol, class IDs are used to identify various field devices, and their range is 1 to 254.
2.2.2 Object
In a control system, there may be more than one device of a certain type. We use objects to define each instance of a device class. The range is 1 to 254.
Note: The system defaults to class ID and object ID of the upper-level main monitoring station as (0, 0). The system broadcasts class ID and object ID as (255, 255).
2.2.3 Associated Nodes
We can configure one associated node for an Ethernet node, with a maximum of ten. An associated node can be understood as a node that can work collaboratively with the current Ethernet node. When the current Ethernet node exhibits a certain behavior, such as a malfunction, it can promptly notify the associated nodes to take appropriate measures, thereby ensuring better system performance.
2.2.4 Parameter Settings
Ethernet nodes are the carriers of class IDs and object IDs in this protocol. Each node must have its parameters configured before use, including its class ID, object ID, and associated nodes. This is done by configuration software on a PC. The PC and the node are connected via a serial port, and the configuration software on the PC configures the node according to the corresponding protocol.
2.2.5 Handshake
Before initiating communication, the device first confirms that the connection is normal; this process is called a handshake. In this system, the handshake is performed in two phases.
First, the host computer is in a waiting state. After the Ethernet node powers on and a random time has elapsed, it actively sends a handshake signal to the host computer. Upon receiving the handshake signal, the host computer immediately replies. During the handshake, the node needs to send its class ID, object ID, and IP address to the monitoring station. The monitoring station stores the node's information in its database for future reference.
After the node successfully hands over with the monitoring station, it then hands over with the field equipment via serial port.
Only after both phases of the handshake are successful can the node proceed to the next phase of operation.
2.2.6 Information Frame Format
The information frames in this protocol are mainly divided into two types: data frames and command frames.
Data frames contain general I/O information, while command frames contain commands such as control, query, and settings.
In this protocol, the information frame formats of the control layer and the device layer differ slightly. Control layer information frames are transmitted between nodes and monitoring stations, and these can be converted into device layer information frames by the nodes. Device layer information frames are transmitted between nodes and field devices; these are raw information that the field devices can understand, and can be encapsulated into control layer information frames by the nodes. The differences between the two layers will be discussed in the next section.
2.3 Protocol Details
2.3.1 Data Frame
7E is the frame header; if the frame is a device layer information frame, it does not contain the class ID and object ID; the length is the length of the data contained; the checksum is the XOR result of all bytes except the checksum byte.
2.3.2 Command Frame
7F is the frame header; if the frame is a device layer information frame, it does not contain the class ID and object ID; the length is the length of the contained commands; the checksum is the XOR result of all bytes except the checksum byte.
2.3.3 Parameter Setting Information Frame
Each Ethernet node must be configured with parameters before it can be put into operation, and this process is carried out according to a specific protocol.
When setting parameters, the node is connected to the PC, and configuration software is used to configure the node. Before communication, they must first perform a handshake, and then transmit configuration information. The specific protocol is as follows:
PC Node: Handshake command, command 00.
Node à PC: Generally responds to commands, command B0.
PC à Node: Configuration commands, command 01.
Node à PC: Generally responds to commands, such as command B1.
2.3.4 Handshake Protocol for Communication in Control Systems
Each Ethernet node in the control system must handshake with the monitoring station after power-on to ensure a normal connection before protocol conversion and other communication operations can proceed. After a successful handshake with the monitoring station, it then handshakes with the field devices; normal communication only occurs after both handshakes are successful. If a device-level fault occurs, the Ethernet node sends an error report to the main monitoring station.
The specific contents of the agreement are as follows:
Node → Monitoring Station: Handshake information, send parameters, command 02.
Monitoring station → Node: Reply command, command B2.
Node → Field Equipment: Handshake Information, Command 03.
Field equipment → Node: Reply command, command B3.
2.3.5 Error Alarm Mechanism
When a fault occurs in the field equipment or connection line, the node will send an error report to the monitoring station.
Node → Monitoring Station or Associated Node: Error Reporting Command, Command E0.
Field devices can also proactively send error reports to nodes, which in turn send them to the monitoring station.
Field device → Ethernet node: A field device or connection line malfunctions, command E0.
2.3.6 Equipment Layer Reliability Assurance Mechanism
Information at the device layer is transmitted via serial port. After sending information, both devices at either end of the serial port wait for a response frame from the other. Communication is considered successful only upon receiving a response frame. If no response frame is received after a period of time, the sender must resend the information. When a node detects that there is still no response after multiple retransmissions, it will report an error to the monitoring station.
Field device → Ethernet node: Device layer response frame, command B4.
3. Summary
After a period of on-site operation and debugging, the system has proven to be stable. Even under heavy communication loads, the system operates reliably. When communication is interrupted due to data loss, the system can quickly resume operation. This demonstrates that the industrial Ethernet architecture and the hardware and software structure of the Ethernet nodes are reasonable and effective. Furthermore, the system's application layer protocol also exhibits stable and efficient performance; it is not only simple and practical but also easy to implement and highly scalable. The application of Ethernet in my country is still in its early stages, and it is believed that the solution proposed in this paper can be used as a reference by peers.
References
[1] IEEE Standard 802.3 Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications 2002.
[2] Liu Zhengrong, Zhang Zhichao, Xu Zhenshan, et al. Detailed Explanation of Embedded Linux Application Development [M]. Beijing: Machinery Industry Press, 2004.
[3] Li Juguang, Zhang Hua. Design of intelligent nodes for industrial Ethernet control systems based on ARM. Electronic Technology, 2003, (7): 17-18
[4] Feng Dongqin, Jin Jianxiang, Zhu Jian. Ethernet and TCP/IP. Automation Instrumentation, 2003, (5): 67-70
