11 ETHERCAT

EtherCAT is a highly flexible Ethernet network protocol that is developing at a rapid rate and growing
at an even faster clip. A unique principle called “processing on the fly” gives EtherCAT a handful of
unique advantages. Because EtherCAT messages are passed before being processed in each node,
EtherCAT operates at a high speed and efficiency. The process also creates flexibility in topology and
incredible synchronization. Outside of the advantages gained from “processing on the fly,” EtherCAT
benefits from superb infrastructure. EtherCAT includes, among other things, a safety protocol and
multiple device profiles. EtherCAT also benefits from a strong users group. The combination of
benefits means EtherCAT is poised for continued growth.

11.1 History of EtherCAT

Ethernet application layers used in industrial and building automation systems are typically “low
payload”, half-duplex application layers. An Ethernet message for an application layer like Modbus
TCP, for example, may carry only a single register for a server device with little data like a valve
controller. In small payload devices like that, huge slices of bandwidth are lost as not only small data
packets are moved but those messages are only issued when the Client or Master device requests that
data. Modbus TCP is an extremely inefficient example but the same kinds of bandwidth and payload
issues can be found in application layers like EtherNet/IP and Profinet IO.

Beckhoff, a German automation company, developed a fieldbus system called Fast Lightbus
to correct the low bandwidth utilization problem present in other Ethernet protocols. This protocol
led to EtherCAT which Beckhoff released in 2003.

11.2 Fundamental Principle

The fundamental principle of EtherCAT is pass-through reading. Pass through reading means that
messages are not destined for a single node and consumed by that node. Instead, messages are
transmitted to the following node in a string as they are processed. Input data to a node is read as the
message is processed and output data is inserted in the message to the next node.

A single message is issued by the EtherCAT Master with data for all nodes. As the message is
transmitted around the ring and back toward the Master, each node reads its inputs and adds its
outputs to the message. When the message arrives back at the EtherCAT Master every node in the
network has received new input data from the Master and returned new output data to the Master.
Without the deficiency of small payloads or messages targeted to specific nodes, an EtherCAT network
can achieve maximum bandwidth utilization.

An EtherCAT network can be compared to a railway where each station can off-load and re-
load train cars while the train moves through the station.

11.3 Self Terminating Technology

EtherCAT uses the standard IEEE 802.3 physical layer. No special hardware is required to implement
an EtherCAT network.

External switches are not used in an EtherCAT network. Instead, each EtherCAT device embeds
a switch. Each device has two RJ45 ports. One RJ45 is connected to the previous node in the network
and one is connected to the next node.
 Somewhat unique to Ethernet is the EtherCAT concept of self-terminating networks. Any node
that does not detect a next node in the string automatically terminates the network at that point.
Terminating nodes copy messages from the Master’s transmit path to the Masters receive path.

EtherCAT networks can be wired in a ring if the Master has two Ethernet ports. Networks
wired in a ring provide a measure of redundancy. Cable breaks anywhere in the ring are closed by the
ports upstream and downstream of the break. The Master can detect the break and send messages
out to both of the new sub-segments.

Because of this self-terminating feature, EtherCAT networks can be wired using several
different topologies including star, line, or tree.

11.4 Data Representation

How a network represents data is a fundamental characteristic of a network. It is a distinguishing
factor that should be the first question on the mind of anyone seriously investigating a network
technology.

The Ethernet application layer with the most sophisticated data representation is CIP. CIP
(Common Industrial Protocol) devices from the ODVA use an Object/Instance/Attribute data
representation. Like data is collected in objects. Common sets of those objects are specified as
instances. Data items within those objects are attributes. Objects can also have event handlers and
operational structures implemented as state machines.

The Ethernet application layer with the least sophisticated data representation is Modbus
TCP. Like it’s serial cousin, all Modbus TCP devices represent data as either 16-bit unsigned registers
or coils. There are input and output versions of each. Unfortunately, there is little standardization or
commonality in Modbus devices. Each manufacturer develops their own unique Modbus Register
map.

Profinet IO uses a similar data representation to Profibus. Each device looks like an I/O rack.
There is a rack designator, a slot, a channel and a point.

EtherCAT uses a very simple data representation, sort of like Modbus. There is a data space,
a huge data space, and each device is allocated a part of that data space. As messages are transmitted
through the network, they map their portion of the data space to the data in the Ethernet message.

11.5 EtherCAT Frame

For the EtherCAT frame to keep rolling without stopping at each node, the packet must contain specific
components, much like a train’s cars.. Looking at the EtherCAT frame, its analogy to a train is quite
apparent. The header acts like a locomotive. The cars, plus their content, are PDO Data. The caboose,
complete with shipping information, is the working counter.

All of these parts fit simply into the EtherCAT frame, and the frame fits simply into an Ethernet
frame. The Ethernet is the transmission media that allows EtherCAT to operate. The EtherCAT frame
simply replaces the IP frame of a standard Ethernet message. Thus, the Ethernet frame does not need
modification, again contributing to flexibility for EtherCAT.
 Figure 11-1

11.5.1 EtherCAT Header

The EtherCAT frame starts with a standard header. The first integer is a length identifier. This bit tells
the nodes how long the EtherCAT portion of the frame will be. Length is especially important in an
EtherCAT frame; the length varies with the number of message bytes and nodes just like more train
cars of product makes the train longer.

The second portion of the EtherCAT header is a reserved bit, which is followed by a type integer. The
type integer defines the type of message, ensuring correct interpretation.

11.5.2 PDO Data

After the header, the Ether CAT frame contains Process Data Objects, or PDOs. The PDOs correspond
to the number of nodes and messages within the frame. Each PDO contains data for a node, the
product inside the boxcar. The PDOs are also individually addressed, telling the nodes which PDOs to
take.

11.5.3 Working Counter

The final portion of an EtherCAT frame is the working counter. This number works much the same way
a frame check sequence works. The working counter is dependant on the content of the EtherCAT
frame. By ensuring the working counter is correct, each node can ensure it receives the entirety of the
frame.

11.6 Advantages
11.6.1 Speed
The fundamental principle of “processing on the fly” behind EtherCAT provides a clear advantage. The
delay a message would experience over a standard Ethernet network is much larger than the small
delay in an EtherCAT network. There are two important things to note, however. First, there is a delay.
The EtherCAT frame cannot move continuously, so each node introduces a small delay.
Second, EtherCAT networks can be slowed if necessary. Some computers may have difficulty handling
the increased quantity of cycles and decreased cycle times optimized EtherCAT can offer. The network
can be configured for the computer, however, to allow the greatest speed these computers can
operate under.

As is always said about numbers; “figures don’t lie but liars figure”. Giving any performance
numbers for an industrial network is open to suspicion but generally 1000s digital IOs can be updated
in 30 microseconds and 100 Servos can be updated at 10Khz.

11.6.2 Flexible Topology

The “processing on the fly” principle of EtherCAT has another advantage in addition to speed.
EtherCAT networks can be configured in many types of topology. Just like Ethernet, a star topology is
quite simple. EtherCAT can extend well beyond a star topology, though.

EtherCAT creates the possibility of a fieldbus system using Ethernet hardware. Combing the
fieldbus, or trunk, topology with the start topology creates an incredibly useful new style. The
combination of trunk lines and individual branches give flexibility in programming for an EtherCAT
network.

EtherCAT has built-in redundancy that compensates for potential breaks in wiring. When a
line is broken, the network can detect a break. The EtherCAT frame can travel to the end of the
network and, because messages travel back over the same path in reverse, the frame reverses and
travels back to the master. In this way, all EtherCAT networks can act as though they’re in a ring
topology. Configuring an EtherCAT network in a ring topology, then, adds another level of redundancy.

It might be assumed from this discussion that EtherCAT is limited to a single subnet. That is
not true. EtherCAT telegrams can be transported in routable UDP packets. Of course, routing will
introduce more delays than having all EtherCAT slaves on a single subnet.

11.6.3 Synchronization
As made clear through the publishing of the IEEE 1588 Precision Time Protocol standard,
synchronization has gained importance in the Industrial Networking industry. Synchronization is
another advantage of EtherCAT systems. EtherCAT includes a distributed clock mechanism, giving it a
low jitter that meets the specifications of IEEE 1588 without additional hardware.

The mechanism is possible because of the timestamps each node includes in the EtherCAT
frame. Each node attaches a time stamp to the EtherCAT frame twice. First, the slave node adds a
timestamp when receiving the message as it is sent through the network. Then, when the frame
returns back through the nodes, each slave adds another time stamp. The master receives the frame
with two time stamps per slave.

With the time information, the master can calculate the delay for each node. The master
repeats the calculation for every frame it sends. As the network operates, the enormous sample size
means the master has incredibly accurate data. The inherent ring topology creates an incredibly
efficient clock mechanism that increased in accuracy with every message.
11.7 Other Features
Synchronization, flexible topology, and speed are advantages EtherCAT has due to its unique operating
principle. Through the work of the ETG, though, EtherCAT has some other distinct features worth
mentioning.

11.7.1 Device Profiles

EtherCAT uses device profiles much like Ethernet/IP and other CIP protocols use objects. Many
fieldbus devices used in EtherCAT networks are already defined in CAN. EtherCAT supports the entire
CANopen family, another IEC standard EtherCAT fits within. In addition to CANopen, EtherCAT
supports the Sercos drive profile. The drive profiles allow a user to configure the EtherCAT network to
their specific needs without “reinventing the wheel.” Basic profiles are predefined.

11.7.2 Safety Protocol

One more IEC standard among the many that describe portions of EtherCAT is IEC 61508. This standard
describes Functional Safety over EtherCAT (FSoE). The FSoE version of the EtherCAT protocol meets
the requirements of Safety Integrity Level 3. To achieve higher safety, FSoE adds in safety information
to the standard EtherCAT frame.

11.7.3 Development
EtherCAT Master devices can be developed using any standard Ethernet MAC. No special hardware is
needed. Beckoff provides a PC Master device that can access EtherCAT slave devices from a standard
Windows PC. EtherCAT Slave devices must use the EtherCAT ASIC (Application Specific Integrated
Circuit) to access the EtherCAT network. The EtherCAT ASIC is available from Beckoff and other
suppliers.

11.7.4 Implementation Costs

Hardware costs for the controller or Master device are limited as no special hardware is required and
any Ethernet enabled PC can be used as a Master device. EtherCAT Slave devices require a fairly large
investment in design and development as the EtherCAT ASIC is a large footprint device that is more
expensive than standard Ethernet enabled microprocessors. On system implementation, EtherCAT
can be very cost effective. No additional switches, routers or hubs are required to form the EtherCAT
network and it can be deployed in the topology that is most suitable for the application.

11.8 Summary
EtherCAT is a very high performance, easy to deploy, open application layer protocol for Ethernet
applications. Its synchronization capabilities and full bandwidth utilization are very attractive for
motion applications where synchronizing large numbers of drives is required. It saves installation
expense by eliminating both Ethernet start topology and all switches routers and hubs. EtherCAT fits
will in the spectrum of Ethernet application layers where performance, topology and overall
deployment cost are driving factors.

12 EtherNet/IP
Most people who work in an office associate the term “Ethernet” with the physical cable behind their
desk. This cable connects their office PC to the printers and servers of the local network and the infinite
web sites on the Internet. This cable is only the physical part of Ethernet, the media carrying Ethernet
messages to your PC. On this wire is a whole series of communication protocols such as IP, the Internet
Protocol; TCP, the Transport Control Protocol; and various Microsoft protocols such as NetBEUI. This
suite of protocols works well for the office environment. It allows users to share files, access printers,
send email, search the Internet and perform all the other communications used in the office
environment.

The needs of the factory floor are much different with some very special requirements.
Instead of accessing files and printers, factory floor controllers must access data embedded in drive
systems, operator workstations and I/O devices. Instead of letting a user wait while a task is being
performed, factory floor data communications needs are real-time or very close to real time.
Terminating the fill operation on a bottle requires much more time-precise communications than
accessing the next page of an Internet site.

Traditionally, Ethernet had only limited acceptance in Industrial Automation. Until recently
the expense, lack of intelligent switches and routers and the domination of large vendors with
proprietary protocols prevented the wide acceptance of Ethernet on the factory floor. Now with prices
falling, PCs with inherent Ethernet capability moving in droves onto the factory floor and intelligent
switches and routers, Ethernet is gaining acceptance. Only the lack of a widely accepted, flexible
application layer targeted to Industrial Automation has prevented its complete acceptance.

12.1 The 6 Things You Must Know about EtherNet/IP

Figure 12-1
1. EtherNet/IP is an application layer protocol that is transferred inside a TCP/IP Packet. That
means that EtherNet/IP is simply the way data is organized in a TCP or UDP packet.
2. All devices on an EtherNet/IP network present their data to the network as a series of data
values called attributes grouped with other similar data values into sets of attributes called
Objects.
 3. There are EtherNet/IP Required Objects – Identity, TCP, Router that every device must have.
The EtherNet/IP Specification defines those objects.
4. There are EtherNet/IP Application Objects that have the data for your specific device. For
example, an EtherNet/IP Drive device has a Motor Object. EtherNet/IP devices that support
specific devices all have the same set of EtherNet/IP application objects.
5. There are two kinds of messages that are transferred between an EtherNet/IP Scanner Device
(opens connections and initiates data transfers) and EtherNet/IP Adapter devices (provides
data to Scanners). These messages are Explicit Messages (asynchronous, as needed) and I/O
Messages (Data messages that are continuously transferred).
6. EtherNet/IP is part of CIP, the Common Industrial Protocol. CIP defines the Object structure
and specifies the message transfer. CIP protocol over CAN is DeviceNet. CIP protocol over
Ethernet is EtherNet/IP.

https://youtu.be/pTPjI6lnRgY

12.2 More on EtherNet/IP

Ethernet/IP is the application layer protocol that can meet this challenge. Four independent groups
have joined forces to develop and promote EIP as a public domain Ethernet application layer for
Industrial Automation. These groups include the ODVA, the Industrial Open Ethernet Association
(IOANA), Control Net International (CI) and the Industrial Ethernet Association (IEA). The goals of this
effort illustrate how EIP provides a wide-ranging, comprehensive, certifiable standard suitable to a
wide variety of automation devices:

1. Ethernet/IP uses the tools and technologies of traditional Ethernet. Ethernet/IP uses all the
transport and control protocols used in traditional Ethernet including the Transport Control
Protocol (TCP), the Internet Protocol (IP) and the media access and signaling technologies
found in off-the-shelf Ethernet interface cards. Building on these standard PC technologies
means that EIP works transparently with all the standard off-the-shelf Ethernet devices found
in today’s marketplace. It also means that EIP can be easily supported on standard PCs and all
their derivatives. Even more importantly, basing EIP on a standard technology platform
ensures that EIP will move forward as the base technologies evolve in the future.
2. Ethernet/IP is a certifiable standard. The groups supporting EIP plan to ensure a
comprehensive, consistent standard by careful, multi-vendor attention to the specification
and through certified test labs as has been done with DeviceNet and ControlNet. Certification
programs modeled after the programs for DeviceNet and ControlNet will ensure the
consistency and quality of field devices.
3. EIP is built on a widely accepted protocol layer. EIP is constructed from a very widely
implemented standard used in DeviceNet and ControlNet called the Control and Information
Protocol (CIP) and is illustrated on the attached drawing. This standard organizes networked
devices as a collection of objects. It defines the access, object behavior and extensions which
allow widely disparate devices to be accessed using a common mechanism. Hundreds of
vendors now support the CIP protocol in present day products. Using this technology in EIP
means that EIP is based on a widely understood, widely implemented standard that does not
require a new technology shakedown period.

12.3 Advantages to EtherNet/IP

The advantages of the CIP protocol layer over Ether are numerous. The consistent device access means
that a single configuration tool can configure CIP devices on different networks from a single access
point without using vendor specific software. The classification of all devices as objects decreases the
training and startup required when new devices are brought online. EtherNet/IP provides improved
response time and greater data throughput than DeviceNet and ControlNet. EtherNet/IP links devices
from the sensor bus level to the control level to the enterprise level with a consistent application layer
interface.

There are numerous application layer competitors to EtherNet/IP including Modbus/TCP from
Groupe Schneider, Profinet from Siemens, and EtherCAT from Beckhoff. Unfortunately space prevents
a detailed review of each of these products. However, none of these competitors can provide the
vendor support, flexibility and total architecture support offered by the implementation of CIP over
Ethernet.

12.4 User Challenges of EtherNet/IP

EtherNet/IP implementation is not without challenges. Two of the most important challenges to the
first time user include training and network configuration. One common problem is the lack of trained
staff who understand both the IT fundamentals and the automation network. A collaborative effort
between the IT and Automation staffs is required to successfully implement the first Ethernet/IP
system. A second challenge is proper network configuration. Planning your Ethernet factory
automation infrastructure is essential. Careful identification of all your control loops, choosing the
correct routers, switches and paths and documenting your network properly are requisites for a
communications network which meets your production goals and requires little ongoing maintenance.

Detractors of Ethernet applications on the factory floor often cite the lack of inherent
determinism in Ethernet communications to keep it out of automation applications. While true in the
past, recent developments in intelligent switches have largely eliminated this argument. These
switches create separate collision domains that offer the determinism required of almost all but the
most demanding of automation applications.

13 MODBUS
The Modbus communications protocol is the networking granddaddy of the industry. Modbus has
stood the test of time and is still being used in a wide range of applications, including industrial
automation, process control, building automation, transportation, energy, and remote monitoring.

Virtually any type of sensor and controller devices can be found that incorporate Modbus
networking, including programmable logic controllers (PLCs), process controllers, process
instruments, process sensors, PID controllers, motor drives, energy meters, Supervisory Control and
Data Acquisition (SCADA) systems, programmable automation controllers (PACs), discrete sensors,
valves, and many other embedded devices.

In simple terms, Modbus is a method used for transmitting data over serial lines between
electronic devices. Originally intended for communications between programmable logic controllers
(PLCs) and computers, it has become a de facto standard communication protocol for connecting a
wide range of industrial electronic devices.

Modbus is an extremely compact and flexible protocol that continues to prove it can be
adapted for use in a wide range of applications and media. It is popular for remote applications that
communicate over almost any means, including wired and cellular telephone, licensed and unlicensed
radios, and satellite.
13.1 History of Modbus
The Modbus serial communication protocol was developed by Modicon and published by the
company in 1979 for use with its programmable logic controllers (PLCs). The early roots of Modicon
started in 1968 with a core group of engineers led by Dick Morley that invented the first programmable
logic controller.

Modbus is an open standard, meaning that manufacturers can build it into their equipment
without having to pay royalties. It is the most pervasive communications protocol in industrial
automation and is the most commonly available means of connecting industrial electronic devices.

Modbus introduced the concept of data on the factory floor. Modbus made it possible to
connect an entire group of devices using only two wires on the controller. That alone saved a massive
investment in wire, labor and installation time. Instead of miles and miles of wire connecting hundreds
of devices, a simple two-wire pair could be daisy-chained from one device to the next to the next. It
was revolutionary for its time.

Modbus has found its way into hundreds of thousands—if not millions—of devices. You can
find it in everything from valve controllers, to motor drives, to HMIs, to water filtration systems. It
would be difficult indeed to name a product category in Industrial or Building Automation that doesn’t
use Modbus.

13.2 Why Modbus has Flourished

Why did Modbus have such an impact on the Industrial Automation industry that it still survives to
this day as one of the leading industrial networks of the 21st century? Here are the three primary keys
to its success:

1. Modbus is an Open Standard: Modicon did not keep the standard proprietary. They released
it as a non-proprietary standard and welcomed developers, even competitors, to implement
it. They rightly assumed that it would be best for everyone, including them if Modbus became
successful in the marketplace. Because of this thinking, Modbus became the first widely
accepted Fieldbus standard.
2. Modbus uses Standard Transports: The transport layer for Modbus RTU commands is also
simple to understand. Modbus RTU uses RS232, RS422, and RS485. Modbus TCP/IP uses
Ethernet.
3. Modbus uses a Simple Protocol: Modbus is very easy to understand. Its primary purpose is to
simply move data between an RTU Master device (a Client in Modbus TCP) and an RTU Slave
 device (a Server in Modbus TCP). There are only two kinds of data to move, registers and coils.
Registers are 16-bit unsigned integers. Coils are single bits. The simplicity of Modbus has also
led to many companies expanding the message structure, data representation, and
transports.

Another reason Modbus was so successful was the fact that it could be so readily understood
by non-programmers. Simplicity has led to an incredible amount of activity and propagation of
Modbus into many different industries around the world. There is probably no product category in the
last thirty years that hasn’t had an offering without Modbus.

13.3 MODBUS TCP/IP

MODBUS TCP/IP is a variant of the MODBUS family of simple, vendor-neutral communication
protocols intended for supervision and control of automation equipment. Specifically, it covers the
use of MODBUS messaging in an ‘Intranet’ or ‘Internet’ environment using the TCP/IP protocols. The
most common use of the protocols at this time are for Ethernet attachment of PLC’s, I/O modules,
and ‘gateways’ to other simple field buses or I/O networks.

The MODBUS TCP/IP protocol is being published as a (‘de-facto’) automation standard. Since
MODBUS is already widely known, there should be little information in this document which could not
be obtained elsewhere. However, an attempt has been made to clarify which functions within
MODBUS have value for interoperability of general automation equipment, and which parts are
‘baggage’ from the alternate use of MODBUS as a programming protocol for PLC’s.

This is done below by grouping supported message types into ‘conformance classes’ which
differentiate between those messages which are universally implemented and those which are
optional, particularly those specific to devices such as PLC’s.

13.3.1 Connection-Oriented
In MODBUS, data transactions are traditionally stateless, making them highly resistant to disruption
from noise and yet requiring minimal recovery information to be maintained at either end.

Programming operations, on the other hand, expect a connection-oriented approach. This

was achieved on the simpler variants by an exclusive ‘login’ token, and on the MODBUS Plus variant
by explicit ‘Program Path’ capabilities which maintained a duplex association until explicitly broken
down.

MODBUS/TCP/IP handles both situations. A connection is easily recognized at the protocol

level, and a single connection may carry multiple independent transactions. In addition, TCP/IP allows
a very large number of concurrent connections, so in most cases it is the choice of the initiator whether
to reconnect as required or re-use a long-lived connection.

Developers familiar with MODBUS may wonder why the connection-oriented TCP/IP protocol
is used rather than the datagram-oriented UDP. The main reason is to keep control of an individual
‘transaction’ by enclosing it in a connection which can be identified, supervised, and canceled without
requiring specific action on the part of the client and server applications. This gives the mechanism a
wide tolerance to network performance changes, and allows security features such as firewalls and
proxies to be easily added. Similar reasoning was used by the original developers of the World Wide
Web when they chose to implement a minimal Web query as a single transaction using TCP/IP on well-
known port 80.
https://youtu.be/E1nsgukeKKA

13.4 MODBUS RTU

Modbus RTU is an open serial protocol derived from the Master/Slave architecture originally
developed by Modicon (now Schneider Electric). It is a widely accepted serial level protocol due
to its ease of use and reliability. Modbus RTU is widely used within Building Management Systems
(BMS) and Industrial Automation Systems (IAS).

Modbus RTU messages are a simple 16-bit structure with a CRC (Cyclic-Redundant Checksum).
The simplicity of these messages is to ensure reliability. Due to this simplicity, the basic 16-bit
Modbus RTU register structure can be used to pack in floating point, tables, ASCII text, queues, and
other unrelated data.

This protocol primarily uses an RS-232 or RS-485 serial interfaces for communications and is
supported every commercial SCADA, HMI, OPC Server and data acquisition software program in the
marketplace. This makes it very easy to integrate Modbus compatible equipment into new or existing
monitoring and control applications.

13.4.1 A Little Modbus RTU History

You might call the Modbus protocol the grandfather of industrial networking. It truly is as old as the
hills and has the whiskers to prove it. In today’s age of Internet connectivity and Web Services,
Modbus’ unconnected message and simple request-response communication structure are almost
quaint. Almost as old as the first Programmable Logic Controller, the Modicon 084, which in those
days was called a PC for programmable Controller.

Modbus RTU is an open standard, meaning that manufacturers can build it into their
equipment without having to pay royalties. It is the most pervasive communications protocol in
industrial automation and is now the most commonly available means of connecting industrial
electronic devices.

Modbus is used widely by many manufacturers throughout many industries. Modbus is

typically used to transmit data from control instrumentation to a logic controller or a system for
archiving data. In building automation, for example, temperature and humidity are often
communicated to a computer for long term storage. Modbus is often used to connect a supervisory
computer with a remote terminal unit (RTU) in supervisory control
and data acquisition (SCADA) systems.

https://youtu.be/OvRD2UvrHjE

14 PROFINET IO
This section presents an overview of PROFINET IO, a high-level network for industrial automation
applications. Built on standard Ethernet technologies, PROFINET IO uses traditional Ethernet hardware
and software to define a network that structures the task of exchanging data, alarms and diagnostics
with Programmable Controllers and other automation controllers.

PROFINET IO is one of two open Ethernet standard automation “views” from Profibus
International. While PROFINET IO focuses on Programmable Controller data exchange, PROFInet CBA
(Component Based Automation) focuses on distributed automation systems. PROFINET CBA provides
a DCOM-based system for organizing automation systems into networks of peer devices that can
automatically exchange data using predefined relationships between the interfaces of the automation
components. PROFINET CBA is thoroughly discussed in another paper.

PROFINET IO is very similar to Profibus on Ethernet. While Profibus uses cyclic

communications to exchange data with Programmable Controllers at a maximum speed of 12Meg
baud PROFINET IO uses cyclic data transfer to exchange data with Programmable Controllers over
Ethernet. As with Profibus, a Programmable Controller and a device must both have a prior
understanding of the data structure and meaning. In both systems data is organized as slots containing
modules with the total number of I/O points for a system the sum of the I/O points for the individual
modules.

14.1 A Little PROFINET IO Background

Most people who work in an office associate the term “Ethernet” with the physical cable behind their
desk. This cable connects their office PC to the printers and Servers of the local network and the
infinite web sites on the Internet. This cable is only the physical part of Ethernet, the media carrying
Ethernet messages to your PC. On this wire are a whole series of communication protocols such as IP,
the Internet Protocol; TCP, the Transmission Control Protocol; and various Microsoft protocols such
as NetBEUI. This suite of protocols works well for the office environment. It allows users to share files,
access printers, send email, search the Internet and perform all the other communications used in the
office environment.

The needs of the factory floor are much different with some very special requirements.
Instead of accessing files and printers, factory floor controllers must access data embedded in drive
systems, operator workstations and I/O devices. Instead of letting a user wait while a task is being
performed, factory floor data communications needs are real-time or very close to real time.
Terminating the fill operation on a bottle requires much more time-precise communications than
accessing the next page of an Internet site.

Traditionally, Ethernet had only limited acceptance in Industrial Automation. Until recently
the expense, lack of sophisticated switches and routers and the domination of large vendors with
proprietary protocols prevented the wide acceptance of Ethernet on the factory floor. Now with prices
falling, PCs with inherent Ethernet capability moving in droves onto the factory floor and intelligent
switches and routers, Ethernet is gaining acceptance. Only the lack of a widely accepted, flexible
application layer targeted to Industrial Automation has prevented its complete acceptance.

14.2 PROFINET IO Benefits

PROFINET IO is a unique industrial Ethernet application layer. It offers many benefits over competing
application layers including:

 High Speed Operation – The real time communication channel provides high speed message
exchange by bypassing the time required to process the TCP/IP stack.
 Seamless and nearly identical Siemens S7 PLC integration to Profibus
 Support for time critical motion control applications
 Short Startup
 Distributed Intelligence
 Ease of installation
 Minimum commissioning time and engineering support
14.3 PROFINET Device Classification
PROFINET IO classifies devices into three types; IO-Controllers, IO-Devices and IO-Supervisors. IO-
Controllers are devices that execute an automation program. Controllers, functionally similar to a
Profibus Class 1 Master, exchange data with IO-Devices. IO-Devices are distributed sensor/actuator
devices connected to the IO-Controller over Ethernet. In Profibus terms, IO-Devices are similar to
Profibus slaves. IO-Supervisors are HMIs, PCs or other commissioning, monitoring or diagnostic
analysis devices. These devices are similar to Class 2 Profibus Masters.

IO-Controllers map IO data from PROFINET IO devices into the process image of the controller.
In Siemens S7 Programmable Controllers, I/O data, alarms and status data is mapped into the process
image in much the same way it is done for Profibus devices. These data values are then available for
use by the control program. IO-Controllers must support the following kinds of services:

 Cyclic Data Exchange – The exchange of data between IO-Controllers and IO-Devices.
 Acyclic Data Exchange – The exchange of Configuration and Diagnostic data
 Alarms – Alarm data exchange from an IO-Device to an IO-Controller
 Context Management – Connection processing

IO-Supervisors are used for commissioning and diagnostic data collection. IO-Supervisors can
read and write internal diagnostic data associated with the PROFINET IO stack or diagnostic data
provided by the application program of a device. IO-Supervisors can also read and write configuration
data using special, non cyclic record data object services. These types of devices may only be used
during the commissioning process or they may be used as an HMI to display diagnostic data to the end
user.

A PROFINET IO system requires at least one IO-Controller and one IO-Device. Systems can be
configured in various configurations; multiple IO-Controllers for a single IO-Device; single IO-
Controllers for multiple IO-devices and multiple IO-Controllers with multiple IO-Devices.