Get documents about "Industrial Ethernet EtherNetIP
Document Sample
Mälardalen University 2003-02-27
Department of Computer Science and Engineering
Johnny Nordin
Marie Persson
Master thesis in computer engineering
Industrial Ethernet
EtherNet/IP
ABB Robotics Mälardalen University
Supervisor: Jan Carlsson Supervisor: Thomas Nolte
Examiner: Christer Norström
Abstract
For field bus communications ABB Robotics uses Interbus, Profibus and Devicenet
which are based on non-Ethernet media. For technical reasons and due to customer
demands ABB Robotics are looking for possibilities to Ethernet enable their products.
The purpose of this thesis is to evaluate Ethernet for industrial use together with the
EtherNet/IP field bus protocol. EtherNet/IP is an industrialized extension of Ethernet
TCP/IP that acts as an application layer and is used together with a standard TCP/IP
stack. A test system including a PLC, DeviceNet Bridge and a S4C+ robot controller was
used for evaluation and performance tests. The main concern when using Ethernet for
control purposes is the non-deterministic nature of the Ethernet protocol together with the
lack of standardization among the field bus protocols.
2
Preface
We would like to thank our supervisors Jan Carlsson, ABB Robotics, and Thomas Nolte,
Mälardalens Högskola for all help during this master thesis. We also would like to thank
Mikael Långberg for his support and the other employees at Embedded Knowledge for
the nice coffee breaks.
3
TABLE OF CONTENT
1 INTRODUCTION & BACKGROUND................................................................................. 8
2 HISTORY................................................................................................................................. 9
3 ETHERNET & OSI MODEL............................................................................................... 10
3.1 OSI MODEL (OPEN SYSTEMS INTERCONNECTION) .......................................................... 10
3.2 IEEE 802.3 STANDARD ...................................................................................................... 11
3.3 SWITCH/HUB TECHNOLOGY ............................................................................................... 13
3.4 VLAN................................................................................................................................... 14
3.5 MEDIA CONVERTERS AND REPEATERS .............................................................................. 14
3.6 BRIDGES/DEVICE SERVERS ............................................................................................... 14
3.7 GATEWAYS .......................................................................................................................... 14
4 TCP/IP.................................................................................................................................... 15
4.1 IP.......................................................................................................................................... 15
4.2 TCP - TRANSMISSION CONTROL PROTOCOL ................................................................... 15
4.3 UDP - USER DATAGRAM PROTOCOL ................................................................................ 15
5 INDUSTRIAL ETHERNET................................................................................................. 16
5.1 TECHNOLOGY ...................................................................................................................... 16
5.2 DETERMINISM ...................................................................................................................... 16
5.3 ADVANTAGES AND DRAWBACKS OF INDUSTRIAL ETHERNET .......................................... 17
5.4 PROTOCOLS ........................................................................................................................ 17
5.4.1 ENCAPSULATION TECHNOLOGIES ..................................................................................... 17
5.4.2 SYSTEMS FOR DISTRIBUTED AUTOMATION ........................................................................ 18
6 AUTOMATION AND CONTROL NETWORK ARCHITECTURE .............................. 20
7 ETHERNET/IP...................................................................................................................... 21
7.1 FIELD BUS COMPARISON CHART ....................................................................................... 21
7.2 CONTROL AND INFORMATION PROTOCOL (CIP)............................................................... 22
7.2.1 CIP BACKGROUND ............................................................................................................ 22
7.2.2 PRODUCER/CONSUMER DATA MODEL .............................................................................. 23
7.2.3 CIP OBJECT MODEL .......................................................................................................... 24
7.3 MESSAGING PROTOCOL ..................................................................................................... 28
7.4 DEVICE PROFILES................................................................................................................ 29
7.5 ETHERNET/IP ENCAPSULATION PROTOCOL ..................................................................... 31
7.5.1 ENCAPSULATION HEADER ................................................................................................. 31
7.5.1 ENCAPSULATION COMMANDS ........................................................................................... 32
7.6 CIP CONFIGURATION .......................................................................................................... 34
4
7.6.1 ELECTRONIC DATA SHEET................................................................................................. 35
7.7 BRIDGING AND ROUTING CIP ............................................................................................. 36
7.8 DATA MANAGEMENT ........................................................................................................... 37
8 ETHERNET IP CONFIGURATION .................................................................................. 38
8.1 ETHERNET/IP ADDRESSING ISSUES .................................................................................. 38
8.2 BOOTP - BOOTSTRAP PROTOCOL ................................................................................... 38
8.3 DHCP - DYNAMIC HOST CONFIGURATION PROTOCOL .................................................... 39
9 PLC ......................................................................................................................................... 40
9.1 TECHNOLOGY ...................................................................................................................... 40
9.2 IEC 1131 ............................................................................................................................. 40
9.3 PLC PROGRAMMING LANGUAGES ..................................................................................... 41
10 EMBEDDING ETHERNET/IP IN A PRODUCT............................................................ 42
10.1 SELECTING APPLICATION LAYER PROTOCOL .................................................................. 42
10.2 DIFFERENT APPROACHES INTEGRATING ETHERNET/IP................................................. 42
11 TEST PLATFORM............................................................................................................. 44
11.1 HARDWARE ....................................................................................................................... 44
11.1.1 CONTROLLOGIX PLATFORM ............................................................................................ 45
11.1.2 FLEX I/O......................................................................................................................... 46
11.1.3 DEVICENET MODULE ...................................................................................................... 47
11.1.4 S4C+ ROBOT CONTROLLER ............................................................................................. 47
11.1.5 SWITCH/HUB/CABLES .................................................................................................... 47
11.2 SOFTWARE ........................................................................................................................ 48
11.2.1 RSLOGIX 5000................................................................................................................. 48
11.2.2 RSLINX ............................................................................................................................ 49
11.2.3 RS NETWORX FOR DEVICENET ....................................................................................... 50
11.2.4 SOFTLOGIX 5800 ............................................................................................................. 50
12 TOOLS ................................................................................................................................. 51
12.1 RA BOOTP SERVER........................................................................................................ 51
12.2 ETHEREAL ......................................................................................................................... 51
12.3 ETHERNET/IP TOOL ......................................................................................................... 52
5
13 RESULTS............................................................................................................................. 53
13.1 PERFORMANCE ................................................................................................................. 53
13.1.1 PERFORMANCE TERMS ..................................................................................................... 53
13.1.2 PERFORMANCE MEASUREMENTS .................................................................................... 55
13.1.2 ANALYZE AND RESULT.................................................................................................... 56
13.1.4 PROBLEMS ....................................................................................................................... 62
13.2 CONCLUSIONS AND FUTURE WORK ................................................................................... 63
14 REFERENCES .................................................................................................................... 64
Appendix 1: Electronic Data Sheet
Appendix 2: A ControlLogix Project
Appendix 3: A SoftLogix Project
Appendix 4: Performance Measurements
6
Definition of terms
ATM Asynchronous Transfer Mode
BOOTP Bootstrap Protocol
CIP Control and Information Protocol
DHCP Dynamic Host Configuration Protocol
EtherNet/IP EtherNet Industrial Protocol
LAN Local Area Network
MAC Media Access Control
NIC Network Interface Card
TCP Transmission Control Protocol
IP Internet Protocol
UDP User Datagram Protocol
VLAN Virtual LAN
OS Operating System
PLC Programmable Logic Controller
7
1 Introduction & Background
A field bus is an industrial control network for the interconnection of example
sensors, actuators and controllers. At present time ABB Robotics mainly uses the
field buses Interbus, Profibus and DeviceNet in their products. Due to request from
clients, ABB want to evaluate a new field bus, the EtherNet Industrial Protocol
(EtherNet/IP). EtherNet/IP is an industrialized extension of Ethernet TCP/IP that acts
as an application layer and is used together with a standard TCP/IP stack.
The purpose of this thesis is to evaluate the EtherNet/IP technology and the
EtherNet/IP network.
The following are the main issues we address in this thesis:
• Whether it is possible to replace current field busses with EtherNet/IP
• What alternatives there are when it comes to EtherNet/IP-enable a product
• The EtherNet/IP product availability status for central components like I/O-
modules and other equipment in the network structure such as switches.
Moreover, a comparison with other field buses will also be performed based on
functionality and performance.
8
2 History
The evolution of the automation industry and its need to exchange data to control and
monitor the process has developed the field bus concept. The main objectives when
implementing the field buses was to reduce the costs for cabling and installation as
well as increase the productivity and implement monitoring and configuration
capabilities. The field bus has many technical advantages compared to the old
systems, however since the field bus is mainly used in the industry the most attractive
benefit is the reduction of capital costs. When converting to field bus technologies the
end users could reduce their initial costs, maintenance costs and make savings due to
the increased system performance.
Before the introduction of the field bus in the industry a typical control system was
built up around a central controller with I/O-cards for connecting remote devices like
sensors and actuators. When using field buses the data is sent in a sequence instead of
parallel using multiple wires. Somewhere in the middle 80’s the network technology
was ready to handle the most demanding applications on the factory floor.
In the beginning there was a technology race between the major companies. Every
company developed their own technology optimized for a certain target application.
In the late 90’s a standardization process was finished. The IEC61158 standard
comprises of 9 different field bus systems. Some of the field buses included in the
standard are Profibus, Device Net, Interbus, Fieldbus Foundation, ControlNet, P-Net
and WorldFIP. There are a few more industrial networks that are in use or under
development today.
Today’s field buses are much more intelligent than the early field buses, which only
purpose was to distribute I/O signals to and from remote locations. Nowadays a field
bus can be seen as a network for distributed intelligent devices with great
configuration possibilities and since the data is collected directly from the devices no
complicated programming is necessary to retrieve the data.
9
3 Ethernet & OSI Model
For better understanding of this thesis a review of relevant theory behind Ethernet and
TCP/IP networks will be presented in the first chapters of the thesis.
3.1 OSI Model (Open Systems Interconnection)
The OSI reference model is based on a proposal developed by the international
organization for standardization (ISO). The purpose of the model is to reduce the
complexity when designing network structure using layers.
Figure 1: OSI Model
1. Physical Layer
The lowest layer in the model is also called the physical layer. Its responsibilities
are to activate, maintain and deactivate the physical circuit between the device
and the network.
2. Data Link Layer
The Data Link Layer transfers data at bit-level and provides synchronization, flow
control and error detection.
3. Network Layer
The Network Layers primary objective is to handle the routing of the packets
from source to destination nodes. It also provides some congestion control to
handle bottlenecks in the network.
4. Transport Layer
The basic functionality of the transport layer is to receive data from the session
layer and split the data into smaller packets if necessary and pass these on to the
underlying network layer. It also provides the user with options in obtaining
different levels of quality from the network itself.
10
5. Session Layer
The session layer allows users on different machines to establish sessions between
them. It provides a user interface to the transport layer making it possible for the
user to select synchronization and control.
6. Presentation Layer
The presentation layer provides the syntax of the data used in the model. It
contains many tables of syntax, such as ASCII, Unicode, Teletype and Videotext.
7. Application Layer
The application layer is concerned with the support of a end user application data.
The layer contains a wide range of protocols that are commonly used. It handles
the differences between various systems such as terminal types and file transfer
protocols.
3.2 IEEE 802.3 standard
The most common physical layer of a TCP/IP network is Ethernet IEEE 802.3 using
coaxial, twisted pair or optic medium connected together preferably in a star topology
using hubs or switches. For industrial use the choice of cable must be compatible with
the temperatures, the noise level and chemicals in the operating environment.
Data
Preamble (7) SOF (1) DST (2-6) SRC (2-6) SIZ (2) (0-1500) CRC (4)
Figure 2: IEEE802.3 Frame format
• Preamble
The first seven bytes contain a bit-pattern. The encoding of the bits generates a
10MHz square-wave during 5.6µs to let the receiver synchronize with the
transmitter.
• SOF
A one-byte start of frame delimiter.
• Destination and Source address
Contain of a 2 to 6 byte address for the destination and source nodes.
11
• Size
The size field contains how many bytes of data that is present in the data-field.
• Data
The data-field contains a maximum of 1500 bytes of data. Since the minimum
size of an Ethernet-frame is 64 bytes the data-field is padded with 0-46 bytes to
reach the 64 byte minimum limit. However this restriction was made to be able to
perform collision detection when the primary medium in use was coaxial cables
and the address length was 2 bytes. Today twisted-pair is used and connected
using a hub or a switch and an address is usually represented by 6 bytes resulting
in that the minimum size could be smaller than the 64 bytes.
• CRC
The CRC-field contains a 32-bit checksum of the data. If some of the bits in the
data-field are corrupted due to noise on the cable the error will be detected when
running the checksum test.
All the IEEE 802.3 base band systems use Manchester encoding. When using
Manchester encoding every bit is divided into two intervals. A one is transmitted
when the signal is high during the first interval and low the other half of the bit. To
transmit a zero the intervals are swapped to initially low and high signal during the
second interval. The level for a high signal is +0.85V and –0.85V for at low signal,
which gives a DC-level at 0V.
The data link layer of the IEEE 802.3 uses the multiple access protocol CSMA/CD
(Carrier Sense Multiple Access / Collision Detect). A node that wants to transmit
listens to the medium if it is possible to start transmitting. If the medium is occupied
the node waits until it is available and starts transmitting. If two or more nodes start
transmitting at the same time a collision occurs. All nodes involved in the collision
uses the binary exponential back off algorithm to retry transmitting.
At the first collision the transmitting nodes chooses randomly to wait one or two slot
times. A slot time in this case is the time it takes to deliver the smallest Ethernet
packet at a certain network speed (At 10Mbit the smallest packet is 64 bytes that is
512 bits which gives a slot time of 51,2us). If another collision occurs, the
transmitting nodes randomly pick a back off time of 0, 1, 2 or 3 slot times. The
general formula for the algorithm is 2n–1, where n is the number of retries. The
maximum value of retries (n) is 10 that give a maximum delay of 1023 slot times the
last try. After 16 collisions, the controller reports a failure to the application.
12
3.3 Switch/Hub Technology
ETHERNET SWITCH/HUB TECHNOLOGY
A hub or a switch is used to connect several computers/devices together. A
10/100Mbit Ethernet hub is only half-duplex and therefore a client can only send or
receive data at a particular time. The switch can be considered as a faster version of
the hub. Ethernet switches allow the clients to operate in full-duplex mode making it
possible for the clients to send and receive data at the same time. Switches also route
the traffic between the ports instead of broadcasting the traffic to all the ports. Using a
switched technology gives every port a dedicated bandwidth instead of a shared
bandwidth. Since the primary target of the thesis is industrial real-time control
systems the obvious choice is to use switch technology to reduce collisions.
CUT-THROUGH SWITCHES
The Cut-Through Switches sends the packet to the MAC as soon as the first 14 bytes
of the frame are received. This result in a minimal delay and the packets are received
in shortest possible time. When using Cut-Through Switches it is not possible to pass
packets forward to a faster network because the data is sent through the switch at a
constant data-rate and the transmit- and receive rate is always the same. A typical
latency in Cut-Through Switches is 2.2-35µs. Since the frame is forwarded before
reading the CRC checksum it is not possible to discard error frames. This type of
switch is recommended for networks with the need for minimal delays, low network
loads and uses one port on the switch for each client.
FRAGMENT-FREE SWITCHES
The Fragment-Free Switches provides a compromise between speed (Cut-Through)
and error-control (Store and Forward). Fragment-Free Switches checks that there is
no collision for the first 64 bytes of the frame, which is the minimum packet-size in
the IEEE 802.3 specification. This prevents forwarding of message fragments smaller
than 64 bytes that typically occurs in systems when there are collisions. Since the
frames are sent through the switch at a constant data-rate it is not possible to pass
messages to higher speed networks. The typical latency for Fragment-Free Switches
is 6.4-115µs.
STORE AND FORWARD SWITCHES
The Store and Forward Switch buffers the complete frame in the switch and checks
for errors. If the frame is error-free it is forwarded and otherwise it is discarded.
When buffering the complete frame it is possible to forward messages to a higher
speed network. Store and forward offers the best error prevention but has also got the
highest delays. The typical latency for Store and Forward Switches is 7.2µs-1.5ms
13
3.4 VLAN
The VLAN functionality that is included in some switches makes it possible to
configure the switch based on the MAC addresses of the clients or the port numbers
on the switch to set up virtual network groups in the network. When using VLAN’s
the broadcast, multicast and unicast packets will only be sent to the nodes of the
respective VLAN. This reduces the total number of packets on the network when
broadcasting and increases the security options on the network.
3.5 Media converters and repeaters
The media converters and repeaters normally work in layer 1 and layer 2 of the OSI
model. They convert the electrical signals from one physical media to another. An
example could be a 100Mbit Ethernet to a 100Mbit Fibre converter. A repeater is
used if a signal needs to travel a long distance. The repeater takes a signal (weak)
from a segment and then regenerates it and sends it to the next segment. A switch can
be used as an intelligent repeater since they amplify the signals and enables analysing
of the packets received. A switch can look at the entire packet and verify using the
CRC checksum that the packet is correct. If not the packet is discarded. All media
converters and repeaters have in common that they do not provide any additional
values to the application.
3.6 Bridges/Device Servers
Bridges operate in the layer 1-4 in the OSI model. Bridges can establish connections,
handle retransmissions and errors. The data is not modified since the 1-4 layers have
no mechanism to process the data itself. For Ethernet it is quite common to use
Device Servers to bridge from a serial network to Ethernet. The Device Server
contains a complete TCP/IP stack and receives data from the serial link and
encapsulates the data into a TCP/IP frame so it can be transported over the Ethernet
network. Bridges and Device Servers works well in an environment where the data-
messages is transmitted on a cyclic basis. When it comes to real-time I/O data
exchange there must be level 7 processing to be able to bridge the messages between
two different networks.
3.7 Gateways
A gateway is the solution if you want to communicate between different network
architectures and different protocols. Before the gateway transports a packet to the
other network it repacks the data so the other network understands it. Since the
gateway incorporates all the OSI layers from 1 to 7 it allows complete data translation
and processing. A drawback is that gateways are quite complex and hard to set up.
14
4 TCP/IP
4.1 IP
The Internet Protocol (IP) is a connectionless protocol that is responsible to move
packets of data from node to node. IP handles the routing of data between the
networks and the nodes in the networks. An IP address is a unique set of four bytes.
Every byte in the address is a number between 0 and 255 (for example 192.169.0.1).
The IP protocol breaks single large packets into smaller ones to be able to handle the
network traffic better. Each single packet containing the fragmented data is
responsible for finding its way across the network. Every packet that arrives at an IP
router is routed individually and not necessary the shortest physical way.
4.2 TCP - Transmission Control Protocol
TCP is a connection based protocol that enabled a reliable connection between two
endpoints. The unit of data that is transmitted is called a stream. A stream like a file is
only a sequence of bytes. Before starting to transfer data a connection between the
two endpoints must be set up. When the connection is done it is possible to send and
receive data full duplex at only one connection. Both ends know when a connection
opened and closed. Both sides can close an existing connection. The TCP protocol
guarantees that all the data is sent and in the correct order. If any error occurs it will
be corrected (retransmission) and if it is not possible to correct the error it will be
reported. The TCP message header is larger than the UDP header and TCP is not able
to send multicasts. Another issue that makes TCP not ideal for control purpose is the
fact that seven handshakes is required to send a message when a connection has not
been established (establish connection, send message, verify arrival and close
connection).
4.3 UDP - User Datagram Protocol
UDP provides a connectionless host-to-host communication path. The UDP datagram
has a minimal overhead. Each packet is composed only of a small header and user
data. Since UCP is connectionless no advertising, negotiation and preparation is
necessary before the packet is sent. The method is simple, just send the datagram and
hope that the receiver gets it. UDP is an unreliable protocol since there is no
guarantee that is will be delivered to the destination address. Even though there is no
guarantee the protocol is useful because the error rate is very low on then Internet and
very close to null on a LAN unless the network load is heavy. The unreliability of
delivering the datagram is not the only problem with UDP; the packets can be
delivered in an incorrect order and it is possible to receive the same packet more than
one time. This makes it difficult to program the application using UDP. An
application using UDP must be able to handle missing datagram, multiple datagram
and datagrams in incorrect order. Even though all the drawbacks with UDP it is used
because of the small overhead, it is fast, and the possibilities to perform broadcasts.
15
5 Industrial Ethernet
Industrial Ethernet is a term for using Ethernet technology in industrial automation
and control systems.
5.1 Technology
Some of the major technical advances in the Ethernet technology like fast Ethernet,
switching technology and full duplex transmissions have increased the interest from
the industrial automation technology. Some of the benefits using Ethernet as an
industrial field bus are the possibility to use cheap standard hardware components and
the possibility to use the same network technology all the way from the office to the
plant floor. When using Ethernet on all levels it is possible to use the standard
Internet protocols such as HTTP and FTP. Another aspect is the fact that the Ethernet
and TCP/IP are well known technologies for many people and it might make
development easier and faster. Implementing an HTTP-server at the device level, all
the data can be presented using a simple web browser with a well-known interface at
control or office-level. When using the field bus with more intelligent devices and
moving closer to a distributed system approach the demands for high-speed large data
transfers increases. The transfer speeds of Ethernet technology with its 10 or 100Mbit
is superior to other field bus technologies that operate at significantly lower speeds.
When moving from the field buses that are in use today to Ethernet based field buses
the network topology changes from a ring-topology to a star/tree-topology. This
might look like a step in the wrong direction since one of the reasons for the
introduction of the field bus was to reduce the cabling costs and complexity. A
problem when building systems for the industry is the operating environment with the
sometime extreme temperatures and high noise-levels. If using standard of-the-shelf
Ethernet equipment for rough industry environments might lead to lower system
performance because of a high error rate generated by high noise-levels.
5.2 Determinism
When designing a control system for an industrial application it is essential to be able
to predict the behavior of the communication systems. To achieve a strict
deterministic behavior it must be possible to predict the behavior and schedule the
events concerning the time and in what order the events are performed. When using
Ethernet it is not possible to achieve a strict deterministic behavior since the data link
layer protocol uses CSMA/CD and therefore apply the binary back-off algorithm that
generates an unpredictable behavior. To get as close as possible to deterministic
behavior when using Ethernet technology the delays and collisions has to be reduced
to an absolute minimum. By using full-duplex high speed switches instead of hub
technology the number of collisions decreases significantly. If the application
demands big data transfers, using fast 100Mbit Ethernet or eventually Gigabit
Ethernet can reduce the network load.
16
5.3 Advantages and drawbacks of Industrial Ethernet
Advantages and drawbacks of using Ethernet for industrial applications:
+ Cheap standard hardware
+ Well known technology
+ High Bandwidth
+ One wiring scheme can handle multiple protocols
- Standard Ethernet hardware is not very well adapted to industrial environments
- Power to operate
- Every node needs CPU to process network stack
- CSMA/CD inherently non-deterministic
5.4 Protocols
There is no standardization for protocols using Ethernet as a field bus. The existing
protocols can be divided into two groups, Encapsulation protocols and Systems for
distributed automation.
5.4.1 Encapsulation Technologies
Protocols that use encapsulation technologies pack the messages into a TCP or UDP
frame. The benefits when using this technology are that it is possible to combine the
protocol with the current field bus solutions and it results in a scalable network. Other
advantages are the reuse of tools and the fact that it easy to resolve compatibility
issues. A drawback would be that its not very effective or optimal since the message
is being repacked and extra data is added to the packet.
ETHERNET/IP
The Ethernet Industrial Protocol has been developed by ODVA with support from
Rockwell Automation. EtherNet/IP uses the well-known CIP (Control and
Information Protocol) which are used in both Control Net and Device Net. CIP
provides object model that includes services for data management and network
control services. The CIP messages are encapsulated before being sent over the
Ethernet network. The protocol supports both explicit and implicit messaging. For
explicit messages (Information & configuration) the TCP/IP protocol is used to
transport data and for implicit messaging (Real-time I/O-data) it uses UDP/IP for
transportation. Since this is the protocol being evaluated in the thesis there will be a
more detailed description in chapter 7.
17
INTERBUS ON ETHERNET
The Interbus on Ethernet Concept has integrated a TCP/IP channel into the hybrid
Interbus protocol. By using a multiplex method the TCP/IP packages are sent over the
Interbus. The structure of the hybrid Interbus protocol enables different data-types to
be forwarded independently. I/O-data that is transferred through the Interbus process
data channel, parameter and configuring-data is transmitted using the parameter data
(PCP) channel while the larger file transfer packages are transferred through the
TCP/IP channel.
MODBUS TCP
The Modbus/TCP protocol was invented by Modicon/Group Schneider. The protocol
is based on the old Modbus protocol from the 1970’s. No changes have been made to
the protocol itself but there have been made some changes in how and at what rate the
messages are sent in order to fulfill the real-time needs of industrial applications.
Modbus/TCP embeds a Modbus frame into a TCP frame. Since TCP is a connection-
based protocol and every query requires a response this technique works well with the
master/slave nature of Modbus.
FIELD BUS FOUNDATION HSE (HIGH SPEED ETHERNET)
The Foundation HSE field bus is based on a 10/100Mbit switched Ethernet backbone
with Linking Devices connecting H1 (31.25 kbit/s) field bus segments to the Ethernet
backbone. The Linking Devices also provide Master capability for the downstream
H1 segments. H1 and HSE were designed to work as complementary networks. HSE
is supposed to provide information control and plant integration using commercial
off-the-shelf Ethernet components while H1 is optimized for traditional process
control applications.
5.4.2 Systems for distributed automation
The protocols in this approach are aimed at an application that is decentralized and
distributed over controllers via the network.
PROFINET
ProfiNet is under development in the Profibus User Organization and is strongly
supported from Siemens. ProfiNet is a high-level communication system that supports
distributed automation. In ProfiNet Ethernet-TCP/IP is only used for information that
is not considered as time-critical. All the time-critical information such as real-time
I/O-data is transmitted using the standard Profibus-DP technology. It is possible to
integrate the information from the Profibus-DP network with the ProfiNet system
using proxy technology. ProfiNet does not define an own protocol for industrial use.
The object model used by ProfiNet is Microsoft’s Component Object Model and all
communication between the distributed objects uses Microsoft’s DCOM wire
protocol and TCP/UDP/IP. ProfiNet uses a vendor independent object and connection
editor and device description in XML when specifying distributed automation
environments. All interactions between the ProfiNet components are defined using
the connection editor and downloaded to the devices using Ethernet-TCP/IP.
18
IDA (INTERFACE FOR DISTRIBUTED AUTOMATION)
IDA is a new protocol for automation using Ethernet that is developed by the IDA
group with strong support from Schneider Automation and Jetter. The first public
specification of IDA was released in April 2001. IDA is an open object oriented
communication system that defines both the methods for real-time communication
and information communication between the nodes. The protocol also includes
methods for web-based management using standard Internet web-browsers, device
descriptions using XML for automatic device detection and support for clock
synchronization. For real-time communication IDA uses the RTPS (Real-time
Publish/Subscribe) protocol which is implemented as a middleware on top of the
UDP protocol. The supported real-time communication relationships of IDA are pre-
configured/dynamic, cyclic/on-demand, point-to-point / group oriented and single-
source/redundant.
19
6 Automation and Control Network Architecture
Since EtherNet/IP will be the protocol studied in the thesis the network structure will
be looked at from an EtherNet/IP point of view. The industrial network used for
control and information purposes can be split into three levels:
Figure 3: Industrial network
1. Information Level
Typical devices operating at the information-level are desktop PC-computers and
other configuration or presentation units.
2. Control Level
Devices connected at control-level are devices involved in the control-process like
PLC's (Programmable Logic Controller), robot controllers and sometimes high-level
I/O devices.
3. Device Level
The lowest level in the architecture includes all different types of I/O-devices,
operator interfaces and micro-PLC's.
EtherNet/IP can be used in all three layers in the architecture but at the moment it is
best suited for the information and control levels.
20
7 EtherNet/IP
Figure 4: CIP common overview
Figure 4 illustrates the relationship between the protocols in the CIP family. Since
DeviceNet, ControlNet and EtherNet/IP share a common application layer it is
possible for devices from all three protocols to interoperate. This chapter will mainly
handle the application layer, encapsulation protocol and messaging protocol.
7.1 Field bus Comparison Chart
Name Developer/Year Physical Max Nodes Transmission Rate
Media
Profibus DP/DA Siemens/94-95 TP or fibre. 127 DP: 9.6kbps to 12Mbps
DA: 31.25kbps
Interbus S Phoenix Contact, TP or fibre. 256 500 kbps
Interbus Club/84
Foundation Fieldbus TP, fibre or 240/segment 31.25 kbps
Fieldbus H1 Foundation/95 slipring. 65000segments
DeviceNet Allen-Bradley/94 TP for signal 64 125 to 500 kbps
& power
ControlNet Allen-Bradley/96 Coax or fibre 99 5 Mbps
CANopen CAN in automation/95 TP 127 10 kbps to 1 Mbps
Ethernet DEC, Intel and Xerox TP, coax or 1024+ 10 Mbps to 1Gbps
/76 fibre
Table 1: Field bus comparison chart
When comparing the physical aspects of some common field busses EtherNet/IP has
superior data when it comes to scalability and data transmission rates.
21
7.2 Control and Information Protocol (CIP)
The CIP Family of Field bus Protocol
7.2.1 CIP Background
Field buses like Profibus and Interbus-S are effective buses that are suited for certain
layers within the automation hierarchy, but due to their limited functionality is it
difficult to provide interoperability between similar device types on difference
networks. CIP offers a scalable solution that allows a homogeneous protocol to be
used from top to bottom of the automation hierarchy. CIP have three family members:
DeviceNet, ControlNet and EtherNet/IP (Industrial Protocol). DeviceNet was
introduced in 1994 and is based on the Controller Area Network (CAN) technology.
The CAN protocol cover the layers 1 and 2 of the OSI 7-layer model while
DeviceNet/CIP defines the rest of the layers. ControlNet (1997) implemented the
same basic protocol in a new physical layer that allows much higher speed and a
deterministic behavior. The youngest family member, EtherNet/IP, was born in 2001
and uses standard Ethernet and TCP/UPD/IP (Internet Protocol) technology to
transport CIP messages. With CIP as a common application layer is it possible to
send a message from, for example, an EtherNet/IP module to a DeviceNet module.
The messages are first packed in a TCP-packet and then repacked in a bridge module
to a DeviceNet-packet. CIP supports a common object library, device profiles, control
services and routing. These objects and profiles make it possible for plug and play
interoperability among devices from various vendors.
For more information and a comparison between CIP’s field buses, see table 2.
EtherNet/IP ControlNet DeviceNet
Max segment 10 km 1 km (coax), 3 km (fiber) 100 m, 250 m, 500 m
length
Max length Unlimited 30 km (coax, fiber or both) 4 km (with repeaters)
Max nodes 1024 99 64
Rates 10 m, 100 m 5Mbps 125kbps, 250kbps, 500kbps
Media Coax, twisted pair, Coax, fiber 2 Twisted-shielded pair, flat
fiber, wireless
Redundant Media Yes Yes No
Intrinsic safety No Yes No
Standard IEEE 802.3 IEC 61158 CENELEC CENELEC EN 50325
EN501 70 IEC 62026
Table 2: CIP’s field busses
CIP is a peer-to-peer object oriented protocol that provides connections between
industrial devices (e.g. sensors) and higher-level devices (e.g. controllers). A device
consists of different CIP objects from the CIP common object library depending of
the type of the device but some objects are common for every CIP device, for
example the identity object.
22
CIP has the two following main tasks:
- Transportation of control-oriented data associated with I/O devices
- Transportation of other information which is related to the system being controlled
(e.g. configuration parameters or diagnostics)
7.2.2 Producer/Consumer Data Model
CIP supports the Producer/Consumer data model that describes how information is
forwarded on the data-link layer. The producer/consumer model provides the
following benefits over the traditional Client/Server and Source/Destination model:
• Multiple nodes can consume the same data from a single producer
• Nodes can be synchronized
• Optimized bandwidth potential for increased performance
• Protocol easily handles collection, configuration and control data over the same
network.
• No system master needed for network management.
The producer/consumer model supports polled, cyclic, change of state, and multicast
I/O data exchange.
The producer/consumer packet consists of a unique identifier (connection ID) at the
front of each packet. The devices are configured to respond to a particular identifier
and several devices can respond to the same identifier. With the source/destination
model, devices can only receive packets with their destination device number and if
more than one device needs the same data it must be transmitted multiple times.
Figure 5 and 6 illustrates the difference how information is forwarded between the
two models.
Figure 5: The source/destination model
23
Figure 6: The producer/consumer model
7.2.3 CIP Object Model
CIP uses an abstract object model to describe which communication services are
available and the externally visible behavior of a device. A CIP node consists of a set
of objects; each object is an abstract representation of a particular component within a
product. Objects are structured into classes, instances, attributes and services, see
table 3 for an object class example. A class is a set of objects that all represent the
same kind of system component. All objects in a class are identical in form and
behavior. An instance is a specific object in a class and each instance of a class has
the same attributes but different attribute values. Attribute is a description of an
externally visible characteristic or feature of an object and are divided into two
sections, class attributes and instance attributes. A class attribute is shared by all
objects within the same class, for example revision number, max instance or number
of instances. Instance attributes are unique to an object instance and not shared by the
object class, for example vendor identification number, device type or serial number.
Service is an operation or function that an object performs after a request from
another object; examples of services are reset, start or stop.
Class Instances Attributes Attribute Values
Country Sweden Population 8.000.000
Capitol Stockholm
England Population 24.000.000
Capitol London
Table 3: Example of an object class
OBJECT ADDRESSING
The nodes and their objects are addressed by a uniform addressing scheme. Each
node, class, instance, attribute and service is assigned an identification value to
distinguish them from each other.
24
CIP node #1 CIP node #2
EtherNet/IP link
Instance #1
Instance #1 Attribute #1
Attribute #2
Instance #1 Object Class #7
Object Class #5 Instance #2
CIP node #3 Object Class #5
CIP node #4
IP address #4, Object Class #5; Instance #2, Attribute #2
OBJECT LIBRARY
CIP has (at present date) 46 commonly defined objects, 6 of these objects are network
specific, and the rest can be used in all three networks. The common objects can be
divided into three types: general use objects (e.g. Connection object, Message Router
object), application specific objects (e.g. AC/DC Drive object, Motor Data object)
and network specific objects (e.g. DeviceNet object). The general use objects can
exist in several different devices while the application specific objects only exist in
devices hosting such applications.
In a device are the following objects obligatory:
• At least one Connection Object
• An Identity Object
• One to three network link related objects (e.g. 2 network objects for EtherNet/IP)
• A Message Router Object (at least its function)
Additional objects are added according to the functionality of the device. This allows
for a good scalability of devices so that small device is not burdened with
unnecessary overhead. A developer uses the commonly defined objects but can also
create own objects or extend existing objects functionality. Figure 8 illustrates the
object model of a device with a subset of different objects.
Figure 8: Object model
25
Identity Object
The Identity must be provided in every CIP device and it provides identification and
general information about the device. It is possible to have multiple Identity objects in
a device.
Attribute Name Description
ID
1 Vendor ID Identification of vendor
2 Device Type Identification of general type of product
3 Product Code Identification of a product
4 Revision Revision number
5 Status Summary status of device
6 Serial number Serial number of device
7 Product name Readable identification of device
Table 4: Identity Object Attributes
Message Router
The client uses the Message Router object as a connection point for messages. All
explicit request/response messages are handled by the message router. The client can
address services provided by any objects and instances residing in the device. The
Message Router routes all CIP messages that are not sent to an object using a direct
connection. Performs CIP routing (not network wide) defined by the Message Router
path segments.
Assembly Object
The Assembly object binds attributes from multiple objects in the device to a single
connection. Assembly instances can be either dynamic or static. When using dynamic
assembly, instances of the member lists can be altered by adding and removing
members. The static assembly instances are specified in the device profile. The
member list and instance parameters are fixed.
Connection Object
Every CIP connection is represented by a connection object. The connection object
can be created in two different ways depending on the subnet that is used. If the
subnet defines that connections are created through the Connection Object, a CIP
device must support the Create service for this class. The Create service instantiates a
connection instance. If the subnet defines that connections are established through the
Connection Manager Object the CIP device shall support the Forward Open service.
When the Forward open service is successful it instantiates an instance of the
Connection class. The connection instance is configured with the parameters provided
with the Forward Open request.
Connection Manager
The connection manager class allocates and manages the internal resources associated
with both I/O and explicit messages. The specific instance generated by the
connection manager is called connection instance or connection object. The
Connection Manager processes all forward open and forward close services.
26
Code Command Note
0x4E Forward Close Closes a connection
0x52 Unconnected Send Only for originating devices
0x54 Forward Open Opens a connection
0x56 Get Connection Data For diagnostics of a connection
0x57 Search Connection Data For diagnostics of a connection
0x59 Ex Forward Open Open connection larger than 504 bytes (N/A)
0x5A Get Connection Owner Determine the owner of an redundant connection
Table 5: Connection Manager Object Instance Object Specific Services
TCP/IP Interface Object
The TCP/IP Interface Object makes it possible to configure an EtherNet/IP device’s
network interface. The configurable parameters are IP address, gateway address and
subnet mask. The TCP/IP Interface Object can be associated with any interface that
supports the TCP/IP protocol.
Ethernet Link Object
The Ethernet Link Object maintains link specific counters and status information for
an Ethernet 802.3 communications interface. Typical device attributes stored are
interface speed and physical address (MAC).
Application Objects
Application specific objects may be connectable or not connectable. The Connectable
objects may be defined as connection points in a forward open request. When
establishing connection data and messages will be routed directly to the object.
The unconnected objects will have their messages routed by the Message Router.
27
7.3 Messaging Protocol
CIP is layered on top of a connection-based network. A CIP connection provides a
path between multiple applications. The following two types of connections can be
established:
• I/O connections (Implicit messaging)
• Explicit messaging connections
Both of the connection types can be bridged between different networks. When a
connection is established, the transmissions associated with the connection are
assigned a Connection ID. A message packet consists of a Connection ID and
associated data (either I/O data or information data).
EXPLICIT MESSAGE CONNECTIONS
Explicit Messaging Connections are connections between two devices only and they
provide the typical request/response-oriented network communications; see figure 9.
Each request contains explicit information that the receiving node decodes, executes
upon and then generates a suitable response. An explicit message is triggered by
event external to the application layer of CIP and uses the TCP/IP protocol for
transferring the none-time critical data. Examples of explicit messages are
downloading programs and peer-to-peer messaging between two PLC’s.
Request
Response
Figure 9: Explicit messaging
IMPLICIT MESSAGE CONNECTIONS
I/O connections or implicit messaging provide special-purpose communication paths
between a producing application object and one or more consuming application
objects. I/O connections are typically used when the data transfers are time critical or
to obtain a cyclic data synchronization between one producer and one or more
consumers. I/O connections may be producing only, consuming only or producing
and consuming and it uses UDP/IP for transferring the data. There are four main types
of implicit message available in the CIP specification:
• Polled: a master device sequentially sends inquiries to the slave devices and
receives a reply with their input data.
28
• Strobed: special case of polled message. A master sends out a single multicast
request for data and the slaves sequentially send their data to the master, without
any further messages required by the master.
• Cyclic: a producing device sends messages on a predetermined scheduled; any
device that needs this data accepts the packets from the producing device.
• Change of state: similar to cyclic, but data is produced in response to an event
which caused the data to change.
The implicit message type that is recommended to use on an EtherNet/IP network is
the cyclic message type because of the balance between data integrity and network
traffic optimization. For an example of sending an I/O message from one device to
another, see figure 10.
Figure 10: Implicit messaging
UNCONNECTED MESSAGE MANAGER (UCMM)
Most messaging on a CIP network is made through connections and the UCMM
assignment is to establish connections between devices that are not “connected” yet.
This includes establishing both Explicit Messaging and I/O Connections.
7.4 Device profiles
To provide interoperability and support interchangeability by similar device types
there must be some consistency between the devices. The devices shall:
• Show the same behavior
• Produce and/or consume the same basic set of I/O data
• Contain the same basic set of configurable attributes
To achieve this, a device profile is created that consist of an object model for the
device, I/O data format for the device type configuration data and the public
interface(s) to that data. Since each device type has the same required objects, devices
from different vendors have the same behavior and can therefore work together.
29
SETTING UP A CONNECTION TO A DEVICE
To initiate an explicit connection with a target device a socket is opened and
connected to the TCP-port 0xAF12. All explicit communication must start with a
Register Session Request. The target responds with a connection handle that will be
used until the TCP connection is closed or an UnRegister Session Request is sent by
the originating node.
After a successful Register Session the originating node can send any explicit
messages to the target using the session handle received.
An example showing the messages that are sent when setting up a connection and
making a Get Attribute Single request to receive the device’s Vendor ID.
Register Session Request
Register Session Response
(Session Handle)
RR Request
(Get Attribute Single, class1,
instance1, attrib 1)
RR Response
(Vendor ID)
UnRegister Session
Close socket
Figure 11: EtherNet/IP connection
30
7.5 EtherNet/IP Encapsulation Protocol
The encapsulation protocol is used to encapsulate CIP on a TCP/IP network. The
encapsulation protocol specifies that the TCP/UDP port 0xAF12 shall be supported
and used by all EtherNet/IP devices. The device must support two or more TCP
connections on the specific port. The encapsulation protocol server handles all
encapsulation between TCP/IP and CIP.
All encapsulated messages shall be composed by a 24 byte header followed by
optional data. The max length of a message is 65535 bytes including header. Not like
most Internet network protocols all multi byte fields in the encapsulated message
should be transmitted in little-endian byte order.
7.5.1 Encapsulation Header
Name Size (bytes) Description
Command 2 Encapsulation command
Length 2 Data length
Session Handle 4 Session ID
Status 4 Status Code
Sender Context 8 Information that is only for the sender
Options 4 Options flags
Table 6: Encapsulation header
LENGTH
The length field specifies the total size of the message data potion. Thus the total size
of the encapsulated CIP-message is the data potion + the protocol header (24 bytes).
SESSION HANDLE
The session handle is generated by the target device when after a connection attempt.
The sender includes the session handle in all subsequent messages sent.
STATUS
The status field indicates if the receiver was able to execute the encapsulated
command. If the execution on the command was successful the status field in the
response should contain a zero. All request messages that not contain zero in the
status field shall be ignored by the target and no response generated.
SENDER CONTEXT
The value provided in the sender context is provided by the sender and should be
returned by the target without modification.
31
OPTIONS FIELD
The sender of an encapsulated packet shall set the options field to zero and the
receiver checks if the options field is zero. The purpose of this field is to be able to
send various options with the encapsulation commands. But since there is no options
specified for the command the field has to be zero.
7.5.1 Encapsulation Commands
When a message containing an unknown command is received by a device the
connection is not supposed to be broken. A status code in the reply should indicate
that the command is not supported. The Send RR Data and Send Unit Data are passed
on to the CIP stack instead of being handled locally like the other requests. Incoming
I/O data are passed to connection transport when received on UDP. Outgoing I/O data
are transmitted on UDP address associated with the connection.
Code Command Note
0x0000 NOP Provides a way for the sender to test if the connection is
till open (TCP)
0x0004 List Services Determines which encapsulation services the target
supports (UDP or TCP)
0x0063 List Identity Can be used by a connection originator to identify
potential targets (UDP or TCP)
0x0064 List Interfaces Can be used by a connection originator to identify
potential non-CIP interfaces associated with the target
(Optional, TCP or UDP)
0x0065 Register Session Sent by a originator to initiate a session (TCP)
0x0066 Unregister Session Sent by originator or target to terminate a session (TCP)
0x006F Send RR Data Sends encapsulated Request/Reply packages (TCP)
0x0070 Send Unit Data Sends encapsulated connected messages, a reply should
not be generated(TCP)
0x0072 Indicate Status (TCP)
0x0073 Cancel (TCP)
Table 7: Encapsulations commands
NOP
The NOP command may be sent by all nodes. No reply should be sent to a received
NOP command. The data size may be 0 to 65511 bytes long. All data should be
ignored.
32
LIST IDENTITY
The List Identity command can be sent by using TCP or UDP and it does not require
an established session. The primary usage for this command is to broadcast it to
identify potential targets. The List Identity response sent by the target contains the
same information as the attributes of the identity object.
LIST INTERFACES
The List Interfaces encapsulation command is used to identify potential non-CIP
interfaces. Like the List Identity command it is not necessary to register a session
before sending the request. The command may be sent using both TCP and UDP.
REGISTER SESSION
The Register Session command is used by an originating node to initiate a session
with the target node. The target node responds with a generated session handle that
must be included in the requests and responses until the connection is closed or an
Unregister Session is received.
UNREGISTER SESSION
The Unregister Session command is used to close a session that has been established
using Register Session. This can be useful if a node need to end a session without
closing the socket.
LIST SERVICES
The List Services command can be used to identify a targets communication
capability. The target reply contains information of which CIP-classes that are
supported and if the device supports TCP and UDP.
SEND RR DATA
The Send RR Data command is used to transfer encapsulated request/reply packets.
The encapsulated packet is located in the data potion of the message and is processed
by the originator and target. A request/reply packet is sent to a specific class or
attribute of an instantiated class and therefore the target class determines what
services that are available.
SEND UNIT DATA
If the encapsulation protocol has its own underlying end-to-end transport mechanism
the Send Unit Data command can be used. The command is for connected TCP
messages with no reply generated. Send Unit Data can be sent by both originator and
target.
33
7.6 CIP Configuration
With CIP is it possible to remotely configure devices across the network and for
embedding configuration parameters in devices. With these features it is possible to
select and modify device configuration settings for use in a particular application.
Devices containing configuration settings available through CIP communications
interface needs a configuration tool to change the settings. CIP supports the following
methods to configure devices:
• A printed data sheet
• An Electronic Data Sheet (EDS)
• Parameter Objects and Parameter Object Stubs
• A combination of an EDS and Parameter Object Stubs
• A Configuration Assembly and any of the above methods
If the configuration information is gathered on a printed data sheet, the configurations
tools can only provide prompts for service, class, instance and attribute data and
forward the data to the device but it do not determine the context, content or format of
the data. Parameter Objects provide a known public interface to a device’s
configuration data values, descriptive text and data limits, default, minimum and
maximum values. One disadvantage with this method is that it could be too much
information for small devices. Parameter Objects Stubs can be used instead.
Parameter Object Stubs provide an established address to a device’s configuration
data values without requiring specification of descriptive text, data limits and other
parameter properties. A combination of EDS and Parameter Object Stubs provides
the full functionality and ease of use of the Parameter Object without burden the
individual devices. The Parameter Object Stubs provide a known public interface to a
device’s parameter data values while the EDS provides descriptive text, data limits
and other parameter properties. Configuration using a Configuration Assembly allows
for bulk upload and download of configuration data.
34
7.6.1 Electronic Data Sheet
An EDS is a file on disk that contains configuration data for specific device types. It
supplies information about the configuration data context, content and format and it is
also possible to change the configurable parameters of the device. EDS provides an
open standard for device configuration and compatibility between CIP products and
may contain vendor-specific device parameter information. A CIP configuration tool
must be able to:
• Load the EDS into the configuration tool’s memory.
• Interpret the EDS contents to determine the characteristics of each parameter.
• Provide the user with a list of alternatives for each device parameter.
• Load the user’s parameter choices to the correct parameter address in a device.
To perform the actual configuration, a configuration tool uses CIP messaging to
execute the changes in the device; for an overview on how to configure, see figure 12.
Figure 12: Configuration using an EDS
Enclosure 1 illustrates a part of a modified Electronic Data Sheet for the Flex input
module.
35
7.7 Bridging and routing CIP
The CIP protocol provides bridging capabilities between the DeviceNet, ControlNet
and EtherNet/IP. The routed data have the same path all the time; this to insure
consistent I/O transactions time. A message sent from a device on EtherNet/IP to a
device on DeviceNet, via ControlNet will have a number of hops between the
different networks. The routing information is found in the port segment (se chapter
7.8, Data Management). Each port segment represents a hop in the path, from one
network to another. The CIP router removes the port segment from the path before
forwarding the message to the next destination. The port segment informs the router
which port (network) to send the message on and the node address of the destination
node on the network. The final target in the path receives only a connection path
without a port segment. From the destination to the arrival at the DeviceNet the CIP
frame will remain intact. The frame will first exist in a TCP or UDP packet and then
in a ControlNet packet and finally in a CAN packet.
The following section describes how a message is sent from a DeviceNet module to
an EtherNet/IP module; an overview of the modules with addresses is illustrated in
figure 13. The requesting device on the DeviceNet network sends the message to the
DeviceNet router and the connection manager object in the DeviceNet router (Port 2)
examines the message route-path. The path tells the connection manager that the next
hop is the EtherNet/IP router (Port 3) and the node address is the IP-address of the
target device (192.169.0.10). Since this is the only Port/Node address pair specified in
the route-path the messages has reached its destination network and the message is
delivered to the target device on the EtherNet/IP network. The target device then
returns an answer to the requesting device on the DeviceNet network through first the
EtherNet/IP router and then the DeviceNet router.
DN EN
Router Router
Requesting Port ID Port ID Target
Device =2 =3 Device
Mac ID = 5 Mac ID = 7 IP Address 192.169.0.11 IP Address 192.169.0.10
DeviceNet (DN) EtherNet/IP (EN)
Figure 13: A single hop between DeviceNet and EtherNet/IP
36
7.8 Data management
Data management describes addressing models for CIP nodes and the data structure
of the entities themselves. The node addressing is performed with CIP segments. A
CIP segment is a stream of encoded items used to describe, reference and/or
configure a specific CIP node. A common use of CIP segments is to specify
relationships among different CIP objects. A value used to specify such relationship is
referred to as a path and a path attribute consists of multiple segments. In the
connection object and connection manager object; a path indicates to/from which
object that I/O data is moved. A segment contains information about the segment
type, the format of the segment data and the actual segment data. Examples of
segment types are:
• Port segment
• Logical segment
• Network segment
• Symbolic segment
• Data segment
PORT SEGMENT
The port segment informs which communication port is used for leaving the node
and the link address of the next device in the routing path.
LOGICAL SEGMENT
This segment selects a particular object address within a device, an address contain
the object class, instance and attribute.
NETWORK SEGMENT
The network segment is used to specify the network parameters that are required by a
node for transmitting a message across a network. This segment is the first item in the
path that a device receives.
SYMBOLIC SEGMENT
This segment contains an International String symbol (for example Japanese symbols)
which is interpreted by the device.
DATA SEGMENT
This segment provides a mechanism for delivering data to an application.
37
8 EtherNet IP Configuration
8.1 EtherNet/IP addressing issues
The addressing and configuration of EtherNet/IP equipment is one of the things
EtherNet/IP has not yet standardized. One of the most important issues is when a
malfunctioning device must be replaced and the new device needs to be configured to
act like the old one. Some of the methods that can be implemented to handle the
configuration of EtherNet/IP devices are:
• Serial Configuration
• Removable EPROM
• Mechanical Switched
• LCD and Keypad
• "Smart Switch" (Remembers the IP address of the device plugged into particular
physical port.
• BOOTP/DHCP
When listing all the alternatives it is clear that the problem is not how to configure the
device but to configure it in a standard way. The EtherNet/IP developer's workshop is
working on the standardization issue.
INITIAL CONFIGURATION
Most EtherNet/IP clients require a static IP address for the communications. When a
device still has not got any IP address the only way to communicate over Ethernet is
through low-level protocols using the device's MAC address. On power-up the device
should issue a DHCP or BOOTP request.
8.2 BOOTP - Bootstrap Protocol
The bootstrap protocol lets devices connected to a network to be automatically
configured. The services provided could include retrieving an IP address, DNS server,
default gateway or having an OS or service booted without any user interference.
BOOTP needs a server managed by a network administrator that automatically
assigns IP addresses from a pool of available addresses.
38
8.3 DHCP - Dynamic Host Configuration Protocol
The DHCP protocol can be seen as a more advanced version of the BOOTP protocol.
It provides all the services the BOOTP protocol supports. DHCP supports assigning
of both static and dynamic addresses. A DHCP server is configured with a range of
available IP addresses to assign to the devices on the network. The main difference
between BOOTP and DHCP is that DHCP can be configured to lease an IP address to
a client for at specific amount of time.
How the DHCP protocol works:
1. Client broadcast DHCPDISCOVER package
2. DHCP servers respond with DHCPOFFER
3. Client responds DHCPREQUEST (I choose server X, my MAC is Y, what's my
IP)
4. Server sends DHCPACK (You're IP is A, It is good for B hours)
5. If the client is done with the IP it sends DHCPRELEASE
39
9 PLC
9.1 Technology
A Programmable Logic Controller (PLC) is a computer-type device used in process
control applications. PLC performs logical operations on input signals and then
generates output signals. PLC’s are designed for high-speed, real-time and rugged
industrial environments. Advantages with using PLC are for example high reliability,
small space requirements and expandability.
9.2 IEC 1131
IEC 1131 is an international standard for programmable controller languages.
Completed in 1993 after twelve years in the making, IEC 1131 was developed in
response to industry pressures for greater compatibility among programmable
controllers. The goal was to develop a portable, extendable language that would
eliminate proprietary barriers and their associated training costs. The resulting multi
language specification combines modern software engineering principals with the
best of existing programming languages.
IEC 1131 consist of
• General Information
• Equipment and test requirements
• User guidelines
• Communications
• PLC programming languages
40
9.3 PLC Programming languages
LD (LADDER DIAGRAM)
A graphical method that is best suited for persons that are familiar with relay controls.
SFC (SEQUENTIAL FUNCTION CHARTS)
SFC is a graphical method of organising a program. SFC consists of three main
components; steps, actions and transitions. Steps can be seen as a block of
programming logic that performs a particular task. Actions are specific aspects of the
steps task. Transitions are the mechanisms for moving from one task to another. The
control logic for each of the steps in SFC is programmed using one of the other
languages like Ladder Diagram or Structured text.
FBD (FUNCTION BLOCK DIAGRAM)
The function block diagram is used for applications that require a high information
and dataflow like process control. Like SFC this is a graphical method allowing
programming in other languages and connecting them within FDB.
ST (STRUCTURED TEXT)
Structured text is a high level language that has similarities with Basic or Pascal
programming languages. It is best suited for the realization of algorithms that requires
more math or complex solutions. People that are trained in computer programming
tend to prefer structured text prior to other PLC programming methods.
IL (INSTRUCTION LIST)
Instruction list is a low-level programming language for PLC's. It has similarities with
assembly language and is considered difficult to learn in conjunction to the other
programming languages. The primary area of use is when writing small functions that
are repeated often.
41
10 Embedding EtherNet/IP in a product
10.1 Selecting application layer protocol
APPLICATION LAYER INTEROPERABILITY
Since the application layers of the different field busses are unable to communicate
with each other the situation may look the same as before the introduction of Ethernet
field busses with no standardization. But the introduction of Ethernet is a step forward
when the ISO layers 1-4 are the same for all protocols. When the first four layers are
the same it is possible for the different application level protocols to coexist on the
same wire. With the mentioned conditions there is nothing that stops a device
manufacturer to implement support for several different Ethernet field buss protocols
at the same time.
10.2 Different approaches integrating EtherNet/IP
USING A GATEWAY
If you want to use the existing equipment and have a fast time-to-market it is possible
to purchase a serial gateway. The only requirement is that your equipment must
support some standard serial communication protocol. The data will be transferred at
a data rate of 1200-19200 baud. By using an off-the-shelf gateway the only real
benefit with this solution is the short time-to-market. Some of the drawbacks are
costs, special gateway configuration tools, the characteristics of the device are lost
and all data is represented as generic data.
ADD-ON PCB BOARD
Another solution much like the gateway-approach with a fast time-to-market time is
to use/buy an add-on internal PCB daughter board. The advantages over the gateway
solution is that the add-on board can be used for making a more flexible and
configurable product. If the product has other communication ports to systems this
might be a good way to get a customized solution fairly quick.
IC/SYSTEM-ON-CHIP (SoC)
Since there are several Microprocessors available that has got embedded Ethernet and
TCP/IP protocols. When building a new device this gives good opportunities as you
can control the object model implementation and messaging characteristics. Another
similar design opportunity would be to create a SoC solution using an own stack or
purchase an existing one. There are no obvious drawbacks with this approach except
that it takes resources and time to implement.
42
PURCHASE TCP/IP & ETHERNET/IP STACK
When using this approach that involves buying a pre-made stack you are given a
stack that hopefully is tested and works satisfactory. This gives you more control over
the development and implementation but you have to take care of the integration of
the stack with CPU, TCP/IP Stack and operating system (if used). The advantages are
the low costs and the flexibility of the implementation. The drawbacks are that the
work effort and time-to-market increases significant together with possible
interoperability problems for the third part products.
DO IT YOURSELF
If absolute control over the design and implementation is important, one solution is to
make the stack and the integration yourself. The obvious advantages are the complete
control over the design and the flexibility when adding functionality. The drawbacks
are that the costs to develop from scratch are more expensive than buying available
products and the time-to-market period is mostly uncertain since it is hard to predict.
43
11 Test platform
The decision of what approach to use when implementing and testing EtherNet/IP
was taken by ABB Robotics to suit their future needs. Their decision was to use an
EtherNet/IP stack from Wind River to integrate in the S4C+ Robot controller and use
it together with a ControlLogix (PLC and I/O) system. The test system was setup by
us except for the integration of the EtherNet/IP stack in the S4C+ system.
11.1 Hardware
Figure 14 illustrates the test platform used in this thesis.
P ENBT DO ENBT DNB
L #1 #2 Scanner
C
D328 DeviceNet I/O
Test Module
Switch/HUB
S4C+ Robot
Flex I/O Digital In Digital Out PC1 PC2
Adapter
Figure 14: Test platform
44
11.1.1 ControlLogix Platform
The ControlLogix system is a multiprocessing system from Allen-Bradley with
emphasis on communication. The system provides sequential-, process-, motion- and
drive-control together with advanced I/O diagnostics. The ControlLogix can also be
used as a gateway by including communication modules for connectivity to other
networks, without including a controller. Each module (processor, I/O or
communication) has an intelligent backplane interface. The backplane inside the
chassis it called the Control Bus backplane and it operates like a mini network that is
based upon the ControlNet producer/consumer network. A chassis is available in 5
different dimensions of module slots (from 4 slots to 17 slots) and a module can be
placed into any slot. It is possible to have multiple processors, communication
interfaces and I/O modules in the same ControlLogix chassis. Figure 15 illustrates a
chassis with 7 different modules. For an example of how to create, program and run
one ControlLogix controller with Flex digital I/O modules, refer to enclosure no 2.
Figure 15: Controllogix chassis
CONTROLLOGIX 5555 PROCESSOR (1756-L55M12)
The ControlLogix Processor have integrated motion control and can also monitor and
control I/O across EtherNet/IP, DeviceNet, ControlNet and Universal Remote I/O
links. The processor module is available in a selection of user memory, from 64K to
7.5M bytes; in this thesis a processor with 750K bytes of memory will be used. The
ControlLogix processor has a multi-tasking operating system that supports up to 32
configurable tasks.
CONTROLLOGIX BRIDGE MODULE
To be able to bridge or route information between different networks, network
specific bridge modules are plugged into the ControlLogix chassis. No processor is
needed in bridging and routing between the different networks. The bridge module
can function as an interface between network specific devices and the Logix5555
processor and it can also communicate with network specific devices over the
network to read inputs from the device, write outputs to the device or download
configuration data. Is it not necessary to configure a routing table for the bridge
module because the producing device contains the whole path to the consuming
device. Other devices on the way just pass the packet on without storing it. With
multiple bridge modules (one for each network) in a ControlLogix chassis is it
possible to communicate between EtherNet/IP, DeviceNet, ControlNet, RS-232 and
45
Data Highway Plus networks. Through a web-browser is it possible to view: module
information (product name, vendor etc), TCP/IP configuration (e.g. IP address and
Ethernet address), diagnostic information (encapsulation statistics or UDP statistics)
and chassis configuration.
Two network specific bridge modules are used in this master thesis:
• EtherNet/IP Bridge Module (1756-ENBT)
• DeviceNet Scanner Module (1756-DNB)
CONTROLLOGIX I/O MODULE (1756-OB16E)
ControlLogix have different types of I/O modules and the one used in this thesis is the
1756 OB16E. The output module has 16 digital outputs and the letter E in its name
stands for electronically fusing. The output module can reside in a local or remote
chassis (depends where the owner- controller is located). If an output module is in the
same chassis as the owner-controller it receives the data almost immediately after the
controller transmitted the data because the backplane transfer time is short. When an
output module resides in a remote chassis the owner-controller transmits data as least
as often as the module specified RPI rate. The minimum RPI for a remote output
module is 2.0ms.
11.1.2 FLEX I/O
The Flex I/O is a modular system made for distributed applications. The Flex I/O
system consists of three components: adapter, terminal base unit and I/O modules.
The terminal base units and I/O modules are network independent, only the adapters
are network specific. The system has Plug-n-Play operability and it is possible to mix
and match multiple I/O to multiple devices. Flex supports only the cyclic I/O message
type.
ETHERNET FLEX I/O ADAPTER MODULE (1794-AENT)
An EtherNet I/O adapter module provides an interface for communication between
one or more I/O modules and one scanner via an EtherNet/IP link. The adapter
module uses the CIP protocol and supports both real-time I/O data (implicit
messaging) and explicit messaging. The adapter module has a web-server and it is
possible to get module information there, for example TCP/IP configuration and
diagnostics information. To view these web pages enter the adapter IP address in a
standard web browser.
TERMINAL BASE UNIT
A terminal base module creates a backplane for the FLEX I/O module(s) and provides
connections between the I/O adapter module and the I/O modules. Each I/O module
and adapter plugs into an individual base unit.
46
I/O MODULE
The I/O modules offer a selection of 4 to 32 I/O each. In this master thesis one input
and one output module with 16 digital I/O’s are used. Up to 8 I/O modules can be
used together with one I/O adapter module.
11.1.3 DeviceNet Module
When testing the bridging functionality between DeviceNet and EtherNet/IP the
D328 DeviceNet module from ABB was used. The D328 is a digital in/out DeviceNet
module for test purposes.
11.1.4 S4C+ Robot controller
The S4C+ is a robot controller and the target platform for the implementation of
EtherNet/IP. Since the integration of the EtherNet/IP stack from Wind River was not
a part of this master thesis the only contact with the S4C+ were during the
performance tests.
11.1.5 Switch/HUB/Cables
All the Ethernet network components used in the tests are standard off the shelf
products. If setting up an EtherNet/IP network for operation in an industrial
environment with possible high noise levels it is not recommended to use standard
off-the-shelf Ethernet components. Several manufacturers offer Ethernet hardware
suited for industrial use. The Ethernet equipment used for the test platform:
• Intel InBusiness 8-Port 10Mbit HUB
• D-Link DES-1008D 8-Port 10/100Mbit Switch, type: store and forward.
• D-Link 10/100Mbit Network Interface Cards
• Twisted Pair Cables, RJ45-Cat5
47
11.2 Software
The software products that have been tested and evaluated have been developed by
Rockwell Automation.
11.2.1 RSLogix 5000
The Logix platforms use RSLogix (Rockwell Software Logix) for sequential-,
process-, drive- and motion-control programming and for configuring I/O- and
communication modules. Programming logic can be done in a number of ways,
through a ladder diagram, a function block diagram, structured text and/or sequential
function charts. RSLogix also include an IEC1131-3 compliant interface.
A CONTROLLER PROJECT
A project file in RSLogix stores the logic, configuration, data and documentation for
a controller. When a new controller project is created, a Main Task, Main Program
and Main Routine are automatically created by the software. Each project has a
controller organizer that provides a graphical overview of the project (controller file).
The organizer consists of a tree of folders and files that contain all the information
about the programs and data in the project.
TASK
Tasks are used to schedule the execution of programs; there can be up to 32 tasks in a
controller project. One task can be continuous while the others are periodic.
Continuous task runs continuously through all assigned programs from top to bottom
and can be compared to a background task that is interrupted by all periodic tasks. A
project does not need to have a continuous task, by default the Main Task is a
continuous task but can be changed to a periodic task. A periodic task is triggered by
the operating system at a repetitive period of time and interrupts any lower priority
tasks. Periodic tasks are used for functions that require accurate or deterministic
execution.
PROGRAM
A program is a set of related routines and a collection of tags and is executed by the
task in which it is scheduled. Each program contains program tags, a main routine,
subroutines and an optional fault routine. If a task is large or complex is it possible to
break up the logic into multiple programs. A task can have up to 32 different
programs; each with its own local data and logic. If a task has more than one
program, the programs are executed in the order they appear underneath the task in
the Controller Organizer in RSLogix.
ROUTINE
A routine provides the executable code for the controller project. A routine is a
sequence of logic that is executed as a block. Each routine uses a specific
programming language (ladder diagram, sequential function chart, function block
diagram, or structured text).
48
The main routine executes first when a program executes and it is possible to call
other routines (so-called subroutines) within the program. Moreover, subroutines can
also call other subroutines. Routines are found in the Controller Organizer underneath
the chosen program.
TAGS
Tags are a named area of the controller’s memory where the data is stored. It is the
basic mechanism for allocating memory, referencing data from logic and monitoring
data.
GENERIC ETHERNET MODULE
This module type is used for non Rockwell products. In this case the module has been
configured for the S4C+ Robot controller. When creating the module the following
properties been stated: name, the robots IP-address or host name, Requested Packet
Interval, connection format, and connection parameters.
11.2.2 RSLinx
RSLinx (Rockwell Software Linx) is a factory communication solution that provides
PLC processor connectivity for several of Rockwell applications, for example
RSLogix 5000. With RSLinx is it possible to navigate through a network hierarchy
via a graphical interface, including routing over an office Ethernet network to get to a
control network and devices on the plant floor.
RSWho is the network browse interface that provides a single window to view all
configured network drivers. RSWho allows navigation through network hierarchy in
the left pane while displaying device icons along with their status in the right pane,
see figure 16.
To view th
Figure 16: Overview of the network hierarchy
49
RSLinx includes diagnostics options in three main categories; networks, station, and
Dynamic Data Exchange/OLE for Process Control.
11.2.3 RS Networx for DeviceNet
The RS Networx for DeviceNet is software for configuring DeviceNet networks.
When using EtherNet/IP together with DeviceNet the DeviceNet section of the
network must be configured using RS Networx for DeviceNet. The configuration file
generated by RS Networx is used with RS Logix to configure the interface to the
DeviceNet.
11.2.4 SoftLogix 5800
The SoftLogix controller is a software-based controller that resides in a Microsoft
Windows NT / 2000 environment and integrates sequential and motion control. The
SoftLogix system is based on three components: the Logix control engine, RSLogix
5000 programming software and a virtual chassis. The SoftLogix5800 controller uses
the virtual chassis monitor to display the devices in its system, these devices all reside
on a virtual backplane. The virtual backplane acts like a real hardware backplane in
that it connects the controller's devices and allows bridging. The chassis monitor can
be used to change the processor mode, monitor motion performance and configure the
controllers, communication interface cards. The SoftLogix supports communication
and I/O control over ControlNet and DeviceNet, not over EtherNet/IP but this will be
supported in a future edition. SoftLogix supports EtherNet/IP messaging. The
SoftLogix controller supports a software-based module (1789-SIM) that can be used
to simulate I/O points for an application and test logic written with RSLogix. To
understand how a SoftLogix System operates, a controller and a number of SIM-
modules were implemented. For an example how to create, program and run one
SoftLogix controller with one SIM-module, refer to enclosure no 3.
50
12 Tools
The following additional tools were used during the work.
12.1 RA BOOTP Server
To configure the network parameters of the EtherNet/IP Modules a BOOTP Server
from Rockwell Automation was used. The modules were configured with a static IP
address to avoid the need of having a BOOTP Server present on the network all the
time. The BOOTP Server can be used to alter the settings for a device by entering
current IP address or MAC address.
12.2 Ethereal
Ethereal is a free network protocol analyzer and it was used for logging and
debugging the traffic on the EtherNet/IP network. An EtherNet/IP plug-in from Wind
River was used to decode the EtherNet/IP frames sent since Ethereal does not support
EtherNet/IP. Ethereal allows browsing the captured data and viewing detailed
information for each packet. It also contains filter functionality that is useful when
logging busy networks.
Figure 17: Overview of Ethereal
51
12.3 EtherNet/IP Tool
The EtherNet/IP Tool was developed by us because there was no easy way to quickly
connect and send messages to an EtherNet/IP device for testing purposes. The
configuration software RS-Networx for DeviceNet contains a function called Class
Instance Editor that makes it possible to query the devices classes and instance
attributes. Since the RS Networx for EtherNet/IP not yet has been released a tool with
some basic functionality was implemented.
The other alternative when you want to setup a connection and send messages to an
EtherNet/IP device is to use RS Logix to program the PLC. A major disadvantage
when using the PLC for sending test and debug messages is the fact that a new
program has to be downloaded to the PLC every new test session.
Figure 18: EtherNet/IP Tool
To connect to a target device the IP address or Hostname of the device is entered
together with what object, instance and attribute to access.
EtherNet/IP Tool supports the following commands:
• Get Single Attribute (TCP)
• List Identity (TCP&UDP)
• List Interfaces (TCP&UDP)
• List Services (TCP&UDP)
• NOP (TCP)
The data returned by the target device is displayed in the received data field and all
messages are logged to a log-file. The data can be displayed in hexadecimal, binary or
decimal.
52
13 Results
13.1 Performance
The test platform performance was tested with respect to I/O timing when using a
dedicated network with no network load and while using the network for other traffic.
13.1.1 Performance terms
THROUGHPUT
Throughput is the maximum continuous traffic rate that a device can handle without
dropping a single packet. It is measured in terms of the number of frames per second
at a given frame size.
LATENCY
The time between a message is sent to a device and a corresponding event occurring
at the device.
WORST CASE JITTER
The jitter is defined as the difference between the minimal and maximal latency.
OVERLOAD BEHAVIOR
Overload behavior describes the behavior of a device operating in an overloaded
state. Important considerations are the devices ability to recover from an overloaded
state and the response to system management in an overloaded state.
STANDARD DEVIATION
The standard deviation is a measure of how widely values are dispersed from the
average value. The formula is: √ ( (n∑x2- (∑x)2) / n(n-1) ) .
REQUEST PACKET INTERVAL (RPI)
RPI is the update rate specified for a particular piece of data on the network, it can
also be called a cyclic update. RPI is specified for example adapters and I/O modules,
and it states how often the modules will receive or transmit data. If RPI is set to 20ms,
the module send data to the controller or the controller send data to the module every
20 ms. RPI has a minimum and maximum value that is module dependent, in a Flex
I/O module the RPI can be between 2.0 to 750 ms, while in a ControlLogix I/O
module the RPI interval is between 0.2 and 750 ms.
RACK AND DIRECT CONNECTIONS
A module can have a direct or rack connection, see figure 19 and 20.
Direct Connection
This kind of connection is a real-time data transfer link between the controller and a
module. A direct connection transfer messages at a cyclic rate specified by the RPI
value. The RPI value can be set individually for each module and is set during
configuration of the module. This type of connection must be used for analog
modules.
53
ControlLogix chassis Flex adapter and digital I/O modules
with a controller
Direct connection, RPI =5ms
Direct connection, RPI =10ms
Figure 19: Direct connection
Rack Connection
With a rack connection only one connection is needed instead of having multiple
connections between the controller and the modules. One disadvantages with rack
connections is that is only possible to send I/O data and status information,
diagnostics are for example not available through this connection. Rack connections
only supported for digital modules.
ControlLogix chassis with a controller Flex adapter and digital I/O modules
Rack connection, RPI=5ms
Figure 20: Rack connection
54
13.1.2 Performance measurements
The performance measurement was performed between the different modules in the
test platform, for example between Flex Input and Flex Output. The equipment used
for these measurements were the test platform (see chapter 11), a Hewlett Packard
53131A 225MHz Universal counter and the software product RSLogix. With the HP
Universal Counter is it possible to measure time intervals between two signals and
receive statistics from the measurements. The time interval is measured from signal
1’s positive slope until signal 2 is high. The statistic function of the HP counter
delivered the maximum, minimum, and average latency and the standard deviation.
The statistic calculations are based on 1000 measurements. The worst-case jitter was
calculated from the maximum and minimum values.
The measurements were performed with different network load to get a realistic
behavior of a network. The network load was stimulated through a FTP-server with
various speeds, from 50kbytes/s to full speed (1000kbytes/s). The files that were
transferred were of different size and that resulted in that the speed varied during the
transfer. When measured towards the robot, the robots own FTP-server was used; this
resulted in a FTP-transfer speed of approximate100kbytes/s.
Both a switch and a hub were connected to the network (not at the same time). The
reason was to see if there were any improvements in the measurements when a switch
was used and how they operate under different network load.
REQUESTED PACKET INTERVAL (RPI)
Table 8 specifies the RPI’s used for the different modules in the test platform. The
local Ethernet/IP bridge module (the one that resides in the same chassis as the
controller) does not require an RPI because it is not a data-producing member of the
system; it is only used as a bridge to remote racks.
Module RPI (ms)
Flex I/O 3.0
1756 Digital Output 0.2
DeviceNet scannner 5.0
EtherNet/IP bridge, remote 5.0
Robot 1.0
Table 8: RPI for the modules
The DeviceNet I/O module does not have a RPI but has an interscan delay of 10 ms.
THEORETICAL CALCULATIONS
ControlLogix controllers update data asynchronous with the execution of logic. Over
an Ethernet/IP network remote data is sent close to the RPI, on average. The
theoretical time it takes to send a message between two modules is shown in the table
9. These theoretic calculations is based on that the data is sent cyclic without any
delay. The time is in milliseconds.
55
Modules Flex 1756 OUT 1756-DNB DN I/O Robot Sum
Flex In – Flex Out 3.0 + 3.0 6.0
Flex In – DN Out 3.0 5.0 10.0 18.0
Flex In – 1756 Out 3.0 0.2 3.2
Flex In – Robot 3.0 1.0 4.0
DN In – Flex Out 3.0 5.0 10.0 18.0
DN In – DN Out 5.0 10 + 10 30.0
DN In – 1756 Out 0.2 5.0 10.0 15.2
DN In – Robot 5.0 10.0 1.0 16.0
Table 9: Theoretically calculations
Explanation of table 9: The time it takes from a input signal is set in the Flex module
until the signal is set in the DeviceNet output module is 18 ms. This time is calculated
with the following approach: the input module send data every 3 ms to the plc and the
plc send data to the DeviceNet scanner module close to every 5:th ms, the module in
its turn send data to the DeviceNet I/O module every 10:th ms. Furthermore, latency
in the network and plc-execution time can be added to these calculations. Example of
latency is the switch that has latency between 7.2µs-1.5ms. Moreover, since UDP
protocol is used to transfer I/O messages there is no guaranteeing that the message
will be delivered.
The RPI of the remote EtherNet/IP bridge module is not included in these theoretical
calculations since data is transferred according to the RPI of the DeviceNet scanner
module.
13.1.2 Analyze and Result
In this chapter the result from the performance measurements is presented, and a short
analysis of the measurements is made.
FLEX DIGITAL INPUT – FLEX DIGITAL OUTPUT
Both a rack and direct connection can be set up between the PLC and the FLEX I/O
modules, both connection types have been used during the measurement.
Different RPI’s of the direct connections was tested and evaluated to find an adequate
RPI for the rack connection. The rack connection RPI was set to 3 ms because the
FLEX I/O modules could not be updated faster.
The measurement with different direct connection RPI is shown in table 10; these
measurements were performed only with a hub connected to the network and no
network load.
Originator Target Mean Max Min Jitter Std dev RPI
Flex-DI Flex-DO 6,34 9,87 2,45 7,42 1,42 3 / module
Flex-DI Flex-DO 5,62 8,84 2,23 6,61 1,13 2 / module
Flex-DI Flex-DO 5,82 9,70 2,80 6,90 1,15 2.5/module
Table 10: Direct connection, measured in milliseconds
56
Table 11 shows the result from measurements with a rack connection with either a
hub or a switch connected to the network and with different network load.
Originator Target Mean Max Min Jitter Std dev Network load H/S
Flex-DI Flex-DO 6,38 10,03 2,58 7,45 1,39 No Traffic Hub
Flex-DI Flex-DO 7,20 82,33 2,44 79,89 5,54 100kbytes/s Hub
Flex-DI Flex-DO 6,44 9,84 2,45 7,39 1,41 No Traffic Switch
Flex-DI Flex-DO 6,43 10,04 2,57 7,47 1,40 Full Speed Switch
Table 11: Rack connection, measured in milliseconds
The theoretical calculated time (6.0 ms) corresponds fine to the measured average
value; the reason why the average time is slightly higher depends on for example,
network latency. A reason why the minimum value is so low might be that the input
signal is set close to the input modules update cycle. When the maximum latency was
measured a collision might have took place in the switch and the module had to wait
another 3 ms before receiving new update data. Another reason to the maximum
latency might be that the input signal was set close to the modules update time and
the module did not manage to send it immediately. The signal will be transferred the
next cyclic update interval and a delay of 3 ms will occur.
When using a hub and the FTP-transfer speed is 100kbytes/s the average latency is a
little bit higher but the maximum value is significant higher and at a transfer speed of
200kbytes/s and higher the output module is not responding. Although the FTP-traffic
were turned off the module wasn’t answering, a reset had to be done to get it working
again. When a switch was connected to the network and various FTP-transfer speeds
were used, the modules did not have any problems with receiving data and the mean,
maximum and minimum latency is relativity stable independent of the network load.
General when a hub was used the modules stopped to function at a transfer speed of
approximate 200kbytes/s and higher.
FLEX DIGITAL INPUT – 1756 DIGITAL OUTPUT
This is the shortest way between an input and output module in the network and
therefore the fastest. Measurement with a hub were done with different network load
and already at a FTP transfer speed of 50kbytes/s the maximum value was increase
almost 10 times, but the average value was unchanged. In this case the output module
received data all time, but the maximum and average latency is too high to be
accepted. The average latency is increased almost 60 times when the FTP is
transmitting with full speed. The result from the measurements is shown in table 12.
Originator Target Mean Max Min Jitter Std dev Network load
Flex-DI 1756-DO 4,00 7,99 1,49 6,50 1,36 No Traffic
Flex-DI 1756-DO 4,77 95,90 1,51 94,39 6,00 50kbytes/s
Flex-DI 1756-DO 5,36 122,00 1,44 120,56 8,60 100kbytes/s
Flex-DI 1756-DO 240,60 3910,00 1,47 3908,53 872,20 Full Speed
Table 12: Measurements with a hub connected to the network, (milliseconds)
57
When the switch was connected to the network the measured values were more
stable, the difference is in microseconds between no traffic on the network and full
speed, see table 13. The theoretically calculated value, 3.2 ms, is rather close to the
measured average latency. Reasons why the average value is slightly higher can be
plc-execution time and latencies in the switch. This standard deviation is among the
lowest of all the performance measurements.
Originator Target Average Max Min Jitter Std dev Network load
Flex-DI 1756-DO 3,58 6,39 1,43 4,96 0,95 No Traffic
Flex-DI 1756-DO 3,52 6,40 1,43 4,97 0,95 Full Speed
Table 13: Measurements with a switch connected to the network, (milliseconds)
1756 DIGITAL OUTPUT - FLEX DIGITAL OUTPUT
These measurements are made to test how long it takes for a signal to be set in the
Flex Output module. Due to the fast RPI of the 1756 digital output module it is
possible to get a realistic measurement of how long time it takes from the plc send
update data until the output module receives the data and the signal is set. The mean
value (add about 0.2 ms for the time between the plc and 1756 Digital Output
module) is close to the Flex module’s RPI of 3 ms.
Target Target Average Max Min Jitter Std dev Network load
Flex-DO 1756-DO 2,69 5,10 0,43 4,68 1,02 No Traffic
Flex-DO 1756-DO 2,72 5,12 0,47 4,65 0,99 Full Speed
Table 14: Measurements using a switch, (milliseconds)
FLEX DIGITAL INPUT – DEVICENET OUTPUT
The measurements has been done when the scanner module resides in the remote
chassis, this apply for most of the measurements involving the DeviceNet I/O
module. The theoretically calculated value is 18 ms and that is almost 3.5 ms higher
than the measured average latency, see table 15 for the result from the measurements.
A reason may be faster communication between the modules. If data is received in the
scanner module it might be forwarded almost immediately to the I/O module. Since
new data is delivered to the scanner every 5: th ms and the scanner in its turn send
message to the I/O module every 10: th ms, every other message could be transferred
directly while the remaining data have to wait 5 ms. The maximum latency can be
deduced from the case that the data has to wait 5 ms in the DeviceNet scanner
module, plus some latency in the network. The minimal measured time might come
from when the data get an instant transfer to the I/O module from the scanner module.
This is the longest way for data to be transferred with Flex input module as a starting
point. Three hops are made, from the Flex I/O to the PLC, from the PLC to the
DeviceNet scanner and finally from the scanner module to the DeviceNet I/O module.
This resulted in a higher standard deviation value.
58
Originator Target Average Max Min Jitter Std dev Network load
Flex-DI DNet DO 14,37 23,83 5,20 18,63 3,95 No Traffic
Flex-DI DNet DO 14,40 23,51 5,60 17,91 3,96 Full Speed
Table 15: Measurements between Flex and DeviceNet using a switch, (milliseconds)
DEVICENET INPUT - FLEX DIGITAL OUTPUT
This is the performance measurements with the DeviceNet input module as starting
point. The measured latencies are in general higher when data is sent from the
DeviceNet I/O module compared to sending data to the module. The reason is the I/O
modules interscan delay time (10 ms). The measured latencies between the DeviceNet
input and Flex output are almost 5 ms higher than between Flex input and DeviceNet
output but the standard deviation is the same.
Originator Target Average Max Min Jitter Std dev Network load
DNet-D1 Flex-DO 19,66 29,08 11,67 17,41 3,67 No Traffic
DNet-D1 Flex-DO 19,87 28,05 10,51 17,54 3,63 Full Speed
Table 16: Measurements with a switch connected to the network, (milliseconds)
DEVICENET INPUT – DEVICENET OUTPUT
This is the longest way a message can travel in the network if the scanner module
resides in the remote chassis. Table 18 shows the result from measurements with the
DeviceNet scanner module in the remote chassis and a switch connected to the
network. When the scanner module was moved to the local chassis (where the PLC
resides) the maximum value was decreased with 10 ms while the average value was
decreased with 1 ms, the minimum latency was practically unchanged, see table 17.
Why the maximum latency is 10 ms higher with the scanner module in the remote
chassis may depend on several things, for example that the Ethernet/IP bridge module
did not manage to forward the message to the DeviceNet scanner module in time.
Originator Target Average Max Min Jitter Std dev Network load
DNet-DI DNet-DO 23,83 31,59 17,17 14,42 3,50 No Traffic
DNet-DI DNet-DO 23,78 33,40 16,98 16,42 3,54 Full Speed
Table 17: DeviceNet scanner in the local chassis. (Milliseconds)
Originator Target Average Max Min Jitter Std dev Network load
DNet-DI DNet-DO 24,85 42,53 16,87 25,66 4,83 No Traffic
DNet-DI DNet-DO 24,48 42,63 16,58 26,05 4,83 Full Speed
Table 18: DeviceNet scanner in the remote chassis. (Milliseconds)
59
1756 DIGITAL OUTPUT – DEVICENET OUTPUT
The measured minimum value shown in table 19 (add 0.2 ms for transferring the data
to 1756 digital output module) is the fastest time data can be transferred to the
DeviceNet I/O module from the processor.
Target Target Average Max Min Jitter Std dev Network load
1756-DO DNet-DO 10,59 20,02 2,50 17,52 3,80 No Traffic
1756-DO DNet-DO 10,79 18,79 2,63 16,16 3,73 Full Speed
Table 19: Measurements using a switch, (milliseconds)
For the fastest data time from the DeviceNet I/O module to the processor see the table
20.
DEVICENET INPUT – 1756 DIGITAL OUTPUT
The theoretically value was calculated to 15.2 ms and the measured average value
was almost 2 ms higher, but the measured average value is including latencies in the
network. When data is transferred three hops on the network, the standard deviation is
about 3.6 ms, see also measurements between DeviceNet input and Flex output
module.
Originator Target Average Max Min Jitter Std dev Network load
DNet-DI 1756-DO 17,02 25,51 9,17 16,34 3,53 No Traffic
DNet-DI 1756-DO 16,98 24,84 10,26 14,58 3,58 Full Speed
Table 20: Measurements when a switch is connected, (milliseconds)
DEVICENET INPUT – ROBOT
To be able to compare performance between the networks EtherNet/IP and
DeviceNet, measurements with DeviceNet were received from ABB Robotics. The
DeviceNet measurements were made between the DeviceNet I/O module and the
robot system with no network load.
D328 DeviceNet I/O
Test module
DeviceNet Link
S4C+ Robot
Figure 21: Test system for DeviceNet
60
As figure 21 illustrates, data is transferred directly between the I/O module and the
robot system while in the EtherNet/IP network data travel a longer way between this
two modules. Due to the longer transfer the EtherNet/IP measured values (see table
21) were much higher than the DeviceNet measurement (see table 22).
Originator Target Average Max Min Jitter Std dev Network load
D328-D1 Robot 18,59 27,09 10,54 16,55 3,57 No Traffic
Table 21: Measurements with EtherNet/IP
Originator Target Average Max Min Jitter Std dev No of signals
Dnet-DI Robot 1,22 3,34 1,01 2,33 0,27 1
Dnet-DI Robot 26,40 37,81 17,99 19,82 2,80 16
Table 22: Measurements with DeviceNet
The DeviceNet performance test included measurements when more than one signal
was set. When several signals were set in the robot the measured values increased
rapidly, this could be an interesting measurement to do with EtherNet/IP in the future,
to see if the same behavior is repeated there.
1756 DIGITAL OUTPUT – ROBOT DIGITAL OUTPUT
This is an almost directly transfer of data to the robot from the processor (via the
switch). The average and maximum values is practically the same as the average and
maximum values from the DeviceNet measurements (when one signal was set) and
the minimum value is better with EtherNet/IP. But one important measure is higher;
the standard deviation is nearly twice as high as the DeviceNet measurement. Every
performance measurement that has been made with EtherNet/IP showed a high
standard deviation.
Target Target Mean Max Min Jitter Std dev Network load
1756-DO Robot 1,06 3,18 0,32 2,86 0,46 No Traffic
1756-DO Robot 1,07 3,98 0,29 3,69 0,47 Full Speed
Table 23: Measurements between the 1756 Output and the Robot
See enclosure 4 for all the performance measurements.
61
13.1.4 Problems
Problems occurred when the DeviceNet I/O module were used. The first problem was
detected when measurement was made to the DeviceNet test module; channel two on
the HP counter was connected to the DeviceNet module while channel one was
connected to Flex Input module. Channel two was set to trigger on a voltage level of
22, but the counter trigged not once but twice on the same DeviceNet output signal,
see figure 22.
Real curve
24 V
22 V
Ideal curve
0V
Figure 22: Curve behaviour
The voltage level was then reduced to 18 V and the phenomenon stopped. The
voltage level on channel one was also lowered to 18 V.
When measurements were made from the DeviceNet module the same phenomenon
was detected, the HP counter trigged twice on the same signal; channel one was
connected to the input signal on the DeviceNet I/O module and channel two to the
Flex output module. This was discovered by that the maximum latency followed a
timer-value in the RSLogix program. The time interval is measured from the first
spike on channel 1 to the first spike on channel 2, and if there are two spikes on
channel 1, a new measurement is made from the second spike until channel 2 is set
again and this is where it goes wrong; channel one must wait until channel 2 is set
again and how long this takes depends on how long time it takes to execute the
program in RSLogix. With increment of the voltage level to 21 V on channel 1 and a
low pass filter; to avoid small spikes, the problem was taken care of.
62
13.2 Conclusions and future work
Considering the situation today many things indicate that Ethernet will be used in the
industry for automation purposes. Economic factors will most likely speed up the
transition to Ethernet based field busses even though the protocols may not be ready.
When looking at the standardization problem there are already several Ethernet based
field bus protocols on the market. Moving to Ethernet can be seen as a step towards
standardization because the first four OSI-layers are agreed upon. This means that all
protocols can use the same wiring scheme and this has not the situation before
Ethernet. EtherNet/IP was one of the first Ethernet based field bus protocol and due to
the CIP protocol it has a great chance of becoming the dominating protocol. The CIP
protocol makes it easier for DeviceNet and ControlNet users to start using Ethernet/IP
because of the common application layer protocol and bridging functionality. Another
thing that makes Ethernet attractive as a field bus is the wide range of usable internet
protocols such as HTTP, FTP and SMTP. One of the main reasons for using Ethernet
is the cheap components available. The problem is that the standard cheap Ethernet
equipment is not very well adapted to industrial environments and when using
equipment that is adapted for industrial use it is no longer cheap. Before starting to
use Ethernet extensively at device level something has to be done in order to solve the
deterministic problem. The current approach using higher bandwidth and more
advanced switches to get a near deterministic behaviour will encounter problems
when moving to larger systems. Maybe an introduction of IEEE 802.3p prioritization
in the EtherNet/IP protocol will make it more suitable for field bus use at device
level.
For the moment the development of the protocol seems to have stagnated waiting to
see the industry’s response. In the future some alternative media like wireless
Ethernet, USB or Firewire media can be tested as platform for the CIP protocol.
EtherNet/IP does not at the moment require specific implementation or performance
requirements due to the broad range of application requirements. But work is in
process to define a standard set of EtherNet/IP benchmarks and metrics by which the
performance of devices will be measured. These measurements may become required
entries within a product's Electronic Data Sheet. The goal of such benchmarks and
metrics will be to help the user determine the suitability of a particular EtherNet/IP
device for a specific application.
63
14 References
Computer Networks 3rd edition, Andrew S. Tanenbaum, Prentice-Hall 1996
What is PLC, http://omarz.htmlplanet.com/PLC_info.htm
EtherNet/IP Addressing issues and recommendations,
http://www.rtaautomation.com/documents/EIPAddressIssuesPaper.pdf
Interfacing the Controllogix PLC over EtherNet/IP, Publication: THAP020,
http://arxiv.org/ftp/cs/papers/0110/0110065.pdf
From Allen Bradley homepage:
CIP: Not just another pretty acronym, www.ab.com/networks/CIPwhitepaper2.html
ControlLogix DeviceNet Interface Module, Publication: 1756-6.5.19, May 2000,
http://www.ab.com/manuals/cl/1756-um515b-en-p.pdf
ControlLogix Digital I/O Modules, Publication: 1756-UM058C-EN-P, Mars 2001,
http://www.ab.com/manuals/cl/1756-um058c-en-p.pdf
ControlLogix Ethernet Communication Interface Module, Publication: 1756-
UM051B-EN-P, November 2000, http://www.ab.com/manuals/cl/1756-um051b-en-p.pdf
ControlLogix System User Manual, Publication: 1756-UM001E-EN-P August 2002,
http://www.ab.com/manuals/cl/1756-um001e-en-p.pdf
ControlLogix System, http://www.ab.com/catalogs/b113/controllogix
EtherNet/IP: Industrial Ethernet White Paper: http://www.ab.com/networks/whitepapers.html
EtherNet/IP media planning and installation manual, Publication: ENET-IN001A-
EN-P, January 2001, http://www.ab.com/manuals/cn/enet-in001a-en-p.pdf
EtherNet/IP Performance and Application guide, Publication: ENET-AP001B-EN-P,
June 2001, http://www.ab.com/manuals/cn/enet-ap001b-en-p.pdf
Flex I/O, www.ab.com/catalogs/b113/io/1794.html
Flex I/O EtherNet/IP Adapter Module, Publication: 1794-UM006A-EN-P, July 2001,
http://www.ab.com/manuals/io/1794/1794-um006a-en-p.pdf
SoftLogix5800 System User Manual, Publication: 1789-UM002D-EN-P, August
2002, http://www.ab.com/manuals/sl/1789-um002d-en-p.pdf
64
RSLinx Technical Data, Publication: LINX-TD001C-EN-P, November 2002,
http://www.ab.com/manuals/swrsi/linx-td001c-en-p.pdf
RSLogix Overview, http://www.software.rockwell.com/rslogix/
Victor Schiffer, The CIP Family of Fieldbus Protocols and its newest Member –
EtherNet/IP, http://www.ab.com/networks/CIPwhitepaper.html
From ODVA homepage (http://www.odva.org):
EtherNet/IP specification release June 2001
Open DeviceNet Vendor Assoc. & ControlNet International Volume 1, CIP Common
Specification
65
Related docs
