Evaluation of timing characteristics of a prototype system
based on PROFINET IO RT_Class 3
Paolo Ferrari, Alessandra Flammini, Daniele Marioli, Andrea Taroni, Francesco Venturini
University of Brescia - DEA
Via Branze 38, 25123 Brescia, Italy
Ph.+390303715627 Fax. +39030380014
alessandra.flammini@ing.unibs.it
Abstract
The PROFINET architecture can provide real-time,
high-performance, isochronous communication
regardless the presence of other real-time data exchange
and TCP/IP traffic for a considerable portion of network
bandwidth. In this work some experimental tests have
been executed in order to evaluate timing performance
of a PROFINET ASIC (ERTEC 400 chip) and its related
development kits. Results shows that communication
isochrony has been ensured with a jitter of about 100 ns
despite TCP traffic (70% of bandwidth) and presence of
PROFINET IO RT_Class 1 nodes. On the contrary, some
improvements are still needed as regard features of the
software stack and of the interface with the application
layerl. The highlighted problems will be probably fixed
in the next firmware releases planned by manufacturer.
1. Introduction
Some industrial processes (like packing, machining,
and motion control) could take advantage, in terms of
production quality and costs, from a strictly repetitive
behavior in input and output management. Event
reaction time, i.e. the delay between an input event and
the output reaction, should be in the order of
milliseconds but its variability (i.e. maximum value less
minimum value) should be three orders of magnitude
below. Only few isochronous deterministic fieldbuses
(i.e. PROFIBUS DPV2) can provide these
characteristics.
Today, many Ethernet based solutions easily make
available soft-real time protocols with TCP/IP traffic
compatibility, but variability of event reaction time is
quite high. In fact, fieldbuses usually have a very simple
infrastructure with negligible delays and they manage
the medium in an exclusive way [1].
A completely new scenario has been open by Real
Time Ethernet (RTE) protocols that take in account
several unpredictable sources of delay: switches,
coexistence with TCP/IP traffic, and the intrinsic non-
1-4244-0826-1/07/$20.00 © 2007 IEEE
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
determinism of Ethernet [2]. For all these reasons, RTE
protocols require more complex synchronization
methods in order to achieve isochrony in frame delivery.
IEC 61784-2 defines several RTE solutions, each
with its pros and cons. Among them, PROFINET IO
offers a multi-level approach that joins together: high-
performance real time and isochrony required by some
nodes; with simplicity and flexibility desired by other
nodes; the acyclic needs of TCP/IP traffic, in terms of a
significant part of bandwidth, for low priority data
transfer. As better described in the following,
PROFINET IO provides three types of communication
class, each with different complexity and performance,
sharing the same medium and bandwidth in order to
satisfy different communication needs. Thanks to the
recent availability of development tools that simplify the
design of nodes based on PROFINET IO RT_Class 3,
the ambitious scenario of fully isochronous and
deterministic networks could become true.
The aim of this work is the experimental evaluation of
PROFINET IO RT_Class 3 nodes built with these
development kits. Particularly, this paper highlights good
and bad aspects of design process, discussing timing
characteristics of frame delivery and behavior at input
output level. Finally, some improvements at the
Firmware (FW) / Application Layer (AL) interface are
proposed.
2. PROFINET IO RT_Class 3 (IRT)
The trade name PROFINET IO corresponds to the
communication profile specifications CP 3/4, CP 3/5 and
CP 3/6 of the new international standard
IEC61784-2:2007. PROFINET IO RT_Class 2 and 3
cover the CP 3/6, whereas PROFINET IO RT_Class 1
corresponds to CP 3/4 and CP 3/5. An introduction of
PROFINET IO is presented in [4]; in the following, a
brief description of RT_Classes behavior is given.
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.)
1254
and IO-Supervisors for configuration and diagnosis
purposes.
IO-Controllers and IO-Devices exchange data using
different channels with different properties. Process data
use real-time communication channels, while
configuration, statistics, and management data use non
real-time channels (i.e. UDP/IP). PROFINET IO grade
of determinism is described with the class number:
RT_Class 1 (RT, Real-Time) is used in systems
requiring cycle time down to tenth of milliseconds;
RT_Class 2 and RT_Class 3 (often called IRT,
Isochronous Real-Time) are used with applications
requiring isochrony and cycle time in the order of 1 ms.
PROFINET IO data exchange is based on a highly
repeatable cycle as described in IEC61158-5-10 and
illustrated in Fig. 1. A synchronization message (sync
frame) determines the cycle start. Several phases can be
recognized in a cycle:
• RED phase: during this phase, only RT_Class 3
messages are sent on a time scheduled basis through
“a priori” defined path. This means that all
PROFINET IO RT_Class 3 devices know when, and
on which physical port, they are allowed to talk or
listen to.
• ORANGE phase: only RT_Class 2 frames are sent
in this phase. Also RT_Class 2 has a time base
schedule but the physical path is not defined.
• GREEN phase: this phase is composed of Ethernet
message managed using the Ethernet priorities
(IEEE 802.1Q). GREEN phase communication is
used by: RT_Class 2 devices with extra frame to
send; RT_Class 1 (RT) devices which are not
synchronized each other; all the rest of the IP based
communication (TCP, UDP). It should be noted
that, as a result, RT RT_Class 1 frames may suffer
of low but unpredictable delay as illustrated in [3].
• YELLOW phase: this is a transition phase used for
the same type of traffic of the GREEN phase.
During this period, only frames which can be
completely transferred within the end of the
YELLOW phase are transmitted.
A relevant portion of the cycle (in the GREEN phase)
is left for non real-time communication (NRT) such as
TCP or UDP. Such traffic has low priority tags and very
variable delays. Actually, IP traffic is used for big data
transfers, and the only important thing is the bandwidth.
TPN
TProfinetComm < 60% TPN
S RT Class 3 RT Class 2 Prio Prio 6 Prio Prio … Prio
y RED ORANGE 7 RT Class 2/1 6 5 0
n
c
(optional) (optional)
GREEN (mandatory)
Figure 1. PROFINET IO communication cycle.
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
In PROFINET IO, NRT phase occupies at least the 40%
of the total bandwidth.
RT_Class 3 (also called IRTtop) is the top
performance class. No delays can happen within this
RT_Class since the scheduling sequence in each cycle is
“a priori” known and always identical. The engineering
(network configuration) tool calculates the trip for every
frame of a cycle and downloads the schedule in the
network infrastructure (i.e. RT_Class 3 compliant
switches). As a consequence, RT_Class 3 has a rigid
network topology that must be decided during
configuration. Switches forward frames looking only at
the time schedule, no MAC address check is done. If a
frame is missing, a dummy one is transmitted with “bad”
status indication. If a frame can not be transmitted (e.g.
the destination port is busy), it is dropped. As a
consequence, the duration of the RED phase must be
greater than the longest propagation delay (from source
to destination) of any RT_Class 3 frames. It should be
noted that RT_Class 3 has an extremely low jitter since
any cause of uncertainty is avoided.
A synchronized RT_Class 2 communication is also
known as IRTflex. In fact, in this RT_Class the network
topology can be changed and no planning for each frame
is necessary. Switches forward frames using MAC
addresses, as usual. In the case of traffic burst, frames
can be buffered and delayed to the next GREEN phase.
RT_Class 2 exhibits a jitter higher than RT_Class 3.
As described above, PROFINET uses a TDMA (time
division multiplexed access) to allow for coexistence of
different types of protocols and classes. This means that
an extremely high level of synchronization must be
reached among IRT devices and network infrastructure.
Since the synchronization accuracy provided by IEEE
1588 PTP (Precision Time Protocol) is not enough for
RT_Class 3, PROFINET IO defines the PTCP (Precision
Transparent Clock Protocol) to share the reference time.
PTCP is quite similar to PTP; the main differences are a
reduced time sync_interval and the definition of a new
class of clocks. In fact, RT_Class 2 and 3 require
switches with embedded support to synchronization
(known as “transparent clock”) that add a fixed delay to
sync frames. Fortunately, many PROFINET IO
RT_Class 2 and 3 products, which are available since the
second half of 2006, embed such switch.
3. The prototype system
The prototype system is shown in Fig. 2. The two
YELLOW
RT_Class 3 devices (IO-Controller 1, IO-Device 1) have
(optional) been realized using two demo-boards that support
RT_Class 3. Moreover, two RT_Class 1 devices (IO-
Controller 2, IO-Device 2) have been added in order to
demonstrate down-compatibility of PROFINET IO
architecture.
1255
 IO-Controller 1
IO-Device 1
ERTEC
on PCI
(CP1616)
VxWorks
PC +
Linux RTAI OS
Development
tool
IO-Controller 2 IO-Device 2
(IM151-3)
(S7 317)
Figure 2. PROFINET IO prototype system.
3.1. Hardware
IO-Controller 1 (IOC1) and IO-Device 1 (IOD1) are
compliant with RT_Class 3. They are based on the same
ASIC, whose name is ERTEC400.
ERTEC400 provides: a four ports switch with
“transparent clock” functionalities; an ARM 946
processor; a direct memory access to the switch memory
which is used by the processor for fast reading of
incoming frames and for writing of outgoing frames. In
addition to the communication part, other standard
peripherals are available: two USARTs; one SPI; two
timers; up to 32 I/O signals (GPIO); one 16-bit local bus
interface; one 32-bit PCI interface at 66MHz.
There is also a a lower cost ERTEC version: the
ERTEC200. It has a two ports switch and no PCI
interface, making it suitable for IO-Devices only.
Both ASICs can be used to realize complete systems
since the embedded processor has enough computational
power to deal with the PROFINET stack and a medium-
complexity application program. ERTEC400/200 are
produced by Siemens and NEC and are available at the
time of writing. In reality, there are other ASICs that
could operate with RT_Class 3: netX from Hilscher and
hyNet from Hyperstone. They will be tested in the next
future, when their development systems become more
stable.
3.2. Development boards
There are two demo-board models for the ERTEC400
[5].
The first model is the EB400, designed for the
development of PROFINET IO field devices. Besides
the four Ethernet ports dedicated to PROFINET IO, the
board has a plenty of expansion connectors since all the
peripherals inside the ERTEC400 are accessible:
USARTs, SPI, I/Os. System architecture is completed by
32 Mbyte of SDRAM, 8 Mbyte of RAM, and 36.5
Mbyte of Flash ROM (512.Kbyte of boot Flash). In
order to debug the system, a dedicated connection is
available; a further 10/100 Ethernet port (SMC91C111
chip) can be connected to the development tools of a
remote PC for download and trace. On the software side,
a software stack can be purchased separately for the
implementation of an RT_Class 3 IO-Device with
EB400. The board supports any Operating System (OS)
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
that works with the ARM 9 family. The Siemens
(EB400)
reference demo has been done with VxWorks.
The second demo-board is the Siemens CP1616, a
OS PCI board to be inserted in a PC. CP1616 does not offer
any I/O expansion and it works only if plugged in a PCI
slot. Moreover, no debug interface is provided because
the firmware of this board is locked. With the CP1616
and a suitable software stack the implementation of an
IO-Controller is possible. In fact, CP1616 comes with
low level drivers and a Linux RTAI based application
example of a controller.
3.3. Software stack and applications
The approach to the realization of an RT_Class 3
network starting from demo boards is not so simple from
the software point of view.
The CP1616 and the EB400 have different software
stacks and a different OS even they are based on the
same ERTEC chip. Programmers need to deal with two
development environments.
At the IO-Controller side the CP1616 is almost like a
black box. The user can modify only the program at the
AL since the lower levels are given as object code.
Luckily, realization of custom applications is quite
simple since standard GNU compiler/debugger are
available under Linux. On the other hand, the reference
demo uses a pretty old Linux version (kernel 2.6.10)
with RTAI 3.2. It should be noted that authors
recommend (and use) Kernel 2.6.17 and RTAI 3.4.
At the IO-Device side the software stack is more open
and users can operate at any levels. Clearly,
modifications should be done only if they do not
interfere with RT_Class compliance. The board comes
with VxWorks OS and its development environment,
Tornado II.
The key aspects of the firmware reference
implementation of a PROFINET IO-Device are
illustrated in Fig. 3. The more important task of the
firmware is the manipulation of the I/O data transported
in the RED phase. In fact, the isochronisms goal is
reached only if new output data (coming from the IO-
Controller) are processed immediately and new input
data (destined to the IO-Controller) are prepared before
the end of the current cycle.
Cycle k
Other tasks
Callback Done
IO-Device
firmware
User routine for manipulation of
RT_Class 3 I/O data
Sync
PROFINET RED Phase GREEN Phase
cycle RT_Class 3 RT_Class 1
Cycle k RED phase Cycle k+1
Starts here ends here Starts here
Figure 3. EB400 firmware implementation.
1256
 The original firmware (version 2.0), given with the
EB400, fulfils such requirements by means of a callback
function linked to the interrupt of “End of RED phase”.
The user can write its own code to be executed during
the callback, provided that routine finishes before the
end of the GREEN phase. VxWorks is a multithread OS;
the user callback is one of the tasks that simultaneously
run in the system.
In the original firmware, actuation of the ERTEC
outputs and sampling of the ERTEC inputs must be done
in the callback routine writing or reading the
corresponding I/O register in the ERTEC memory space.
As a result, actuation/sampling time accuracy directly
depends on time delay and jitter of the callback
mechanism. As shown in the experimental section such a
solution is not the best one. Siemens plans to release a
new version of the firmware that exploits the possibility
of having a hardware signal linked to the PROFINET
sync frame. ERTEC can output such signal but it is
disabled in the current firmware version.
4. Experimental evaluation
The experimental evaluation of the prototype system
has been divided into two parts. First of all, performance
at PROFINET IO level has been measured. During these
experiments the attention has been focused on the
network level, with a detailed analysis of timing
behavior. Successively, the FW/AL interface has been
tested in order to estimate benefits that a PROFINET IO
system gives to end users.
The block diagram of the low level test bench is
shown in Fig. 4. The capture of network frames is done
by means of an Endace NinjaCapture network analyzer
[6] connected to the network segment by means of
Commercial Ethernet TAPs [7]. A TAP has two
transparent ports (A and B) that are used to connect the
network link under test. Traffic can flow in full duplex
from A to B without noticeable delay. A copy of the
traffic is available at the two monitor ports, each one
replicating frames of a single direction. The introduced
delay is less than 10 ns.
IP Traffic Endace
generator Ninjacapture
IO-Controller 1
B→A
ERTEC TAP
on PCI
A
1
(CP1616)
A TAP B
2 OS
PC +
Linux RTAI OS
IO-Controller 2
(S7317)
Figure 4. Network test bench.
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
Endace NinjaCapture 1500 is a rack computer with
Linux (Debian) operating system and a DAG 4.5G2
card. System architecture includes also a 2 TB disk
system and 2 GB of RAM. The DAG 4.5G2 card has
two full-rate 10/100/1000BaseT Ethernet ports, allowing
acquisition of Ethernet traffic over two independent
channels without dropping frames. DAG card has a
reference clock of 67.1MHz, that means a timestamp
resolution of about 14.9 ns. It should be noted that
internal time reference short term stability (two minutes)
shows a standard deviation of σ1s = 5 ns. Last, DAG card
can provide a 1-PPS reference for external devices and
can accept a 1-PPS reference from a more accurate time
reference (e.g. a GPS receiver).
The generation of TCP traffic has been achieved by
means of a software generator called IPERF. The user
can set many parameters like packet dimension and
transfer rate. All the tests with traffic have been done
using packets of variable dimension and the highest
generation rate (slightly higher than 70%).
4.1. Performance at PROFINET IO RT_Class 3
layer
The goal of this section is the evaluation of isochony
behavior of a PROFINET IO RT_Class 3 network. A
very good indication of this quality is the stability of the
communication cycle on the bus. In other words, it is
possible, looking at the Ethernet frames at the cable
level, to estimate timing characteristics.
The PROFINET cycle duration (TPN1) can be set by
means of the engineering tool. If only IOC1 and IOD1 are
active on the network just three frames can be seen in
any cycle: synchronization frame, data exchange frame
in the direction IOC1→IOD1 and a data exchange frame
in the opposite direction IOD1→IOC1. All frames are
transmitted in a short RED phase (30.4 µs), followed by
an empty GREEN phase that lasts till the cycle end.
In an isochronous system the cycle is supposed to be
always identical with the same frame scheduling. Hence,
the time period between two frames of the same type
must be identical. The period between sync frames
(TSYNC) and the period between data exchange frames
(TDXC1 and TDXD1) have been measured.
IP Traffic
generator In Table 1 are listed the results obtained for a traffic
free network composed of IOC1 and IOD1 only. The
B
TAP
experiments have been repeated for several TPN1 values
3 and average periods are reported together with standard
B→A
A→B
A
IO-Device 1 deviation and jitter (defined as the difference between
(EB400)
B maximum value and minimum value) computed over
VxWorks 10000 frames. Distribution of TSYNC is shown in Fig. 5.
for the case TPN1=1ms.
IO-Device 2
(IM151-3)
The average values of TSYNC, TDXC1, and TDXD1 are
PROFINET Port
always the same, demonstrating the locking capability of
Monitoring Port the synchronization algorithms implemented at
Pass-through Port
Hardware level in the ERTEC400. The standard
deviation and especially the jitter values indicate a very
stable cycle. It should be remembered that they are in the
1257
same order of magnitude of the Ninjabox resolution.The 500
jitter of IOD1 is greater than the IOC1 jitter. This
400
behavior is natural since IOC1 is the master clock and

Samples
IOD1 is a slave clock. 300

In the next experiments the same measures have been 200

repeated in different conditions. In particular, the
100
network link between IOC1 and IOD1 has been loaded
with RT_Class 1 traffic between IOC2 and IOD2 0
999,96 999,98 999,99 1000,01 1000,03 1000,04
(TPN2 = 4 ms), and TCP traffic sourced from generators.
T SYNC (µs)
Results are shown in Table 2. Performance of the
RT_Class 3 does not degrade, despite the high traffic Figure 5. Distribution of TSYNC in a traffic
level. In fact, the RED phase is still very short (30.4 µs) free network segment (TPN1=1ms).
and there is enough space in the GREEN phase to
accommodate TCP traffic and RT_Class 1. Moreover, 4.2. Performance at FW/AL interface
ERTEC capability of rearranging frames in their relevant The objective of this group of experiments is the
phase is clearly demonstrated. evaluation of the prototype system at the interface
between AL and Firmware. PROFINET IO RT_Class 3
communication has been proved to be really real-time
TPN1 Cycle Average Jitter Std. Dev. and isochronous, but the end user sees the system from
(ms) time (ns) (ns) (ns) the outside (at the input/output level). In fact, a user is
TSYNC 1 000 014 90 20 interested in having physical output signals with
1 TDXC1 1 000 014 90 20 predictable latency and low jitter to better serve his
TDXD1 1 000 014 135 18 control algorithms.
TSYNC 2 000 020 90 22 The reference figure for the following description is
2 TDXC1 2 000 020 90 22 Fig. 6. In order to produce an output signal that is related
TDXD1 2 000 020 135 25 to the PROFINET cycle, an ERTEC output pin is
TSYNC 3 000 044 90 21 commutated every time the callback routine associated
3 TDXC1 3 000 044 90 21 to the “End of RED phase” interrupt is called. A single
TDXD1 3 000 043 135 27 instruction (output inversion) has been added at the very
TSYNC 4 000 057 90 14 begin of the original callback routine. The situation is
4 TDXC1 4 000 057 90 13 illustrated in Fig. 6 in the temporal diagram called
TDXD1 4 000 057 135 28 “Original firmware”.
Due to OS overhead and to jitter of interrupt latency,
Table 1. Cycle time of PROFINET IO the begin of the callback routine does not have a constant
RT_Class 3 frames in a traffic free network delay with respect to the end of the RED phase. As a
segment. consequence, the duration of the cycle varies when it is
measured at the input/output level (intervals THo or TLo).
Experimental results with several TPN value are reported
TPN1 Average Jitter Std. Dev.
in Table 3 (in the rows labeled Original). The average is
(ms) (ns) (ns) (ns)
taken over 1000 samples. Distribution of THo is shown in
TSYNC 1 000 015 90 20
Fig. 7. Analyzing Table 3, it is clear that the original
1 TDXC1 1 000 015 90 21 firmware is not able to transfer at the AL the excellent
TDXD1 1 000 015 120 18 characteristics of the PROFINET IO communication.
TSYNC 2 000 029 90 22 The maximum jitter is greater than 100µs, more than
2 TDXC1 2 000 029 90 22 1000 times the jitter at Ethernet level.
TDXD1 2 000 029 135 24
TSYNC 3 000 042 90 21 4.3. Possible improvements at FW/AL interface
3 TDXC1 3 000 042 90 21 In this paper an improved version of the FW/AL is
TDXD1 3 000 042 135 27 proposed by the authors, in order to partially reduce jitter
TSYNC 4 000 057 90 14 at AL.
4 TDXC1 4 000 057 75 14 It should be remarked that the new proposed firmware
TDXD1 4 000 057 135 29 is not the best solution, since it is still a software
solution. The best performances will be given by a
Table 2. Cycle time of PROFINET IO firmware that uses the hardware support (synchronism
RT_Class 3 frames in presence of output pin) that comes with the future version of the
RT_Class 1 and TCP load (70%). EB400 drivers, as promised by Siemens.

1258
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
 Output
Tfd
signal Tfd Tfd Tfd
Tpoll

Improved THi TLi

firmware

t
Start of
Output callback
signal routine

Original THo TLo

firmware

t
RTC3

RTC3

RTC3

RTC3
SYNC

SYNC

SYNC

SYNC
PROFINET RTC1 RTC1 RTC1 RTC1
Cycle and TCP and TCP and TCP and TCP
Cycle k Cycle k+1 Cycle k+2 Cycle k+3 t

Figure 6. Temporal diagrams of output signals used to measure

the FW/AL interface performances.

Referring to temporal diagram called “Improved Table 4 summarizes the results obtained when the
firmware” in Fig. 6, the basic idea is the introduction of network segment is loaded with TCP and RT_Class 1
a fixed delay (Tfd) from the start of cycle before communication. Average value and standard deviation
commuting the output. In this manner, the duration of remain in the same order of the previous ones.
the cycle measured from the outside (intervals THi or TLi) In conclusion, the proposed improvements to the
will be constant. The practical realization of this idea EB400 firmware allow for a drastic reduction of jitter
requires a “protected” polling loop of the local time and standard deviation at FW/AL interface with respect
reference for a variable time (Tpoll). When the difference to the original firmware. Anyway, performance is
between the actual time and the start of the cycle (which significantly lower than possible because of lack of
is automatically saved by ERTEC in a register) is greater hardware support to output synchronization.
than the imposed Tfd, the output is inverted. Since
protection of the critical loop involves disabling of TPN1 Firmware Average Jitter Std. Dev.
interrupt and scheduling mechanisms, Tpoll must be kept (ms) version (ns) (ns) (ns)
as short as possible; in the current implementation Tpoll 1 Improved 999 971 2 960 501
must remain under 5 µs. If the Tpoll limit is broken, the 2 Improved 1 999 946 3 400 489
loop suddenly ends and the output is actuated 3 Improved 3 000 050 3 401 491
immediately. It should be noted that in the last case jitter 4 Improved 4 000 039 2 462 409
can be introduced.
New experimental results with several TPN1 value are
reported in Table 3 (in the rows labeled Improved). The Table 4. Cycle time of a signal actuated at
average is taken over 1000 samples in a traffic free FW/AL interface in presence of RT_Class 1
network. Distribution of THi is shown in Fig. 8. and TCP load (70%).

4.4. Event reaction time

TPN1 Firmware Average Jitter Std. Dev.
An important timing characteristic at AL is the
(ms) version (ns) (ns) (ns)
“Event Reaction Time” (TER), that is the time required by
Original 1 000 442 73820 12 300
1 the system to acknowledge an external event (e.g input
Improved 1 000 238 1 840 357
change) generating a suitable response action. This time
Original 2 003 880 110 721 19 310
2 is very important in practical applications and it
Improved 1 999 870 2 810 520
significantly depends on AL implementation.
Original 2 992 200 55 962 7 058 Considering the improved firmware, the experimental
3
Improved 2 999 908 3 241 517 setup for TER estimation is shown in Fig. 9. The IO-
Original 4 000 949 57 119 5 700 Controller IOC1 has been programmed at AL to execute
4
Improved 4 000 038 3 485 538 the following instruction DO=not(DI) where DO is a
remote output of IOC1 and DI is a remote input of IOC1.
Table 3. Cycle time of a signal actuated at
Then, DO and DI have been connected
FW/AL interface in a traffic free network.

1259
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
 60
40
50

30 40

S amples
30
20
Samples

20

10 10

0
999,5 999,9 1000,2 1000,6 1000,9 1001,3
0
959,0 973,0 987,1 1001,1 1015,1 1029,2 T Hi (µs)
T Ho (µs)

Figure 7. Distribution of THo with the Figure 8. Distribution of THi after the
original EB400 firmware (TPN1=1ms). proposed improvements (TPN1=1ms).
together (shorted). In this way, the loop has been created DO
IOC1 h … DI … … IOD1
and the DO value continuously commutates between
high and low state, since the feedback is positive. A DO=not(DI) … … D0 … h

square wave appears at DO; the time THDO it remains in Data Exchange DI

the high state and the time TLDO it remains in the low
state are both equivalent to TER (TER = THDO or TER = TLDO). Output
signal
In Table 5 are listed the result obtained (over 1000 at DO
TLDO
THDO
samples) at various TPN1 in a traffic free network. It can
be seen that TER = 2⋅TPN1 with a standard deviation in the t

same order of that is listed in Table 3.

Figure 9. Experimental estimation of TER.
TPN1 TER Ave. Jitter Std. Dev. on the same chip, use different software stack and
(ms) (ns) (ns) (ns) Operating Systems. Moreover the Firmare/Application
1.000 2 000 134 3 593 610 Level interface of the original firmware is poor and not
1.250 2 500 327 4 165 627 oriented to input/output operations. Some new firmware
1.500 3 000 008 3 583 618 improvements have been proposed in order to decrease
1.750 3 500 020 3 861 671 event reaction time jitter from tens of microseconds to
2 4 000 002 3 558 612 few microseconds. It should be noted that a Siemens
3 6 000 030 3 920 593 release of new firmware exploiting all ERTEC hardware
4 8 000 067 3 341 572 features, could outdate the proposed improvements.
Table 5. Event reaction time at AL after the
6. Acknoledgments
proposed improvements (TPN1=1ms).
Authors would like to thank Mr. B.B. Girelli for his
5. Conclusions help in experimental work.

PROFINET IO RT_Class 3 demonstrates a very good References

behavior, joining very high-performance real-time,
isochronous communications with (less-performing)
real-time data exchange (RT_Class 1) and TCP traffic
(40% minimum reserved bandwidth).
First experimental results show that development
boards based on ERTEC 400 allow for real time
isochronous communication with jitter well below the
traditional limit of 1µs. In particular, a maximum jitter of
135 ns has been measured in the test network, where
PROFINET IO RT_Class 1 nodes and TCP traffic (about
70% of bandwidth) were also present.
At the moment, development kits, although based
[1] G. Cena, L. Durante, A. Valenzano, “Standard Field bus
networks for industrial application”, Computers
Standards & Interfaces 17, 1995, Pages: 155-167
[2] M. Felser, “Real-time Ethernet - industry prospective”,
Proceedings of the IEEE, , Vol. 93, Issue 6, pp:1118 –
1129, June 2005
[3] 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
[4] M. Popp, K Webber, The rapid way to PROFINET,
PROFIBUS Nutzerorganization e.V., 2004.

1260
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.
[5] DK-ERTEC 400 PN IO, package including EB400 and
CP1616 boards, http://www.automation.siemens.com/pr
ofinet/html_76/produkte/development-kits_fuer_ertec.h
tm
[6] Endace Ninjabox Analyser <www.endace.com>.
[7] 96430 - 10/100BaseT Tap, Datasheet available online at
<www.netoptics.com>

1261
Authorized licensed use limited to: SIMON FRASER UNIVERSITY. Downloaded on August 08,2023 at 22:44:52 UTC from IEEE Xplore. Restrictions apply.