Assembly Automation

Developments in real-time control with EtherNet/IP

R.S.H. Piggin
Article information:
To cite this document:
R.S.H. Piggin, (2007),"Developments in real-time control with EtherNet/IP", Assembly Automation, Vol. 27 Iss 2 pp. 109 - 117
Permanent link to this document:
http://dx.doi.org/10.1108/01445150710733333
Downloaded on: 27 June 2016, At: 00:22 (PT)
References: this document contains references to 14 other documents.
To copy this document: permissions@emeraldinsight.com
The fulltext of this document has been downloaded 1909 times since 2007*

Access to this document was granted through an Emerald subscription provided by emerald-srm:318550 []
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)

For Authors
If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service
information about how to choose which publication to write for and submission guidelines are available for all. Please visit
www.emeraldinsight.com/authors for more information.
About Emerald www.emeraldinsight.com
Emerald is a global publisher linking research and practice to the benefit of society. The company manages a portfolio of
more than 290 journals and over 2,350 books and book series volumes, as well as providing an extensive range of online
products and additional customer resources and services.
Emerald is both COUNTER 4 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics
(COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.

*Related content and download information correct at time of download.

 Feature

Developments in real-time control

with EtherNet/IP
R.S.H. Piggin
Rockwell Automation, Milton Keynes, UK

Abstract
Purpose – Ethernet continues to evolve as a viable fieldbus technology for industrial automation. This paper seeks to discuss the development of the
Common Industrial Protocol (CIP) for Ethernet and standards with particular reference to time synchronisation, real time motion control and safety.
Design/methodology/approach – The CIP is introduced, with an overview of four network adaptations: CompoNet, DeviceNet, ControlNet, and
EtherNet/IP. Developments in the EtherNet/IP implementation are discussed, along with key features. These include CIP Safety to meet the requirements
for safety-related control, CIP Sync for time synchronisation across CIP networks and CIP motion for real-time closed loop motion control.
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)

Findings – Standard, unmodified Ethernet will support time synchronisation, real time motion control and safety-related applications with the CIP
adaptation EtherNet/IP. The CIP enables complete integration of control with information, multiple CIP networks and internet technologies. CIP provides
seamless communication from the plant floor throughout the enterprise, with a scalable and coherent architecture, incorporating functionality, such as
safety, time synchronisation and motion control, hitherto only available with specialised or incompatible networks.
Practical implications – The implementations of CIP Sync, CIP Motion and CIP Safety and the corresponding standards provide functionality and
flexibility not available from disparate specialist networks. The ability to fully integrate internet technologies and safety, synchronisation, motion and
safety together is a distinguishing feature. Industrial Ethernet technologies vary in the ability to integrate to the same level of functionality and offer
similar flexibility.
Originality/value – The development of CIP technology and the use of open standards are described. The opportunity to use the combination of an
established automation protocol and standard, unmodified Ethernet provides potential cost benefits, flexibility, and innovative solutions, whilst
providing integration, performance and cost advantages.

Keywords Robotics, Functional management, Motion, Network operating systems

Paper type General review

1. Introduction characterised by numerous specialised and generally

1.1 Yesterday’s networks
Networks utilised in manufacturing have traditionally been
optimised for performance in specific applications; most
commonly, device, control and information in the automation
network paradigm. The recent addition of safety to
automation networking required the integration of a
separate sub-system. While well suited to the functionality
for which they were designed, these different networks were
not developed with a single, coherent enterprise architecture
in mind. Since, efficiency, reliability and, ultimately,
profitability are generally dependent on having more than
one of these capabilities; manufacturers have been forced to
implement several different networks, none of which
communicates innately with the other. As a result, most
manufacturing enterprise network environments are
The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0144-5154.htm
incompatible networks existing in one space.
Today, however, corporate expectations for the
manufacturing automation network landscape have changed
dramatically, thanks to the rapid and ubiquitous adoption of
internet technology. Companies of all sizes, all over the world,
are trying to find the best ways to connect the entire enterprise.
No longer is control of the manufacturing processes enough: the
new manufacturing mandate is to enable users throughout the
company to access manufacturing data from any location, at any
time, and to integrate this data seamlessly with business
information systems. During recent years, a rapidly increasing
number of users worldwide have looked to “open” systems as a
way to connect their disparate enterprise processes. However,
the great promise of open systems has often gone unfulfilled.
The devices, programs and processes used at the various layers
of the seven-layer open system interconnect (OSI) model have
different options, capabilities and standards (or lack thereof).
Integrating these networks requires extra resources and
programming. Even then, gaps between the systems often

DeviceNet, DeviceNet Safety, CIP, CIP Motion, CIP Safety and CIP
Assembly Automation
27/2 (2007) 109– 117 Sync are trademarks of ODVA. EtherNet/IP is a trademark of ControlNet
q Emerald Group Publishing Limited [ISSN 0144-5154] International under license by ODVA. Other trademarks are the property
[DOI 10.1108/01445150710733333] of their respective owners.

109
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
cannot be fully and seamlessly bridged. Consequently, users
compromise their investments and rarely achieve all of the
productivity and quality benefits promised by open network
technology.
1.2 Today’s networks
Common application layers are the key to advanced
communication and true network integration. The Common
Industrial Protocol (CIPe) allows complete integration of
control with information, multiple CIP networks and internet
technologies. Built on a single, media-independent platform,
CIP provides seamless communication from the plant floor
throughout the enterprise, with a scalable and coherent
architecture. CIP allows companies to integrate I/O control,
device configuration and data collection across multiple
networks. This ultimately minimises engineering and
installation time and costs whist maximising return on
investment.
Developments to the CIP protocols, including CIP Sync,
CIP Motion and CIP Safety are discussed. The focus of this
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
paper is EtherNet/IP, the CIP protocol utilising TCP/UDP/IP
over Ethernet.
Other Ethernet developments are taking place, the majority
affecting automation will form parts of the “Real-Time”
Ethernet (RTE) work of TC65, SC65 C Working Groups.
These will be published in the IEC 61784 standard series
(IEC 61784-2, n.d.), and will include EtherCAT, EtherNet/
IP, Foundation Fieldbus HSE, Modbus TCP/IP, Powerlink
and PROFInet. Discussion of these is beyond the scope of this
paper; for an illustration of fieldbus and standards
development see Thomesse (2005).
2. Common Industrial Protocol
2.1 DeviceNet
Introduced in 1994, DeviceNete is the first member of the
CIP family. DeviceNet is a CIP implementation using the
popular controller area network (CAN) data link layer
developed by Bosch, originally for multiplexing electronic
control units (ECUs) in vehicles. CAN in its native form (ISO
11898) defines only layers 1 and 2 of the OSI 7-layer model
(EN 50325-2, 2000; ISO 11898, 1993; Chaffee and
Hirschinger, 2006). DeviceNet is optimised, requiring only
the layers 1, 2, and adds an application layer (layer 7). Since,
DeviceNet has a low cost of implementation and is easy to
use, many device manufacturers have built DeviceNet capable
products. Several hundred of these manufacturers have
organised and are members of the Open DeviceNet Vendor
Association (ODVA, www.odva.org).
2.2 CompoNet
CompoNet meets the requirements of applications using large
numbers of simple sensors and actuators sending and receiving
bit and byte size data. The first edition of the CompoNet
specification has been recently approved by the ODVA and will
be published in the next publication cycle of the CIP Networks
Library and associated network specifications.
2.3 ControlNet
ControlNet, introduced in 1997, implements the same basic
protocol on new data link layers that allow for much higher speed
(5 Mbps), strict determinism and repeatability while extending
the range of the bus (several kilometres with repeaters) for more
110
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
demanding applications. Vendors and users of ControlNet
products are members of ControlNet International (CI, www.
controlnet.org) to promote the use of ControlNet.
2.4 EtherNet/IP
In 2000, ODVA and CI introduced another member of the
CIP family: EtherNet/IP, where “IP” stands for “Industrial
Protocol.” In this network adaptation, CIP runs over TCP/IP,
and therefore, can be deployed over any TCP/IP supported
data link and physical layers, the most popular of which is
IEEE 802.3 (2000), commonly known as Ethernet. The
universal principles of CIP easily lend themselves to possible
future implementations on new physical/data link layers, e.g.
ATM, USB or FireWire. The overall relationship between the
three implementations of CIP and the ISO/OSI 7-layer model
is shown in Figures 1 and 2 (Schiffer, 2006; ISO/IEC 7498,
1994).
3. EtherNet/IP
3.1 Standard Ethernet
Since, its introduction in 2000, EtherNet/IP has shown a
remarkable growth in many applications that utilised
traditional fieldbuses. This success is largely attributed to
the fact that this TCP/UDP/IP-based Ethernet system has
introduced real-time behaviour into the Ethernet domain
without giving up any of its highly appreciated features such
as company-wide access with standard and specialised tools
through corporate networks. The specific strength of
EtherNet/IP is the fact that does not require a modified or
highly segregated network; switches and routers using
standard features known in the office world can be used
without modification. This differentiates the technology from
other RTE implementations. At the same time, this means
that all existing transport level or TCP/UDP/IP level
protocols can continue to be used without any need for
special bridging devices. The substantially improved real-time
behaviour of CIP Sync, CIP Motion and the introduction of
CIP Safety allows EtherNet/IP to be used in applications that
previously required a set of several dedicated fieldbuses
(Schiffer, 2006).
3.2 CIP Safety
CIP Safety provides functional safety for CIP networks and
provides users with fail-safe communication between devices,
controllers and networks for safety applications. Safety is a
protocol extension that allows the transmission of safety
relevant messages. Such messages are governed by additional
timing and integrity mechanisms that are guaranteed to detect
system flaws to a very high degree, as required by
international standards such as IEC 61508 (1989) (Piggin,
2006). If anything goes wrong, the system will be brought to a
safe state, typically taking the machine to a standstill.
3.3 CIP Sync and CIP Motion
Two other significant additions to CIP are CIP Sync and CIP
Motion. CIP Sync allows synchronisation of applications in
distributed systems through precision real-time clocks in all
devices. These real-time clocks are kept in tight
synchronisation by background messages between clock
masters and clock slaves using the new IEEE 1588: 2002
(2002) standard. This makes the CIP Sync technology ideally
suited for motion control applications such as CIP Motion.
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
Figure 1 The CIP family of protocols
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
Figure 2 EtherNet/IP stack
3.4 CIP in unison
Ordinary devices can operate with CIP Sync, CIP Motion or
CIP Safety devices side by side in the same system. There is
no need for strict segmentation into “Standard” “Sync” and
“Safety” networks. It is even possible to have any combination
of all three functions in one device.
4. CIP Sync
4.1 The need for synchronisation
The use of time in a control system is generally applied to two
different types of applications: time stamping applications and
111
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
frequency-based applications. In time stamping applications,
the knowledge of absolute time is important since the timing
of specific events often need to be compared from one event
to another. Which event occurred first? How far apart were the
events? In some applications, such as power distribution, the
events may even occur in different geographical regions that
have different time zones. Therefore, the notion of an
absolute value of time is required. Specific events and alarms
are then time stamped so that correlation of these events can
be accomplished after the events have occurred.
There are also many frequency-based control applications.
For instance, the regulation of several drives that execute in
perfect unison so as not to stretch or damage the fabric
between them. In this application, the process is optimised
when the drives are synchronised. If each drive samples its
feedback and executes its control algorithms at precisely the
same time, force is applied in a uniform manner minimising
the torque differentiations that might exist between the two
and enabling better control of the process that affects the
material. In order to sample and execute at precisely the same
time, both drives depend on an accurate metering of time in
order to execute their control algorithms. These applications
do not necessarily need to have an understanding of hour,
day, or year; however, there is a requirement to know that
current execution started precisely with a millisecond
resolution since the last execution. The oscillators on each
drive are synchronised against the others’ and the frequencies
of both are correlated so that time is metered consistently
between both drives.
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
In addition to using time to synchronising both drives’
regulating loops, this application represents a velocity
regulated process where speed is ultimately determined by
measuring rotation of the motor over time. If the frequencies
of both drives are not synchronised, then the scale by which
these drives measure speed is different and each drive will
regulate to a different speed; despite the their commanded
references being identical. This would certainly adversely
affect on the process.
4.2 Synchronisation with standard Ethernet
CIP Sync is a CIP-based communication principle that
enables synchronous low jitter system reactions without the
need for low jitter data transmission. This is of great
importance in systems that do not provide absolute
deterministic data transmission or where it is desirable for a
variety of higher layer protocols to run in parallel to the
application system protocol. The latter situation is
characteristic for Ethernet. Most users of TCP/IP-based
Ethernet want to keep using it as before without the need to
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
resort to a highly segregated network segment to run the real-
time protocol. The CIP Sync communication principle meets
these requirements utilising Standard for a Precision Clock
Synchronisation Protocol for Networked Measurement and
Control Systems (ISO 11898, 1993). This lays the foundation
for a precise synchronisation of real-time clock in a distributed
system.
4.3 IEEE 1588 Precision Time Protocol
An IEEE 1588 system consists of a time master that
distributes its system time to time slaves in a tree-like
structure. The time master may be synchronised with another
real-time clock higher up in the hierarchy while the time slaves
may be time masters for other devices “below” them. A time
slave that is time master to another set of devices (typically in
another part of the system) is also called a boundary clock.
The time distribution is done by multicasting a message with
the actual time of the master clock. This message originates in
a relatively high layer of the communication stack, and
therefore, the actual transmission takes place at a slightly later
point in time. Also, there will be a variation of the stack
processing time from one message to another. To compensate
this delay and its jitter, the actual transmission time can be
captured in a lower layer of the communication stack such as
noting the “transmit complete” feedback from the
communication chip. This update time capture is then
distributed in a follow-up message. The average transmission
delay is also determined so that the time offset between
master and slave clock can also be compensated. This
protocol has been fully defined for Ethernet UDP/IP systems
and the protocol details for further industrial communication
systems are to follow. The clock synchronisation accuracy that
can be achieved with this system largely depends on the
precision time capture of the master clock broadcast message.
Hardware-assisted time capture systems can reach a
synchronisation accuracy of 250 ns or less. It is expected
that Ethernet chip manufacturers will offer integrated IEEE
1588 hardware support in the very near future.
The IEEE 1588 standard, Precision Clock Synchronisation
Protocol for networked measurement and control systems,
commonly referred to as the Precision Time Protocol (PTP).
PTP offers fundamental services for synchronising multiple
clocks in a system. It utilises a selection process, referred to as
112
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
the best master clock algorithm, which allows each clock in a
subnet to choose a master clock which it will follow. This is
done by examining a set of “credentials” that each clock
passes to the others it is connected to. Any clock in the subnet
that has the best credentials becomes the master for that
group. As this selection process occurs, a waterfall of master
and slave hierarchies is established, which, when followed to
the top, leads to the final system master called the
grandmaster clock.
After the alignment and instantiation of all master and
slave clocks occurs, PTP makes additional provisions for
synchronisation of these clocks. Through a set of messages,
called “Sync” messages, PTP offers tools to compensate for
offset and frequency adjustments of the slave clocks relative to
the master. These messages are simple in implementation and
utilise a very small level of network resources to accomplish
their goals.
4.4 Additional capabilities of CIP Sync
CIP Sync adds some additional capabilities to those offered
by the PTP. Aside from the basic synchronising mechanisms,
CIP Sync also offers the concepts of system time, local time,
and offset. This model allows for the separation of a common
system time from the individual device’s local time. These are
correlated through the individual device’s offset. In this
fashion, changes to system time may be applied without
necessarily affecting the device’s local time. This is important
if a discontinuity in frequency or the linear time scale would
be detrimental to that device’s ability to control properly.
Group Sync is another CIP Sync construct, over and above
the PTP layer. The Group Sync function allows a group of
devices, at an application layer, to become a part of a given
community, while ignoring other devices that are not a part of
that community. A given set of drives, for example, might
need to be synchronised in order to form a working,
functional subsystem. Given this, it is important that all the
drives within that community be synchronised prior to
starting any part of that subsystem.
4.5 Summary
CIP Sync offers a simple, unobtrusive method for
synchronising multiple clocks in a system. It is flexible
enough to manage synchronisation for applications that
require time stamping, while, in the same system, servicing
devices that depend on synchronised frequency. Its services to
do not require a lot of system resources, and once integrated,
they do not need a high level of management from the user’s
perspective. Finally, CIP Sync is robust enough to handle the
situations that would normally cause disturbances in time to
adversely affect the critical elements of the control system
(Harris and Kucharski, 2006).
5. CIP Motion
5.1 High performance distributed motion
CIP Motion, as it is currently defined by the ODVA, is
the name given to extensions made to the CIP to facilitate
distributed motion control over CIP networks. These
extensions together with CIP Sync provide a rich motion
control infrastructure that includes a timing model based on
time stamped data, a dynamic data connection, and a new
CIP Motion drive device profile.
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
When applied to EtherNet/IP, CIP Motion offers a high
performance motion control solution that has distinct
advantages over other emerging motion control networks.
CIP Motion’s use of standard unmodified switched
Ethernet with Quality of Service (QoS), prioritisation and
time stamped data delivery eliminates the requirement to hard
schedule network traffic, making high performance motion
control over standard Ethernet a practical reality. This allows
use of standard Ethernet components and infrastructure,
provides support for any IEEE 802.3 compliant nodes
without the use of special switches or gateways, and allows
support of future Ethernet and EtherNet/IP enhancements.
Dynamic data connections allow the size and content of CIP
Motion data packets to change during operation, and even
allow drive device nodes to be added or deleted at run-time.
How does CIP Motion achieve high performance motion
control while maintaining IEEE 802.3 compliance over
standard Ethernet hardware, especially given that other
Ethernet-based motion control network solutions have
resorted to proprietary mechanisms that, in general, are not
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
fully IEEE 802.3 compliant? The answer lies in the use of
standard 100BaseT full-duplex switched Ethernet and QoS
functionality, as defined in IEEE 802.1Q (2003) and an
innovative approach that distributes time stamped data to
time-synchronised network nodes. CIP Motion uses time
stamped data over standard switched Ethernet with QoS
prioritisation to relax these strict data delivery requirements
typically associated with motion control. Transmission
collisions are eliminated by the switches and queuing delays
minimised by QoS prioritisation so network determinism is
insured without eliminating the CSMA/CD data link layer.
This approach allows full IEEE 802.3 compliance, while
providing a robust open motion control network solution
when applied to high performance digital servo drives.
5.2 Time stamped data
Traditionally, network control of distributed servo drives rely
on absolute hard delivery of time-critical cyclic data across the
network. Drive nodes are synchronised with the controller’s
clock and connection update cycle by transmission of a
synchronisation packet at the start of the cycle. Command
data delivered to the drive nodes is implicitly referenced to a
designated time within the update cycle. By design, there is
little built-in tolerance in these protocols for late data packets.
A further ramification of hard synchronising the connection
update cycle to the controller update cycle, is that the update
period of the controller must be an integer multiple of the
computational update period of the drive. This places
constraints on both the drive’s computational update period
and PWM frequency selections of the drive.
CIP Motion’s use of time-stamped data along with its
simple timing model eliminates this hard synchronisation
constraint. Thus, the connection update period can be totally
unrelated to the drive’s computational update period and the
associated PWM rate. Real-time data values are adjusted at
the end device at the time the data is applied based on an
interpolation polynomial. In the case of late data, the
interpolation polynomial becomes an extrapolation
polynomial that allows the device to ride through the late
data condition. CIP Motion is, therefore, much more tolerant
of late data conditions.
CIP Motion provides comprehensive motion connectivity
that includes both point-to-point unicast and peer-to-peer
113
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
multicast connections. The point-to-point connection, or
drive connection, is used for data transfer between a motion
controller and its associated drives, while the peer-to-peer
connection, or peer connection, is designed to connect
multiple controllers together in a producer-consumer
relationship. Each connection type has its place in today’s
motion control applications. Point-to-point connections are
applicable to multi-axis systems employing a central
controller, whereas peer-to-peer connections effectively
address the requirements of line shafting applications.
5.3 CIP Motion drive connections
Both the CIP Motion drive connection data structures
(controller-to-drive and drive-to-controller) begin with a
connection header that includes a 32-bit time stamp, followed
by a series of data blocks for each axis instance supported by
the drive node. Each instance data block within the CIP
Motion drive connection packet consists of three sets of data
blocks associated with the cyclic, event, and service data
channels. The size of these data blocks for a given update is
variable and determined by the connection and instance data
block headers. From the drive’s perspective, these three
distinct data channels have different data processing priorities.
The specific functionality of these three data channels is as
follows:
1 Cyclic data channel. Carries cyclic data blocks that are
sampled or calculated every controller update period and
synchronised with other nodes in the motion control
system through use of distributed system time. Cyclic data
is high priority data that must be immediately processed
and applied to the drive axis within one drive update
period.
2 Event data channel. Carries event data associated with
drive event(s) (e.g. registration, homing, etc.) that have
occurred within the last controller update period. Event
data is medium priority and should be processed and
applied within one controller update period.
3 Service data channel. Carries data associated with service
requests to read or write attribute values of the drive axis
object as part of online configuration and diagnostic
functionality. Service data has lowest priority and is
typically buffered and processed as a background task.
There is no guarantee that a service request will be
processed within a controller update period.
Taken together, these three data channels provide a
comprehensive controller to drive data connection solution
for industrial motion control.
5.4 Synchronous vs asynchronous operation
Another advantage of the CIP Motion connection protocol
over time-slot protocols is the flexibility it has in handling
different types of drives and time synchronisation
requirements. The same network connection can be used on
both a high performance servo drive with 200 ns time
synchronisation accuracy, and a low performance Volts/Hertz
drive with no time synchronisation capability.
CIP Motion defines a simple single cycle timing model for
cyclic data transfer that delivers a fresh command value to
each drive based on the actual position values sampled at
the beginning of the previous cycle. Should a motion packet
be late for the next cycle, the time stamp of the packet can be
used to compensate for the delay, based on previous axis
trajectory, and smooth motion is maintained.
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
5.5 Online ADR
The simplicity of CIP Motion connection protocol is borne
out by the ease in which automatic device replacement (ADR)
can be achieved. Simply remove the CIP Motion device from
the network, set the address switch of the replacement device,
and attach it to the network. The new device is automatically
configured and placed online without disrupting the operation
of other nodes in the system.
5.6 Interchangeability
Today’s industrial control industry is demanding a higher
degree of drive device interchangeability than existing drive
profile specifications have been able to deliver. Low level
interchangeability such as being able to establish a network
connection to another vendor’s drive is not uncommon, but
what is uncommon is the ability to swap one vendor’s drive for
another vendor’s drive in a given application and run that
application without having to configure a large number of
vendor specific configuration parameters.
To achieve the goal of true device interchangeability, the drive
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
interface specification must go further in defining required
device behaviour than today’s drive interface standards have
ventured. Many parameters that these drive profiles have
previously left optional or vendor specific must be classified as
required in the implementation. Units for drive parameters
must be explicitly defined rather than being left to the discretion
of the manufacturer. Behaviour of each parameter and
behaviour of the drive as a whole must be explicitly defined so
there is no ambiguity. To extend the interchangeability of CIP
Motion devices beyond the CIP family the CIP Motion profile
has been incorporated, along with many other industry
standard drive profiles, into the pending IEC-61800-7
standard defining a generic interface to power drive systems.
5.7 Extensibility
While a comprehensive list of standard parameters are defined
to facilitate the goal of drive interchangeability, it is also the
goal of this design to accommodate drive axis object
extensions to the open standard, and extensions that are
vendor specific. CIP Common already supports this concept
by defining attribute ID and service ID ranges that may be
used to define additional open and vendor specific attributes
and services. In addition, enumerated and bit mapped drive
axis object attributes are defined to leave room for future open
and vendor specific extensions.
5.8 Scalability
The CIP Motion drive device profile has been designed to address
the wide range of drive devices on today’s market from simple
variable frequency drives to full featured vector controlled servo
drives. Unfortunately today’s drive profiles are fragmented into
two basic classes with certain profiles being appropriate for simple
VFD drives while others are tailored for complex servo drives.
Providing a common profile to a broad range of drives
facilitates creation of a consistent user experience. To achieve
this goal of scalability, the drive axis object includes parameters
associated with variable frequency drives as well as a
comprehensive set of parameters for vector control servo
drives. To avoid burdening a simple VFD drive with the
parameters of a complex servo drive, the attributes defined in
the drive axis object have been categorised by drive classification
so only parameters that are applicable to the given drive class are
marked as required in the implementation.
114
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
5.9 Simplicity
One of the goals of the CIP Motion drive profile and,
specifically, the drive axis object is to minimise complexity.
This goal applies to both the network connection behaviour
and to the drive parameter set. Most industrial motion control
networks today require a complex “time-slotting” protocol.
CIP Motion eliminates the “time-slotting” requirement by
including system time stamps with the data. As a result,
establishing a connection to a CIP Motion compliant drive is
far simpler than that for a “time-slotted” network.
In terms of the parametric data set, the drive axis object
design has taken full advantage of several recent trends in the
drive industry to simplify the device profile. Today’s
embedded processors have far more computation power
than their predecessors and are capable of performing floating
point operations with relative ease. Drive control engineers
are recognising the time-to-market and maintainability
benefits of writing their control algorithms using floating-
point maths. With floating-point maths there is no need to
manage implied decimal format, overflow, and precision. The
drive axis object uses floating-point data types wherever
applicable for the same reasons. Gone are all the configurable
scaling factors and per-unitisation schemes that permeated
the previous generation of drive profiles.
Finally, there had been a drive-centric view that formed the
basis for many of the existing drive profile definitions. Such a
view was based on the concept of an HMI or programming
device being directly connected to the drive and the drive
being responsible for non-volatile data storage and motion
profile sequencing (indexing). As a result, the drives were
burdened with the task of storing all aspects of the associated
drive parameters, i.e. the parameter name, value, default
value, display format, range limits, units as well as extensive
indexing tables. By contrast, the CIP Motion drive profile is
based on a controller centric view of the drive. In this view, it
is the controller’s job to provide connectivity to an HMI and
programming device as well as provide motion profile
sequencing via execution of an application program. As a
result, there is neither a need for the drive to store large blocks
of HMI related parametric data or application related
indexing tables, nor is there any requirement for the drive
to store this data in non-volatile memory. The end result is
considerable simplification of the overall drive profile.
5.10 Summary
CIP Motion provides a comprehensive drive device profile
that scales to support drives ranging from simple VFD drives
to high performance servo drives. The device profile defines
variable size motion control connections for unicast
controller-to-drive communication, and well as multi-cast
controller-to controller connections that are critical for line-
shafting applications. CIP Motion delivers the first device
profile that provides true device interchangeability. Unlike
currently available drive profiles, the new CIP Motion drive
device profile provides superior drive interchangeability,
extensibility, scalability, and simplicity, based on
contemporary drive behaviour and control-centric design.
Using a switched Ethernet physical layer, motion control
applications can now be realised using EtherNet/IP in
standard Ethernet star, trunkline or dropline network
topologies (Chaffee and Hirschinger, 2006).
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
6. CIP Safety
6.1 Philosophy behind CIP Safety
In the earliest stages of development and concept approval at
TÜV all CIP networks were considered for application of the
CIP Safety protocol. For this reason the specification changes
to release CIP Safety on EtherNet/IP are minor. They focus
on the enabling the safety feature not new development.
CIP Safety works with the real-time and seamlessly bridged
networks collective to the CIP. CIP Safety is a set of highly
integrated safety services which utilise the underlying
communications stacks of the standard CIP networks to
transport data from a source to a destination, as shown in
Figure 1.
CIP Safety ensures integrity through the use of an extensive set
of TÜV approved protection measures. CIP Safety cannot
prevent communication errors from occurring. Communication
networks by there nature are susceptible to noise or disturbances
such as cable breakage. The communication errors which must
be detected are shown in Figure 3, along with the measures CIP
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
Safety uses to detect these errors. CIP Safety ensures
transmission integrity by detecting these errors and it enables
application integrity by allowing devices to take the appropriate
actions. For most applications, when an error is detected, the
device will go to a known de-energised state, typically called a
safety state. The safety code in each device is responsible for
detecting these communication errors. This safety code is
executed in a high integrity section of safety devices, typically
using redundant hardware, which has been approved by a
certification agency. Since, the EtherNet/IP communication
stacks are part of the underlying communication network and not
part of the safety code, commercial communication stacks can
be used.
This decision to partition the safety services and build on
the underlying standard communication services means that
CIP Safety is media independent. This means that the same
CIP Safety communication stack can work on DeviceNet and
EtherNet/IP. The safety packets coming from an EtherNet/IP
Safety node are encapsulated within a standard EtherNet/IP
data frame, the same way the safety packets coming from
Figure 3 Error detection measures
115
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
DeviceNet Safety node are encapsulated within a standard
DeviceNet data frame, as shown in Figure 4. Since, the safety
coding and not the underlying communication layers ensure
the integrity of the data, the underlying communication layers
can be interchanged.
6.2 Consistency across CIP networks
It is obvious that using the same safety communication
protocol on DeviceNet and EtherNet/IP will provide a more
consistent user experience during installation, verification,
operation and maintenance. This consistency allows easy user
migration between CIP Safety networks. The secondary
benefit of a consistent media independent safety protocol is
that a safety connection can span across multiple subnets.
Since, the safety coding and not the underlying
communication layers ensure the integrity of the data, the
underlying communication layers can be interchanged and
intermixed even across subnets. Meaning a safety connection
can start on EtherNet/IP and end on DeviceNet (Figure 4).
6.3 EtherNet/IP Safety or DeviceNet Safety?
CIP Safety on EtherNet/IP will not replace CIP Safety on
DeviceNet. CIP Safety on DeviceNet and EtherNet/IP will
serve different applications. When to use EtherNet/IP or
DeviceNet for safety will depend largely on the same
requirements for standard EtherNet/IP and DeviceNet
communications. Factors such as, distances, packet length,
response time, device cost and device power requirements will
determine which network makes the most sense for a
particular application. In an application where large
distances, larger safety packet sizes or greater throughput is
required, CIP Safety on EtherNet/IP will have advantages
over DeviceNet. In applications where DeviceNet bandwidth
is sufficient or power via the network is required, DeviceNet
may have an advantage over EtherNet/IP.
6.4 CIP Safety messaging
Safety messages are encoded in the safety application layer of
the transmitting device and decoded and checked in the safety
application layer of the final receiving device. Any
intermediate devices such as bridges or linking devices can
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
Figure 4 Media independent protocol
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
have no knowledge of the contents of the run-time safety
protocol; they are simply a transport mechanism for the
encapsulated safety message.
All safety protocol must detect the age of the received data
to ensure the desired safety time is being achieve. When a
safety protocol goes through a complex device with retentive
memory, such as a bridge or router, the failure mode and
effect analysis of the protocol must ensure that delays are
detected. This type of failure may not be detected with simple
watchdog type protocols. For this reason CIP Safety has a
time stamped based protocol which can directly detect the
data age.
6.5 CIP Safey and Ethernet
The changes to the CIP Safety volume to add EtherNet/IP
support have few new requirements. As a result, the specific
changes and/or recommendations for EtherNet/IP are
intended to enhance the reliability of the network or to
explain how safety features are to be used on EtherNet/IP.
The addition of safety to EtherNet/IP requires all safety
devices on EtherNet/IP have a unique network identifier
(UNID) that consists of a safety network number (SNN) and
the device’s IP address. Factory installations will often
segment EtherNet/IP subnets to allow for re-use of IP
addresses. Users will assign a unique SNN to those subnets so
that the combined SNN/IP address is unique.
CIP Safety on EtherNet/IP does not restrict how the IP
address is set in an EtherNet/IP Safety device. All existing
methods such as DHCP, BOOTP, or Option 82 can be used.
However, the UNID in the device must be set through the
safety supervisor’s propose/apply services. The user will be
required to use an independent method to set the UNID.
6.6 Duplicate IP detection
Duplicate address assignments on any network are a
disruptive condition that needs to be avoided. The solution
needs to be one where existing nodes are not prevented from
functioning when the offending node comes on the network.
A solution is currently being considered by the EtherNet/IP
116
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
System SIG, and this proposal is potential addition to the
Ethernet/IP standard.
6.7 Summary
The CIP Safety protocol was developed to be network
independent from the start of development. CIP safety and
the newest addition of CIP Safety on EtherNet/IP provide
unprecedented flexibility, usability, and consistency. Now
standard and safety communications can coexist in a multi-
vendor environment, on multiple networks, that can span
multiple subnets (Vasko and Kucharski, 2006).
7. Conclusion
The CIP enables complete integration of control with
information, multiple CIP networks and internet
technologies. CIP provides seamless communication from
the plant floor throughout the enterprise, with a scalable and
coherent architecture, incorporating functionality, such as
safety, synchronisation and motion control, hitherto only
available with specialised or incompatible networks.
References
Chaffee, M. and Hirschinger, B. (2006), “CIP Motion,
Motion Control for CIP”, paper presented at CIP
Networks Conference and 11th Annual Meeting, 21 –
Phoenix, Arizona, 23 February, pp. 1-13.
EN 50325-2 (2000), “Industrial communication subsystem
based on ISO 11898 (CAN) for controller – devices
interfaces – Part 2. DeviceNet”, EN 50325-2.
Harris, K. and Kucharski, S. (2006), “CIP Sync, time
synchronization for CIP”, paper presented at CIP Networks
Conference and 11th Annual Meeting, Phoenix, Arizona,
21-23 February, pp. 1-12.
IEC 61508 (1989), “Functional safety of electrical/electronic/
programmable electronic safety-related systems”, IEC
61508.
 Developments in real-time control with EtherNet/IP
R.S.H. Piggin
IEC 61784-2 (n.d.), “Digital data communications for
measurement and control – Part 2. Additional profiles for
ISO/IEC 8802-3 based communication networks in real-
time applications”, IEC 61784-2.
IEEE 802.1Q (2003), “IEEE standards for local and
metropolitan area networks – virtual bridged local area
networks”, IEEE 802.1Q.
IEEE 802.3 (2000), “ISO/IEC 8802-3:2000 IEEE standards
for information technology – local and metropolitan area
networks – Part 3. Carrier sense multiple access with
collision detection (CSMA/CD) access method and
physical layer specification”, IEEE 802.3.
IEEE 1588 (2002), “IEEE standards for a precision clock
synchronization for networked measurement and control
systems”, IEEE 1588.
ISO 11898 (1993), “Road vehicles – interchange of digital
information – controller area network (CAN) for high-
speed communication”, ISO 11898.
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)
To purchase reprints of this article please e-mail: reprints@emeraldinsight.com
Or visit our web site for further details: www.emeraldinsight.com/reprints
117
Assembly Automation
Volume 27 · Number 2 · 2007 · 109 –117
ISO/IEC 7498 (1994), “ISO/IEC standard – information
technology – open systems interconnection – basic
reference model”, ISO/IEC 7498.
Piggin, R. (2006), “What’s happening with machine safety
standards and networks?”, Assembly Automation, Vol. 26
No. 2, pp. 104-10.
Schiffer, V. (2006), The Common Industrial Protocol (CIP) and
the Family of CIP Networks, Open DeviceNet Vendor
Association, Inc. (ODVA), Ann Arbor, MI, pp. 1-2.
Thomesse, J.P. (2005), “Fieldbus technology in industrial
automation”, Proceedings of the IEEE, Vol. 93 No. 6,
pp. 1073-101.
Vasko, D.A. and Kucharski, P.G. (2006), CIP Safety on
EtherNet/IP, Open DeviceNet Vendor Association, Inc.
(ODVA), Ann Arbor, MI, pp. 1-10.
Corresponding author
R.S.H. Piggin can be contacted at: rpiggin@ra.rockwell.com
 This article has been cited by:

1. P Ferrari, A Flammini, S Rinaldi, E Sisinni. 2010. On the Seamless Interconnection of IEEE1588-Based Devices Using a
PROFINET IO Infrastructure. IEEE Transactions on Industrial Informatics 6:3, 381-392. [CrossRef]
2. P. Ferrari, A. Flammini, D. Marioli, S. Rinaldi, E. Sisinni, A. Taroni, F. VenturiniClock synchronization of PTP-based devices
through PROFINET IO networks 496-499. [CrossRef]
3. Richard PigginRockwell Automation, Milton Keynes, UK Vivek HajarnavisRockwell Automation, Brussels, Belgium. 2008. A
model for function block communication and diagnostic messaging with EtherNet/IP. Assembly Automation 28:1, 36-42. [Abstract]
[Full Text] [PDF]
Downloaded by HACETTEPE UNIVERSITY At 00:22 27 June 2016 (PT)