Industrial Ethernet Technologies: Overview

Industrial Ethernet Technologies: Overview
Industrial Ethernet Technologies
Page 1
© EtherCAT Technology Group
Editorial Preface:
This presentation intends to provide an overview over the most important
Industrial Ethernet Technologies. Based on published material it shows
the technical principles of the various approaches and tries to put these
into perspective.
The content given represents my best knowledge of the systems
introduced. Since the company I work for is member of all relevant
fieldbus organizations and supports all important open fieldbus and
Ethernet standards, you can assume a certain level of background
information, too.
The slides were shown on ETG Industrial Ethernet Seminar Series in
Europe, Asia and North America as well as on several other occasions,
altogether attended by several thousand people. Among those were
project engineers and developers that have implemented and/or applied
Industrial Ethernet technologies as well as key representatives of some of
the supporting vendor organizations. All of them have been encouraged
and invited to provide feedback in case they disagree with statements
given or have better, newer or more precise information about the systems
introduced. All the feedback received so far was included in the slides.
You are invited to do the same: provide feedback and – if necessary –
correction. Please help to serve the purpose of this slide set: a fair and
technology driven comparison of Industrial Ethernet Technologies.
Nuremberg, February 2014
Martin Rostan, [email protected]
Industrial Ethernet Technologies
Page 2
© EtherCAT Technology Group
All Industrial Ethernet Technologies introduced in this presentation are
supported by user and vendor organizations. EPSG and ETG are pure
Industrial Ethernet organizations, whilst the others have a fieldbus
background and thus members primarily interested in the respective
fieldbus technology.
All technology names as well as the names of the organizations promoting
and supporting those are trademarked. The trademarks are honored.
Industrial Ethernet Technologies
Page 3
© EtherCAT Technology Group
Depending on the real time and cost requirements, the technologies follow
different principles or approaches. This comparison tries to group those
approaches in three different classes by looking at the slave device
implementations:
Class A uses standard, unmodified Ethernet hardware as well as standard
TCP/IP software stacks for process communication. Of course some
implementations may have modified „tuned“ TCP/IP stacks, which provide
better performance.
Class A approaches are also referred to as „best effort“ approaches. The
real time performance is limited by unpredictable delays in infrastructure
components like switches – no just due to other traffic on the network. The
by far largest obstacle to better real time performance however is provided
by the software stacks (TCP/UDP/IP).
Industrial Ethernet Technologies
Page 4
© EtherCAT Technology Group
Class B approaches still use standard, unmodified hardware, but do not
use TCP/IP for process data communication. A dedicated process data
protocol is introduced, which is transported directly in the Ethernet frame.
TCP/IP stacks may still exist, but typically their access to the Ethernet
network is controlled and limited by what can be considered a timing layer.
Of course this description is pretty generic – but more details are given in
the technology specific sections.
Industrial Ethernet Technologies
Page 5
© EtherCAT Technology Group
Class C approaches aim even higher with regard to performance. In order
to achieve these goals, dedicated hardware has to be used (at least on
the slave device side).
In case of PROFINET IRT, the Special Real-time Ethernet Controller is
more a Special Switch Device – but the result is the same: better
performance due to better hardware integration.
This does not exclude the use of TCP/IP and the Internet Technologies.
Industrial Ethernet Technologies
Page 6
© EtherCAT Technology Group
There are 3 PROFINET-Versions:
Version 1 („Component Based Automation“), a Class A approach
Version 2 ((Soft) Real Time“), a Class B approach
Version 3: („Isochronous Real Time“), a Class C approach
Profibus International (PI) has moved away from the terms RT/IRT and
introduced the term PROFINET IO for both RT and IRT…
Industrial Ethernet Technologies
Page 7
© EtherCAT Technology Group
Not all IRT devices support cycle times < 0.5 ms, e.g. Siemens Sinamics
Controller.
The jitter shown in the graph above show the intended values for the end
device – and do not necessarily cover the jitter caused by the network
(e.g. forwarding jitter of the switches)
Industrial Ethernet Technologies
Page 8
© EtherCAT Technology Group
Initially the PNO/PTO message was: protect your investment and continue
using Profibus, for Ethernet connectivity we provide a transparent
gateway.
Work on the gateway (proxy) concept was started as early as 1999. First
spec (V0.9) published in March 2001 (EtherNet/IP was first introduced in
2000).
Meanwhile CBA is not supported by Profibus International any more. The
most recent document mentioning CBA on the PROFINET Website is from
2009.
Industrial Ethernet Technologies
Page 9
© EtherCAT Technology Group
PROFINET CbA (Component Based Automation) comprises more than
just a communication protocol: the CbA programming approach with
graphical mapping of variables to establish communication links.
Industrial Ethernet Technologies
Page 10
© EtherCAT Technology Group
PROFINET V2 was initially called SRT (Soft Real-time). The term „soft“
was later dropped for marketing reasons.
PROFINET RT is meanwhile mainly addressed as PROFINET I/O
(together with IRT).
Siemens communicated that PROFINET RT provides performance similar
to Profibus. Even though this is optimistic (typically Profibus is faster and
provides better node synchronization), one can read this statement as
follows:
If Profibus performance is sufficient, but Profibus is not expensive enough,
PROFINET RT is an alternative.
Industrial Ethernet Technologies
Page 11
© EtherCAT Technology Group
PROFINET IRT (V3) is a class C approach which introduces special hardware in
order to achieve sufficient performance and synchronicity for motion control
applications.
Industrial Ethernet Technologies
Page 12
© EtherCAT Technology Group
In PROFINET RT, cyclic data exchange is triggered by local timers, which are NOT
synchronized (High Precision Time synchronization with PTCP is only required in
IRT = Conformance Class C). Hence in PROFINET RT there is no general support
for sub-ms network wide synchronization, and there are frequency fluctuations.
Industrial Ethernet Technologies
Page 13
© EtherCAT Technology Group
Even though PROFINET marketing claims that line topology is supported,
in fact this is not recommended by Siemens.
Industrial Ethernet Technologies
Page 14
© EtherCAT Technology Group
The minimum cycle time is determined by the approach to include generic
TCP/IP traffic in a gap wide enough for the largest Ethernet frame.
This approach leads to limited bandwidth utilization, since even though
most applications only have sporadic TCP/IP communication, the
bandwidth remains reserved for this kind of traffic.
For cycle times below 250µs the so called High-Performance-Profile has
to be implemented, which is an optional feature in V2.3.
As of Feb 2014, there are no master devices supporting this profile. The
standard PROFINET masters from Siemens start at 250µs (Motion
Controller) or at 1ms (e.g. PLC S7-315).
Industrial Ethernet Technologies
Page 15
© EtherCAT Technology Group
The non-linear and even unpredictable interdependency between topology
and performance may require several iterations (or „try and error“ steps)
when designing a network layout for a required performance.
Industrial Ethernet Technologies
Page 16
© EtherCAT Technology Group
In principle both varieties (RT+IRT) can be mixed. Since IRT switches
have to be used then, one can say:
RT devices can be integrated in IRT networks, if there is sufficient
bandwidth and if the master supports this.
Siemens recommends in the current System Manual* to position the RT
devices at the end of the PROFINET system, outside of the IRT sync
domain. Synchronization between the RT and IRT devices is not possible
(“if you want to synchronize with IRT, the respective PROFINET devices
must support IRT communication”).
* Source: Siemens PROFINET System Description, page 153, “Setting up PROFINET with IRT”, 07/2010, A5E00298288-05
Industrial Ethernet Technologies
Page 17
© EtherCAT Technology Group
Besides hardware costs, the crucial issue of PROFINET IRT is the
complex system planning.
Industrial Ethernet Technologies
Page 18
© EtherCAT Technology Group
For each node all communication relationships have to be known and
scheduled. Of course there are strong interdependencies between the
schedules. Therefore the system planning is a complex recursive
optimization problem without a straightforward solution – even with fairly
simple topologies.
Due to the complex nature of this problem the optimization algorithm may
come up and be satisfied with a relative rather than the absolute optimum
– which means, that a small change in the configuration (e.g. adding just
one more node) may result in large changes in the network performance.
The algorithm was developed by Prof. Dr. Ulrich Lauther and has 23.000
lines of code, according to Siemens. A license for the planning algorithm
(in dll format) can meanwhile be obtained by PI members – it remains a
black box algorithm, however.
Industrial Ethernet Technologies
Page 19
© EtherCAT Technology Group
This is the performance data table published for PROFINET IRT.
However, the table is valid only for a cluster of networks: 272 nodes
sharing 50% bandwidth at 1ms cycle time means 500 µs / 272 = 1,84 µs
per node. The shortest Ethernet frame takes 7µs to transmit.
Furthermore, most controllers using the Siemens ERTEC 400 chip have a
limit of 64 IRT nodes – on all 4 ports combined, due to resource limitations
within the chip.
Controllers using the 2-port ERTEC 200P can only handle a much smaller
number of nodes (~16)
This is not to state that PROFINET IRT was not fast enough for most
applications...
Industrial Ethernet Technologies
Page 20
© EtherCAT Technology Group
In order to avoid the complex topology network planning process, an
intermediate approach had been introduced: Realtime (RT) Class 2 (within
Siemens also called IRT “Flex” or “IRT with high flexibility”) using
PROFINET chips (e.g. ERTEC). High priority network traffic is sent in the
IRT time slice, but without predefined timing for each connection. Low
priority communication is handled in the NRT time slice. PROFINET chips
have to be used throughout. Cyclic behavior can be achieved if the
network load is low and the application tasks are synchronized with the
communication cycle. The downside is that there is unused bandwidth that
is exclusively reserved and cannot be used for other communication.
IRT Flex was intended as a simplified PROFINET IRT variety for PLC type
applications that utilize ERTEC profinet chips (Siemens Simatic S7).
However, due to incompatibility issues, IRT Flex is not promoted or
recommended by Siemens any more. In the PROFINET Specification
V2.3 IRT Flex is marked as “legacy”, thus not supported any more.
RT Class 3 (also called IRT “TOP” or “IRT with high performance”) is the
variant formerly referred to as PROFINET IRT. This approach provides
hard real time behavior but requires the detailed network planning
(topology editor) and the optimization algorithm: the topological
information from the configuration is used for planning the communication.
Siemens is adopting this variant for PLCs as well.
PTO/PNO generally downplays the differences between the PROFINET
variants, summarizing all of them with the term “PROFINET IO”.
Industrial Ethernet Technologies
Page 21
© EtherCAT Technology Group
In addition to the RT classes, PROFINET has introduced (see IEC 617842) Application Classes (Isochronous for motion control, Non-isochronous
for factory process + building automation),
Redundancy Classes (MRP: Media redundancy protocol; MRRT: Media
redundancy for real-time (dropped in PROFINET V2.3); MRPD: media
redundancy for planned duplication) and
Conformance Classes. The Conformance Classes predominantly define
the support for the topology recognition features. Redundancy Classes
and Conformance Classes are interlinked.
Topology Recognition originally was required for Conformance Class B +
C, only; meanwhile this is required for Conformance Class A (but without
LLDP-MIB).
Industrial Ethernet Technologies
Page 22
© EtherCAT Technology Group
It was found that there are issues when using unmanaged switches with
PROFINET Class A (in B managed switches are mandatory): common
COTS switch chips forward LLDP (Link Layer Discovery Protocol) frames
to all ports, which leads to substantial additional network traffic (the
frames are handled like broadcast frames).
Conclusion: even for Conformance Class A PROFINET networks, in
reality managed switches have to be used (for LLDP) - and they have
to be selected very carefully (IT support required).
see also EFTA 2007 Conference Paper by Iwan Schafer + Max Felser, Berne
University of Applied Sciences: “Topology Discovery in PROFINET”:
http://www.felser.ch/download/ETFA-01-2007.pdf
Industrial Ethernet Technologies
Page 23
© EtherCAT Technology Group
PROFINET marketing has always claimed that PROFINET provides (quote from PI
“PROFINET Benefits” presentation):
• “Unlimited IT communications parallel to real-time communications
• Easy use and integration of standard Ethernet applications”
However, since the PROFINET technology itself (unlike e.g. EtherCAT) has no means
to control or restrict incoming “unlimited IT communications”, there can be rare
overload situations that cause the network to fail. If the communication processor of a
device is too busy to handle e.g. an occasional burst of broadcasted ARP frames and
therefore cannot keep up with executing services such as IP communication,
propagation delay measurement or synchronization, the communication times out and
the master will recognize an error – the system stops.
One could consider this an implementation problem that can be avoided by providing
sufficient processing resources throughout – but it is a problem that occurs in reality,
especially in large networks. And adding resources such as processing power eases
the problem, but does not resolve it reliably.
It can be challenging to ensure that certain network load limits are not exceeded. If
e.g. a service notebook starts to scan the network for IP addresses at high pace, who
knows what kind of load condition this generates?
By the way: Industrial Ethernet technologies that tunnel other Ethernet traffic - such
as EtherCAT – remain in control of the additional network load and avoid such
situations by design.
Industrial Ethernet Technologies
Page 24
© EtherCAT Technology Group
Regardless of the net load class, PROFINET IO devices are only required
to handle 50 ARP request per second (in any density within that second).
This means that things may go wrong if an average of one ARP request
per 20 ms is exeeded. The latest draft version of the PROFINET IO
Security Level 1 - Netload Guideline was published in Nov 2013. Now
LLDP traffic exceeding 5% within one ms is suggested to be a “faulty”
condition.
Industrial Ethernet Technologies
Page 25
© EtherCAT Technology Group
This press release shows that vendors take the net load specifications
seriously: Softing is happy that their device passed (the preliminary) test
cases for net load class III, but how does the user ensure that the net load
is confined within a certain class?
Industrial Ethernet Technologies
Page 26
© EtherCAT Technology Group
Since PROFINET has no structuring concept, all modules within reach of one
PROFINET node (e.g. all machines and subsystems in an assembly line) have to
have unique names/addresses. This means that the node address has to be
assigned by the system integrator: the node addresses assigned by the machine or
subsystem supplier may conflict with neighboring systems and may therefore have to
be modified at the customer site.
Industrial Ethernet Technologies
Page 27
© EtherCAT Technology Group
Profibus organization PNO showed a PROFINET IRT+ demonstrator in
April 2008 at Hannover Fair. According to a PNO press release of Nov 26,
2008, “The specifications will be finished in the second half of 2009“.
Similar to RT and IRT version that are summarized as “PROFINET IO” in
order to play down the many varieties of the technology, the PROFINET
organization does not use the term IRT+ any more. The features of the
new version which requires new chips are contained in the PROFINET
specification V2.3, of which Ed. 1 was published in October 2010.
V2.3Ed.2 was published in December 2012.
The next version V2.3Ed.2MU1 was published in October 2013.
(substantial change log in Technical-editorial-Changes-d23Ed2MU1_V1_Oct13.pdf).
Currently PNO is working on Ed. 3.
Industrial Ethernet Technologies
Page 28
© EtherCAT Technology Group
DFP will work in line topologies, only.
With DFP PROFINET introduces the layer 2 fragmentation of IP-Frames –
another feature that EtherCAT has introduced and which PROFINET
marketing used to condemn…
Industrial Ethernet Technologies
Page 29
© EtherCAT Technology Group
For introducing Fast Forwarding the address usage had to be modified.
The goal is to reduce the „per-node-delay“ of PROFINET. Since
PROFINET Version 2.3 the FrameID is part of the OUI (Organizationally
Unique Identifier) in the MAC address, with the first two bits set to “1” (=
Locally Administered Group Address).
The MAC addresses used for Fast Forwarding are not protected and can
be used by others as well – it is the responsibility of the user to ensure
that there is no address conflict within his network.
Examples for systems with known address conflicts:
03:00:C7:00:00:EE HP (Compaq) ProLiant NIC teaming
03:00:FF:FF:FF:FF All-Stations-Address
03:BF:00:00:00:00 MS-NLB-VirtServer-Multicast
Industrial Ethernet Technologies

Page 30
© EtherCAT Technology Group
Industrial Ethernet Technologies
Page 31
© EtherCAT Technology Group
Siemens/Renesas ERTEC400 chip is intended for master devices, has 4 ports and
supports minimal cycle times of 250µs;
Siemens/Renesas ERTEC200 chip is intended for slave devices, has 2 ports and
supports minimal cycle times of 250µs;
Siemens ERTEC200P chip is intended for slave devices, has 2 ports and claims to
supports minimal cycle times of 31,25µs (if there was a master supporting this).
In Feb 2013 The Intel Ethernet Controller I210 was introduced as breakthrough for
low cost IRT Master implementations. However, according to reports the chip is only
suitable for relaxed synchronization requirements.
There are considerably smaller PROFINET stacks that claim to be V2.3 compatible –
however, these are PROFINET RT (Conformance Class A, Realtime Class 1) stacks,
not supporting IRT.
Industrial Ethernet Technologies
Page 32
© EtherCAT Technology Group
TPS1 is also called “Tiger” chip, since it was planned to be released in the Year of the Tiger
(2/2010 – 2/2011). Even though it will now be released in the Year of the Rabbit (or Hare), no
plans are known to officially rename it the “Rabbit” chip.
The Tiger aka TPS1 (aka Rabbit) chip is a Phoenix Contact development (subcontracted to the
Institut Industrial IT (inIT) of the University of Applied Science Westfalen Lippe) – and Phoenix
Contact (not Siemens) also was the driving force behind PROFINET V4 (IRT+). So the TPS1 was
intended to be the first chip supporting the new PROFINET version.
But end of 2009 it looked that Siemens was unhappy about Phoenix trying to take the lead in
PROFINET advancement and therefore forced Phoenix into a lengthy consensus building process
within PNO in order to delay the availability of PROFINET V4. Later Siemens seemed to have
recognized that this strategy backfired on PROFINET in general.
So in March 2010 PNO held a press conference where in total contrast to the statements of Nov
2009, where Siemens had denied any involvement in the TPS1 development, Siemens and
Phoenix Contact called the TPS1 a joint development of both companies which they plan to use
also in the future in devices of their own product portfolio.
Nevertheless, PNO committees changed the Fast Forwarding technology again in fall 2010 and
thus too late for the first version of the TPS1 chip. So the TPS1 chip will initially not support the
DFP and FF – which is not such a big problem, since there is no master in sight supporting these
features anyhow. The Siemens next generation PROFINET chip (ERTEC 200P) thus has been
the first one to support DFP and FF.
The TPS1 is for slave devices only. The integrated “PROFINET CPU” is an ARM core and
executes the time critical parts of the PROFINET protocol. Digital I/O can be connected directly to
the chip. For communication with the application (host) CPU the chip contains internal DPRAM,
which can be accessed via serial or parallel interface. Since its cyclic process data image is
limited to 340 bytes, it is hardly suitable for bus couplers of modular I/O devices or other more
complex devices. KW Software claims that with this chip the interface hw costs can be reduced to
13€ (~19$).
Industrial Ethernet Technologies
Page 33
© EtherCAT Technology Group
First samples of the ERTEC 400 were shipped in May 2005, first samples
of the ERTEC 200 were shipped in May 2006. The ERTEC 200P was
released in April 2013.
Initially, the ERTEC 400 was sold for 38€ and the ERTEC 200 for 19 € per
chip (@ 10.000 units/year). As of Oct 1st, 2007, Siemens lowered the
prices substantially (-40%).
12.50€ respective 30€ per chip still exceeds fieldbus cost levels not only
for simple devices, in particular if one considered the amount of memory
needed:
A PROFINET slave device needs about 1-2 MByte of Code for the
communication part. For implementation with ERTEC chips, a VxWorks
license is required: the stack is provided as object code for this RTOS.
Industrial Ethernet Technologies
Page 34
© EtherCAT Technology Group
The PROFINET IO Varieties lead to corresponding test tool and test case
varieties. So far no test for V2.3 available.
PROFINET International is working on an integrated test specification,
though.
Industrial Ethernet Technologies
Many versions of PROFINET.
Page 35
© EtherCAT Technology Group
Industrial Ethernet Technologies
Page 36
© EtherCAT Technology Group
In October 2013 a document listing the Technical and editorial Changes of
the PROFINET specs IEC 61158-5-10, 61158-6-10, 61784-2 was
published. It contains a long list of changes, but no details.
There are even 3 completely different Siemens Implementations of
PROFINET IO.
PROFINET remains a moving target…
Industrial Ethernet Technologies
Page 37
© EtherCAT Technology Group
Interesting enough, Siemens has also developed another Ethernet based
motion control network: Drive-CLiQ.
Drive-CLiQ is used to connect the Sinamics motion controller containing
the path planning algorithm (trajectory controller) with the drives, the
position sensors (encoders, tachometers, resolver) and also with terminal
modules (HMI).
PROFINET IRT and Profibus are used to network and synchronize
several such motion controllers – so primarily for controller/controller
communication.
End of November 2010 Siemens announced that they are is now even
opening Drive-CLiQ to feedback sensor manufacturers who are invited to
implement this interface in their encoders, resolvers, tachometers and
linear position sensors. Siemens also provides a special chip for that
purpose.
Industrial Ethernet Technologies
Page 38
© EtherCAT Technology Group
Given that the first version of PROFINET was introduced over 12 years
ago, and that it is promoted by the market leading automation giant, the
adoption rate of PROFINET is poor.
As of February 2014, there are still very few non-Siemens PROFINET
masters – in particular non-Siemens IRT-masters are difficult to find. Also,
there are very few known non-Siemens IRT drives, and if they support
IRT, the usage can be very limited. E.g. the KEB F5 drive supports IRT,
but only at 2000µs cycle time (not shorter).
The PROFINET Node Count has a very high Siemens share, but most of
the nodes are the low cost S7 1200 controllers, which hardly use
PROFINET.
Industrial Ethernet Technologies
Page 39
© EtherCAT Technology Group
Even though PROFIsafe is based on a black channel approach, license
conditions in the PROFIsafe Policy restrict the usage to PROFIBUS and
PROFINET.
The PROFIsafe Policy explicitly prohibits to mention any Profisafe related
problems in public:
It says: “Negative statements to the public about problems without prior
consultation or clarification with the PI Working Groups shall be avoided.
Violators may be liable for any damage.”
We hope that quoting from the Profisafe policy and describing the
evolving Profisafe technology and its versions cannot be considered to be
a “negative statement.”
Industrial Ethernet Technologies
Page 40
© EtherCAT Technology Group
The PROFIsafe specification has passed through several changes to fulfill
requirements of a black channel safety protocol which is capable to be used e.g. in
Ethernet-based communication systems.
The new Profisafe specification V 2.6 was published within PROFINET International
in October 2013, intended as input for the third edition of IEC 61784-3.
In the foreword it says:
This third edition cancels and replaces the second edition published in 2010. This edition
constitutes a technical revision. The main changes with respect to the previous edition are
listed below:
– Legacy V1-mode removed from this protocol edition;
– Protocol extensions to protect against possible loopbacks (LP extensions);
– Protocol extensions to keep SIL3 for safety networks with large numbers of participants
(XP extensions) and subsequent new F-Parameter "F_CRC_Seed";
– Introduction of random and disjoint Codename based MonitoringNumbers (MNR) in
addition to the previous Consecutive Numbers;
– Provisions for Channel Granular Passivation and subsequent new F-Parameter
"F_Passivation";
– GSD extensions due to new F-Parameters;
This suggests that Profisafe is currently undergoing another major change.
Industrial Ethernet Technologies
Page 41
© EtherCAT Technology Group
In Basic protocol (BP) version a loop-back error may occur with
symmetrical F-Input/Output data in an F-Device. The user has to consider
certain features of his system to prevent this:
- Does the Black channel comprise programmable IO Data routers?
- Is there Symmetrical F-Input/Output data in F-Device?
- Furthermore, verification of each and every safety function shall be
performed after any change within the programmable IO data router. In
case of routing variants, this verification shall be performed for each
variant.
In Expanded protocol (XP) the CRC polynomial has changed from 24-bit
to a 32-bit.
Industrial Ethernet Technologies
Page 42
© EtherCAT Technology Group
The expanded protocol functions require conformance considerations
between three F-Host protocol versions (BP, LP, XP) and F-Devices/FModules according to IEC 61784-3-3 Edition 2 and Edition 3.
Industrial Ethernet Technologies
Page 43
© EtherCAT Technology Group
PROFINET RT is not low cost, requires a lot of code and is not high
performance, but in the long run it will be a success – regardless of the
technology, simply due to the Siemens (+ PNO/PTO) market position, just
like Profibus.
The German car makers have announced to use PROFINET in car
assembly lines „if it provides technological and economical advantages“
(quote). Daimler, e.g., has clearly stated that this announcement does not
cover the power train business, where CNC and other motion control
applications are in place.
The situation is different for PROFINET IRT: A solution with sufficient
performance, but with rather expensive chips and a very complex network
planning and configuration tool where the key algorithms are not open.
IRT is positioned at servo motion control applications and will therefore be
– just like Profibus MC – a Siemens motion control solution with limited
support from third party vendors (just like PROFINET MC).
Plus, Siemens latest Motion Control product line prefers a different
communication link for closed loop control: DriveCliq, which uses Ethernet
physical layer, only.
Industrial Ethernet Technologies
Page 44
© EtherCAT Technology Group
EtherNet/IP claims to use the same application layer as Devicenet,
Controlnet and CompoNet. This may be beneficial for those that are
familiar with those fieldbus networks. However, taken from the experience
when implementing Devicenet and Controlnet, the synergy effects are
expected to be somehow limited, since the communication technologies
and even the protocols differ substantially.
Industrial Ethernet Technologies
Page 45
© EtherCAT Technology Group
By applying broadcast or multicast communication, the switches cannot
forward incoming frames to a single destination port only - so they act like
(full-duplex) Hubs, but with larger delay.
Industrial Ethernet Technologies
Page 46
© EtherCAT Technology Group
This paper by Anatoly Moldovansky, a well-respected senior engineer
from Rockwell Automation, highlights some of the issues with EtherNet/IP:
there is a need for routers with multicast/broadcast control features, and
there is no standard way to implement or configure these.
IGMP snooping constrains the flooding of multicast traffic by dynamically
configuring switch ports so that multicast traffic is forwarded only to ports
associated with a particular IP multicast group.
Furthermore, high-end switches typically have high-end prices. Rockwells
documentation states that switches for EtherNet/IP have to support IGMP
snooping as well as port mirroring (for troubleshooting). They should also
support VLAN and SNMP – so manageable switches are required.
Industrial Ethernet Technologies
Page 47
© EtherCAT Technology Group
Even though the switch delays are unpredictable by nature, the delays
introduced by the software stacks are much more significant.
Industrial Ethernet Technologies
Page 48
© EtherCAT Technology Group
DLR technology first published in Nov 2008 version of EtherNet/IP spec.
First products in Q3 2009.
Requires special nodes who support the DLR protocols
Ring supervisor node monitors network status with “Beacon frames”, per
default every 400µs. In case of failure, ring supervisor actively
reconfigures the network (e.g. by remotely opening or closing ports)
ODVA recommends to connect “DLR unaware nodes” through 3-port
protocol aware switches.
Fault recovery time for a 50-node network: about 3 ms.
Enhances the EtherNet/IP topology options, also supports combinations of
several rings and combinations of redundant rings with classical Ethernet
star topologies – at the price of special nodes.
Industrial Ethernet Technologies
Page 49
© EtherCAT Technology Group
EtherNet/IP distinguishes CIP and TCP Connections. A CIP connection transfers data from an
application running on one end-node to an application running on another end-node. A CIP connection is
established over a TCP connection. A single TCP connection can support multiple CIP connections.
Most Rockwell EtherNet/IP devices support up to 64 TCP connections, the number of CIP connections
differs from device to device (e.g. 1756-ENBT: 128 CIP connections, 1756-EN2T and later: 256 CIP
connections). All Rockwell scanners support a maximum of 32 multicast tags (producer/consumer I/O
connections).
For communication with an I/O device, typically more than one CIP connection is used (e.g. one for
implicit messaging, one for explicit messaging).
The Rockwell Automation (RA) publication “Ethernet Design Considerations” (ENET-RM002A-EN-P,
July 2011) shows the complex process of how to predict the network performance. There is also an
“EtherNet/IP Capacity Tool“ available.
Rockwell also recommends to add scanner cards to the controller and divide the scanning function
between the cards if the throughput is not sufficient.
The Packet Rate Capacity (packets/second) of most Rockwell EtherNet/IP scanners is 5000 Frames/sec
– with the exception of the ControlLogix series, where Rockwell is constantly increasing the scanner card
performance. As of August 2011, the latest generation (firmware >3.6) scanners support up to 25.000
frames/second (see Table 9 of Rockwell Automation Publication ENET-RM002A-EN-P, July 2011). With
these new high end scanners (1756-EN2xx, 1756-EN3xx) the right hand column of the cycle time table
applies – and it is obvious that the system real time performance remains comparatively poor.
The standard ControlLogix Ethernet IP Bridge (1756-ENBT) still supports 5000 Frames/sec. The release
notes (Publication 1756-RN591Q-EN-P - January 2008) of this device contain the following passage:
Performance Considerations: In general, the 1756-ENBT module is capable of supporting 5,000
packets/seconds. However, it is possible in some applications, depending on the combination of
connection count, RPI settings, and communication formats, that the product may be able to achieve
only 4,000 packets/seconds.
See also: Rockwell Automation (RA) publication “EtherNet/IP Performance” (ENET-AP001D-EN-P,
released October 2004, according to RA website still valid in Aug 2011)
Industrial Ethernet Technologies
Page 50
© EtherCAT Technology Group
16 Axes: 8ms update rate, I/O update rate: 20ms, all this at 80% bus load
(and 100MBit/s). And this with a star topology, which is favorable for
EtherNet/IP.
Data from August 2012.
A properly configured DeviceNet system should achieve better
performance (@ 500 kbit/s).
Industrial Ethernet Technologies
Page 51
© EtherCAT Technology Group
CIP sync was introduced to improve the real time behavior of the system.
The marketing message given by ODVA tries to tell that by adding
synchronization the real time capability is achieved – but time
synchronization does not improve cycle time, throughout or performance.
CIP sync was announced in April 2003, and included in Version 3.0 of the
CIP spec in May 2006.
First CIP sync products from Rockwell Automation are the sequence of
events (SOE) data capture modules that support timestamps. The version
with CIP sync support is shipping since mid of 2009.
Industrial Ethernet Technologies
Page 52
© EtherCAT Technology Group
IEEE 1588, officially entitled "Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems" , is a technology for
time synchronization that is or will be used by a variety of systems: EtherNet/IP,
PROFINET, Powerlink,... EtherCAT also supports gateways to IEEE 1588 systems
for external time synchronization.
The first version of IEEE1588 was published in November 2002. Version 2 (IEEE
1588-2008) followed in March 2008 and added various features, including the layer
2 transport option (embedded in the Ethernet frame without UPD/IP) and the
“transparent clock” approach which improves the accuracy for linear systems (line
topology) since it eliminates cascaded clocks.
V2 of the standard is not directly interoperable with V1.
IEEE supports an annual international symposium on 1588 technology. In
conjunction with this symposium a plug fests for improving interoperability is held.
Industrial Ethernet Technologies
Page 53
© EtherCAT Technology Group
In general the stack processing times limit the accuracy in case of pure
software implementations. For good results hardware with built in
IEEE1588 timestamp support has to be used – and the corresponding
switches. First silicon was introduced by Intel and Hyperstone, meanwhile
National Semiconductor, Freescale, Zarlink and others provide
processors, MACs and PHYs with such features. FPGA-IP with IEEE1588
timestamp functionality is also available.
Industrial Ethernet Technologies
Page 54
© EtherCAT Technology Group
In order to make the time synchronization independent from software
jitters and stack performance, at least the time stamp functionality had to
be implemented in hardware (directly in or at the Ethernet MAC).
This turns the class A approach “EtherNet/IP” into the class C approach
“EtherNet/IP with CIP Sync”, even though silicon with direct timestamp
support may be considered COTS technology at some stage.
Industrial Ethernet Technologies
Page 55
© EtherCAT Technology Group
Even though it is more and more used for I/O communication as well, the
nature of EtherNet/IP clearly shows that this technology is aimed at the
controller to controller level. The synchronization capabilities of CIP Sync
are suitable for synchronizing motion controllers, but the communication
performance is not sufficient for closed loop servo drive communication.
Industrial Ethernet Technologies
Page 56
© EtherCAT Technology Group
Beginning of 2006, ODVA announced an initiative to enhance the CIP
protocols by CIP Motion for motion control over EtherNet/IP.
ODVA acknowledges that three main ingredients are required:
Synchronization services: for this purpose IEEE1588 time synchronization (CIP
Sync) will be employed
Timely Data Transfer: The goal is to use standard Mechanisms to ensure this:
- Full-Duplex 100-BaseT or 100BaseF “Fast” Ethernet.
- Ethernet switches to eliminate collisions.
- QoS frame prioritization to eliminate queuing delays
Motion Control Device Profiles: have been added in V3 of the CIP spec.
The goal is to achieve high-performance motion control over standard, unmodified,
Ethernet.
Even though ODVA aims to achieve timely data transfer in the sub-millisecond cycle
time range, this is in total contradiction to the “real life” EtherNet/IP performance. It
may be possible to achieve sufficient results in very small, isolated and well
engineered networks with carefully selected components. But real life applications
will almost certainly be limited to open loop motion control with the trajectory
generator in the drive – which is also possible with legacy fieldbus systems like
DeviceNet. Whilst the CIP Motion Device Profile is mapped to EtherNet/IP only (and
not to DeviceNet, ControlNet), most parameters and mechanisms of the profile
clearly have been included to compensate for lack of short cycle times: they describe
local trajectory generation. Compared to other drive profiles of IEC 61800-7, the
profile is therefore rather complex.
Introducing CIP Motion products implies that Rockwell – a Sercos vendor in the past
– has turned down Sercos-III and tries to push an own motion bus approach.
Industrial Ethernet Technologies
Page 57
© EtherCAT Technology Group
It is interesting that ODVA now recommends to use an FPGA for implementing the
protocol: at the 2007 ODVA general assembly the presentation “Why CIP Motion,
Why Now?” claimed that CIP Motion – unlike its competitors – was using “COTS
Ethernet hardware, no proprietary ASICs or processors”.
First CIP Motion products were previewed at the Rockwell Automation Fair in
November 2009 and became available in 2010. In September 2010, RA published a
comprehensive CIP Motion Reference Manual (286 pages) and a CIP Motion
Configuration and Startup user manual (298 pages).
See also:
http://www.odva.org/Portals/0/Library/CIPConf_AGM2009/2009_CIP_Networks_Conference_Technical_Track_CIP_
Motion_Implementation.pdf
Industrial Ethernet Technologies
Page 58
© EtherCAT Technology Group
The guideline (ENET-TD001D-EN-P) can be found here:
http://literature.rockwellautomation.com/idc/groups/literature/documents/td
/enet-td001_-en-p.pdf
Or here:
http://www.cisco.com/en/US/docs/solutions/Verticals/CPwE/CPwE_DIG.p
df
Industrial Ethernet Technologies
Page 59
© EtherCAT Technology Group
As of February 2014, about 15 years after publication of the spec, the
adoption rate is not really convincing – especially outside of the
Rockwell/Allen Bradley world.
Industrial Ethernet Technologies
Page 60
© EtherCAT Technology Group
A quote from a Rockwell employee: if you need more performance, use
Controlnet...
Industrial Ethernet Technologies
Page 61
© EtherCAT Technology Group
CC-Link is an RS485 based fieldbus technology introduced by Mitsubishi Electric
in 1997. In 2000, the CC-Link Partner Association (CLPA) was founded, and since
then CC-Link is promoted as an open technology. CC-Link is intended for I/O type
communication – not for motion control (for this purpose Mitsubishi developed
SSCNET).
CC-Link LT is the CLPA technology focusing on simplified wiring and intended for
simple I/O devices; it competes with Componet and AS-Interface.
CC-Link Safety is the CLPA network for functional safety. Unlike other functional
safety protocols, CC-Link Safety is not making use of the “black-channelapproach” but requires a separate network: CC-Link Safety cannot be transported
via CC-Link or CC-Link LT.
CC-Link IE is the Industrial Ethernet technology of CLPA.
There are two main versions:
1. CC-Link IE Control (also named CC-Link IE Controller) is intended for
controller/controller communication.
2. CC-Link IE Field was originally intended for I/O type communication (similar to
CC-Link). In Nov 2011 a Motion Control Profile was added.
Furthermore, since April 2011 there is also a Functional Safety Protocol for
integration into CC-Link IE Field.
Industrial Ethernet Technologies
Page 62
© EtherCAT Technology Group
Token Passing Approach:
A CC-Link IE network consists of a single control station and multiple
slave stations. As in standard token passing networks, the control station
manages the network and starts the token passing sequence by sending
the token to the first slave station on the network.
The slave station that receives the token performs its cyclic transmission,
and then passes the token to the next station in the sequence.
After the last slave station completes the process, it passes the token
back to the CC-Link IE control station where the entire sequence is started
again.
A general problem of Token Passing is the error recovery: if the token
frame is lost for any reason, the entire token passing system has to be
reconfigured – of course the real time behavior is then gone temporarily.
Industrial Ethernet Technologies
Page 63
© EtherCAT Technology Group
The CC-Link IE Control frame is directly embedded in the Ethernet frame.
In addition to the MAC address there is a node number and a network (in
the CC-Link IE Header), which are primarily used for addressing.
Unfortunately the CLPA CC-Link IE Control specification does not cover
the transport layer and the network layer, protocol details are not
published.
According to an article published by CLPA Europe (IEB Issue 49, November 2008),
“TCP/IP communications is supported by way of the transient/acyclic communication
function.” However, the specs do not mention this option – it seems that the authors
refer to the SLMP over TCP/IP option (see below).
Industrial Ethernet Technologies
Page 64
© EtherCAT Technology Group
Unlike most other Industrial Ethernet technologies, which use a standard
Ethernet network (which is in place in many factory automation
environments already), CC-Link IE Control needs a dedicated and
separate network of its own.
Only ring topology is supported – switches cannot (and may not) be used.
CC-Link IE Control products may limit the max. no of nodes. Example: as
of 2/2014, the Mitsubishi CC-Link IE Control Interface supports 120 nodes
only in conjunction with a specific PLC. With other controllers, 64 nodes
are supported.
Industrial Ethernet Technologies
Page 65
© EtherCAT Technology Group
The information about the special ASIC is difficult to find: neither the CC-Link IE website, nor the
brochures nor the spec provide any information about this fact. Also, detailed information regarding
the CC-Link IE Control chip – which is NOT the same as the CC-Link IE Field chip CP220 - itself is
not available.
„Lean“ Specification
(as of February 2014, CLPA distributes the first version of the spec, dated Dec 2007):
• Device Profile Spec:
1 page
• Implementation Rules Spec:
3 pages
• Application Layer Service Definition:
41 pages
• Application Layer Protocol Definition:
115 pages (+ 10 pages description of ‘Transmission Point
Extended Mode’ added in Oct 2010)
• Communication Profile Specification:
2 pages
The application layer specs are relatively comprehensive as they have been prepared for inclusion in
IEC61158 – CC-Link IE is type 23. Publication of the edition of this standard containing CC-Link IE is
expected for April 2014.
Data link layer/transport layer/network layer with key features such as boot-up, network management
and error control are not specified. The Implementation Rules Spec, the Device Profile Spec and the
Communication Profile Specs are not sufficient for implementing the technology, the chip seems not
to be available outside Mitsubishi.
The “CC-Link Product Development Guidebook“, 12/2013 of CLPA Europe includes CC-Link IE
Control, but does not mention the corresponding chip. The only implementation possibility listed in
this brochure is a Mitsubishi PC board, for which software drivers are mentioned. So it remains
impossible for a PLC vendor to implement CC-Link Control.
Thus the conclusion is that, six years after the introduction of CC-Link IE Control as open network
technology, the implementation of CC-Link IE Control is not encouraged – if not impossible – for
third parties, at least not outside Japan.
CC-Link IE Control thus cannot be considered an open technology.
Industrial Ethernet Technologies
Page 66
© EtherCAT Technology Group
Due to using Gigabit Ethernet physical layer, CC-Link IE Control cycle
time is hardly influenced by the amount of data exchanged. In contrast,
due to its functional principle, EtherCAT is hardly influenced by the
number of nodes – and is much faster anyhow, in spite of using 100Mbit
technology.
In order to have a fair comparison, the dedicated and separated CC-Link
IE Control network was compared with a dedicated and separated
EtherCAT (Device Protocol) network, which can also be used for
controller/controller communication. However, in many cases the
EtherCAT Automation Protocol (EAP) will be used for that purpose, since
EAP can be transmitted via an already existing Ethernet backbone (which
is of course not limited to 100Mbit/s). Since EAP is making use of
standard Ethernet switch technology, the EtherCAT cycle times listed
above are not achieved with the EAP option, though.
The Link Scan Time (=Cycle Time) formula used was taken from Chapter 7.1 (Link
Scan Time) of the “MELSEC Q series CC-Link IE Controller Network Reference
Manual” SH(NA)-080668ENG-I of May 2012 (as of Feb 2014, this is the latest
version available). We used formula (1) with LY=0, T=2 (default value) and the Line
Control Time Nc (Time required for reconfiguring the data link when network is
disconnected and reconnected) =0. Usual values for Nc given in that manual are
50ms (Normal) and 100ms (Worst). For error case considerations this time has to be
added. For Cyclic Transmission Delay Time the Link Refresh Times have to be
taken into account as well.
Industrial Ethernet Technologies
Page 67
© EtherCAT Technology Group
CC-Link IE Field is the adaptation of CC-Link IE Control to the field level.
The functional principle – token passing - is shared by both variants. CCLink IE Field uses copper based Gigabit Ethernet, and supports non-ring
topologies such as star and line.
120 Slave stations: the specification allows for up to 253 slave devices;
however, as of Feb 2014 implementations only support 120 slave devices.
Industrial Ethernet Technologies
Page 68
© EtherCAT Technology Group
CC-Link IE Field uses Ethernet frames according to IEEE 803.2 and the
Ethertype 0x890F.
As of February 2014, the CC-Link IE Field Data Link Layer specification
contains no further information than this. The format of the transmission
control frame, of the transient transmission control frame and the cyclic
transmission control frame are not published.
Industrial Ethernet Technologies
Page 69
© EtherCAT Technology Group
The CC-Link IE Field specification describes the phases in general and
also shows the sequence of frames that are exchanged – but it does not
contain the frame formats itself.
Industrial Ethernet Technologies
Page 70
© EtherCAT Technology Group
After receiving the token, the slave device first sends its status frame,
then one or more cyclic transmission frames, optionally followed by acyclic
frames (for the so called transient communication). The number of acyclic
frames per node and cycle can be limited in order to avoid cycle time
violations. Lastly, the node sends the Token Frame to the next token
holder.
All Frames are broadcasted: nodes with two ports send all frames to both
ports, and switches are used like hubs (making use of broadcast MAC
addresses).
CC-Link IE distinguishes different node types, which differ by maximum
process data size as well as features such as support of acyclic
communication:
e.g.:
• “Remote Device Stations” are limited to 128 bits of cyclic I/O data (+
register data) and do not support client functionality in acyclic
communication.
• “Remote I/O stations” are limited to 64 bits of cyclic I/O data (no register
data) and do not support acyclic communication at all.
Industrial Ethernet Technologies
Page 71
© EtherCAT Technology Group
The topology of CC-Link IE Field is more flexible than the CC-Link IE
Control topology. 120 nodes: spec allows for up to 254, but as of Feb
2014 we could not find any products supporting more than 120 nodes.
Industrial Ethernet Technologies
Page 72
© EtherCAT Technology Group
According to Mitsubishi Electric Germany in Feb 2014, the CC-Link IE Field chip
CP220 is not (yet) available in Europe.
“Lean” Specification
(as of Feb 2014, the latest version is BAP 1605 of Nov 2011):
• Device Profile Spec:
23 pages
• Implementation Rules Spec:
8 pages
• Data Link Layer Spec:
2 lines (not pages)
• Application Layer Service Definition:
69 pages
• Application Layer Protocol Definition:
197 pages
The application layer specs are relatively comprehensive as they have been
prepared for inclusion in IEC61158 – CC-Link IE is going to be type 23. Publication
of the edition of this standard containing CC-Link IE is expected for 4 / 2014.
While it looks feasible meanwhile to implement a slave device, it looks as if the
master device cannot be implemented by third parties as of now: there is no
information about the Data Link Layer and there are no chips supporting a master.
Industrial Ethernet Technologies
Page 73
© EtherCAT Technology Group
By introducing SLMP, CLPA aims to install a common protocol layer and
thus a “cross-media” communication option for all CC-Link technologies.
This can be seen as the attempt to provide an approach similar to CIP
(ODVA) – however, SLMP does not contain device profiles. Thus, it may
provide a common “how to communicate” protocol, but lacks a “what to
communicate” definition.
Industrial Ethernet Technologies
Page 74
© EtherCAT Technology Group
CLPA suggests to use the SLMP via TCP/IP approach for devices such as
RFID controllers, HMI, Barcode readers or Vision Sensors. Of course this
approach is non-real time.
To make this very clear: According to the available specifications, CC-Link
IE Field cannot transport other Ethernet traffic such as TCP/IP. The SLMP
via TCP/IP approach simply means that the SLMP protocol of CC-Link IE
can also be transported via TCP/IP, and Ethernet TCP/IP devices also
supporting the SLMP protocol can exchange information with a CC-Link IE
network via a gateway.
Industrial Ethernet Technologies
Page 75
© EtherCAT Technology Group
The Mitsubishi CC-Link IE Field Master supports two modes: Normal Mode – which
is the default - performs both cyclic and acyclic (transient) transmission without
losing their inherent speed performance, while High Speed Mode preferentially
performs cyclic transmission for high-speed communications and reduces
processing speed for transient transmissions. In High Speed Mode the maximum
data size for register communication is reduced.
Similar to CC-Link IE Control, the cycle time of CC-Link IE Field is hardly influenced
by the amount of data exchanged. In contrast, due to its functional principle,
EtherCAT is hardly influenced by the number of nodes – and is much faster
anyhow, in spite of using 100Mbit technology.
The Link Scan Time (=Cycle Time) formula used was taken from Appendix 5.2 (Link Scan
Time) of the “MELSEC Q CC-Link IE Field Network Master/Local Module User’s Manual”
SH(NA)-080917ENG-H of July 2012, found in Feb 2014 on www.meau.com (Mitsubishi
Electric Automation Inc, USA). CC-Link IE manuals are not available on the European
website of Mitsubishi Electric – their CC-Link IE products are not offered in Europe.
We used the link scan time formula with Ka=25,8 (Normal Mode)|18,5 (High Speed),
Kb=655 (NM)|168(HS), Kc=160+60*(no_of_nodes_with_acyclic_comm)(NM)|80(HS), Ni=0
and Kd (Maximum data link processing time when the station is disconnected from or
returned to the network) =0. Using recommended values for Kd leads to additional ~20ms
cycle time. For error case considerations this time has to be added. For Cyclic
Transmission Delay Time the Link Refresh Times have to be taken into account as well.
Industrial Ethernet Technologies
The adoption rate is exceptional.
Page 76
© EtherCAT Technology Group
Industrial Ethernet Technologies
Page 77
© EtherCAT Technology Group
Seems difficult to find a convincing reason why an automation vendor
should adopt any CC-Link IE variant – it will be challenging to position CCLink IE as an alternative to existing Industrial Ethernet Technologies.
Industrial Ethernet Technologies
Page 78
© EtherCAT Technology Group
The list of features of SERCOS-III reads like the list of features of
EtherCAT – except the last three items.
Industrial Ethernet Technologies
Page 79
© EtherCAT Technology Group
SERCOS-III has adopted the EtherCAT functional principle: processing Ethernet
frames on the fly. There are some main differences, though:
1. SERCOS-III separates input and output data in two frames – so there are at minimum
two frames per cycle
2. The slaves process the data twice: on the way out and on the way back
3. Very rigid frame layout – no changes at runtime, no bit-wise mapping.
4. Non Realtime Data (such as TCP/IP) is inserted in gaps between the frames.
These differences have the following impact – compared with EtherCAT:
1. Bandwidth utilization is lower. Dual processing in the slave devices. Therefore in
average 2-3 times slower than EtherCAT.
2. Separating input and output data and processing twice allows for topology independent
slave-to-slave communication within the same cycle. For topology independent slaveto-slave communication, EtherCAT has to relay the data through the master
(performance implementation dependent, can also be done with 2nd frame within in
the same cycle). However, since Servos III overall cycle time is higher, slave-to-slave
performance is not better than with EtherCAT.
3. Due to the „processing twice“ principle, only line topology (+ ring for redundancy) are
possible: no drop lines, tree configuration etc.
4. No flexibility in process data communication: same update rate for all nodes and data.
5. If the IP gap is shorter than the maximum Ethernet frame length (< 122 µs), the MTU
(Ethernet Maximum Transmission Unit) has to be adapted accordingly: the device
interfacing Ethernet to Sercos III has to handle the fragmentation, similar to an
EtherCAT switchport.
Industrial Ethernet Technologies
Page 80
© EtherCAT Technology Group
SERCOS-III originally supported line and ring topology, only.
Ring structure: Recovery time in case of cable failure < 25µs.
Industrial Ethernet Technologies
Page 81
© EtherCAT Technology Group
In November 2012 the so called TopoExtension Module was announced. It
allows one to extend the ring topology using one cable instead of two. In
theory, the same functionality could be included into a slave device as
well.
Industrial Ethernet Technologies
Page 82
© EtherCAT Technology Group
The TopoExtension Module combines two Ethernet lines into one (+
optional power).
At first glance it looks as if the TopoExtension adds drop line and tree
topology support to Sercos-III; however, this is not really the case, since
standard Sercos-III devices cannot be directly connected to the
TopoExtension cable.
So one can replace two standard cables with two TopoExtension modules
and a special cable (RJ50).
Conclusion: the main advantage/purpose of the Sercos TopoExtension is
the ability to actively switch off a sub-ring.
Therefore we think it is appropriate to maintain the following statement:
Sercos-III supports line and ring topology.
Industrial Ethernet Technologies
Page 83
© EtherCAT Technology Group
IP data is inserted in a gap (originally named IP channel, now called
Unified Communication Channel UCC).The gap can either be after the
input and output frames (method 1) or in between (method 2). Typically
method 1 is used.
Industrial Ethernet Technologies
Page 84
© EtherCAT Technology Group
Once in real time mode, Sercos-III uses the same frame structure in every
cycle. Therefore there is no flexibility in process data communication: each
node and each process data part is updated at the same rate.
It is thus not possible to e.g. cyclically read a status bit of a device and
request data only if this status bit indicates new data.
Furthermore, since the process data length per node is fixed to either 2,4
or 8 bytes (+ 4 bytes status per device), this approach is not ideal for
devices with very small process data images (like digital I/O).
Industrial Ethernet Technologies
Page 85
© EtherCAT Technology Group
Just like with SERCOS-II, synchronization in SERCOS-III is based on
cyclic, deterministic and jitter-free communication. This requires special
hardware support in the master: a special dedicated SERCOS master
card.
IEEE1588 support may be added later, but will as well need hw support for
accuracy.
Industrial Ethernet Technologies
Page 86
© EtherCAT Technology Group
In April 2007, Sercos International announced the development of a
Sercos-III “Soft-Master”, implementing the master functionality using
software (+ a standard Ethernet Port). According to the press release
(quote), ”The achievable synchronization accuracy of a SERCOS III realtime network using a soft master is depending on the performance of the
hardware and the characteristic of the used operating system”.
Sercos International:
• special hardware support for 1µs jitter
• soft master for up to 50µs jitter
Industrial Ethernet Technologies
Page 87
© EtherCAT Technology Group
SERCOS-III Controllers are either FPGA based, or the Hilscher netX chip
family can be used, which also supports EtherCAT + PROFINET.
Furthermore, the TI Sitara Chip Family can also be equipped with a
Sercos-III Slave Core.
In order to push the adoption of the SERCOS I/O profile (which was
published in Nov 2006), Sercos launched Easy-I/O in April 2007), a free IP
Core for the Xilinx Spartan-3 XC3S250E FPGA. This code is limited to 64
Byte I/O data, and targeted at encoders, measuring sensors, valve
clusters, 24V digital I/O and analog I/O. It is not suitable for Sercos-III
drive implementation.
For Sercos International (SI) members, a commercial IP core for SercosIII is available for a one time fee. For non members of Sercos International
an annual license fee for this IP core applies. Alternatively, run-time
licenses are available (non members pay double runtime fees).
In April 2009, Sercos International announced to publish a Sercos-III
master API under GPL license. The API only supports the SERCON100M
Master IP Core (no generic Ethernet MAC).
Industrial Ethernet Technologies
Page 88
© EtherCAT Technology Group
This performance data is taken from the Sercos-III brochure published by
Sercos International, Edition 1/2014. At cycle times below 250µs the IP
channel is shorter than a maximum frame length, and thus IP traffic is
fragmented: MTU (Ethernet Maximum Transmission Unit) has to be
adapted accordingly by the gateway.
This MTU adaptation is not supported by the Ethernet/Sercos-III gateways
as of Feb 2014.
Industrial Ethernet Technologies
Page 89
© EtherCAT Technology Group
Comparing SERCOS-III and EtherCAT performance: at given cycle times
and amount of data per slave, the maximum number of nodes is given for
both technologies.
Please note that as of Feb 2014, we could not find a gateway supporting
the shortened IP channel (which would lead to the values marked in
green)
Industrial Ethernet Technologies
Page 90
© EtherCAT Technology Group
Another view for the comparison: now the number of nodes and the
amount of data per slave is fixed, and the resulting cycle time is
compared.
Industrial Ethernet Technologies
Page 91
© EtherCAT Technology Group
A graphical view for the previous table.
In average (over 9 different application scenarios), EtherCAT is 2,7 times
faster.
Industrial Ethernet Technologies
Page 92
© EtherCAT Technology Group
Sercos-III implementations either follow the “store and forward” approach
for the switch (NRT) mode, which in case of Sercos-III means that the
NRT frame is only forwarded in the next cycle, or the follow the “cut
through” methodology, which means that they forward the frame only
within the same cycle if after the analysis of the destination address the
remaining IP-Slot is able to carry the maximum frame length.
It will be interesting to see how the IP communication over a large number
of cascaded switches behaves.
Industrial Ethernet Technologies
Page 93
© EtherCAT Technology Group
In order to allow for IP access to slave devices at run-time, either routing
through the master or a special gateway device have to be used.
This is the same if IP access (e.g. for remote diagnosis) shall be
supported without the need to physically connect the link first.
If an unused port is available, this can be used alternatively. Since SercosIII Devices have two ports, in line topology there is one unused port at the
last node in the line (no unused port in ring topology)
Industrial Ethernet Technologies
Page 94
© EtherCAT Technology Group
In each RT cycle, the slave controllers switch between “processing on the
fly-mode” for process data and “switch-mode” for IP data.
The forwarding behavior of IP frames in the IP slot depends on the slave
device capabilities and on the network configuration
Industrial Ethernet Technologies
Page 95
© EtherCAT Technology Group
Most current Sercos-III implementations support Store and Forward,
which means that within one Sercos-III cycle an IP frame moves from
node n to node n+1, if frame sending takes longer than half of the UCC
phase.
Industrial Ethernet Technologies
Page 96
© EtherCAT Technology Group
If Cut-Through behavior in NRT mode is supported, an IP frame can move
several nodes before it is stored for the next cycle. However, if the IP slot
is shorter than 125µs, the only Cut-Through Sercos-III slave controller
(SERCON FPGA) buffers the frame for the next cycle.
Industrial Ethernet Technologies
Page 97
© EtherCAT Technology Group
If UCC phase is long enough (>>125µs) and cut-through is supported
throughout, the performance of the IP communication looks sufficient.
Industrial Ethernet Technologies
Page 98
© EtherCAT Technology Group
If UCC phase is short IP communication performance may deteriorate
substantially – especially in larger networks.
This can be avoided by smart configuration tools, which take the node
behavior and network size into account and adjust the IP slot time
accordingly.
It is obvious, though, that the IP handling mechanism of SERCOS III
works best in small networks.
Industrial Ethernet Technologies
Page 99
© EtherCAT Technology Group
In February 2011 Bosch Rexroth became a “Principal Member” of ODVA.
It is understood that the goal of this move was to get better access to the
US market, especially to market segments dominated by Rockwell
Automation. So Bosch Rexroth followed the example of Schneider Electric
from 2007, even though it seems not to have really worked out for
Schneider. Whereas many had expected that the Bosch Rexroth move
towards ODVA would pave the way for ODVA accepting Sercos-III as
official motion network, this did not happen. Unlike for Modbus TCP, for
which an integration into the ODVA architecture was build after Schneider
Electric became a principal member, similar activities were not started for
Sercos-III.
However, Sercos International had to integrate EtherNet/IP instead, which
raised some eyebrows: one of the fastest motion control bus systems
adopts the slowest available Industrial Ethernet technology for I/O
integration. This can also be seen as the confession of failure for SercosIII as general automation bus. If Sercos-III would have been successful in
integrating generic I/O, sensors and other non-motion control
components, why promote EtherNet/IP as the solution for such devices?
As of Feb 2014, no master product with dual stack capabilities can be
found in the Sercos Product Guide.
Industrial Ethernet Technologies
Page 100
© EtherCAT Technology Group
Whilst the SERCOS technology has a good reputation for servo drive
control, similar reputation as general bus system I/O, sensors, or other
devices has not been achieved.
With only very few exceptions, all drive and I/O products supporting Sercos-III als also
available with EtherCAT interface, since EtherCAT can be implemented on the same
FPGAs that are used for Sercos-III.
Industrial Ethernet Technologies
Page 101
© EtherCAT Technology Group
SERCOS-III achieves a performance comparable with PROFINET IRT –
and thus sufficient for most applications.
Whilst the SERCOS technology has a good reputation for servo drive
control, SERCOS-III has not been able to establish itself as generic
automation bus with seamless integration of I/O, sensors and other
devices.
Industrial Ethernet Technologies
Page 102
© EtherCAT Technology Group
Powerlink replaces the Ethernet CSMA/CD Media Access Control Method
by Polling: The master (called managing node) sends a poll request to
each slave (called controlled node) which then answers with a response.
Hubs (no switches): the Powerlink Spec states: „To fit EPL jitter
requirements it is recommended to use hubs“*.
Protected real time mode: Since the Powerlink topology (up to 10 nodes in
line configuration) violates IEEE802.3 roundtrip delay rules, CSMA/CD
does not work in this configuration – so a network designed for protected
mode cannot be accessed with standard Ethernet interfaces (not even in
non-realtime mode).
* In theory switches can be used, but due to the additional latency the network
performance would be unacceptable. All performance calculations in the Powerlink spec
assume a Hub Delay Time of 500ns – „store and forward“-switches have a delay time of
>10µs (for short frames), „cut through“-switches have a delay time of ~5µs. If hubs were
replaced by switches with 10µs delay, the cycle time of example 4 in the Powerlink Spec
would be increased from 2,34 ms to 19,44 ms.
In September 2005, EPSG announced that Micrels new 3-Port switch chip is endorsed for
Ethernet Powerlink implementations. However, in Powerlink applications this switch chip
is operated in half duplex repeater mode, only. Thus it is a switch chip that supports a hub
mode, too.
Industrial Ethernet Technologies
Page 103
© EtherCAT Technology Group
Powerlink Marketing calls the Media Access Method „Time Slicing“ or „Slot
Communication Network Management“. The principle nevertheless is
polling – the controlled device only „speaks“ after it was „asked“.
Due to the broadcast nature of hubs, all nodes receive all frames.
Therefore the nodes have to filter each frame.
The broadcast mechanism can be used for slave to slave communication
(consumer/producer principle). However, performance of slave to slave
communication cannot be better than the cycle time...
The accumulation of the hub delays limits the number of nodes in a line
topology.
Industrial Ethernet Technologies
Page 104
© EtherCAT Technology Group
The timing (and thus the performance) of a Powerlink network is mainly
determined by the topology and the node response times: each poll
request first has to get from the master through all hubs (both the external
ones and the integrated ones in a daisy chain or line topology) to the
destination node, then the node has to process the request, send the
response, which then again goes through all hubs back to the master.
Only after the master has received the response, he can issue the next
poll request.
At the end of the cycle there is the asynchronous phase.
Industrial Ethernet Technologies
Page 105
© EtherCAT Technology Group
The PollResponse Chaining mode increases the performance of
Powerlink but also increases the complexity and vulnerability. Boot-up and
error handling become complex since collisions are not avoided by the
polling mechanism any more. If a device responds just slightly too late
collisions happen and the system becomes instable.
In previous versions of Powerlink the topology already had a substantial
influence on the network performance. With PollResponse Chaining not
only the topology, but also the sequence of node addresses influences the
network performance: the timing depends not only on the sum of the
propagation delays between master and slave devices, but also on the
propagation delays of the subsequent node addresses. Overall, it
becomes even more difficult to predict the performance of Powerlink for
any given scenario.
PollResponse Chaining requires implementation of master and slave
controller in Hardware (FPGA or netX)
The PollResponse Chaining Specification can be downloaded from the
EPSG website. In particular the very “lean” error handling sections leave
lots of implementation freedom, which is probably not such an issue since
there are no non-B&R masters supporting this version.
Industrial Ethernet Technologies
Page 106
© EtherCAT Technology Group
Furthermore, the cycle time setting must provide sufficient leeway for accumulated response jitter
of all nodes and for repeating corrupt messages.
EPSG announced several times (also in the V2.0 spec of 2006) that precise synchronization
using IEEE1588 time precision protocol will be added in Version 3.0.
However, in order to downplay the Powerlink versioning issue V2.0 of the specification was later
renamed in DS301 V 1.0. In Feb 2014 the 2008 version (Ds301 V1.01) of the spec is still valid,
which contains no such synchronization.
Industrial Ethernet Technologies
Page 107
© EtherCAT Technology Group
This performance example is taken from the Powerlink V 2.0 specification, Version 0.1.0. In this
version of the spec, the
- slave response time = 8µs; master response time = 1µs (!)
- TAsyncMax = 90µs; TStart = 45µs; THubDelay = 0,5µs
and the resulting Cycle Time is 291 µs.
In Powerlink V 2.0 specification Version 1.0.0, this performance example is not available any more.
However, the performance examples in this version assume
- slave response time = 1µs (!); master response time = 1µs (!)
- TAsyncMax = 120+32 (=152)µs + maximum signal propagation; TStart = 26µs; THubDelay = 0,5µs
Applying these values to the performance example shown above leads to a Cycle Time of 281 µs.
The Powerlink DS 301 V1.01 specification (which is the current one as of Feb 2014) does not
contain any performance example any more.
However, the Powerlink Spec does not demand any specific slave response time, and manuals or
data sheets of Powerlink products typically do not provide that value. Meanwhile most B&R
Powerlink products are FPGA based and thus provide a short response time – since there are few
“non-B&R” Powerlink products, such a short response time may be assumed. However, we have
seen Powerlink drives in a multivendor motion control demonstrator (equipped with a network
analyzer tool) on an EPSG booth with a response time of 10..20µs.
Industrial Ethernet Technologies
Page 108
© EtherCAT Technology Group
This performance example is referenced in the EtherCAT introductory presentation, it is
taken from the Powerlink V 2.0 specification, Version 0.1.0.
In this version of the spec, the
- slave response time = 8µs; master response time = 1µs (!)
- TAsyncMax = 90µs; TStart = 45µs; THubDelay = 0,5µs
and the resulting Cycle Time is 2347 µs.
In Powerlink V 2.0 specification Version 1.0.0, this performance example is not available
any more. However, the performance examples in this version assume
- slave response time = 1µs (!); master response time = 1µs (!)
- TAsyncMax = 120+32 (=152)µs + maximum signal propagation; TStart = 26µs
- THubDelay = 0,5µs
Applying these values to the performance example shown above leads to a Cycle Time of
1767 µs.
The Powerlink DS 301 V1.01 specification (which is the current one) does not contain any
performance example any more.
EtherCAT cycle time for this setup would be 276µs if one waits for the frame to return
before the next one is sent out, or 125µs if one does not wait (unlike Powerlink, EtherCAT
is full-duplex)
Industrial Ethernet Technologies
Page 109
© EtherCAT Technology Group
This performance example assumes a slave response time of 1µs (!) and a master
response time of 1µs (!)
With EtherCAT the topology influence on the cycle time is negligible, the cycle time
for separate 53 nodes with the same amount of data is 149µs (@50% bus load).
Industrial Ethernet Technologies
Page 110
© EtherCAT Technology Group
This hardware block diagram was drawn by an EPSG member company
and shows the hardware effort for a Powerlink interface based on
standard chips. The discrete design of a Powerlink slave interface is not a
very cost efficient approach.
Industrial Ethernet Technologies
Page 111
© EtherCAT Technology Group
EPSG is now supporting different implementation possibilities – the most
cost effective is the FPGA solution. It uses the same Altera FPGA that is
used for EtherCAT as well, but requires additional 10ns 256k x 16 SRAM.
In November 2007, IXXAT, B&R + Lenze announced that the master
(managing node) is now also implemented in an FPGA.
The rationale is, according to a press statement*: “Until now on the control
side there were only solutions which had limited performance and which
were not suitable or too expensive for extremely demanding applications
such as highly dynamic motion systems, since very powerful CPUs are
used.”
* Translated from the Article “Master-FPGA für Powerlink”, Computer&Automation Magazine 12/2007, p.17
Industrial Ethernet Technologies
Page 112
© EtherCAT Technology Group
Powerlink Version 1 products are available from B&R only.
Powerlink Version 2: Lenze Drives (founding member of Ethernet
Powerlink Standardization Group and driving force behind V2) started
shipping first Powerlink Products End of 2006. Lenze has meanwhile
moved to EtherCAT as system bus (Powerlink may remain in use for
applications in which there is no controller, just networked drives)
Powerlink Version 3 (Gigabit Powerlink) was announced in November
2006. Lenze is not contributing to Powerlink V3, which seems to be B&R
driven. In 2009 B&R published an article describing the functional principle
(see next slides) and announced products for 2011. As of February 2014,
no Gigabit Powerlink specification has been published (neither within
EPSG nor externally), and the most recent publication mentioning Gigabit
Powerlink on the EPSG Website is from 2008.
In 2012 the Powerlink Version 4 (PollResponse Chaining) was published.
EPSG will not consider this a new version, but since the entire
communication mechanism is changed dramatically it should be
considered to be one.
Industrial Ethernet Technologies
Page 113
© EtherCAT Technology Group
In November 2006, EPSG announced Gbit Powerlink as a simple
hardware modification (Quote from Powerlink “Facts” 1/2007:
“POWERLINK users can easily boost network performance by a factor of
10. Changing the hardware platform to include 1 Gigabit hardware instead
of 100 Mbit components is all any developer must do, resulting only in a
somewhat different list of components to be fitted onto an otherwise
identical PCB.”)
However, this approach was later abandoned: Doing the math's shows
that the performance gain would have been minimal. Depending on the
configuration, a factor of 1.38…2 was to be expected, since most of the
Powerlink cycle time is made up by stack delays which are not influenced
by bandwidth increase. Furthermore, moving on to switches increases the
forwarding delay within the infrastructure substantially, which would have
over-compensated the bandwidth increase.
So in 2/2009 it was announced that Powerlink V3 will be based on a new
functional principle (see next slide).
Many device vendors postponed their Powerlink implementation plans
since V2 was already outdated in 2006/2007, and Gigabit Powerlink not
yet specified.
Industrial Ethernet Technologies
Page 114
© EtherCAT Technology Group
As with the change from Powerlink V1 to V2, the announced version V3 will change both
the protocol and the cyclic behavior of the network. Hence downwards compatibility
cannot be expected.
Hubs will be replaced by switches, and instead of individual polling a “burst polling”
approach will be introduced.
The “Start of Asynchronous” Frame will be abandoned, its functionality will be included in
the “Start of Protocol” (SoP) Frame, which replaces the “Start of Cycle” frame of Powerlink
V2. A node that wants to send an asynchronous frame informs the master by flagging this
in its poll response frame. With the next SoP frame the master then allows the node to
send such a frame. Other than with Powerlink V2, asynchronous frames are thus
postponed to the next cycle.
The “poll response” frames are going to be sent with broadcast MAC addresses –this
preserves the slave-to-slave communication but puts substantial load on all devices,
which have to filter all poll responses. Furthermore, this means that for half of the traffic
the switches sacrifice their routing capabilities and become “slower hubs”.
For synchronization with IEEE 1588, the sync frame of the 1588 protocol is included in the
SoP frame. All switches have to support the IEEE 1588 peer-to-peer, one-step transparent
clocks in hardware. Thus special switches are required.
The shortest cycle time is either determined by the sum of frames sent by the master, or
by the sum of frames sent by the slaves, or by response time and the overall propagation
delay of the farthest slave device (including the switch delays). It is thus still difficult to
predict and influenced by protocol stack performances, topology and the performance of
the infrastructure components.
Industrial Ethernet Technologies
Page 115
© EtherCAT Technology Group
According to a B&R customer presentation (July 2008), the R&D phase for
Powerlink V3 (Gigabit Powerlink) products is scheduled for 2009/2010,
and first products are planned for 2011. However, since the B&R
Powerlink Day in May 2011, Gigabit Powerlink was not even mentioned
any more.
So meanwhile many people assume that Gigabit Powerlink died before it
was really born….
By the way: the functional principle of Gigabit Powerlink was introduced in
2001 by Beckhoff („RT-Ethernet“ – a predecessor of EtherCAT)
Industrial Ethernet Technologies
Page 116
© EtherCAT Technology Group
Ethernet Powerlink Standardization Group is managed and hosted by an
advertising agency. Technical and implementation support is available by
the advertising agency and by technology providers, who charge for these
services.
Obviously membership figures of EPSG and ETG cannot be compared
directly: EPSG charges between 500€ and 5000€ per annum for
membership, while e.g. ETG has adopted the philosophy that charging for
access to a technology is not a sign of openness.
Therefore in small print: (Between 5/2006 and 11/2007, ETG grew from 315 to 634
members, exceeding 2600 members in Jan 2014).
The figures discussed above were taken from the EPSG publication
“Powerlink Facts”, which was published until 2010 and is available for
download from the EPSG website. Until end of 2007, there all members
were listed; the June 2008 and all later editions do not list members any
more.
Please note that EPSG typically uses the term “members, supporters and
users” when referring to membership levels, and accumulates those to
over 400* (as of 5/2007). As of 02/2014, the website lists 170 “members
and users”.
* The EPSG website e.g. lists Tetra Pak in the members and users list. According to a Tetra Pak R&D
manager, they used Powerlink in one R&D project which was later cancelled, never delivered a Powerlink
equipped system and also terminated their EPSG membership.
Industrial Ethernet Technologies
Page 117
© EtherCAT Technology Group
95 entries, out of which 32 are tools and services.
Third party (“non-B&R”) Powerlink products are typically complementary to
the B&R products – so for B&Rs own products there are few third party
alternatives available, if at all.
For many of the complementary products B&R either implemented the
Powerlink interface or paid for the implementation.
3 master vendors: besides B&R, the product guide lists Baldor Motion and
IXXAT. Baldor Motion was acquired by ABB in 2011, and ABBs motion
system bus is EtherCAT – it looks like Powerlink is being phased out (no
new Powerlink products since the acquisition, but several EtherCAT
products). For IXXAT, a PCI interface card and the “Econ 100” embedded
Controller are listed: as of Feb 2014, the IXXAT website advertises the
Econ 100 with EtherCAT, only: http://www.ixxat.com/embeddedcontroller_en.html.
Industrial Ethernet Technologies
Page 118
© EtherCAT Technology Group
The Wago Powerlink Bus Coupler was featured in the “product news”
section of the “Powerlink Facts” brochure 1/2006 (May 2006), 2/2006 (Nov
2006) and 1/2007 (April 2007).
For many of the few new Powerlink Products introduced since 2007, B&R
either implemented the Powerlink interface or paid for the implementation.
At SPS/IPC/Drives Show in November 2009, B&R introduced EtherCAT
products.
At SPS/IPC/Drives Show in November 2013, ABB/Baldors booth did not
show any Powerlink products any more.
http://www.eckelmann.de/nc/en/presse/latest/detail/date/2013/04/09/eexc-66-mit-ethercatR
http://www.baldormotion.com/pdf/ABB%20literature/16124%20Motion_control_brochure_3AUA000
0068580_RevD.pdf
Industrial Ethernet Technologies
Page 119
© EtherCAT Technology Group
• In 2004 IAONA asked EPSG to make available Powerlink Safety for
other Ethernet Technologies; this was turned down by EPSG.
• Also in 2004, innotec GmbH (a German Safety Consultancy company)
filed several patents regarding Powerlink Safety / openSAFETY. These
were granted in 2006.
It is unclear how a license is granted for the usage of the technology
• Since the BSD-licensed safety stack needs to be modified for
integration, the certification has to be started from scratch.
• E.g. CRC calculation routines are not part of the code
Industrial Ethernet Technologies
Page 120
© EtherCAT Technology Group
Statement# of Katherine Voss, Executive Director ODVA: “ODVA and Sercos
International are cooperating on the adaptation of CIP Safety to their respective industrial
Ethernet networks, EtherNet/IP and Sercos III. At this time, ODVA does not have a similar
cooperation arrangement with any other organization. … CIP Safety on EtherNet/IP is
the only network configuration for functional safety that is authorized by ODVA to run on
EtherNet/IP. “
Statement# of Peter Lutz, Managing Director Sercos International: “We were
surprised by the unauthorized usage of our registered Sercos trademark in publications
and displays on the Ethernet Powerlink Standardization Group (EPSG) booth at
Hannover fair. This might imply that the announced concept and the combination of
"openSafety" (Powerlink Safety) and Sercos III is approved and supported by Sercos
International. We would like to clearly state that no discussions have been held and that
no formal agreements are in place between SERCOS International (SI) and either EPSG
or B&R. … The introduction of an additional – incompatible – safety protocol is not
helpful as the complexity for manufacturers and users is significantly increased and the
acceptance is diminished to the same degree.”
In Nov 2010, EPSG announced an openSAFETY solution for PROFINET.
Technical limitations are described on the next slides.
#
Statements quoted from: Industrial Ethernet Book Issue 58
Industrial Ethernet Technologies
Page 121
© EtherCAT Technology Group
Powerlink Safety, as do most safety protocols, uses the “black channel
approach”, which means that the transporting communication channel
does not have to be included in the safety considerations. The “black
channel approach” is the pre-requisite for bus independence of the safety
technology.
However, with Powerlink Safety the black channel approach is only valid
within the constraints listed above which lead to a minimum safety
container of 31 Bytes.
For comparison: the minimum safety container of Safety over EtherCAT
(FSoE) is 6 bytes (for 1 Byte payload), thus FSoE is suitable e.g. for CAN
as well.
Industrial Ethernet Technologies
Page 122
© EtherCAT Technology Group
A Safety Input device often has only a few Bit of SafeData. For a safe light
curtain for example only 1 Bit SafeData can be sufficient.
Container length for 1 Bit SafeData
Powerlink Safety:
31 Bytes
Safety over EtherCAT:
6 Byte
Industrial Ethernet Technologies
Page 123
© EtherCAT Technology Group
Powerlink Safety requires a proven communication channel for safety
payload data 1..8, 26…254 Byte.
Bit Error Probability Pe ≤ 10-3 can be assumed for 100BASE-TX Ethernetbased Powerlink based communication,…
… but the Black channel may also consist of
- internal backbone communication,
- other physical layers for Ethernet,
- infrastructure devices like switches or gateway devices,
- Routing of safety containers via software within the standard
master or infrastructure devices (switches, router)
- …
With Powerlink Safety the user has to ensure that the „Grey“ Channel
does not exceed these limitations and in fact is a Black Channel.
For any other equipment in the system, next to the Powerlink
communication, this assumption has to be approved!
As of now we are not aware of any standard covering non-Powerlink
based openSafety.
Industrial Ethernet Technologies
Page 124
© EtherCAT Technology Group
The typical number of safety payload data per connection is small, e.g. in
the range of 1...4 Bytes.
With 2 Byte of SafeData for example
- a 16 channel Safety Input device can be handled or
- 16 different drive integrated safety functions can be activated
Industrial Ethernet Technologies
Page 125
© EtherCAT Technology Group
Incompatible changes for openSAFETY have been introduced for the next
edition of IEC 61784-3-13.
Industrial Ethernet Technologies
Page 126
© EtherCAT Technology Group
Multicast messaging increases the complexity of device implementation and of
configuration effort.
Time synchronization in Powerlink Safety:
In order to avoid a delay of data the Consumer must query all connected Producer for
their relative time. That means each Producer/Consumer connection needs a
bidirectional communication channel on the underlying fieldbus to synchronize the time
information.
Configuration effort:
Within a Producer/Consumer network such as Powerlink the number of communication
relations is a multiplication of the number of Producer (n) and the number of Consumer
(m). In a Master/Slave network such as EtherCAT the number is a summation.
Example: 10 Emergency stop buttons acting on 10 drives
Powerlink Safety
10 * 10 = 100 communication relations
Safety over EtherCAT
10 + 10 = 20 communication relations
Complexity of each device:
For Powerlink Safety each Consumer device (e.g. Safety related Drive) must provide
several safe connections if it supports several Producer Inputs. The Input information
must be combined within the device (Safe Logic functionality).
With Safety over EtherCAT a single connection per FSoE Slave device to the FSoE
Master is sufficient. The logical combination of Safety Inputs is done in the FSoE
Master device.
Industrial Ethernet Technologies
Page 127
© EtherCAT Technology Group
Safety rated products have to be certified by a “notified body” (such as
e.g. TÜV). For the safety certificate not only the safety layer has to be
tested, but also the (non-safe) communication protocol layer: the notified
bodies request a conformance certificate for this layer as well.
However, we are not aware of any fieldbus organization with an own
(native) safety protocol, that would be prepared to issue a protocol
conformance certificate for a safety device that uses an alien (non-native)
safety protocol layer.
In 2011 EPSG and published press releases with suggested that Nestlé
selected openSafety as their safety standard (quote: “Nestlé chooses
openSAFETY as the safety standard for packaging machines”). According
to Nestlé, this is not the case. Nestlé is in favor of an open safety
standard, but did not select the openSafety protocol.
Industrial Ethernet Technologies
Page 128
© EtherCAT Technology Group
Due to the polling principle, the master has to wait for the response of
each slave before he can send the next request – or has to wait for the
timeout.
The response time of each slave device depends
• on its individual implementation:
- if implemented with standard components: processor
performance, software stack implementation quality, varying local
CPU load due to application etc.
- or: implemented with FPGAs
• and on the topology (number and performance of the hubs in between).
Thus it is difficult to determine the performance of the network without
measuring it.
Performance limitations require complex bandwidth optimization in more
demanding applications.
Industrial Ethernet Technologies
Page 129
© EtherCAT Technology Group
Modbus/TCP is very widely used, since it is simple to implement.
Non-real-time approach: Due to its operating principle, Modbus/TCP
cannot guarantee delivery times or cycle times or provide precise
synchronization. Strongly depending on the stack implementation,
response times of a few milliseconds can be achieved, which may be
sufficient for certain applications.
Apart from the basic data exchange mechanisms, there is hardly any
additional feature. Network management, device profiles, etc. have to be
handled by the application program, the network layer does not provide
solutions.
Industrial Ethernet Technologies
Page 130
© EtherCAT Technology Group
Modbus/TCP client/master implementations can either wait for each
response to return before the next request is issued, or send several
requests at once in order to allow for parallel processing in the
server/slave devices. In the later case the overall performance is
improved.
Since the performance is primarily determined by the stack performances,
it very much depends on the implementation of the client (master) and
server (slave) devices – which is difficult to assess.
If a client is implemented on a standard socket interface of a Windows
OS, typical response times (per server) are in the order of 10-20ms with a
worst case (e.g. moving a Window) of well over 250ms (We have tested
this. The reason is that the OS processes the TCP/IP stack with low
priority). Of course it is possible to implement a client/master with an
RTOS and/or using a dedicated communication CPU and achieve better
results.
A server/slave device with sufficient processing power and an optimized
(=functionally reduced) TCP/IP stack may typically reply within 1-4 ms
(and in worst case, depending on the load, within 10-15ms). Standard
TCP/IP stacks on µC may have typical response times of >5ms.
Critical can be the retry times of the TCP/IP stacks – in case a frame was
lost. These retry times can be in the order of seconds – and typically are
not user definable nor mentioned in the product manuals.
Industrial Ethernet Technologies
Page 131
© EtherCAT Technology Group
Schneider replaced one non-real-time protocol by another one.
Details regarding the integration of Modbus TCP into CIP can be found
here:
http://www.modbus.org/docs/CIP%20Modbus%20Integration%20Hanover%20Fair_0408.pdf
Modbus/TCP will certainly not vanish any time soon, but this move of
Schneider suggests that there will not be any further enhancements of the
protocol.
The most recent Modbus Application Protocol Specification V1.1b3 (April
2012) is a slightly reformatted update of the previous version (V1.1, June
2004). It corrected some acronym misnomers, contains some
clarifications, and replaces the traditional master/slave language with the
client/server construct. With regards to Modbus/TCP it refers to the
MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE V1.0b of
October 2006.
By the way: in 2009 the former “Modbus-IDA” organization (IDA meaning Interface for Distributed
Automation) changed its name (and logo) to Modbus, and the web-address to www.modbus.org.
www.modbus-ida.org was abandoned and is now used by a whirlpool company.
Industrial Ethernet Technologies
Page 132
© EtherCAT Technology Group
The Slave implementation of EtherCAT is a class C approach: the
„processing on the fly“ technology requires dedicated slave controllers.
The EtherCAT Slave Controllers can be implemented as FPGA, ASIC or
with standard µController with EtherCAT Slave Controller interface option
– all solutions meet or undercut the cost levels of the other technologies
discussed in this presentation. It is not required to buy an ASIC, and there
are a variety of sources for EtherCAT Slave Controllers.
On the master side, EtherCAT does not require a dedicated master card:
any standard Ethernet Controller is sufficient, the master functionality is
implemented in software running on the host CPU that also runs the
application program. It was found that the master code adds less load on
the host CPU than servicing the DPRAM of an intelligent plug in card.
There is a wide range of master stacks available.
Industrial Ethernet Technologies
Page 133
© EtherCAT Technology Group
EtherCAT is very effective even with small amounts of data per slave
device, since it is not necessary to send an individual Ethernet frame for
each data unit.
Since process data communication is handled completely in hardware
(EtherCAT Slave Controller), the network performance does not depend
on the µC performance of the slave devices – and is thus predictable.
Switches are not necessary and thus optional. Hence there are no costs
related to switches, their power supply, mounting, wiring, configuration and
so on.
Since the CRC is checked by each device - regardless if the frame is
intended for this node – bit errors are not only detected immediately, but
can be also located exactly by checking the error counters.
The EtherCAT approach is Ethernet compatible: in the master
commercially off the shelf Ethernet MACs are sufficient, since only
standard Ethernet frames are used.
Industrial Ethernet Technologies
Page 134
© EtherCAT Technology Group
The cycle time figures of the competing technologies were determined as
follows:
PROFINET: Computations based on the specification (done by a well
known PROFINET expert). The configurable cycle time for this example
would be 1ms (IRT) resp. 8ms (RT).
Powerlink: see Powerlink section of this presentation. With Powerlink at
this cycle time there is no remaining bandwidth for asynchronous
communication.
For EtherCAT the Update Time (276 µs) is given: after this period of time
all output data and all input data was transferred from or to the master –
an entire cycle was finished. The telegram time is only 122µs – thus one
could communicate even faster (e.g. new data every 125µs).
Industrial Ethernet Technologies
Page 135
© EtherCAT Technology Group
Since EtherCAT used precisely adjusted distributed clocks (a feature of
the EtherCAT Slave Controller chips), the communication cycle itself does
not have to be absolutely equidistant – a small jitter is allowed. Therefore
EtherCAT masters do not need a special hardware (like a communication
co-processor) and can be implemented in software, only – all that is
needed is an Ethernet MAC, like the one that comes with most PC
motherboards anyhow.
Measurements showed a synchronization accuracy of ~20ns with 300
distributed nodes and 120m (350 ft) cable length. Since the maximum jitter
depends on many boundary conditions (e.g. no. of nodes, network length,
temperature changes etc.), its value is given conservatively with << 1µs.
Industrial Ethernet Technologies
Page 136
© EtherCAT Technology Group
EtherCAT used only standard frames. Any other Ethernet Protocols are
tunneled fully transparently – EtherCAT thus uses a method that is
common with Ethernet itself and with many Internet technologies: every
modem tunnels Ethernet frames as does WLAN, VPN uses this approach
as well as TCP/IP itself.
By using this approach EtherCAT can transport any Ethernet protocol (not
only TCP/IP) at shortest cycle times (even if they are shorter than the
longest possible Ethernet frame).
In addition, it is not necessary to keep a large gap in the data stream – like
most other approaches have to.
The protocol used is named “Ethernet over EtherCAT”.
Many EtherCAT masters support tool access from outside: a tool can
communicate via Ethernet e.g. by TCP/IP or UDP/IP with the master, who
inserts this data into the EtherCAT communication in such a way, that a
fully transparent access to EtherCAT devices is possible without restricting
the real time capabilities.
Industrial Ethernet Technologies
Page 137
© EtherCAT Technology Group
The “tunnel entrance” (Switchport) for any Ethernet protocol can be
implemented in a variety of ways: as separate device, as feature of a
slave device or as software feature of the EtherCAT master.
Industrial Ethernet Technologies
Page 138
© EtherCAT Technology Group
With EtherCAT almost any number of devices (up to 65535) can be wired
in a line structure – there are no restrictions due to cascaded switches or
hubs. Any number of drop lines or branches are possible, too, providing
the most flexible topology.
Industrial Ethernet Technologies
Page 139
© EtherCAT Technology Group
EtherCAT is so fast that it can replace the PCI bus (and thus the PCI
slots) in almost all applications. Fieldbus master and slave card can be
moved into the EtherCAT network. EtherCAT control computers can thus
be very compact, without restricting the expandability.
In addition, this feature provides a very elegant and smooth migration
path: Devices which are not (yet) available with EtherCAT interface, can
be integrated via underlying fieldbus systems – typically without restricting
the performance compared with the PCI solution.
Industrial Ethernet Technologies
Page 140
© EtherCAT Technology Group
The open protocol Safety over EtherCAT (abbreviated with FSoE "FailSafe
over EtherCAT") defines a safety related communication layer for
EtherCAT. Safety over EtherCAT meets the requirements of IEC 61508
SIL 3 and enables the transfer of safe and standard information on the
same communication system without limitations with regard to transfer
speed and cycle time.
It usage is not limited to EtherCAT based communication systems – it may
be used on any fieldbus or Industrial Ethernet technology. However, ETG
refrains from proactively promoting FSoE as universal fieldbus
Industrial Ethernet Technologies
Page 141
© EtherCAT Technology Group
independent safety protocol. We do not believe that a safety protocol that is alien
to the system can displace the native safety protocol promoted by the
corresponding fieldbus user organization. And if the alien protocol has to be
implemented and maintained in addition to the native safety protocol (if such a
product can be certified at all), it would add substantial non-justifiable costs.
Industrial Ethernet Technologies
Page 142
© EtherCAT Technology Group
With Safety over EtherCAT the communication channel is really “black” (or
irrelevant for the safety analysis), and not “grey”. Therefore e.g. no SIL
monitor is required to check the current error rate on the network.
Industrial Ethernet Technologies
Page 143
© EtherCAT Technology Group
With Safety over EtherCAT a decentralized safety PLC (“Safety Logic”)
can be combined with a non-safe standard main controller. With this
approach functional safety can be added to existing control systems
without the need to replace the main controller with a functional safety
PLC.
Of course FSoE also supports the classical approach (PLC also contains
the safety controller).
Industrial Ethernet Technologies
Page 144
© EtherCAT Technology Group
The FSoE license is provided free of charge.
The entire “eco-system” for implementing FSoE is available, including
TÜV certified tests.
Industrial Ethernet Technologies
Page 145
© EtherCAT Technology Group
EtherCAT is – even when wired in line topology – a ring structure, with two
channels in one cable (Ethernet full duplex feature). Whilst device located
before a cable or device failure can continue to operate (the EtherCAT
Slave Controller closes the ring automatically), devices behind the cable
failure are naturally not accessible any more.
Industrial Ethernet Technologies
Page 146
© EtherCAT Technology Group
If the line is turned into a ring, there are two communication paths to each
device: cable redundancy.
With EtherCAT even without special hardware in the master: a second
Ethernet port is sufficient. All slave devices with two (or more) EtherCAT
ports support the cable redundancy feature anyhow.
The recovery time in case of cable failure is shorter than 15µs. The initial
switchover to the redundant line does not require any reconfiguration by
the master.
By using this feature it is feasible to exchange device exchange at run
time (hot swap).
Industrial Ethernet Technologies
Page 147
© EtherCAT Technology Group
The configuration of an EtherCAT network is very simple.
This is in particular the case for the network planning: since the process
data performance does not depend on the devices that were selected (and
their µC and stack performance) and since the topology has almost no
influence at all, hardly anything has to be considered.
Also the network tuning, which has been necessary with many fieldbus
and industrial Ethernet solutions, is hardly needed at all: even with default
settings Ethernet is more than fast enough.
Industrial Ethernet Technologies
Page 148
© EtherCAT Technology Group
Like all Industrial Ethernet technologies that support hard real time,
EtherCAT requires a dedicated hardware interface – unlike its competition
EtherCAT requires such hardware only on the slave side. This provides
both maximum and predictable performance of the network, since
software stack delays do not have any influence any more. In addition this
leads to lower costs. The first EtherCAT Slave Controller (ESC) back in
2004 was FPGA based, released by the originator of the technology, the
German company Beckhoff Automation. In 2005 – 2007 EtherCAT ASICs
were introduced by Beckhoff and Hilscher. Many EtherCAT device vendors
also make use of the configurable EtherCAT IP-Cores for Altera and Xilinx
FPGAs. The Texas Instruments and the Renesas microcontroller and
microprocessor families also support EtherCAT Slave Controller
Interfaces. And more chips from a number of other vendors are in the
pipeline (not yet announced as of Feb 2014).
Industrial Ethernet Technologies
Page 149
© EtherCAT Technology Group
EtherCAT intends to even undercut the fieldbus cost levels – in spite of the
much better performance and many additional features.
Industrial Ethernet Technologies
Page 150
© EtherCAT Technology Group
The EtherCAT Technology Group is official standardization partner of the IEC: the ETG
nominates experts for the international standardization committees and may submit standard
proposals.
Since beginning of 2005 EtherCAT is an official IEC specification: IEC/PAS 62407. Since Oct.
2007 EtherCAT is part of the standards IEC 61158 (Digital data communication for
measurement and control – Fieldbus for use in industrial control systems), IEC 61784-2 (Digital
data communication for measurement and control –Part 2: Additional profiles for
ISO/IEC 8802-3-based communication networks in real-time applications) and IEC 61800-7
(Profiles for motion control systems). The latter is particularly important for motion control
applications, since it makes EtherCAT a standardized communication technology for the
SERCOS and CANopen drive profiles, on an equal footing with SERCOS I-III and CANopen
respectively. The drive parameters and state machines as well as the process data layout of the
device profiles remain untouched when mapped to EtherCAT. Hence the user interface does
not change when moving from SERCOS and CANopen to EtherCAT, and device manufacturers
can re-use major parts of their firmware.
Safety over EtherCAT has been standardized in IEC 61784-3-12 (Industrial communication
networks - Profiles - Part 3-12: Functional safety fieldbuses), and cables, connectors etc. for
EtherCAT are specified in the installation profile IEC 61785-5 -12 (Industrial communication
networks - Profiles - Part 5-12: Installation of fieldbuses - Installation profiles for CPF 12).
EtherCAT is also part of ISO 15745-4 (device description profiles)
The EtherCAT Technology Group (ETG) is an organization in which key user companies from
various industries and leading automation suppliers join forces to support, promote and
advance the EtherCAT technology. With over 2600 members, the EtherCAT Technology Group
has become the largest fieldbus organization in the world. Founded in November 2003, it is also
the fastest growing fieldbus organization.
Industrial Ethernet Technologies
Page 151
© EtherCAT Technology Group
Besides the master/slave communication EtherCAT provides further
possibilities: masters can communicate among each other as well as slave
devices.
For slave to slave communication there are two varieties:
Topology dependent slaves can insert data “upstream” which can be read
“downstream” by all other slaves. In many applications that require slave
to slave communication these relationships are known at network planning
stage and thus can be handled with accordingly. Wherever this is not
possible, the second variant can be applied:
Topology independent two cycles are used for slave to slave
communication. In most cases the corresponding delay time is not critical
at all – in particular if one considers that EtherCAT is even at twice the
cycle time still faster than any other solution….
Industrial Ethernet Technologies
Page 152
© EtherCAT Technology Group
In 2009 the EtherCAT protocol portfolio was enhanced by the EtherCAT
Automation Protocol (EAP). As a result, EtherCAT also comprises the
Ethernet communication between control systems, as well as to the
supervisory systems. EAP simplifies the direct access of process data
from field devices at the sensor / actuator level and also supports the
integration of wireless devices.
For the factory level, the base protocols for process data communication
have been part of the EtherCAT specification from the very beginning. In
2009 ETG enhanced those with services for the parameter communication
between control systems and for routing across system boundaries.
Uniform diagnostic and configuration interfaces are also part of the EAP.
It can be used in switch-based Ethernet topologies as well as via wireless
Ethernet. Process data is communicated like network variables, either
cyclically or event-driven. Both the classic EtherCAT Device Protocol,
which utilizes the special EtherCAT functional principle of "processing on
the fly," and the new EAP make use of the same data structures and
facilitate vertical integration to supervisory control systems and networked
controllers.
While EAP handles the communication in the millisecond range on the
process control level and between control systems, the EtherCAT Device
Protocol handles I/O and motion control communication in the field level in
the microsecond range.
Industrial Ethernet Technologies
Page 153
© EtherCAT Technology Group
EtherCAT devices made in 2004 are interoperable with devices made in
2014 – the new devices may support additional features or may have
implemented a device profile that had not been available in 2004, but the
basic communication protocol has not been changed ever since.
The outstanding stability of EtherCAT has been a major asset of the
technology: vendors of EtherCAT devices do not have to fear that their
implementation is obsolete any time soon.
Industrial Ethernet Technologies
Page 154
© EtherCAT Technology Group
The adoption rate of EtherCAT is outstanding. In particular the adoption
rate among master vendors underlines the wide spread support as well as
the openness of the technology: it makes a difference if a vendor “just”
support another fieldbus interface for his (slave) components such as
drives or I/O, or if he adopts the fieldbus as own system bus and
implements a master.
For two reasons ETG does not publish node counts:
1. ETG does not know the numbers, since sales do not have to be
reported and since the EtherCAT Slave Controller sales cannot be
monitored do to the “buy-out” licensing of the IP Core.
2. It is obvious that the other organizations do not know their numbers
either….
So ETG has to live with the fact that most market research organizations
underestimate the EtherCAT market share.
Industrial Ethernet Technologies
Page 155
© EtherCAT Technology Group
The performance figures have been determined with a mix of physical
layers, thus representing typical installations.
A comprehensive EtherCAT introduction can be found at the EtherCAT
website.
Industrial Ethernet Technologies
Page 156
© EtherCAT Technology Group
EtherCAT typically is chosen for one or more of these three reasons:
- superior performance
- flexible topology – even at large distances
- low costs
For more information regarding EtherCAT please go to
www.ethercat.org
Industrial Ethernet Technologies
•
•
•
•
Page 157
© EtherCAT Technology Group
Most performance comparisons only look at the network itself up to
the slave controller chips, and neglect the stack performances.
However, the stack performance is crucial when looking at the overall
network system performance
Softing is using the eCos RTOS on the Softcore CPU that runs the
stacks
The stack times were measured from the interrupt that is generated
at the reception of the Ethernet frame at the IP core until the data is
made available to the application at the application interface (stack
API).
Industrial Ethernet Technologies
•
•
Page 158
© EtherCAT Technology Group
Most performance comparisons only look at the network itself up to
the slave controller chips, and neglect the stack performances.
However, the stack performance is crucial when looking at the overall
network system performance
Industrial Ethernet Technologies
Page 159
© EtherCAT Technology Group
In principle, one should not compare technologies in such an overview table: since
the ratings are based on figures, assumptions and assessments that cannot be given
in full detail, one may come to a different conclusion. However, some like this and
ask for these tables.
In order to provide a better transparency, comments for each row are provided.
Cycle Time: EtherCAT is about 3 times faster than PROFINET IRT and Sercos-III,
and about 10-15 times faster than Powerlink or CC-Link IE. Due to TCP/IP usage for
process data communication and the related stack delays, the Modbus cycle time in
principle is longer than with PROFINET I/O – but this is widely implementation
dependent.
Synchronicity: The EtherCAT distributed clock mechanism provides jitter-values of
<<1µs. With Sercos-III, Powerlink and CC-Link IE the jitter depends on the
communication jitter of the master, with PROFINET-IRT, Powerlink and CC-Link IE
Field it (also) depends on the number of cascaded switches resp. hubs. All four
technologies claim a jitter of <1µs – as does CIPsync.
Throughput of IP data: with the „best effort“ approaches Modbus, EtherNet/IP and
PROFINET RT the throughput of IP data is basically limited by the stack
performance. Since PROFINET IRT and EtherCAT reserve bandwidth for Real-time
communication, the remaining throughput for IP data is reduced by the protocol – but
typically it remains higher than the stack performance of an embedded TCP/IP stack.
With IRT the user has to ensure that certain load limits are not exceeded. Powerlink
suffers from half duplex communication and overall poor bandwidth utilization due to
polling. CC-Link IE does not transport other Ethernet traffic (the SLMP option is the
other way round: SLMP via TCP/IP in external Ethernet networks). Sercos-III suffers
from the delay introduced by large no. of cascaded switches (in Realtime Mode).
Industrial Ethernet Technologies
Page 160
© EtherCAT Technology Group
Topology Flexibility: EtherCAT supports line, tree, star, ring, drop lines without
practical limitations on number of nodes and hardly any influence on performance.
PROFINET IRT: line, tree, star, drop lines, but limited no. of nodes and strong
interdependency between topology and performance. CC-Link IE Control: ring
only; CC-Link IE Field: star + line, ring announced. Powerlink: line, tree, star, drop
lines, but strong limitation due to hub delays. Sercos-III: line and ring only.
Line Structure: ModbusTCP, EtherNet/IP + PROFINET RT only support line
topology with device integrated switches – and of course, the switch delays
accumulate. With Powerlink, only few nodes in line, due to hub delays. According
to B&R user manual, a maximum of 10 hubs is allowed between master and slave
– so only 10 nodes in line. With PROFINET IRT, accumulated jitter due to
cascaded switches limits the no. of nodes in line topology. CC-Link IE Field: up to
121 nodes in line, Sercos-III specifies up to 511 nodes in line, EtherCAT supports
up to 65535.
Commercially Off The Shelf (COTS) Infrastructure Components: EtherNet/IP
asks for manageable switches with IGMP support. Hubs with 100 MBit/s
(Powerlink) cannot be considered COTS technology, since the chips are obsolete.
PROFINET RT requires a careful switch selection. PROFINET IRT requires
special switches throughout, Sercos-III does not allow switches, EtherCAT can be
used with switches (between masters and EtherCAT segments). If required,
EtherCAT networks can be further extended e.g. by inserting fiber optic segments
using standard infrastructure devices. CC-link IE Control: no COTS devices
possible; CC-Link IE Field: Switches can be used.
Industrial Ethernet Technologies
Page 161
© EtherCAT Technology Group
Slave to Slave Communication: supported by all technologies. Via Master only:
Modbus/TCP. Directly between slaves, but initiated by master: all others (EtherCAT:
depending on topology). Topology independent slave-to-slave communication with
EtherCAT requires 2 frames (which can be sent within the same cycle), so
performance of this communication type may be degraded to Sercos-III or
PROFINET IRT levels.
TCP/IP & other Internet Technologies supported: almost all technologies allow
for TCP/IP communication and Internet Technologies. Modbus/TCP, EtherNet/IP
and PROFINET I/O have no scheduling for this communication, all others do.
Powerlink, PROFINET-IRT, Sercos-III and EtherCAT connect generic Ethernet
devices (e.g. Service notebooks) via Gateways or special switchports. CC-Link IE
Field can connect external SLMP/TCP/IP devices via Gateway, but cannot transport
generic TCP/IP or Ethernet traffic.
Cable Redundancy: For Modbus/TCP switches with spanning tree protocol can be
used to establish cable redundancy (between the switches only). EtherNet/IP has
introduced the DLR protocol (and the corresponding devices). For PROFINET RT
there is the Media Redundancy Protocol (MRP). For Powerlink, redundancy
requires doubling of all infrastructure components plus additional redundancy
interface devices (or special redundancy slaves). For PROFINET IRT there is
Media Redundancy for Planned Duplication (MRPD). Sercos-III and EtherCAT
support cabling redundancy, for EtherCAT with very little additional hw effort (only a
2nd Ethernet port in the master, no special card).
Safety: There is no Modbus/TCP safety protocol. The safety approaches of the
other technologies differ regarding stability: Safety over EtherCAT products are
shipping since end of 2005.
Industrial Ethernet Technologies
Page 162
© EtherCAT Technology Group
Node Costs: Whilst Modbus/TCP – due to limited real time claims – can be implemented on
16bit µC, EtherNet/IP, PROFINET I/O and Powerlink require substantial processing power
and memory. Using FPGAs, Powerlink, Sercos and EtherCAT achieve comparable cost
levels, the ASIC implementation of EtherCAT reaches or undercuts fieldbus cost levels.
Node costs for CC-Link IE Field are difficult to determine, since the ASICs are not available
(at least not in Europe). CC-Link IE Control ASICs are not available at all.
Development effort: Assuming the TCP/IP stack is present, Modbus/TCP can be
implemented with very low effort. PROFINET I/O requires about 1 MByte (!) of code.
PROFINET IRT is very complex – not only but in particular the master. EtherCAT slaves can
be implemented with very little effort, since all time critical functions are provided in
hardware. EtherCAT masters range from very simple (e.g. with one process image) or more
complex (e.g. with dynamic scheduling). Sercos development effort for slave devices is
assumed to be similar to EtherCAT, since real time part is handled in hw, too. Development
Effort for CC-Link IE Field are difficult to determine, since the ASIC manuals are not
available (at least not in Europe).
Master Costs: Modbus/TCP, EtherNet/IP, PROFINET I/O and EtherCAT masters do not
require a dedicated plug in card. Since EtherCAT masters typically only send one frame per
cycle, the additional CPU load on the master is much lower than with the others in this
group. For hard real time applications, PROFINET IRT, CC-Link IE, Powerlink and Sercos-III
require special dedicated master cards with communication co-processors. For soft realtime
requirements, Powerlink and Sercos-III can also be implemented with SoftMaster.
Infrastructure Costs: Whilst Modbus uses switches (but no special ones), EtherNet/IP (+
typically PROFINET RT) require manageable switches (EtherNet/IP with IGMP support).
Depending on the topology, the integrated hubs (Powerlink) or switches (PROFINET-RT) or
special switches (PROFINET-IRT, CC-Link IE) are sufficient - if not, external hubs or special
switches are required. Sercos-III and EtherCAT do not require switches or any other active
infrastructure components.
Industrial Ethernet Technologies
Page 163
© EtherCAT Technology Group
User Group Size: No. of members in the user group is not crucial, but may serve as an
indicator for the acceptance. As of Feb 2014, the EtherCAT Technology Group has 2662
member companies (membership free of charge*), Sercos International has 58 member
companies**. EPSG (Powerlink) has 66 member companies***. ODVA has 304 member
companies****. Profibus International (PI) consists of 25 regional organizations with a total of
over 1400 members (Siemens is 25 x member), and CLPA***** has 1548 members, but their
membership is predominantly fieldbus (Profibus, CC-Link) related. ModbusTCP is so widely
used that the Modbus membership of 82 members****** only does not reflect its acceptance.
Worldwide User Group: ODVA, PI and CLPA are present worldwide – as is ETG, with offices
in Europe, North America, China, Korea and Japan. Sercos has offices in Europe, North
America and Japan.
Worldwide Acceptance: Modbus/TCP vendors exist worldwide. EtherNet/IP vendors are
mainly from North America, some in Asia and Europe. Hardly and PROFINET RT products in
Japan. Powerlink mainly implemented in Europe and China (open source). No non-German
PROFINET IRT products known. No non-Mitsubishi CC-Link IE Control products, hardly any
non-Japanese CC-Link IE Field products. No Non-European Sercos-III products known.
EtherCAT has been implemented by vendors in 6 continents, and it widely accepted in Europe,
NA, and Asia (including Japan).
Technology stability: Has the basic technology reached a stable state or are there still major
changes?
* since ETG membership is free of charge, membership figures should not be compared 1:1 with the other organizations.
** according to website www.sercos.de/www.sercos.com. + 9 Chinese Members of Sercos Asia + 8 Members of Sercos
North America; all as of Feb 2014
***according to EPSG Publication “PowerlinkFACTS” published in November 2007. In April 2007, there were 71 member
companies. Since then now new membership figures published.
**** according to www.odva.org as of Feb 2014
***** CLPA website claims 1900 members as of 2013, but in Feb 2014 lists only 313. There used to be a free of charge
membership option – maybe this is the reason for the difference.
***** according to www.modbus.org as of Feb 2014
Industrial Ethernet Technologies
Page 164
© EtherCAT Technology Group
Special Hardware Used: Modbus/TCP, EtherNet/IP (not: CIPsync) +
PROFINET RT can be implemented with standard hardware chips. For
Powerlink, recommended implementation is with FPGA. PROFINET IRT, CCLink require special chips in master and slave, Sercos-III need special chips
(e.g. FPGA) in aster and slave, EtherCAT requires an EtherCAT Slave
Controller (FPGA or ASIC) but no special chips, cards or co-processors in the
master.
Adoption Rate: Modbus TCP has been used for many years. EtherNet/IP,
PROFINET RT are spreading. Since 2007: hardly any new Powerlink products.
Potential PROFINET IRT vendors wait for technology stability (IRT+). CC-Link
IE Control: only Mitsubishi products (except cable + connectors), CC-Link IE
Field: very few non-Mitsubishi products so far. Sercos-III 1.1 started shipping in
December 2007. EtherCAT: large selection of master and slave devices from
large variety of vendors (e.g. over 90 different servo drive vendors, 60 I/O
device vendors, over 120 master vendors); more than 1200 implementation kits
sold, many more devices expected soon.
International Standardization: As far as international standardization is
concerned, all are part of IEC 61158 and IEC 61784-2 since Oct 2007 – the only
exception is CC-Link IE, which is expected to become an IEC standard in 2013
(only the application layer, though)
Modbus-TCP: Communication Profile Family (CPF) 15, IEC 61158 Type 15
EtherNet/IP: CPF 2, IEC 61158 Type 2
PROFINET: CPF 3, IEC 61158 Type 10
Powerlink: CPF 13, IEC 61158 Type 13
CC-Link IE: CPF 8, IEC 61158 Type 23 (expected to be published in 2014)
Sercos-III: CPF 16, IEC 61158 Type 19
EtherCAT: CPF 12, IEC 61158 Type 12
Industrial Ethernet Technologies
Page 165
© EtherCAT Technology Group
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement