The Basic Principle

The basic principle of the synchronization according to IEEE 1588 consists in recording the
sending time and the receipt time of special packets between local (real time) clocks and in
the transmission of these values in special time stamped datagrams. According to this time
recording, the deviation of the clocks and the transmission delay in the network can be
calculated. By the use of local clocks each node in the network disposes the precise entire
system time. This provides the independence of the execution time accuracy of synchronized
control commands from possible deviations in the network communication. This makes this
technique interesting especially for the use in Ethernet based Systems, since this allows
Ethernet TCP/IP - without basic changes - to be used for the networking within highly precise
control systems. The achievable accuracy exceeds those from state of the art fieldbus based
systems.

System Components

A 1588 respectively PTP system consists of several nodes, all representing a clock. The
clocks are connected with each other via a network. On principle there are two kinds of
clocks: ordinary clocks and boundary clocks. The difference between them is that an ordinary
clock has a Single PTP port and a boundary clock has more than a single PTP port. From
the network view a clock can have either one of the general status: slave clock, master clock
or grand master clock.

A simple system consists of slave clocks and one master clock. If there are several potential
master clocks the active master clock will be determined according to a best master clock
algorithm. All slave clocks permanently compare their own clock characterizations with that
of the current master clock, if there are e.g. new clocks added to the System or the current
master clock is suddenly disconnected, then the other clocks realize this and a new master
will determine itself.

If several PTP subsystems need to be connected with each other, the connection should
exclusively be realized by a boundary clock. Exactly one port of the boundary clock works as
a slave port, this port is connected to the subsystem that provides the time for the whole
system. Therefore the master clock of this subsystem is the grand master clock for the whole
System. The other ports of the boundary clock work as master ports, since over these ports
of the boundary clock the messages for the synchronization of the connected subsystems
will be sent. The port of a boundary clock appears to the connected subsystem as if it would
be an ordinary clock.
Figure 46: IEEE 1588 System

Specified Time Messages

Besides management messages, the PTP protocol defines four types of messages that are
sent per multicast: a synchronization message briefly named Sync, a message followed at
Sync, briefly named Follow_Up, a delay request message, briefly named Delay_Req, and a
reply to the Delay_Req, briefly named Delay_Resp. The reaction of a clock on the receipt of
such a message depends on the current state of that clock.

Figure 47: IEEE 1588 Time Messages

The Sync message will be sent periodically (typically every 2 seconds) from the clock that is
in the master clock state. It also contains the clock characteristics of the sender that are
needed for the best master algorithm. First of all, the Sync message contains a timestamp,
which as precise as possible - specifies the estimated sending time of that packet. Since
the estimated sending time has to be integrated into the packet before it is really sent, the
real sending time can differ from the estimated. Because of that, the precise sending time of
a Sync message is measured and sent in a following Follow_Up message. The receiver of a
Sync message records its precise receipt time. Using the precise sending time contained in
the Follow_Up message and the precise receipt time, the deviation of the slave clock from
the master clock can be calculated and the slave's time can be corrected accordingly.
However, the determined deviation still includes the transmission delay of the network. For
determining this transmission delay the Delay_Req message is used.

A Delay_Req will be sent from a slave clock after the receipt of a Sync message. Equivalent
to a Sync message the sender records the precise sending time and the master clock as the
recipient records the precise receipt time. The precise receipt time is sent within a
Delay_Resp message to the sender of the belonging Delay_Req, where the according
transmission delay can be calculated and considered for the next calculation of the clock
deviation.

Implementation Aspects
The precision of the synchronization - the synchronization jitter - strongly depends on the
kind of realization of the time stamp implementation and the detection of the time messages.

The IEEE 1588 standard, strictly spoken the generation of the corresponding time stamp,
can be implemented on different levels of the ISO/OSI-7-layer model. This results in varying
accuracies of the clocks' synchronization. The realization of layers 1 and 2 of the ISO/OSI
model happens in hardware. Correspondingly, the delays generated here are subject to only
rather small variations which make an implementation of the time stamp optimal here, but
due to the hardware engagement also most complex. The variations emerging here are in
the first instance dependent of the mode of operation of the network's active infrastructure
components. Layer 3 is the first layer realized in Software and normally is part of the
operating System; correspondingly, between layer 2 and 3 mostly the transition from
hardware to software takes place. The possibility to realize a time stamp in software, but as
close as possible to the hardware is given here. An implementation in layers 4 to 6 obviously
would cause the same efforts, but would be of smaller value and, thus, will not be looked at
further considered. An implementation on the application layer is possible without any
interaction with the operating System - and thus the easiest way of an IEEE 1588
implementation; admittedly, by the (Software) technical processing within the underlying
layers and during the transition between the single layers relatively strong variations
regarding the total delay are given.

The standard recommends to implement the time stamp as near as possible to the physical
layer to avoid varying delays within the communication Stack. Implementations of the time
stamp on the application layer result in accuracies of 100 s to 10 ms. The exact range
depends on the respective operating system.

Implementations of the time stamp on the network layer result in typical variations in the 10s
area. An accuracy within the nanosecond range can be reached by means of a time stamp
implementation in hardware directly above the physical layer. Here, variations can be
additionally reduced by a reasonable design of the clocks' algorithm for time adjustment.

Conclusion

In this chapter the real time capability of Ethernet is discussed. For that, starting with general
considerations for real time requirements for timeliness and synchronization the opportunities
of Ethernet were considered. Timeliness requirements can be achieved by the use of
standard Ethernet technologies. To fulfil synchronization requirements special extensions
that meet the demands in the automation world are necessary. There are two approaches:
On the one hand to make the communication via Ethernet deterministic, according to
methods that are used in fieldbus systems, on the other hand to provide a decoupling of the
applications execution time pattern from the communication time pattern. A standard, for the
later approach was introduced more in detail. The fluctuations in the duration of data
transmission that are inherent to Ethernet technology can be tolerated by this for the solution
of highly synchronised automation tasks, since they do not effect the precision of the
execution of control operations.

Figure 50: Synchronization methods over Ethernet

3. Selected Ethernet Industrial Protocols

3.1 EtherCAT

Introduction: Ethernet and real-time capability

There are many different approaches that try and provide real-time capability for Ethernet: for
example, the CSMA/CD media access procedure is disabled via higher level protocol layers
and replaced by the time slice procedure or polling; other propositions use special switches
that distribute Ethernet packets in a precisely controlled timely manner. Whilst these
solutions may be able to transport data packets more or less quickly and accurately to the
connected Ethernet nodes, the times required for the redirection to the outputs or drive
controllers and for reading the input data strongly depends on the implementation.

If individual Ethernet frames are used for each device, the usable data rate is very low in
principle: The shortest Ethernet frame is 84 bytes long (incl. inter-packet gap IPG). If, for
example, a drive cyclically sends 4 bytes of actual value and status information and
accordingly receives 4 bytes of command value and control word information, at 100 % bus
load (i.e. with infinitely short response time of the drive) a usable data rate of only 4/84 = 4.7
% is achieved. At an average response time of 10 s, the rate drops to 1.9 %. These
limitations apply to all real-time Ethernet approaches that send an Ethernet frame to each
device (or expect a frame from each device), irrespective of the protocols used within the
Ethernet frame.

EtherCAT operating principle

EtherCAT technology overcomes these inherent limitations of other Ethernet Solutions: the
Ethernet packet is no longer received, then interpreted and process data then copied at
every device. The EtherCAT slave devices read the data addressed to them while the frame
passes through the node. Similarly, input data is inserted while the telegram passes through.
The frames are only delayed by a few nanoseconds.

Figure 69: Process data is inserted in telegrams

Figure 70: EtherCAT: Standard Frames according to IEEE 802.3

Since an Ethernet frame comprises the data of many devices both in send and receive
direction, the usable data rate increases to over 90 %. The full-duplex features of
100BaseTX are fully utilized, so that effective data rates of > 100 Mbps (> 90 % of 2 x 100
Mbps) can be achieved. The Ethernet protocol according to IEEE 802.3 remains intact right
up to the individual terminals; no sub-bus is required.

EtherCAT features

Protocol

The EtherCAT protocol is optimized for process data and is transported directly within the
Ethernet frame thanks to a special Ethertype. It may consist of several sub-telegrams, each
serving a particular memory area of the logical process images that can be up to 4 gigabytes
in size. The data sequence is independent of the physical order of the Ethernet terminals in
the network; addressing can be in any order. Broadcast, multicast and communication
between slaves are possible. Direct Ethernet frame transfer is used in cases where
maximum performance is required and the EtherCAT components are operated in the same
subnet as the controller.

However, EtherCAT applications are not limited to a subnet: EtherCAT UDP packages the
EtherCAT protocol into UDP/IP datagrams. This enables any control with Ethernet protocol
stack to address EtherCAT systems. Even communication across routers into other subnets
is possible. In this variant, system performance obviously depends on the real-time
characteristics of the control and its Ethernet protocol implementation. The response times of
the EtherCAT network itself are hardly restricted at all: the UDP datagram only has to be
unpacked in the first station.
EtherCAT only uses standard frames - the frames are not shortened. EtherCAT frames can
thus be sent from any Ethernet Controller (master), and standard tools (e.g. monitor) can be
used.

Topology

Line, tree or Star: EtherCAT supports almost any topology. The bus or line structure known
from the fieldbusses thus also becomes available for Ethernet.

Particularly useful for system wiring is the combination of line and branches or stubs.
Therefore, the required interfaces exist on the devices (2 at each) and, thereby, no additional
switches are required. Naturally, the classic switch-based Ethernet star topology can also be
used.

Wiring flexibility is further maximized through the choice of different cables. The application
of EtherCAT is independent of the used communication media whether it is standard copper
Ethernet patch cables or plastic optical fibres (POF) or any other standard conform cabling
system.

The Fast Ethernet physics (100BASE-TX) enables a cable length of 100 m between two
devices. For each connection, the signal variant can be selected individually. Since up to
65535 devices can be connected, the size of the network is almost unlimited.

Since EtherCAT devices will convert the Ethernet communication internally to the E-Bus and
the E-Bus is able to cover a distance of about 10 m it is possible to distribute the devices of
an EtherCAT system within this distance.

Figure 71: Flexible Topology: Line, Tree or Star

Distributed clocks

Accurate synchronization is particularly important in cases where spatially distributed

processes require simultaneous actions. This may be the case, for example, in applications
where several servo axes carry out coordinated movements simultaneously.

The most powerful approach for synchronization is, as mentioned in one of the previous
chapters, the accurate alignment of distributed clocks, as described in the IEEE 1588
standard. In contrast to fully synchronous communication, where synchronization quality
suffers immediately in the event of a communication fault, distributed aligned clocks have a
high degree of tolerance vis-a-vis possible fault-related delays within the communication
system.

With EtherCAT, the data exchange is fully based on a pure hardware machine. Since the
communication utilizes a logical (and thanks to full-duplex Fast Ethernet also physical) ring
structure, the master clock can determine the propagation delay offset to the individual slave
clocks simply and accurately - and vice versa. The distributed clocks are adjusted based on
this value, which means that a very precise network-wide time base with a jitter of
significantly less than 1 microsecond is available. External synchronization, e.g. across the
plant, is then based on IEEE 1588.

Figure 72: Synchronicity and Simultaneousness: Scope view of two distributed devices with
300 nodes and 120 m of cable between them

However, high-resolution distributed clocks are not only used for synchronization, but can
also provide accurate information about the local timing of the data acquisition. For example,
motion controllers typically calculate velocities from sequentially measured positions.
Particularly with very short sampling times, even a small temporal jitter in the position
measurement leads to large step changes in the computed velocity. With EtherCAT,
timestamp data types are introduced as a logical extension. The high-resolution system time
is linked to the measured value, which is made possible by the large bandwidth offered by
Ethernet. The accuracy of a velocity calculation then no longer depends on the jitter of the
communication system. It is orders of magnitude better than that of measuring techniques
based on jitter-free communication.
Performance

Thanks to hardware Integration in the slave and direct memory access to the network card in
the master, the complete protocol processing takes place within hardware and is thus fully
independent of the run-time of protocol stacks, CPU performance or software
implementation. The update time for 1000 I/Os is only 30 s - including I/O cycle time. Up to
1486 bytes of process data can be exchanged with a Single Ethernet frame - this is
equivalent to almost 12000 digital inputs and Outputs. The transfer of this data quantity only
takes 300 s.

The communication with 100 servo axes only takes 100 s. During this time, all axes are
provided with command values and control data and report their actual position and status.
The distributed clock technique enables the axes to be synchronized with a deviation of
significantly less than 1 microsecond. The extremely high performance of the EtherCAT
technology enables control concepts that could not be realized with classic fieldbus systems.
With EtherCAT, a communication technology is available that matches the superior
computing capacity of modern Industrial PCs. The bus system is no longer the bottleneck of
the control concept. Distributed I/Os are recorded faster than is possible with most local I/O
interfaces. The EtherCAT technology principle is scalable and not bound to the baud rate of
100 MBaud - extension to GBit Ethernet is possible.

Figure 73: EtherCAT Performance Overview

Diagnosis

Since EtherCAT uses standard Ethernet frames according to IEEE 802.3, any commercially
available Ethernet monitoring tool can be used for monitoring EtherCAT communication. In
addition, free parser Software for Ethereal (an open source monitoring tool) and the Microsoft
network monitor are available for processing and displaying recorded EtherCAT data traffic.

During commissioning, the actual configuration of the nodes (e.g. drives or I/O terminals) can
be checked for consistency with the specified configuration. The topology should also match
the configuration. Due to the built-in topology recognition down to the individual terminals,
this verification can not only take place during system start-up, automatic reading in of the
network is also possible (configuration upload).

Bit faults during the transfer are reliably detected through evaluation of the CRC checksum:
The 32 bit CRC polynomial has a minimum hamming distance of 4. Apart from broken wire
detection and localization, the protocol, physical layer and topology of the EtherCAT system
enable individual quality monitoring of each individual transmission segment. The automatic
evaluation of the associated error counters enables precise localization of critical network
sections. Gradual or changing sources of error such as EMI influences, defective connectors
or cable damage are detected and located, even if they do not yet overstrain the self-healing
capacity of the network.

Device profiles

The device profiles describe the application parameters and the functional behavior of the
devices including the device class-specific state machines. For many device classes,
fieldbus technology already offers reliable device profiles for example for I/O devices, drives
or valves. Users are familiar with these profiles and the associated Parameters and tools. No
EtherCAT-specific device profiles have therefore been developed for these device classes.
Instead, simple interfaces for existing device profiles are being offered.

CANopen device and application profiles are available for a wide range of device classes
and applications, ranging from I/O components, drives, encoders, proportional valves and
hydraulic controllers to application profiles for plastic processing or textile machines. For
example EtherCAT can provide the same communication mechanisms as the familiar
CANopen mechanisms: object dictionary, PDC (process data objects) and SDO (Service
data objects) - even the network management is comparable. EtherCAT can thus be
implemented with minimum effort on devices equipped with CANopen. Large parts of the
CANopen firmware can be reused. Objects can optionally be expanded in order to account
for the large bandwidth offered by EtherCAT.

SERCOS interface is acknowledged and appreciated worldwide as a high-performance

real-time communication interface, particularly for motion control applications. The SERCOS
profile for servo drives and the communication technology are covered by the IEC 614911
standard. This servo drive profile can very easily be mapped to EtherCAT. The service
channel, and therefore access to all parameters and functions residing in the drive, is based
on the EtherCAT mailbox. Here too, the focus is on compatibility with the existing protocol
(access to value, attribute, name, units etc. of the IDNs) and expandability with regard to
data length limitation. The process data, with SERCOS in the form of AT and MDT data, are
transferred using EtherCAT slave controller mechanisms. The mapping is similar to the
SERCOS mapping. The EtherCAT slave state machine can also be mapped easily to the
phases of the SERCOS protocol. Real-time Ethernet technology is therefore already
available for this device profile, which is particularly widespread in CNC applications. The
benefits of the device profile are combined with the benefits offered by EtherCAT.

Ethernet over EtherCAT

The EtherCAT technology is not only fully Ethernet-compatible, but also characterized by
particular openness "by design": the protocol tolerates other Ethernet-based services and
protocols on the same physical network - usually even with minimum loss of Performance.
There is no restriction on the type of Ethernet device that can be connected within the
EtherCAT segment via a switch port. The Ethernet frames are tunneled via the EtherCAT
protocol, which is the standard approach for internet applications (eg. VPN, PPPoE (DSL)
etc.). The EtherCAT network is fully transparent for the Ethernet device, and the real-time
characteristics are not impaired.

EtherCAT devices can additionally feature other Ethernet protocols and thus act like a
standard Ethernet device. The master acts like a layer 2 switch that redirects the frames to
the respective devices according to the address information. All internet technologies can
therefore also be used in the EtherCAT environment: integrated web server, e-mail, FTP
transfer etc.
International Standardization

The international standardization of EtherCAT is on the way. EtherCAT has been integrated
into the international fieldbus standards IEC 61158 and IEC 61784-2 as well as into the drive
profile standard IEC 61800-7. EtherCAT is also part of ISO 15745-4, the standard for XML
device description.

Summary

EtherCAT is characterized by outstanding performance, very simple wiring and openness for
other protocols. EtherCAT sets new standards where conventional fieldbus systems reach
their limits: 1000 I/Os in 30 s, optionally twisted pair cable or optical fibre and, thanks to
Ethernet and Internet technologies, optimum vertical Integration. With EtherCAT, the costly
Ethernet star topology can be replaced with a simple line structure - no expensive
infrastructure components are required. Optionally, EtherCAT may also be wired in the
classic way using switches, in order to integrate other Ethernet devices. Where other real-
time-Ethernet approaches require special connections in the controller, for EtherCAT very
cost-effective standard Ethernet cards (NIC) are sufficient.

EtherCAT makes Ethernet down to the I/O level technically feasible and economically
sensible. Full Ethernet compatibility, internet technologies even in very simple devices,
maximum utilization of the large bandwidth offered by Ethernet, outstanding real-time
characteristics at low costs are outstanding features of this network. As a high-speed drive
and I/O bus for Industrial PCs or in combination with smaller control units, EtherCAT is
expected to be widely used in a wide range of applications.

The EtherCAT technology and the specifications behind it are maintained by the EtherCAT
Technology Group (ETG). It is a forum for end users from different sectors, and for machine
manufacturers and suppliers of powerful control technology with the aim of supporting and
promoting EtherCAT technology. ETG was established in November 2003.

3.3 Ethernet Powerlink

In Industrial Automation, the need for distributed intelligent systems is steadily growing.
Physically distributed systems are working more and more together to solve common
functions. Databases are connected; Service and diagnostics have to be done by remote
connections, more and more by using TCP/IP.

Previously, the application of different field-bus systems has dominated the arranging of
heterogeneous access on machine level, but in the future Ethernet will be the universal bus
system in automation.

From office equipment, where Ethernet is established since 30 years as a standard, to

machines, a homogeneous bus system based on IEEE 802.3 will be established. Recently it
is the most prevalent technology, in which the users too have profound expertise.
Additionally, a broad spectre of accessories is available, like cable, plugs and equipment in
industrial quality, like Hubs and Switches. The need for long life cycles in industry can be
fulfilled as well, because Ethernet will be improved continuously, just now from 100 Mbit/s to
10 Gbit/s. The high market penetration as an international standard is guarantying this, too.

Nowadays it is possible to use various protocols with Ethernet, e.g. TCP/IP, XML, http,
SNMP and many more. Obviously, there was a need to develop an industrial protocol, which
fulfils requirements for control in automation as described in detail in chapter 1.
The main problem was the realization of real-time capabilities (see chapter 1.6), which have
to be guaranteed for time critical applications, but to achieve transparency in access to
applications and protocols as well. Real interoperability and world-wide access on
automation systems has to be realized.

Open Standard for real-time communication

Regular Ethernet and the well-known and established protocols like TCP/IP and UDP/IP are
not able to transfer data in real-time, was the block-ing factor for establishing Ethernet in
Industrial Automation down to the sensor and actor level.

With ETHERNET Powerlink a standard has been developed, based on IEEE 802.3 Ethernet
specifications. Mixed polling- and time slicing mechanisms on top of Ethernet layer 1 and 2
allow the transfer of time critical data with very short and precise isochronous communication
cycles. Cycle times are configurable in a flexible manner. In addition to time critical data,
sufficient bandwidth for adhoc transfer of asynchronous data for diagnosis, Parameters or
other purposes need to be guaranteed.

ETHERNET Powerlink is available for many years and it has successfully been implemented
in multiple serial applications around the globe. Today's systems are reaching cycle times
down to 100 s with a network jitter well below 1 s.

ETHERNET Powerlink is based on the well-established worldwide Ethernet standards.

Therefore it is possible to use existing Ethernet infrastructure components, any chip
architecture, equipment and testing systems.

All IP-based protocols, like TCP, UDP and above and their applications can be used without
modification. In particular ETHERNET Powerlink is compliant to the following standards:

IEEE 802.3 Fast Ethernet (incl. frame formats and physics)

RFC 791 IP based protocols
CANopen EN 50325-4 communication and device profiles
Any Ethernet chip on the market
IEEE 1588 for distributed Real-time Clock Synchronization in a future version

In addition to being compliant to international standards, ETHERNET Powerlink and parts of

its technology by itself will become standard. Members of the EPSG (ETHERNET Powerlink
Standardization Group) are actively involved in the following standardization projects:

IEC 61784-2 Real-Time Ethernet

IEC 61800-7 Power Drive Systems
IS015745 XML-based Device Description

Lower Layer Protocols

The following list shows ETHERNET Powerlink' basic features:

Up to 240 nodes in one real-time network domain

Guaranteed deterministic communication

- cycle times down to 100s implemented

- minimal jitter (smaller than 1 s) for precise synchronization
 Direct peer-to-peer communication of all nodes. I.e. all data sent out by any networked
node can immediately be read by any other networked node.
Hot-Plugging supported
Seamless transparent integration with IT networks

Reference Model

ETHERNET Powerlink's architecture is structured according to the ISO/OSI stacked layer

model supporting both Client/Server and Publish/Subscribe data relationships. Figure 82
illustrates all ETHERNET Powerlink layers including TCP, UDP, IP and CANopen.

Data Link Layer

Every ETHERNET Powerlink (EPL) device supports the following operation modes:

1. Basic Ethernet Mode

This is the default mode of an EPL device. It allows all devices to boot from the network,
receive configuration data and change to real-time operation if connected to a real-time
domain. However, EPL nodes can always directly be connected to any Ethernet network, no
matter if real-time or not. The system then remains in this mode an behaves like any other
non-real-time device.

2. EPL Mode

The device is running with real-time Performance. It communicates with a deterministic time
slicing mechanism, which is described in the following chapter.
Figure 82: Reference Model Ethernet Powerlink Protocol

Time Slicing

The real-time requirements of an application can only be fulfilled when it is guaranteed that
Information are collected, communicated and processed within well-defined timing
constraints. Regular Ethernet networks are not able to transfer data in real-time. Reasons for
that are the media access mechanism of Ethernet (CSMA/CD - Carrier Sense Multiple
Access/Collision Detect) and queuing delays of infrastructure devices like switches. Both are
heavily depending on the overall network traffic and do not allow to determine within which
timeframe data will be completely transmitted. ETHERNET Powerlink is avoiding both issues
by implementing a time slicing mechanism. Thus, it is guaranteed that only one bus member
at a time is allowed to send data to the network media. Collisions or queuing delays are
therefore not possible.

There needs to be at least one node in the real-time domain of network controlling the timing
of the communication. This node is called the Managing Node (MN). The MN synchronizes
all networked nodes and assigns dedicated time slot for each other node (so called
controlled nodes -CN). Figure 84 gives an overview about the EPL communication cycle.

The ETHERNET Powerlink communication cycle in detail

1. An ETHERNET Powerlink cycle always starts with the synchronization phase by sending a
"Start of Cycle" (SoC) frame from the MN. All CNs synchronize their timing with this frame by
capturing and setting input/output data and initiating data processing.
2.The next phase is the isochronous phase in which time critical data is exchanged on the
network. The MN is sending individual requests to each of the scheduled CNs. Requested
CN will response with their individual data which can be read immediately by all connected
devices. At the end of the isochronous phase the MN is sending its data to all other
networked devices.
3. After isochronous communication the asynchronous phase is started. In this part any
device can send non time-critical data per request. In this phase typically parameters,
diagnosis data or files are transferred. IP-based protocols can be used directly without data
conversion or tunnelling.

Application Layer Protocol and Device Profiles

Today, automation system manufacturers are focusing mainly on interoperability and

exchangeability of devices from various manufacturers. A broad component market with
plenty of alternatives and second sources enables them to produce competitive automation
Solutions without depending on unique or proprietary systems.

The objective of independence can only be achieved by using standard solutions, which
provide widely understood and used data exchange mechanisms. CANopen, as application
layer (layer 7) for CAN Systems, has already proven the market power of a standardized,
vendor independent standard which gives numerous device manufacturers the opportunity to
participate in sophisticated communication mechanisms.

In the past, many specific communication solutions have been developed for the
transmission of plain data on a Data Link Layer (Layer 2) without paying attention to further
definitions of higher layer and application related services like configuration of parameters or
network management. Mostly, messages are defined statically without the possibility of
modification of the data content to be transmitted.

Figure 83: Logo CANopen

Figure 84: Ethernet Powerlink cycle diagram

In general, there are multiple further requirements for a communication system arising when
distributed automation systems shall be built with different types of devices or devices from
different manufacturers:
 Network Management: A common mechanism for Controlling and monitoring the
network consistency during boot-up and run-time of the network.
Object Dictionary and Device Model: A common method for specifying and
referencing data, parameters and functions of a certain device or device type
provided to the system.
Error Signalling: A common method for signalling errors and indicating error
conditions to the system independent of the device type or manufacturer.
Process Data Object - PDO: A common mechanism enabling the user to specify the
data, exchanged between different devices.
Service Data Object - SDO: A common mechanism for transmitting larger amounts of
arbitrary data like configuration data.
Device Profiles: Standardized definitions of data, parameters and functions for certain
device types like drives, I/O modules, encoders, PLCs, etc.

Perfect Match: CANopen and ETHERNET Powerlink

In order to provide a flexible and proven solution for the application layer, ETHERNET
Powerlink has been combined with the well known and widely deployed CANopen family of
communication and device profiles. The EPSG and the CiA (CAN in Automation) has
founded a joint technical working group, which has achieved the adaptation of CANopen's
DS301 and DS302 communication profiles to ETHERNET Powerlink.

Now every ETHERNET Powerlink device is described by a standardized Device Model with
its central element, the Object Dictionary, containing a list of descriptions of all data,
parameters and functions of the device that can be accessed or controlled remotely via
Ethernet. Furthermore, all configurable communication parameters are listed in the Object
Dictionary. By means of the Object Dictionary each data of a device can be easily accessed
from any device of the network by a unique 24-bit reference, consisting of a 16-bit index and
an 8-bit sub-index.

Figure 85: The ETHERNET Powerlink Device Model matches the CANopen specification.
PDOs and SDOs

Real-Time critical exchange of process data is handled by Process Data Objects (PDO).
PDOs are transmitted in the isochronous phase of the ETHERET Powerlink Cycle using a
Consumer/ Producer oriented communication model. Each device is able to communicate its
process data directly with all other devices in the system. The contents of a PDO (process
data which is to be transmitted or received) can be configured during system start-up. This
allows optimizing and adjusting the Real-Time data exchange to the requirements of the
application. The Real-Time critical data is transmitted in PDOs without any overhead.

The exchange of parameters, functions or less Real-Time critical data is handled by Service
Data Objects (SDO). SDOs are based on a Client/ Server oriented communication model,
where every device can access or can be accessed from any other device by an SDO. An
SDO allows a client to implicitly address any entry in the Object Dictionary of the server. The
length of data to be transferred is not limited. Since SDOs are transmitted in the
asynchronous phase using UDP/IP, an ETHERNET Powerlink device can also be accessed
via generic Internet which is connected via a router with the ETHERNET Powerlink segment.

Figure 86: EPL Frame Format for PDO Transfer

Figure 87: SDO Transfer via UDP/IP

Network Management

System boot-up and shut-down or replacing devices has to follow specific rules and has
therefore be completely under control. Specific functions and mechanisms have to be
provided by the Network Management. A Network Manager is responsible for system
consistency checks during boot-up and for monitoring the status of all devices during run-
time. The communication behaviour of each ETHERNET Powerlink device is defined by a
local state machine, which is controlled by certain system events and by commands from the
Network Manager.
Configuration Management

The Configuration Manager is the central intelligence in an ETHERNET Powerlink system. It

is able to maintain the configuration data for its application and all devices locally and
downloads the configuration data during system start-up. This approach enables the set-up
of plug & play systems which allow initial installation and replacement of failed devices very
easily. For describing an ETHERNET Powerlink device, a standardized file format exists in
form of an XML-based Electronic Data Sheet (EDS) according to ISO 15745-4.

Network Migration and Integration

Since the ETHERNET Powerlink Application Layer provides the same mechanisms as CAN-
open, all CAN device profiles can directly be reused. Thus a wide range of profiles for
different device types and application already exists. Users and vendors of CANopen
enabled devices are now able to easily migrate their applications from the well-established
CAN bus to an Ethernet environment which is a hundred times faster. CAN bus and Ethernet
networks can transparently be combined wherever needed.

IT Integration

The idea of integrating IT and automation networks by using Ethernet offers interoperability
with Internet flexibility and transparent worldwide access. With ETHERNET Powerlink
seamless communication down to sensors and actuators is achieved by using IP-based
protocols in Real-Time and non Real-Time domains.

Simple IP Address Assignment

If individual devices are contacted using an IP address on the machine level, it's important
that any replacement device will have the same IP address again.

With ETHERNET Powerlink, the device address is linked with the node selection switch on
the front side of the device. This method is used to calculate the IP address itself, but it can
still be overwritten by a network manager if needed. This guarantees that devices that are
exchanged retain their IP addresses without them having to be entered manually.

Transparent Worldwide Access

Since the number of IP addresses available worldwide is limited, it's usually a company's IT
department that is in charge of allocating them to devices. If automation devices, like PLCs
or drives should be accessible via open IT networks, IP addresses need to be assigned to
these. Apparently, in serial production the number of IP addresses needed may reach high
numbers.

Additionally, IP address ranges are varying, because the manufacturer and user network
environments are different.

ETHERNET Powerlink deals with this by assigning local IP addresses (RFC 1918 - Address
Allocation for Private Internets) on the machine level, regardless if the machine is connected
to the vendor's production network or at the final customer site. The same local IP addresses
are always used on the machine. NAT (Network Address Translation) is used to assign
global addresses to local internal addresses in the network where the machine is running.
This method has already been established in the Internet environment. With ETHERNET
Powerlink, it is used to clearly separate manufacturer and end-user addresses without a
lengthy reconfiguration process after delivery.
For EPL addresses private class C network address 192.168.100.0 is used. Class C
networks support 254 IP addresses, which accord to the node ID in EPL network
(192.168.100.NodelD). For EPL subnet mask is 255.255.255.0 a default gateway
192.168.100.254.

Network Topologies

Ethernet networks installed in office buildings rely mostly on a star topology. This is not
suitable for the majority of machine networks. Field busses helped to reduce the wiring effort,
while adapting the network topology to the needs of the application. To help industrial
Ethernet succeed at the lowest level, it must be possible to use any network topology.

That's why individual ETHERNET Powerlink devices are equipped with several Ethernet
ports which can handle lines and branches. Therefore any topology such as line, tree, star or
mixed structures can be realized. Inside the device, a repeating hub forwards the data
stream to its intended destination. In addition to greater flexibility, this reduces the need for
external infrastructure components such as switching or repeating hubs.

With ETHERNET Powerlink the physical and the logical topology of the network are
separated. It is possible to connect a device to any port on the network without having to
reconfigure it. This achieves a higher degree of freedom when designing and upgrading
modular machine systems and prevents cabling errors. It is very simple to integrate Ethernet
Powerlink with existing Ethernet-based Networks on the factory floor and the Internet.

Figure 88: Typical communication relationships and routing paths between the Internet,
Company factory and machine networks
Nevertheless, a real-time network has to be protected from external malfunctions and
unauthorized access. Besides guaranteeing the real-time behavior and precision in the real-
time domain regular IP-based traffic needs to be able to flow through the network
transparently if addressed to the real-time domain. A router separates the real-time domain
from other networks.

ETHERNET Powerlink distinguishes between Real-Time domains and non Real-Time

domains.

Figure 89: Independency of physical topology and logical topology

This separation matches typical machine and plant concepts. It also satisfies the increasing
security demands to prevent hacker attacks on the machine level or harm through erroneous
data communication on higher network hierarchies. Hard Real-Time requirements are met
within the Real-Time domain. Less time critical data is routed transparently between the
Real-Time domain and non-Real-Time domain using Standard IP frames. A clear boundary
between a machine and factory network prevents potential security flaws from the very
beginning while keeping full data transparency.
Securely Connected to the World

One of the main reasons for using Industrial Ethernet is the transparency achieved when
transferring data to standard applications such as databases, process control systems,
ERPsystems, etc. system accessibility over the Internet also offers new possibilities for
maintenance and service. Hackers, tired of just breaking into email systems, are looking
forward to the time when a large number of machines are connected over global networks.
The potential for loss due to production stoppages, quality reduction, or general damage is
enormous.

For this reason, ETHERNET Powerlink provides a clear separation and access controls on
the machine level from the very beginning. On the one hand, it is important to guarantee that
external access to the machine network is only possible by authorized persons. On the other
hand, it is important to guarantee that the timing of the Real-Time domain is not influenced
by malicious attacks on the higher-level network. Time deviations in the microsecond range
could cause reduced production quality and, in the worst case, could also damage machine
parts. The separation between Real-Time and non-Real-Time domains in ETHERNET
Powerlink ensures security in all aspects.

ETHERNET Powerlink Standardization Group

The EPSG (ETHERNET Powerlink Standardization Group) has been founded in June 2003
as an independent association in Winterthur/ Switzerland. Originated from a group of leading
automation companies, its focus is to leverage the advantages of Ethernet for high
Performance Real-Time networking systems based on the ETHERNET Powerlink Real-Time
protocol, introduced by B&R end of 2001.

The EPSG has clear organizational structures and ensures transparent decision processes.
Various working groups are focusing on different tasks like safety, technology, marketing,
certification and end users. Within these groups, each EPSG member has the opportunity to
shape the future of ETHERNET Powerlink. The EPSG is furthermore cooperating with
leading standardization bodies and associations, like the CAN in Automation Group, the
IAONA and the IEC.

Figure 91: Logo of the EPL Standardization Group

The idea of the EPSG is to maintain the balance between a common understanding of
automation technology and the demands from different directions. This results in widely
acceptable Solutions, which can be implemented on short terms. Thus, ETHERNET
Powerlink ensures a fast time-to-market and consequently ETHERNET Powerlink is currently
the only available Real-Time industrial Ethernet System on the market.

Shape the future of Industrial Ethernet

ETHERNET Powerlink is a proven technology which is deployed in more than 70,000 nodes
used in serial machinery since 2001. Based on mature Standards the EPSG is working on
further development of the specifications to add even more capabilities in areas like safety,
security, system redundancy or precision dock synchronization in heterogeneous
Ethernet/Internet topologies. Similar to already finalized specifications, ease-of-use and
openness will continue to be the major focus for future additions.

There are plenty of opportunities to shape the future of Industrial Ethernet within the EPSG.
No matter, if one is interested in Real-Time communication, safety-related protocols, network
security or other related topics. Everybody is invited to join the EPSG and its working groups
to specify and deploy the next generation automation network. More Information about EPSG
membership, by-laws and application forms are available on www.ethernet-powertink.org.