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. INTRODUCTION

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

Controlled process Ind. PC Ind. PC

PLC PLC PLC Industrial

networks

S S SS AA

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. BRIF DESCRIPTION OF THE ETHERCAT PROTOCOL

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

Figure 2. A Master/Slave EtherCAT network segment

In order to farther improve the data transmission efficiency

the protocol allows data addressing at bit level. Logical

addresses are allocated to every slave node inside of a single

Ethernet frame. When a frame arrives to a slave, the node

will take the data addressed to it (control information to the

process) and in the same time it will put its own data (process

parameter values) on the frame. So, data is transferred

between the master and the slave nodes in a single frame.

In order to increase the reliability of the network the

"application" level of the EtherCAT protocol specifies a

number of states and transitions between them necessary to

switch one or more slave nodes from an inactive state into a

fully operational state. The network driver implemented in

the master node must follow these transitions and it must

detect automatically any defects in the system. Figure 3 shows these states and transitions.

Figure 3. State transitions in a slave node

The master node controls the transitions between states

through sets of predefined control frames, every set being

particular to a slave device. Each set contains the commands

that have to be fulfilled by the slave in order to be able to

make a desired transition. In figure 3 IP (Init to

Preoperational), PI (Preoperational to Init), PS, SP, etc. are

the transition names executed in the slave node as result to a

request from the master node.

The final goal of the project described in this paper was to

develop a driver for a Linux platform that implements the

EtherCAT standard's specification for a master node.

III. THE PROTOCOL DEVELOPMENT FRAMEWORK

A. The hardware platform

The hardware platform used in the development of the

master protocol driver was composed of the following

modules (figure 4):

1. an embedded industrial PC (AAEON PCM-6892) used

as master node

2. an EtherCAT evaluation board (Beckhoff EL9800)

used as slave node

Figure 4 shows the image of the experimental system

3. Ethernet UTP CAT 5e crossover interconnection

cables

4. power supply for the industrial PC

5. 24V power supply for the slave node

6. peripheral devices for storage and user interface

The EtherCAT evaluation board is a multifunctional device

that contains process specific input/output interfaces and a

network adapter based on the Ethernet physical layer. This

board can simulate the behavior of a slave node, both from

the network and from the process point of view. It can

generate digital inputs and display digital outputs according

to the master commands. The software driver for the

EtherCAT slave can be downloaded through a special port.

Through this board the developer can configure different

testing scenarios. This feature was very useful in the process

of protocol driver validation and performance measurement.

B. The software platform

In order to assure the fulfillment of time restrictions,

required in most control applications, a real-time operating

system was necessary. For compatibility purposes a Linux

platform with a real-time extension was considered the best

solution. The RTAI (Real-Time Application Interface) was

adopted, which is a Linux extension installed over the kernel;

it offers a wide set of real-time functions accessible for the

programmer through an API module.

As support for real-time communication the RTnet

protocol driver set was selected. RTnet, developed at the

Hanovra University, is compatible with the RTAI-Linux

platform and accepts many popular network chipsets. The

protocol driver implements the basic functionalities of

UDP/IP, ICMP and ARP protocols in a deterministic fashion.

RTnet offers POSIX socket API for the real-time user

processes or to the kernel modules. Ethernet frames can be

transmitted in real-time through the RTnet protocol [13],[14].