EtherCAT Protocol Implementation Issues on an Embedded Linux Platform
Sorin Potra
LVD-Napomar
Bd-ul Muncii, nr. 14, Cluj-Napoca,
România
Sorin.Potra@lvdnapomar.ro
Gheorghe Sebestyen Technical University of Cluj-Napoca G. Bariţiu, Nr. 26-28, Cluj-Napoca,
România Gheorghe.Sebestyen@cs.utcluj.ro
Abstract – The paper presents the most important
implementation issues of an industrial communication protocol, the EtherCat protocol, on an embedded Linux platform. The authors underscore critical aspects (e.g. reliability, timeliness, predictability) concerning the use of an Ethernet-like protocol in an industrial environment.
I.I NTRODUCTION
Today, the use of industrial communication networks is mandatory in most automation systems [8]. Industrial protocols are specially designed to fulfill the specific communication requirements of control applications, such as: real-time data delivery, high reliability and dependability, priority-based messaging, etc. [6][7].
An industrial network assures the communication environment between different automation devices, from the simplest ones, like intelligent sensors and actuators, until the more complex, process computers. Figure 1 shows a hierarchical automation system where industrial networks are the links between the system's components (sensors – S, actuators – A, Programmable Logic controllers – PLC, and industrial PCs).
The implementation of an industrial protocol involves a number of issues [6]:
-the protocol must be developed on systems (e.g.
intelligent sensors or actuators) with limited hardware
and software resources; such limitations are: small
memory capacity, limited processor speed, few or no
operating system support
-time restrictions and message delivery deadlines must be guaranteed
Figure 1. A network-based automation system
-the roundtrip time of a request-answer message pair is much smaller (usually microseconds) than in the case
of usual networks;
-the protocol drivers must have a highly predictable behavior; for instance, uncontrolled delays caused by
message queues are not allowed
-automatic fault recovery mechanisms must be included in the protocol drivers
The following chapters present the way in which these issues were solved during the implementation of an industrial protocol, namely the EtherCAT.
II.B RIF DESCRIPTION OF THE E THER CAT P ROTOCOL
In the last decade there were a number of attempts to adapt general-purpose computer protocols (e.g. Ethernet, TCP/IP) [4][5] for industrial purposes. EtherCAT (Ethernet Control Automation Technology) is a relatively new industrial protocol built on the Ethernet specifications; it incorporates some new features that make it adequate for control applications. This protocol solves the compatibility gap between an industrial protocol and a computer network protocol.
The EtherCAT combines the efficient and relatively high-speed message transmission (specific for Ethernet networks), with the predictability imposed by a master/slave medium access control policy. This access policy works in the following way: there is a single master node on a network segment that has the right to initiate data transfers; this node sends an Ethernet frame to the slave nodes; a slave node extracts the data from the frame addressed to it, puts some new data in the frame and than sends the frame to the next slave; the frame arrives back to the master node confirming the correctness of the transmission. All the message reception, data processing and frame retransmission operations are made "on the fly" by the slave nodes, without any extra delays. Special hardware components, embedded in the slave's Ethernet interface, are responsible for these operations. This solution assures a minimum roundtrip (reaction time), better than in the case of other industrial protocols (e.g. CAN, Profibus, etc.).
Figure 2 shows a typical EtherCAT segment, with one master node (a data acquisition, control and supervision device) and a number of slave nodes (intelligent sensors and actuators, PLCs, etc.).
1-4244-0361-8/06/$20.00 ©2006 IEEE