New Simulation Models to Evaluate Performance of

PROFINET IO Class 1 Systems

P. Ferrari, Member, IEEE, A. Flammini, Member, IEEE, D. Marioli, A. Taroni and F. Venturini

Abstract This paper deals with a simplified method to

estimate timing performance of real-time automation systems
based on PROFINET IO fieldbus. Simulations can be an
affordable solution to evaluate performance of real-time
networks before their physical implementation. In this work,
two complete models, one for generic PROFINET IOControllers and one for generic IO-Devices, are presented and
their configuration, parameters and attributes are discussed.
Application of the proposed models to extraction of
meaningful performance indicators, like worst event reaction
time, is also described. Last, results of some simulation
campaigns are reported; simulated event reaction time and
jitter for a test system are in accordance with experimental
measurements on the corresponding real system (relative
error < 3%).

I. INTRODUCTION

EAL-time Ethernet (RTE) protocols are used in many

industrial applications. RTE solutions constitute the
main choice for new plants, especially for the high-end
factory automation and the motion control. One of the most
promising RTE protocol is the PROFINET communication
profile family [1], considered in this paper.
RTE systems are required to fulfill strict timing
characteristics, so timing-related performance indicators are
needed. For instance, refresh time, event reaction time and
their jitter (i.e difference between maximum and minimum
value) are the typical parameters considered during system
design. Definitions and applications of such indicators can
be found also in some papers [2], [3], [4], [5] as discussed
later.
Unfortunately, behavior of a complex system is not
easily predictable, due to the extensive use of black box
components. For instance, if a reaction to an event must
take place within a given timeout, system engineers (during
design phase) can only make communication cycle time as
short as possible with respect to the estimated target
requirement. Successively, a compliance test is done during
commissioning phase, directly on physical inputs and
outputs.
An approach by means of simulation can be very useful
when complex network are considered. The proposed
approach, shown in Fig. 1, is based on simplified models

Manuscript received January 15, 2007.

P. Ferrari, A. Flammini, D. Marioli, A. Taroni and F. Venturini are
with the University of Brescia, Dept. of Electronics for Automation,
Brescia, Italy (phone: +39 030 3715445; fax: +39 030 380014; e-mail:
paolo.ferrari@ing.unibs.it).

oriented to timing performance estimation. Models are

implemented using parameters measured on a very simple
(test) network, since measurements on a single device are
simpler than overall network performance estimation.
Subsequently, component models are used in order to
estimate jitter and performance of the original complex
system.
Referring to Fig. 1, the choice of parameters and their
estimation (Phase 1) has been carried out by means of
experimental tests on simple networks as reported in [6].
In this work, new simulation models (Phase 2) are
proposed and discussed in details. Models for two
PROFINET IO Class 1 components are considered.
OPNET Modeler has been used to realize these models
utilizing the parameters obtained in [6].
Following sections regard explanation of the selected
parameters, descriptions of the proposed component models
and simulation results. In particular, verification of model
correctness has been done comparing simulation outcomes
with previously available experimental data. Moreover,
preliminary simulations of more complex systems have
been realized and timing performance at application level
have been estimated.
In the following, the reader is supposed to be familiar
with PROFINET IO and its nomenclature. For sake of
clarity, a brief introduction to PROFINET IO is given in the
next section.
II. PROFINET IO AND OTHER RELATED WORKS
A. Brief overview of PROFINET IO
PROFINET IO communication profile specifications are
available, as CP 3/4, CP 3/5 and CP 3/6, in the IEC
Committee Draft for Vote (CDV), which will become the
new international standard IEC61784-2 (July 2007).
PROFINET IO Class 1 will cover the future CP 3/4 and CP
3/5. A very brief overview of its characteristics is given in
the following, whereas a more detailed one can be found in
[7], [8].
PROFINET IO defines IO-Controllers (i.e intelligent
devices which carry out automation tasks), IO-Devices (i.e.
field devices like sensors, actuators, IO module etc.) and
IO-Supervisors for configuration and diagnosis purposes.
Process data are exchanged among IO-Controllers and

237

Fig. 1 . Flow of the full project.

IO-Devices via real-time communication channels. Any

other data (e.g. configuration, statistics) are transferred
using non-critical channel (i.e. UDP/IP). PROFINET IO
has real-time performance classes: Class 1 is used in
systems requiring cycle time up to tenth of milliseconds;
Class 2 and Class 3 can be used also with applications
requiring isochrony and cycle time of few hundreds of
microseconds. PROFINET IO Class 2 and Class 3 products,
with full isochrony, are available since the second half of
2006. Class 3 differs from Class 2 only for using topology
based bridging instead of address based bridging. In other
words, Class 3 can reach top performances since dedicated
switches reserve a quota of bandwidth for RTE by means of
a TDMA (time division multiple access) policy.
PROFINET IO Class 1 devices make a cyclical use of the
bus; a scheduling sequence is continuously repeated by
each station of the network. A cycle begins with
transmission of real-time data between stations (process
data first, then alarm data), followed by a free slot. This
portion of 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 Class 1 does not require special hardware
for its implementation. Standard switches can be employed
with unpredictable results in terms of latency (i.e.
increasing jitter). In order to limit such phenomena,
PROFINET IO RT specifications [1] require that at least
40% of the bandwidth must left free of any kind of traffic.
Moreover stations are not synchronized among each other;
cycle duration relies on device local clock, so PROFINET
IO Class 1 stations do not begin bus cycles at the same
time. A direct consequence is that, typically, no relation
exists among stations as regards time at which inputs or
outputs are transmitted or received on the network.
B. Existing papers about performance estimation
In [2] a PROFINET CBA (IEC61784-1 CP 3/3)
automation system has been analyzed. The scenario is a
peer-to-peer communication between two PLCs and the
performance indicators (called metrics by papers authors)
are: the Packet Time Interval, i.e the transmission cycle
time; the Round Trip Time Interval, that is the time
required by information to circulate from PLC1 to PLC2
and then to PLC1. Data are transferred from PLC buffer to

238

III.

PARAMETERS AND MODELS

A. Considered parameters
PROFINET IO data passes through several layers when
traveling from the process field to the controller and vice
versa. As a result, delay on inputs and refresh of outputs are
strictly related to cycle times of internal task in PROFINET
IO components, as illustrated in Fig. 2.
The key parameters that have direct influence on
performance of a PROFINET IO Class 1 system are:
the application cycle time in the IO-Controller, TIOC
the communication cycle time of PROFINET IO, TPN
elaboration/actuation/sampling cycles in the IODevice. Since a device can have many microprocessors and/or multiple tasks, several independent
cycle times are observable: TIOD, tIOD etc. It is
impossible to associate a cycle to a specific
microprocessor/task just looking to the device from
the outside (i.e. the device is a black box).
Size (in bits) of PROFINET IO packets, SPN
rising and falling time of physical output lines, Tr
and Tf
time constant of the physical input lines filters,
IO-Controller

TIOC

IO-Device

TPN

TIOD

Input
stage

Process

Phase 3

Internal Buffer

Phase 2

Simulation
of
complex
systems

IO-Device Buffer

Phase 1

Estimation of

Generation
of device
models

IO-controller Buffer

Estimation of
PLC cycle

PLC buffer, without using any I/O signals; thus the

presented results are hardly comparable with performance
of a true automation system.
In [3] simulation models of Ethernet-based automation
components are presented. The reference architecture was
the master-slave architecture. Papers authors define the
Response Time of the system as the time required to
produce an Output in response to an Input change. This
definition can be assumed to be equal to the Event Reaction
Time defined later in this paper. However, the proposed
models can not be applied to the PROFINET IO case, since
PROFINET IO does not offer a master-slave architecture.
Papers [4], [5] and [6] are previous works of the authors
of this paper. They describe the research path that starts
from experimental observations taken on PROFINET CBA
and PROFINET IO. Thanks to those measurements, authors
defined the strategies that are discussed in the following
section.

Application

Estimation of
Bus cycle

tIOD
Output
driver

Tr , Tf

Fig. 2 . Data path, cycle times and delays in a PROFINET IO system.

The proposed component model takes into account the

first four parameters, whereas it ignores the last two. This is
equivalent to suppose Tr = Tf (i.e. perfectly matched output
driver) and = 0 (i.e. a PLC high speed input).
Modifications to the model, in order to consider also such
contributions, are possible and a new model is currently
under development.
Some equations to obtain parameter value are known
from previous works [5], [6], and are used here. In details,
IO-Controller application cycle time TIOC depends on
application complexity. Even if application is practically
empty (e.g. continuous negating of a local input), TIOC is a
function of the number NIOD of connected IO-Devices and,
in our model, it is supposed to be linearly dependent from
NIOD, that is TIOC = + NIOD, where depends on
complexity of the high-level application and slope
depends on PROFINET interface implementation
(hardware and driver) and it is almost independent from
application.
As regards IO-Devices, number of internal cycles (TIOD,
tIOD etc.) must be experimentally estimated and can vary
from component to component. However, at the moment,
the most complicated IO-Device that has been evaluated by
the authors has only two internal cycles. So, two cycle
times, TIOD and tIOD, are sufficient for modelization.
TPN and SPN in PROFINET IO Class 1 are decided during
configuration phase. During normal operation TPN and SPN
do not change.
B. Modelization
As illustrated in the previous section, the behavior of a
PROFINET IO Class 1 component can be simplified and
seen as a combinations of cycle times. The idea behind our
component models for simulation and performance
estimation reflects this architecture. The proposed models
have been realized with the OPNET Modeler simulation
software [9]. Fig. 3 illustrates the basic model structures for
IO-Controllers and IO-Device.
Each cycle time is associated to a Copy action between
layers: regularly, every cycle time associated to the layer,
data are transferred between buffers associated to the
respective layers. Since a maximum of three independent
cycles (two internal cycles plus the communication cycle)
have been observed during experimental test, the proposed
models can have up to three layers.
Referring to Fig. 3, there is a layer, called CPU, that
represents the application level of an IO-Controller, or the
main application of the IO-Device embedded processor.
Sometimes, there is also an inner layer, called Backplane,
that could be associated to hidden operations inside the
PROFINET IO components, as, for instance, the bus
scanning of a modular system. The bottom layer, just over
the network interface, represents the communication cycle
and it is called PNL (PROFINET Layer).
Communication cycle time is imposed by the

a) IO-Controller model

b) IO-Device model

Backplane layer
CPU layer

CPU layer

PROFINET layer (PNL)

PROFINET layer (PNL)

Fig. 3 . Model structure: a) IO-controller model; b) IO-Device model

PROFINET IO configuration Tool. The other two cycle

times depend on IO-Device manufacturer or application
cycle time (user program duration in the PLC).
Each model has two global variables containing current
value of the simulated physical I/O. Simulated outputs are
changed by the CPU (or Backplane) process according to
data coming from PNL. Simulated inputs can be changed
by any other simulator component; inputs are sampled by
the CPU (or Backplane) process. The described architecture
allows realization of faithful application and measurement
scenarios. For instance, timing performance of the
simulated components can be measured directly on the
physical outputs as it happens in the real world.
C. Consideration about Statistical Behavior
Cycle times are not constant; they are generally affected
by jitter. In practical situations, each component has its own
time reference that is used to program transmission on the
bus or the scanning of I/O lines. On the contrary, in a
discrete event simulator any event is related to the
simulation time, a pretty rigid situation.
In order to increase adherence with reality, a small jitter
has been introduced in every cycle times. Since no apriori assumption can be made, a uniform distribution is
used for the jitter. Mean and boundaries values of such
distribution have been derived from [6]. In that paper is
also presented an experimental method to obtain such
parameters. Generally speaking, jitter of cycle times related
to programmable layers (e.g. CPU layer) is greater than
jitter of hardware/firmware based tasks (e.g. PNL).
D. Model Attributes
The discussed parameters and their associated statistical
properties are inserted in the simulator by means of the
Model Attribute panels shown in Fig. 4.
IO-Controller attribute panel has three fields related to

239

CPU cycle time: , and NIOD as previously

discussed.Other attributes allow modification of
communication cycle TPN and PROFINET IO packet size
SPN (expressed in bits).
IO-Device attribute panel has the Modular option that
enables the Backplane process resulting in a three layers
model instead of the normal two layers model. Other
attributes are identical to the IO-controller model.
IV. SIMULATION RESULTS
Aim of this section is to introduce the performance
estimation of complex PROFINET IO Class 1 systems by
means of the proposed models. Three scenarios have been
considered in this paper.
A. Simulation scenario 1: model verification.
The first simulation scenario has been used to verify the
proposed models. The simulation layout, shown in Fig. 5, is
equal to the experimental setup used in [6] to compute the
device parameters. The test network is composed of a
controller, two slaves and a generic store&forward
switch.
Only one slave is active during these simulations: the
other slave is idle and it does not interfere.
Parameters used for the model configuration are listed in
Table I. They correspond to real PROFINET IO
components manufactured by Phoenix Contact (ILB-PN24)
and Siemens (ET200S-PN and 317-2PN/DP).
The network has been configured to exchange packets
similar to the ones of PROFINET IO Class 1. Packet
dimension is 64 bytes in both directions (from the IOController to IO-Device and vice versa).
The IO-Controller (IOC) has one of its simulated digital
inputs, IC, that is virtually shorted with a simulated digital

TABLE I
MODEL PARAMETER FOR SCENARIO 1
Component
model
IO-Controller
(317-2PN/DP)
IO-Device 1
(ILB-PN24)
IO-Device 2
(ET200S-PN)

Parameter
TPN

NIOD
TPN
TIOD
tIOD
TPN
TIOD
tIOD

Mean Value
(s)
16000
117
70
1
16000
177
16000
1760
200

output, ODx, of the active IO-Device x (x=1,2). As

previously explained, the simulation of a physical link
between input and output is obtained by means of global
variables. At the application level, in the CPU process, the
IO-Controller negates input data coming from its own input
IC and sends the results to the IO-Device. At the IO-Device
side, received data are copied to the simulated output ODx.
As the result of this positive feedback loop, a square
waveform is generated on ODx. Due to model symmetry
(Tr=Tf) the time the output remains high, TH, is equal to
TPNq,Dx , that is the TPN quantized by the internal cycle time
of the considered IO-Device. Hence, from [6] it is possible
to write
TH = TPNq,Dx = MTIOD1+ NtIOD1
with M and N integers.
In order to evaluate performance, OPNET simulator has
been programmed to record ODx during the simulation.
Collected data are processed to extract TH distribution, as
shown in Fig 6 and Fig. 7 for IO-Device 1 (IOD1) and IODevice 2 (IOD1) respectively. Several groups of
measurement are visible in simulation results, as it happens
in case of a real experiment.
Verification of the model accuracy has been carried out
recalculating TPNq,Dx (mean value of each group of sample),
TIODx and tIODx from the simulation results. A comparison
between obtained value and real (experimental) value are
shown in Table II. The groups of samples are numbered as
in Fig. 6 and Fig. 7

a) IO-Controller

b) IO-Device

Fig. 4 . Attribute panels: a) IO-controller model; b) IO-Device model

240

Relative
Variation
0.5%
5%
5%
0.5%
2%
0.5%
2%
2%

Fig. 5 . Simulation scenario.

TABLE II
COMPARISON BETWEEN PERFORMANCE ESTIMATION OBTAINED FROM A
SIMULATED NETWORK (SIM.) AND FROM A REAL NETWORK (EXP.)
Component

TPNq,D1
IO-Device 1
TIOD1
tIOD1

TPNq,D2
IO-Device 2
TIOD2
tIOD2

Group of
samples
1
2
3
1&2
2&3
1
2
3
4
5
6
2&5
1&2

Sim.
(s)
15844
16013
16183
169
170
15597
15783
15971
17389
17590
17777
1807
186

Exp.
(s)
15997
16173
176
15554
15761
16017
17312
17522
17692
1761
207

Error
(s)
16
10
-6
43
22
-46
77
68
85
46
-21

General accordance between simulation and experimental

results demonstrate the correctness of the proposed models.
B. Simulation scenario 2: performance estimation
In the second scenario the simulation environment has
been set to evaluate the event reaction time of a PROFINET
IO Class 1 network. Layout, complexity and components of
the network under test can be easily changed thanks to the
powerful simulation environment.
However, for sake of simplicity, the same network of
Fig. 5 is considered. Model parameters are identical to the
ones reported in Table I, with the exception of NIOD = 2.
Event reaction time, TER, is defined as the time taken by
the system to activate an output in response to an event
(e.g. a change of an input value).
In order to measure TER between input ID1 of IO-Device 1
and output OD2 of IO-Device 2, the IO-Controller negates
input data coming from ID1 and sends the results to OD2.
There is also a virtual short-circuit between ID1 and OD2; the
virtual link is realized as described in the previous sections.
As usual, a square waveform is generated on OD2.
In this scenario, thank to model symmetry, the desired

performance indicator is
TER = TH
Moreover, the jitter JER on TER is important and it is
defined as
JER = max[TH] min [TH]
OPNET simulator records OD2 during the simulation and
extracts TH distribution. Simulation results are shown in
Fig. 8: maximum value of TER is 33636 s and its jitter JER
is 19439 s. Experimental results obtained in the same (but
real) situation are TER = 33874 s and JER = 19874 s.
It is clear, from numerical and graphical results, that JER
is roughly equal the imposed TPN (16 ms). Table III reports
simulation outcomes when different communication cycle
times are considered. Obviously JER>TPN because IOC and
IOD communication cycles are not synchronized.
TABLE III
SCENARIO 2: WORST CASE EVENT REACTION TIME TER AND JITTER JER
VARYING COMMUNICATION CYCLE TIME T PN
TPN
(ms)
4
8
16

A further simulation has been carried out varying the

number of switches between IO-Device and IO-Controller.
Network layout has a tree topology with IO-Controller
connected at top level. Results are summarized in Table IV
for TPN = 4 ms.
TABLE IV
WORST CASE EVENT REACTION TIME (AND JITTER)
VARYING NETWORK TOPOLOGY (T PN = 4 ms)
Switches
along path
IOC - IOD1
1
1
1
3
3

Switches
along path
IOC - IOD2
1
2
3
1
3

Max TER
(s)

JER
(s)

9020
9039
9039
9029
9029

5647
5665
5664
5655
5662

200

40

2
2

150

1
20

Sam ples

30
Samples

JER
(s)
5647
10976
19439

Max TER
(s)
9020
17760
33636

100

50

10

1
0
15715

15822

15928

16035

16142

T H (s)

Fig. 6 . Scenario 1: Distribution of TH for IO-Device 1.

0
15367

4
16090

16814

17538

T H (s)

Fig. 7 . Scenario 1: Distribution of TH for IO-Device 2.

241

V. CONCLUSION
1200

JER
1000

Sam ples

800
600
400
200
0
14586

18474

22361

26249

30137

T H (s)

Fig. 8 . Scenario 2: Distribution of TH = TER.

The number of switches does not influence the system

performance since: the network traffic is extremely low; the
PROFINET IO packets are very small; switches internal
delay in the order of 2 s. Clearly such results depend on
switch type and are significant only if switch model is
derived from a true industrial switch. Currently a generic
switch model from OPNET library is used, but estimation
of parameters of a PROFINET switch is planned.
C. Simulation scenario 3: device dependency
The third scenario is used to evaluate if timing
performance are dependent from physical devices or not.
Components and parameters are the same of scenario 2,
but the roles are exchanged between IO-Devices. This
means that ID2 of IO-Device 2 and output OD1 of IO-Device
1 are considered; the IO-Controller negates input data
coming from ID2 and sends the results to OD1. A virtual
short-circuit between ID2 and OD1 is placed, generating a
square waveform on OD1.
OPNET simulator records OD1 during the simulation,
extracts TH distribution and computes TER and JER. Table V
reports simulation results when different communication
cycle times are imposed. It should be noted that
experimental results obtained in a real situation are
TER = 32195 s and JER = 16302 s when TPN = 16 ms is
used.
Comparison between Table III and Table V clearly
shows that system performance depends on which device
drives the system output. Hence, commissioning practice of
moving an output from a device to another (for a variety of
reasons, e.g. to shorten a cable) could impact significantly
on performance.
TABLE V
SCENARIO 3: WORST CASE EVENT REACTION TIME TER AND JITTER JER
VARYING COMMUNICATION CYCLE TIME T PN
TPN
(ms)
4
8
16

242

Max TER
(s)
8277
16293
32266

JER
(s)
4436
8428
16567

PROFINET IO is one of the most promising Real-Time

Ethernet protocol. Several products are available with such
technology, and many plants have been already installed.
This work introduces a new method to estimate timing
performance of automation systems based on PROFINET
IO Class 1. Specifically, simulation models of IOController and IO-Device have been created, discussed and
verified against experimental data. The proposed models
have been included in a OPNET Modeler module library,
hiding their complexity. In other words, they appear like
standard components, usable in the OPNET IT Guru
graphical environment. Models are easily customizable by
means of parameters, since the implementation of IODevices or IO-Controllers may vary from manufacturer to
manufacturer. Configuration parameters can be determined
by means of simple experiments on the real device.
The main application of the presented models is the
simulation of complex systems, allowing performance
indicators estimation before network implementation. For
instance, worst case event reaction time and related jitter
can be obtained, helping engineers during system
development.
Results of model verification show a very good match
among simulation and experimental results, with error
below 100 s. In fact, simulated event reaction time and
jitter for a simulated test system are in accordance with
experimental measurements on the corresponding real
system (relative error < 3%).
REFERENCE
[1]
[2]
[3]
[4]
[5]

[6]

[7]
[8]
[9]

PNO, PROFINET IO application layer service definition,

application layer protocol specification Ver. 2.0, April 2005,
http://www.profibus.com
M. Antolovic, K. Acton, N. Kalappa et alt., PLC Communication
using PROFINET: Experimental Results and Analysis, Proc. of
11th IEEE ETFA2006, Sept. 2006, Prague CZ, CF-001724
G. Marsal, B.Denis, J. M. Faure, G. Frey, Evaluation of Response
Time in Ethernet-based Automation Systems, Proc. of 11th IEEE
ETFA2006, Sept. 2006, Prague CZ, CF-001848
P. Ferrari, A. Flammini, S. Vitturi, Performance Analysis of
PROFINET Networks, Computer Standards and Interfaces, Vol.
28, n. 4, 2006. pp. 369-385
P. Ferrari, A. Flammini, D. Marioli, A. Taroni, An experimental
approach to estimate characteristics of PROFINET IO versus
PROFIBUS DPV2, WSEAS Trans. on Circuits and Systems,
Vol. 5, N. 4, 2006, pp. 485-492
P. Ferrari, A. Flammini, D. Marioli, A. Taroni, F. Venturini
Experimental Analysis to Estimate Jitter in PROFINET IO Class 1
Networks, Proc. of 11th IEEE ETFA2006, Sept. 2006, Prague CZ,
CF-002151
J.Feld, PROFINET Scalable Factory Communication for all
Applications, Proc. of 5th IEEE WFCS2004, pp. 33-38, Vienna,
Austria, 2004
J. Jasperneite, J. Feld, "PROFINET: An Integration Platform for
heterogeneous Industrial Communication Systems", Proc of 10th
IEEE ETFA2005, Sept. 2005, Catania, Italy
OPNET Modeler, OPNET Technologies. http://www.opnet.com