1. EtherCAT Protocol Implementation Issues on an Embedded Linux Platform
Sorin Potra
LVD-Napomar
Bd-ul Muncii, nr. 14, Cluj-Napoca,
România
Gheorghe Sebestyen
Technical University of Cluj-Napoca
G. Bariţiu, Nr , Cluj-Napoca,
România

2. Project goal
To develop a driver for a Linux platform that implements the EtherCAT standard's specification for a 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.

3. Industrial protocols – design issues
Must offer:
Real-time data delivery
High reliability and dependability
Priority based messaging
Implementation issues:
Developed on platforms with limited hardware and software resource
Requires guaranties for message delivery deadlines
Driver’s features:
Must have a highly predictable behavior
Must contain automatic fault recovery mechanisms
Today, the use of industrial communication networks is mandatory in most automation systems. 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.
The implementation of an industrial protocol involves a number of issues like:
- 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
- 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

4. EtherCAT - Ethernet Control Automation Technology
Industrial protocol
Open specification
Features:
High speed message transmission
Deterministic master/slave medium access control policy
‘on the fly’ slave operations execution
Bit level data addressing on slave devices
In the last decade there were a number of attempts to adapt general-purpose computer protocols (e.g. Ethernet, TCP/IP) 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.
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.
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.
Bit level addressing on slave devices further increases the transmission efficiency by allowing data to be transferred between the master and the slave nodes in a single frame.

5. Development Framework
Hardware 5. 3. 4. 1.
The hardware platform used in the development of the master protocol driver was composed of the following modules:
embedded industrial PC (AAEON PCM-6892) used as master node
an EtherCAT evaluation board (Beckhoff EL9800) used as slave node
Ethernet UTP CAT 5e crossover interconnection cables
power supply for the industrial PC
24V power supply for the slave node
peripheral devices for storage and user interface
In order to assure the fulfillment of time restrictions, required in most control applications, a real-time operating system was necessary. The RTAI (Real-Time Application Interface) was adopted, which is a Linux extension installed over the kernel.
RTnet is a real-time Ethernet driver which offers support for a wide range of network chipsets. Using the RTnet protocol, Ethernet frames can be exchanged in real-time.
Software
Linux with RTAI extension
RTnet real-time Ethernet driver 2. 6.

6. Implementation problems: Master driver - functionalities
Initialize and configure the slave nodes
Control of network traffic in a deterministic and predictive manner
Buffer and refresh the input and output process data
Present a set of services to a higher level control application that allow:
Changing a slave’s state
Reading a slave’s state
Start/Stop the refresh of the process data
Write outputs
Read inputs
In the case of EtherCAT protocol most of the higher-level functionalities concerning network initialization, configuration and traffic control are implemented in the master module. This module keeps an image of the input and output data which is transferred through the slave nodes to and from the controlled process.
Through periodical frames sent to the slave devices, the master node builds the actual image of the controlled process and passes the command information to the process. A higher-level control application can access input and output process data through a set of functions offered by the master node driver. The application can also send commands to put slaves in different states, and receives the actual state of the slave as response.
The master driver translates a generic command in a sequence of specific control frames transmitted to the slave nodes. The state transitions will be made in accordance with the state automaton of the slave, specified in the EtherCAT protocol.

7. Master driver - Structure
Advantages of multi-module driver approach:
Offers a scalable and
flexible solution
Allows the decomposition
of network functionality
Suits EtherCAT standard
Reduces complexity
Control Application
Communication interface
Application level module
EtherCAT module
RT Network module D R I V E
Ethernet network
The master driver must be integrated in the kernel part of the Linux operating system, so that any application could access the communication functionalities of the driver. The adopted solution was to build it as a set of cooperating KLM modules instead of a monolithic single module because it offers a number of advantages:
it is a scalable and more flexible solution
It allows the decomposition of network functionalities in hierarchical levels
the inherent complexity of the driver is reduced through division
the EtherCAT protocol suggests the implementation of the driver on two levels: a data-link level and an application level
The figure shows the main components of the EtherCAT master driver:
The RT Network module is responsible for sending and receiving Ethernet frames under real-time restrictions. It offers basic network communication functions to the upper level.
The EtherCAT module offers EtherCAT telegrams' sending and receiving services. It is responsible to format and pack higer level transmission requests in different types of EtherCAT telegrams.
The Application level module offers high-level services for the user applications.
The Control application module is any user application that requires communication services from the EtherCAT network. This module implements the supervision and control functionalities of the automation system.

8. Master driver – Implementation
Implemented as a “real time task”
Free of uncontrolled delays
Real time task
While true
The driver was implemented as a real-time task, activated periodically at well defined time intervals. Its main internal operations are the following:
Receive and handle the incoming telegrams which arrive as responses to the commands sent during the previous cycles.
Test the pending responses in order to avoid waiting forever after a lost telegram. If the wait time for a response has expired, the retransmission procedure for the corresponding request can commence.
The master state machine is responsible with updating the state of the controlled slave devices by sending the configuration telegrams according to the desired state transition.
The cyclic telegrams are sent in order to refresh the process image stored inside the master buffer.
The driver’s routines are free of any uncontrolled delays that can interfere with it’s real time behavior.
Receive telegrams
Wait for new cycle
Test pending responses
Do master state machine
Send cyclic telegrams

9. Master driver – Test Application
In order to test the functional correctness of the master driver, a test application was developed. This application allows access to all driver functions through a flexible user interface. The application has two parts: one that runs in the user space and a LKM that runs in the kernel space. The process running in user space implements the user interface through which high level test commands can be generated and their results visualized. The process running in kernel space transforms the high level requests into service requests sent to the application module of the driver. A special communication mechanism was used to transfer information between the user mode and kernel mode processes. The solution was a shared memory zone between the two processes.
The synchronization of accesses to the shared memory was done using a communication protocol. The functioning of the protocol is based on the flags that protect the data zones that have to be read/written through an atomic operation.

10. Experimental results
Performance parameter = process data transmission time
Maximum delay of process image update is equal to the periodicity of the real time task associated to the master driver
Process data transmission time (period):
Must be as low as possible
Sufficiently high to allow the transmission of all commands in a time frame
Depends on the size of the process image
Test scenario:
Single slave with process image of 32 digital signals
Measured transmission time of IO image: 200us
The most important performance parameter of an industrial network is the process data transmission time.
According to the measurements, the maximum delay in updating the process image is the activation period of the task associated to the master driver. The minimum of this period must cover the time needed to transmit the all the EtherCAT frames containing the commands in the current state. The period of the driver’s task depends on the size of the process image supervised by the system.
In a scenario with a single slave that controls 32 digital signals the optimal activation period was established to 200μs.

11. Conclusions
The developed master driver
Conforms to the EtherCAT standard
Can control complex systems with a variable number of slave nodes
Highly time-efficient implementation
As experiments and validation tests showed the master driver developed during the present project is in accordance with the EtherCAT specifications. The master driver can control complex systems with a variable number of slave nodes. In the same time the performance measurements demonstrated that the implementation is highly efficient, achieving very short response times.
The image presents the time delay magnitude between EtherCAT and CAN reaction time in equivalent networks.