This work-in-progress paper was presented as part of the main technical program at IEEE ETFA'2011
Large PROFINET IO RT networks for factory automation: a case study
P. Ferrari, A. Flammini, F. Venturini
DII - University of Brescia
Via Branze 38
25123 - Brescia - Italy
paolo.ferrari@ing.unibs.it
Abstract
The paper presents a case study regarding a real
PROFINET IO network for factory automation. The aim
of the study is the evaluation of the time related
parameter of a real network. A large factory automation
plant has been chosen as testbed since PROFINET IO
RT Class 1 and 2 (unsynchronized) are mainly used in
those applications. The analyzed network has a high
number of distributed IO, actuators and sensors; its
topology is complex (star and ring); and it is fully
operative (in-production). The considered
implementation stresses the PROFINET IO
communication as no laboratory setup can do, giving
meaningful information about real operative conditions
on short-term. The results of this case study can be used
both to improve simulation models of devices and to
verify critical situations in real plants.
1. Introduction
The applications of Real-Time Ethernet (RTE) in the
factory automation fields are growing very quickly in the
last years. Among the dozen of RTE protocols available
in the market [1], the PROFINET IO is gaining
popularity, thank to the large installed base of
PROFIBUS, its parent technology [2].
The PROFINET IO approach is focused on the use of
the same protocol for all the possible applications, from
supervisory to motion control. Such an idea is applied in
real plants using unsynchronized (called Real-time - RT)
and synchronized (called Isochronous Real time - IRT)
communications. The highest performance are possible
with IRT; its behavior is well known since several
research works investigated it [3][4].
On the other hand PROFINET IO RT is based on the
best effort paradigm; hence its performance depends on
network implementation. Generally speaking, the
manufacturer provides engineering tools that
conservatively estimate the behavior of the network, and
try to suggest a design methodology to the user.
The use of simulations for the verification of the
design choice is not diffused at the end-user level. This
978-1-4577-0018-7/11/$26.00 ©2011 IEEE
A. Augelli
Siemens S.p.A
I IA Sensor and Communication Dep.
Via Piero e Alberto Pirelli 10
10126 Milano (Italy)
is due to limited simulation models and lack of trusted
simulation parameters from real devices/networks
[5],[6],[7].
The aim of this paper is to gather information about
the behavior of a real large PROFINET IO RT network
by means of measurements directly taken during
network operation. The timing parameters estimated
from the case study may be used to feed simulation
models, obtaining more effective simulation results.
Suitable logging equipment has been used to minimize
timestamp error during measurement campaigns.
In Section 2, a brief overview of PROFINET IO RT is
given. In Section 3, the network considered as case study
is introduced and discussed. In Section 4, the
experimental results are presented.
2. PROFINET IO RT (unsynchronized)
The PROFINET IO protocol is one of the RTE
communication profile family of the IEC61784-2.
PROFINET IO covers three communication profiles
CP 3/4, CP 3/5 and CP 3/6. PROFINET IO RT protocol
refers to CP 3/4 and CP 3/5. More details can be found,
for instance, in [8].
The PROFINET IO participants to a network are: IO-
Controllers (i.e. the device that manage/coordinate the
network, usually the PLC), IO-Devices (i.e. field devices
like sensors, actuators, IO modules etc.) and IO-
Supervisors for configuration/diagnosis purposes.
A real time data exchange is established between IO-
Controller and IO-Devices via real-time communication
channels. Other data (e.g. configuration, statistics) are
transferred using non-critical channel (i.e. UDP/IP).
PROFINET IO RT devices cyclically transfer process
data on the bus. The cycle time for real time data
exchange may be different for each device. Anyhow, a
device occupies the available bandwidth only for the
time needed for transfer data. PROFINET IO RT
specifications require that at least 40% of the bandwidth,
in any link, must be left free of any kind of PROFINET
traffic. The remaining bandwidth can be used by the non
real-time communication, allowing coexistence of UDP
or TCP traffic and real-time data on the same physical
network.
 PROFINET IO RT is often referred as ring switches (stars) or connected to drops (lines). The
“unsynchronized communication”; the stations are not maximum drop length is 9 devices. The switches are
synchronized among each other, so PROFINET IO RT configured as IO-Devices, so the total number of
stations do not begin bus cycles at the same time. A PROFINET IO-enabled devices in the network are 127.
direct consequence is that no relation exists between the The ring is managed by means of the Media
times at which inputs (outputs) are transmitted (received) Redundancy Protocol (MRP). The redundancy manager
on the network by each station. Moreover cycle duration is the switch # 1. The evaluation of the redundancy
relies on device local clocks, which have different performance of the considered network is out of the
frequencies, and hence also the phase between data scope of this paper.
transfers of different device is not constant. For all this
reasons, at application level the data update jitter is equal 3.1. Devices belonging to the network
to one cycle time. In the considered network there are products of
On the other hand the network infrastructure is not different vendors. Some manufacturer provides multiple
critical, provided that the sufficient bandwidth is models, and among devices of the same model the
allocated for PROFINET IO RT hardware configuration is different. In order to keep the
As a conclusion the PROFINET IO RT is a typical description in the paper as general as possible, the
best effort approach, whose performance depends on the devices will be classified by model, not by manufacturer.
network design and its operating conditions. A letter will be assigned to each model and the name of
the manufacturer will remain undisclosed. The minimum
3. Network description length of the PROFINET IO payload is 40 bytes, due to
the limit on the shortest Ethernet frames. Table 1 shows:
The considered network belongs to a sub part of the the IO-Devices models; their associated configuration
production line. The automation inside the considered (nominal Data Exchange period TDE; Packet length-
subpart is managed by the IO-controller (Main_PLC) Payload); and the relative number of instances.
with PROFINET IO RT Class 1 and 2. The manufacturer
of the Main_PLC is not relevant for the paper objective, IO-Device Nominal PROFINET Instances
so it will remain undisclosed. The information exchange TDE [ms] Payload
between the subparts of the production line is achieved [Byte In/Out]
by means of gateways (AKA PN-PN couplers) that act A 2 40/40 23
as two IO-Devices, each one in a different network. As a B 2 40/40 29
consequence, there is a complete separation at the C 2 40/40 10
network level between subparts, and hence, the results D 128 40/40 11
obtained in this paper are independent on the condition E 2 179/83 8
of the rest of the plant. F 2 40/40 7
The topology of the considered network is shown in G 4 40/40 27
Figure 1. The network has a ring backbone (100Mbit/s) S (switch) - - 11
with 11 switches belonging to it. The 115 IO-Devices
and the single IO-Controller are attached directly to the
Table 1. IO-Devices in the network.

Switch

IO-Device
1 2 3 4
IO-Controller

11 5

10 9 8 7 6

Figure 1. Topology of the considered network.


4. Experimental results
The experimental setup is shown in Figure 2. In order
both to minimize the impact of the measurement/logging
system on the network, and to obtain accurate results, an
Ethernet Tap (ProfiTap, Procentec) has been inserted in
series with the link of the IO-controller. The more
efficient approach proposed in [9] cannot be applied in
the considered case because of safety rules (the plant is
running at full production speed).
The Tap is transparent to the packets flowing in both
directions. It copies all the data, assigning a precise
timestamp to them (resolution: 5 ns). The logged stream
is sent to the monitor station (PC) that stores it as PCAP
file (a widely diffused file format for Ethernet logging).
All the timing parameters will be computed using the
Tap clock as time reference. Due to the short duration of
the network snapshot, the clock of the Tap can be
considered stable and affected only by white noise.
Hence, the statistical computation of mean and variance
is meaningful. The temperature of each IO-Device is
different, but the system can be considered stable from
the thermal point of view: the network was operating
since 3 hours before the measurements took place.
IO-Controller
Monitor
Tap Station
11 1 2
Figure 2. Experimental setup.
The traffic in the network has been recorded for 30 s.
For each IO-Device the following “short term”
parameters have been computed:
• Average duration of the TDE, measured as the
interarrival time between two packets of the same
IO-Device.
• Standard deviation of the TDE;
• Jitter of the TDE, that is the difference between
the shortest and the longest TDE in the
observation period.
Bandwidth usage in the IO-Controller link under test
is 26% outbound (IO-Controller → IO-Device) and 30%
inbound (IO-Device→ IO-Controller). The IO-Con-
troller and ring switches can be classified as belonging to
the “Net Load Class III” as indicated by PROFINET
reference document [10]. Some non-PROFINET traffic
is also present in the network: it is accounted for the
0.15% in both directions, and it is composed of TCP-
UDP conversations for configuration and management.
A variable number of packets has been considered
for the computation of the timing parameters of the IO-
Devices. For IO-Devices A, B, C, E, F, 14000 packets
have been used; for Type G, 7000 packets; and for type
D, 230 packets. The results are shown in Table 2 and
Table 3, depending on the direction of the data
exchange. For some models, more than one instance has
been considered.
The inbound traffic at the IO-Controller (Table 2) is
prone to path delay variation in the network. For this
reason, the standard deviation and the jitter have the
highest values in the experiments. Excluding IO-Device
D, the maximum jitter is lower than 0.6 ms and the
maximum deviation from nominal TDE is about 1000
ppm (devices B and G) . The great jitter of IO-Device D
is due to the implementation of the PROFINET IO stack
in such a device: it seems its PROFINET stack is
implemented in software. For sake of completeness,
Figures 3 and 4 show the distribution of the TDE for
devices B-1 and F-1 for inbound traffic: the B-1 device
is farther from the IO-Controller than the F-1, hence its
distribution is larger due to path delay variations.
The outbound traffic from the IO-Controller (Table 3)
shows a very regular behavior, as expected: the traffic
cannot modify the delay in this link because it is before
any switch. The maximum standard deviation is less than
6 μs. Some jitter values seems to be more frequent that
others, suggesting the internal operation of the
PROFINET stack is quantized with a time step of about
4.5 μs (greatest common divider of Jitter values).
The number of missing packets is low but not equal to
zero. The number of such events is low and always
under the watchdog condition; hence the system operates
correctly without any alarm. The main reasons for loss of
packets may be: CRC errors; deadline violation in the
firmware of the device; and frames lost by the
measuring/sniffing tool. The actual experimental setup
cannot reveal the exact cause, although results with light
network traffic (not shown here) seem to indicate the
frames are lost by the sniffing tool. However, new
measurements campaign has been planned and will be
carried out in the next future. The new measurements
will be taken using multiple Taps and merged with the
statistical information provided by the switches.
5. Conclusions
The behavior of a real PROFINET IO RT network
has been evaluated in this paper. Moreover, the
considered factory automation system has been analyzed
in the full production state. The preliminary results show
the generally good timeliness of the devices involved in
the network, which operate in a “heavy loaded”
condition. The standard deviation of the data exchange
period from IO-Device to IO-controller is lower than Figure 4. Distribution of TDE for IO-Device B-1.
50 μs. The information about the timing that has been
obtained in this case study may be used as input
parameter for simulation tool of large networks. The IO- Average Std. Dev. Jitter Missing
sporadic phenomenon of some missing packet is visible Device TDE [μs] TDE [μs] [μs] packets
and it will be investigated by means of further A-1 1999.995 0.318 27.840 12
measurements, which have been already planned. A-2 1999.995 0.383 32.640 1
B-1 1999.995 0.374 32.640 3
IO- Average Std. Dev. Jitter Missing C-1 1999.995 0.777 84.320 16
Device TDE [μs ] TDE [μs] [μs] packets C-2 1999.995 0.614 81.465 3
A-1 1999.999 22.069 214.085 1 D-1 127999.7 0.6 13.4 3
A-2 2000.004 53.520 276.965 3 E-1 1999.995 0.361 27.840 10
B-1 2002.342 43.049 595.125 5 E-2 1999.996 5.714 27.520 11
C-1 2000.016 31.832 231.440 8 F-1 1999.995 0.382 32.640 3
C-2 2000.000 29.055 214.165 7 F-2 1999.995 0.344 27.840 17
D-1 128009.4 3995.6 10591.8 0 G-1 3999.991 0.268 23.280 14
E-1 1999.995 30.038 499.770 1 G-2 3999.991 0.424 27.840 2
E-2 1999.990 49.361 563.290 5
Table 3. Timing parameters: IO-Con → IO-Dev.
F-1 1999.915 32.436 271.440 13
F-2 1999.922 14.834 118.640 8
G-1 4005.276 26.963 258.165 10 References
G-2 4005.288 25.619 266.000 6
[1] M. Felser, “Real-Time Ethernet - Industry Prospective”,
Table 2. Timing parameters: IO-Dev.→ IO-Con. in Proc. of IEEE, Vol. 93, N. 6, pp. 1118-1129, 2005
[2] J. Jasperneite, J. Feld, "PROFINET: An Integration
4000 Platform for heterogeneous Industrial Communication
3500
Systems", Proc of IEEE ETFA2005, Sept. 2005
[3] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, F.
3000
Venturini, "Evaluation of timing characteristics of a
2500
prototype system based on PROFINET IO RT_Class 3",
Proc. of ETFA 2007, Patras, Greece, Sept. 2007, pp.
Samples

2000
1254-1261.
1500 [4] Z. Hanzalek, P. Burget, P. Sucha “Profinet IO IRT
Message Scheduling”, Proc. of IEEE ECRTS 2009,
1000
pp.57-65, July 2009
500 [5] L. Liu, G. Frey, “Simulation approach for evaluating
response times in networked automation systems”, Proc.
0
1.85 1.9 1.95 2 2.05 2.1 2.15 2.2 of IEEE ETFA 2007, Sept. 2007, pp.1061-1068
TDE [ms] [6] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, F.
Venturini, "New Simulation Models to Evaluate
Figure 3. Distribution of TDE for IO-Device F-1. Performance of PROFINET IO Class 1 Systems", Proc.
of IEEE INDIN 2007, Vienna, Austria, July 2007, Vol.
1400 1, pp. 237-242.
[7] P. Ferrari, A. Flammini, S. Rinaldi, G. Gaderer,
1200
“Evaluation of clock synchronization accuracy of
1000 coexistent Real-Time Ethernet protocols”, Proc. of IEEE
ISPCS 2008, pp. 87-91, Ann Arbor, 2008
800 [8] B. M. Wilamowski, J. D. Irwin, “The Industrial
Samples

Electronics Handbook – PROFINET chapter ”, Vol. 2,

600
CRC Press, 2010
400
[9] P. Ferrari, A. Flammini, D. Marioli, A. Taroni, " A
Distributed Instrument for Performance Analysis of
200 Real-Time Ethernet networks ", IEEE Transactions on
Industrial Informatics, Vol. 4, N. 1, pp. 16-25 , 2009
0
1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 [10] PNO, “PROFINET IO Net load”, V1.0, Order. N. 7302,
TDE [ms] Nov. 2010