PROFINET - Scalable Factory Communication for all Applications

Joachim Feld
Siemens AG
Gleiwitzer Str. 555
90475 Nurnberg
joachim. feld@,siemens.coni

Abstract
PROFINET is the Industrial Ethernet Standard devised by PROFIBUS International (PI) for either
modular machine and plant engineering or distributed
IO. Using a plant-wide multi-vendor engineering for
modular machines, commissioning time as well as
costs are reduced. With dishibuted IO IO-Controllers
(e.g. PLCs) with their associated IO-devices may also
be integrated into PROFINET solutions. Communication is a major part of PROFINET. Real-time
communication for standard factory automation applications as well as extensions which enables motion
control applications is covered in a common real-time
protocol. The advantages of modular and multi-vendor
engineering and distributed IO can be used even in a j plications with time-critical data transfer requirements.

1. Introduction
PROFINET is the Standard of PROFIBUS Intemational (PI) to emerge Ethernet to the next generation of
industrial automation. PROFINET consists of several
topics such as distributed automation (PROFINET
CBA), decentralized field devices (PROFINET IO),
network management installation guidelines and web
integration. All these different topics will help to make
standard switched Ethernet [3,4] easier to use in industrial automation.
In the distributed automation concept PROFINET
CBA machines and systems are divided into technological modules, each of which is comprised of mechanical and electronical components, electronics and
software. The functionality of the technological modules is encapsulated in the form of PROFINET CBA
components. From the outside the PROFINET CBA
components can be accessed via interfaces with stan-

0-7803-8734-1/04/$20.00
Q2004 IEEE.

dardized definitions. They can be combined with one

another like building blocks as required and easily reused.
PROFINET IO enables the use of decentralized
field devices with Ethernet. With decentralized field
devices all automation devices including IO-devices,
valve islands, frequency converter etc. can easily be
used in a homogenous network infrastructure.
The combination of distributed automation and decentralized field devices is the base for complete solutions for factory automation. Thus the advantages of a
uniform and consistent network infrastructure (one
connector, one cable, standardized network management and diagnosis) become available. But there is not
only a consistent network infrastructure; also data
transfer between devices is standardized and homogenous. Both for communication between intelligent devices and data transfer between PROFINET IOController and PROFINET IO-Device the same protocol, communication mechanisms and network scheduling are in charge.

2. Principles of real-time communication

The requirements of real-time communication comprises in general of deterministic behaviour, reaction
time in the required range (5-IOms for factory automation, Ims and below for motion control applications)
and a small need of device resources e.g. processor
load and memoly use. Reaction time is the time needed
to acquire a signal on a device A (provider), process it
inside the user program, send it over the communication line to a device B and process it in the user program in device B (consumer) (see figure I).

33

datagrams (see figure 2). The value of the ethettype is

0x8892 and is standardized by the IEEE [SI.

OMMUNICATION

COMMUNICATION

Figure 1. Actualization rate consists of several

factors.
Reaction time comprises of several parts:
Ti: Time to acquire data in the application on the
provider resp. process it in the consumer
T2: Time to process data inside the communication stack
T3: Time to transfer data over the wire. This includes both the time on the wire and the delay
of the network components.
Time to acquire or process data or the transfer over
the wire are fixed and are mostly determined by the
architecture of the devices or the network topology. So
it is evident that the best savings can be achieved
through optimizing the processing time needed in the
communication stack.

To initiate a layer 2 communication another high

level protocol is used to keep the layer 2 protocol as
simple as possible. This context management protocol
is based on OSF DCE RF'C. PROFINET IO and
PROFINET CBA use the same ProvideriConsumer
concept and real-time protocol to distribute real-time
data [2].

Figure 2. Layout of the PROFINET real-time

PDU [2]
Real-time data and standard data are scheduled by a
device driver inside the device to keep the real-time
data at a high priority (see figure 3). In further steps the
optimized real-time channel will be integrated into
hardware to relieve the device from communication
tasks and to support more sophisticated applications
l i e e.g. motion control.

Layer 7

The latencies caused by the TCPiIP or UDPAP stack

can be saved. Also additional features of these protocol
stacks are not needed for real-time communication:
Through the use of a cyclic data transfer no connection oriented protocol is needed to control the
communication partner
Real-time communication has typically not to be
routed via subnet boundaries. The functionality of
an I S 0 Layer 3 (IP) needs not to be supported, because delay o f routing is a lot more khan the reaction time needed in automation applications.
The size of application data that have to be transferred are typically in a range of 32-256 Bytes. No
segmentation is needed because with Fast Ethemet
a maximum of 1500 bytes application data fit into
one Ethemet frame. Protocol elements needed for
segmentation can be omitted.

3. PROFINET real-time protocol

PROFINET is enhanced with a communication
channel that is especially designed to fulfil the above
requirements for real-time communication. The realtime channel is based on a cyclic provider / consumer
architecture with Ethemet layer 2 frames for the fast
and reliable data transfer between PROFINET devices.
To ease the processing o f real-time frames inside the
devices a specific ether type is used for PROFINET

34

I RT Driver I

Figure 3. An optimized real-time channel enhances the PROFINET device architecture

The real-time driver itself consists of several parts.
Beneath cyclic real-time data, that is typically accessed
via a buffered interface PROFINET supports acyclic
real-time data via a queued interface for fast diagnosis
and events. Frames for cyclic data transfer are called
RT frames, frames for acyclic data transfer are called
aRT frames.
For acyclic data transfer, an additional acknowledged based protocol is included in the application
data. For cyclic data transfer the layout of the data
frame is configured during the context management
establishing phase. So no additional overhead in terms
of data types, sttucture information etc. is included in
the cyclic exchanged data h e .

3.2 PROFINET real-time classes

The optimized real-time protocol is only one part of
the PROFINET real-time enhancements. As stated in
[I] TDMA based scheduling is best for Ethemet to
achieve
real-time
requirements.
Additionally
PROFTNET shall cooperate with IEEE 802.1 compatible network components. So PROFINET supports
different real-time classes which are all based on a
common scheduling architecture:
Local real-time scheduling: For most applications
with cycle time in the range of 5 ms and above
standard switch based ethemet technology is
sufficient. A bandwidth of
100 MEVS (Fast
Ethemet) full duplex is sufficient enough especially
when using VLAN based prioritization [5] to assure
that real-time telegrams are preferred during
switching lnside standard network components
compared to standard IF' traffic. Synchronization
based on the cycle counter between consumer and
provider improves bandwidth and reduces
tempomy overload The scheduling is independent
of topology knowledge and standard IP traffic is
possible in parallel to real-time data.
Synchronized real-time scheduling: Motion control
applications need cycle time in the range of 1
millisecond and below with a jitter in the range of
less than 1 microsecond. Standard switched
ethemet cannot fulfil these requirements without
enhancements especially when standard IF' traffic
shall be possible in parallel to real-time data.
Other Ethemet based real-time concepts (e.g. PowerLink, EtherCat, ModBusECP, EthemeVIP) support
typically only one of the !NO real-time classes [9]:
Powerlink [ 1 I] uses standard network components
but it is l i t e d to hub technology instead of
switching technology. The real-time traffic is concentrated in a special real-time domains and non
real time traffic must be scheduled by designated
nodes on the boundaries of the domain.
EtherCat [I21 devices are organized in ring topole
gies and real-time traffic only flows through this
ring. At designated positions standard IEEE based
devices may be connected but there is no real-time
tnffic to theses devices. Non real-time traffic can
be sent through the real-time domain using these
designated devices.
ModBusECP [I31 is based on TCPKJDP and standard network components. The cyclic data are
transferred between client and server on a requestireply basis where additional delays are
aroused through the processing time of the request
on the server side. ModBus/TCP delivers no solution for real-time data transfer suitable for motion
control applications.

EthemeVIP [I41 is based on UDP and uses standard

network components. EthemeVIP is m e l l i n g native DeviceNet protocol and inherits all advantages
and disadvantages. If non real time traffic is handled, resource conflicts arise inside the UDP stack
an real-time data may be delayed Like in ModBusECP there is no integrated solution for realtime data transfer suitable for motion control.
3.1 Basic communication Scheduling

'

The scheduling of the PROFINET real-time communication system both for local and synchronized
real-time scheduling is based on the following parameters (see figure 4):
Sendclock
The attribute send clock is expressed in multiples of
the time base 3 1,25 microseconds. A typical value
of the send clock is 32 so the length of a phase (see
below) is exactly 1 ms.
Reduction Ratio
This attribute contains the reduction ratio of the
send clock of the device. The actual send cycle of
the data is reduction ratio multiplied with the send
clock.
Phase
This attribute indicates in which particular send cycle the data has to be sent. Allowed values are between l and the selected Reduction Ratio. The attribute phase allows to spread the sending of the
frames over a whole send cycle and provides a
means to manage distribution of the used bandwidth. The phases e.g. 1 to 4 are possible if the Reduction Ratio is set to 4.
Sequence
This attribute contains the position of the data
frame in the sending queue.
Frame Send Offset
This attribute contains the relative send offset to the
start of the related reduction ratio and phase. Sequence and frame send offset can be used altemative because sequence is not as precise as needed
for motion control requirements.

Figure 4. Overview of scheduling parameters in the real-time channel

35

For every frame in the real-time channel this set of

parameters is computed based on the engineering data
and sent to the producer side of the communication
relation. The cnnsumer side has no explicit
communication scheduling but every consumer is
related to at least one producer.

31,25usc= T-m

e4ms

3.2.1 Local Real-time Scheduling

PROFINET provides a mean for unsynchronized

real-time communication based on a local real-time
scheduling at the sending D E interface. Therefore no
special tolerance parameter for the jitter within the
system are defined. It is aimed to control the usage of
the bandwidth within the system..
PROFINET devices shall use a data rate of 100
MBit/s and full duplex mode in switched environment.
In theory, each device could use always wire speed for
sending frames. Such behavior applied over a certain
amount of time would bring the system out of
operation because on certain links between switches
additonal NRT traffic (e.g between intemet browser
and web server of non PROFINET devices) has to be
handled. The switches involved have to handle the
overload situation with queuing the frames (up to the
situation all their intemal buffers are filled) and at least
dropping them. Therefore, PROFINET provides a fair
mechanism to restrict the sending performance of each
device. To.improve the use of bandwidth and to
prevent temporary overloads on distinct connections or
devices
(e.g.
PROFINET
IO-Controller) a
synchronization of the provider send clock to a
designated consumer send clock is possible. This
synchronization is based on the value of the cycle
counter with an estimated accuracy of one send clock.

...

Figure 5. Example of unsynchronized realtime behavior at the local interface

For the local scheduling the following rules are
applied
The local sending process shall drop all RT frames
for the whole cycle if at the beginning of the new
sending period the fist RT frame can not be send
because of overload at the local interface.
In average, not more than a certain amount of
bandwidth should be used to avoid overload of the
system.
Figure 6 illustrates an example for an overload
situation at the local sending interface. At &h,,k+l
the
provider gets a send error by the MAC because of a
temporary overload situation. In this case the provider
completely skips the sending of RT frames for the
whole cycle and tries again within the next cycle.
However, other frames (e.g. NRT) may be send within
the cycle if it is possible.

I
As shown figure 5 , the sending of frames at the
local DT!? interface is divided into different cycles at
the local interface. Each cycle is defined by T s ~ ~ ~ ~ L
which is between 31,25 microseconds and 4
milliseconds. At the beginning of cycle at tS,kl,k
the
Figure 6. Example of dropping RT frames b e
cyclic scheduled RT frames that are related to the
cause of local overload
device are sent The number of frames depends on the
scheduled kames for the current phase and may be also
3.2.2 Synchronized Real-time Scheduling
zero. The time for RT frames should not exceed a
certain amount of the bandwith (e.g. 50 percent) for
Inside switched Ethernet, different kames that shall
each cycle. Subsequently, possible acyclic real-time
be sent on the same port are processed on a First
(aRT) frames will be sent. The time for such frames
come, First served strategy. With VLAN Tags it is
should also not exceed a certain amount (e.g. IO
possible to improve the delay for special frames, but
percent) of the bandwith. Then Non real-time (NRT)
queuing still adds unpredictable delays to the transfer
frames (uDP,TCP) will be sent during the rest of
time. To improve the determinism for the transfer of
available time.
frames Ethernet bandwidth has to be reserved explicThe amibutes reduction ratio and phase should be
itly for real-time data not only in the devices but also in
used for the distribution of the RT frames over the
the switches.
time. The network load is limited and steady by these
means.

36

Beside the existing cycles on the local device interface, an IRT (isochronous RT) cycle is inserted (see
figure 7). Inside the IRT cycle only designated IRT
frames are transferred. The destination of IRT frames
is based on the application ID and the time offset inside
the cycle when the kames are sent (time scheduled
communication). Other RT frames are buffered until
the RT cycle starts. As stated above RT frames are
transferred based on standard IEEC 802.1 switching.

Redundancy: When sending a frame on different

paths to a device redundancy can be achieved, hecause with a very high probability (single failure) at
least one frame will he received.
Optimized use of bandwidth: Frames in different
parts of the topology may be transferred at the same
time. The scheduling algorithm can suggest topology alternatives for optimization.
The scheduling algorithm needs the following
inputs:
Topology of the network
Amount of data for every producer or consumer
Additional connection features like Length, cable
delay, MAC delay of the local interface, media
type (fibre, copper, WAN),...

Figure 7. Reserved cycle for IRT communication

The jitter of the synchronization of the IRT cycle in
the different devices shall be in the same range as
needed for the motion control applications (<< 1 microseconds). To achieve a deterministic transfer of the
IRT kames inside the IRT cycle the send time of every
frame is explicitly calculated and fix for every frame.
Even the boundaries of the IRT cycle are explicitly
planned. The boundaries between the other parts of the
cycle depend on the amount of frames to be sent and
can vary over time. The boundaries of the IRT cycle
(begin or end) can additionally be used as indication
for the start of an application (e.g. position control).

3.2.2.1 Topology based scheduling

For address based transfer of data in switched
ethemet the configuration of the endpoints is sufficient
Qrodncer, consumer). All other components that lay
between the endpoints (e.g. switches) have address $bles which are learned dynamically during communication.
In difference a time scheduled transfer (like IRT)
needs not only to know the endpoints but also every
node that lies between it. The knowledge of the exact
topology has additional advantages:
Guaranteed determinism: For every frame the time
to send on the device (producer side) is exactly
planned and the send time of one frame is different
to all other frames on the same node. Furthermore
frames sent on different ports of a device may be
sent at the same time. The time to send for all
switching nodes that lay in the topology between
the producer and the consumer. No queuing on the
switches will occur and the transfer time inside the
switching node can be reduced to a minimum.

The output of the scheduling algorithm are the

scheduling parameters for PROFINET as described in
chapter 3.1. Additionally the port number over which
the designated kame shall be sent has to be added. All
switches that lay on the path between the producer and
consumer also need the scheduling information. The
scheduling information is part of the configuration parameters and transferred during the setup phase.
3.2.2.2 Clock synchronizationin switched environments
IRT needs exact clock synchronization of the different devices (PROFINET IOdevices, switches, ...) for
the time based scheduling. In practice the clock s p chronization algorithms will be included in hardware.
Otherwise the requirements of jitter can only be
achieved in selected topologies like all devices connected to one switch in star topology. But automation
applications with Ethemet are typically realized as line
topologies in comparison to star or tree topologies
typically used in office applications (see figure 8 and
figure 9).
Building 1

Building 2

'

Figure 8. Typical network topology used in office buildings

37

Figure 9. Typical network topology used in

automation applications
The number of switches between producer and consumer of a frame is typically much larger (up to 50 100 switches) in an automation environment than in a
typical office environment. So much more care has to
be taken to the delay caused by switches. Synchmnization fiames sent as multi- or broadcast cannot trigger
time-synchronized actions because
the delay in switches is within the range of the microsecond jitter. Thus, the number of bridges between sender and receiver will cause a indetenninable time offset.
as IEEE 802.3 is non preemptive, a frame send
will cause a delay of more than 12000 bit times
(125 microseconds in Fast Ethemet).
To achieve the required synchronization of nodes,
special support is required in the local interfaces and
switches to
measure the line delay of a frame between two
nodes
allow calculation of all extemal and internal delays
from a clock synchronization master to any node.
With IRT a synchronization algorithm that takes
consideration of the above requirements is part of the
specification. To achieve the required accuracy hardware support is needed. The algorithm will be based on
PTP 1588 with enhancements.
In principle the algorithm is based on a correction of
synchronization frames in every switch that transfers
the synchronization telegram from the time sync master to the time sync slave. This local time correction is
called a Bypass clock in comparison to the Boundary Clock introduced with standard PTP 1588 protocol [SI. With these enhancements IRT communication
can be used even in large line topologies.

4. Conclusion
With communication based on local time scheduling
as well as synchronized real-time scheduling
PROFINET offers solutions for real-time communication for factory automation concepts as well as high
end motion control applications. Based on a common
real-time protocol for cyclic and acyclic data transfer
migration between the two real-time approaches is very
easy to achieve.

38

In combination with the concepts for distributed

automation PROFINET CBA and decentralized field
devices PROFINET IO all customer requirements concerning openness and standardization are fulfilled.
With additional concepts for network management,
web integration, safety, installation guideline etc.
PROFINET offers a complete solution for industrial
Ethemet based automation concepts .
References
[11 How to guarantee realtime behaviour using Ethemet,
Jiirgen Jaspemeile, Peter Ne,
1 Ith IFAC Symposium on Information Control Problems in Manufacoxing, Salvador da Bahia, Btazil, April 2004
[2] PROFINET Specifiration, PROFINET IO Application
Layer Service Definition, Application Layer Protocol
Specification, Version 1.0, March 2004,
[3] IEEE. Speci$cation/or 802.3 Full Duplex Operation.
IEEE, New York 1997. ANSVIEEE Std. 802.3~.
[4] IEEE. Media Access Confrol (MAC) Bridges. IEEE,
New York, 1998. ANSVIEEE Std 802.lD-1998.
[SI IEEE. Virtual Bridged Local Area Network. IEEE,
New Yor 1998.ANSIiIEEE Std 802.1Q-1998.
[6] EEE. Camersense multiple access with collision detection (CSWCD) access method and physical layer
specifrrtions. IEEE, New York, 2ooO. ANSVIEEE Std
802.3-2000 Edition (ISOLEC 8802-3:2000(E)).
[7] IEEE. IEEE Standardfor a Precision Clock Synchronization Protocolfor Networked Measurement and Control Systems. IEEE, New York, 2002. ANSIiIEEE Std
1588-2002.

IEEE Etheriype Fieldpublic assigned numbers,

http://standards.ieee.olg/regauth/ethertpuh.html.
[9] Communication in industrial automation - What
is going on?, Peter N e t u , I Ith IFAC Symposium on Information Control Problem in Manufacturing, Salvadorda Bahia, B-I,
April 2004
[IO] Ethemet in der Automation, P6schmann, A, Werner, Th.;Studie ZVEI, Frankfiuf 2003
[I 11 Powerlink, Ethemet Powerlink Standardamtion
Group, www.ethemet-powerlink.com,2003
[I21 EtherCat, EtherCat Technology Group,
www.ethercat.org, 2004
1131
ModBus.
- Modbus Users Web Site.
a
>
www.modbus.org, 2004
[ 141 EthemetIP, Ethemet Industrial Protocol,
wvw.ethcmet-ip.org, 2003
[SI