A new Approach for Increasing the Performance of the Industrial Ethernet

System PROFINET

Markus Schumacher, Juergen Jasperneite Karl Weber

inIT - Institute Industrial IT
OWL University of Applied Sciences Siemens AG
D-32657 Lemgo D-91056 Erlangen
{markus.schumacher, juergen.jasperneite}@fh-luh.de karl.weber@siemens.com

Abstract A performance analysis of these both systems is given

In todays realtime Ethernet systems two approaches
can be differentiated regarding the organisation of the
frame transmission: On the one hand there is a summa-
tion frame approach in which one frame can supply sev-
eral nodes with data at the same time. On the other hand,
there is the approach of providing data with individual
frames for each node. The two most relevant factors influ-
encing the performance in terms of the minimum achiev-
able update time are the propagation delay and the frame
transfer time. In this paper we introduce a new concept
for reducing the minimum possible update time for indi-
vidual frame based systems like PROFINET IRT. The per-
formance evaluation compares the results of our concept
with the summation frame based EtherCAT System.
1. Introduction
in [10]. The named paper comes to the conclusion that
there are two most relevant factors influencing the perfor-
mance, based on the minimum achievable update time. As
shown in Figure 2 these factors are the propagation delay
and the frame transfer time. At the field level of indus-
trial automation systems, the line topology is very impor-
tant [11]. Unlike office communication systems wiring
installations in the industrial enviroment must follow me-
chanical conditions and cabling channels of machines and
plants. This often leads to line topologies with only a few
trunks. When using Ethernet, an industrial control system
may have tens or even up to hundreds of cascaded active
nodes or switches. The analysis [10] concludes that in a
scenario for simple sensor/actor networks with a pure line
topology and 100Mbit/s, PROFINET shows a better per-
formance compared to EtherCAT when there are larger
framesizes per node. Thus, there is a potential for opti-
mization regarding smaller frames, which can usually be
found in simple sensors/actors.

The future of industrial communication is evolving to-

wards industrial Ethernet networks. A brief introduction
to industrial Ethernet networks and the standardization
process can be found in [1, 2, 3].
Industrial Ethernet protocols may be classified in three
main categories (Figure 1). As the protocols update time
decreases from category 1 to category 3 additional func-
tionality at the data link layer simultaneously becomes
necessary.
In order to further decrease update times in the range
below milliseconds, an intervention in the scheduling pro-
cedure of the original Ethernet MAC layer is necessary.
Systems of the category 3 are Ethernet Powerlink [4],
EtherCAT [5, 6, 7] and PROFINET IRT [8, 9]. With ref-
erence to the organisation of the frame transmission, this
category can be differentiated in two concepts namely a)
summation frame approach in which one frame can sup-
ply several nodes with data at the same time, b) the ap-
proach of providing data with individual frames for each
node. PROFINET IRT is a good example for this indi- Figure 1. Classification of industrial Ether-
vidual frame approach, while EtherCAT is a prominent net protocols
candidate for the summation frame approach.

978-1-4244-2350-7/08/$25.00 2008 IEEE.


Figure 2. Propagation delay and frame
transfer time are determining the perfor-
mance of realtime Ethernet
This paper introduces a new approach to the optimiza-
tion of the PROFINET performance regarding the propa-
gation delay and the frame transfer time.
After a brief introduction to the used protocols in chap-
ter 2, chapter 3 presents our concepts for optimizing
the performance of PROFINET. In section 4 the perfor-
mance enhancements based on the optimization are dis-
cussed. Thereafter the standard PROFINET and the en-
hanced PROFINET version, let it call IRT+, are bench-
marked to the summation-frame-based EtherCAT and thus
evaluated. The conclusion is presented in chapter 5.
2 Brief Introduction to the used Protocols
This chapter gives a brief introduction to EtherCAT and
PROFINET taking the used frame structure into consider-
ation.
2.1 Standard Ethernet Frame
Obviously, all Industrial Ethernet Protocols are using a
native Ethernet Frame as a carrier, shown in figure 3 [12].
It starts with a 7 bytes long preamble and an 1 byte long
Start-of-Frame Delimiter (SFD). These 8 bytes are used
to synchronise the physical layer (PHY) of the receiver.
The following 12 bytes are the destination and the source
addresses. The next 2 bytes are reserved for the Ethertype
which marks the encapsulated higher layer protocol (e.g.
IPv4: 0x0800, EtherCAT: 0x88A4, PROFINET: 0x8892).
Hereafter the payload of the frame follows. The frame
ends with a 4 bytes-long Frame Check Sequence (FCS) to
8 6 6 2 46-1500
Preamble/SFD Source address Payload
Target address Ethertype FCS-Status
Figure 3. Structure of a native Ethernet
frame
2
Telegram 1 Telegram 2 Telegram n
10 x 2
Ethernet-Overhead Telegramheader Working Counter
EthCAT-Header Payload
Figure 4. Structure of an EtherCAT frame
check the integrity of the received data.
2.2 Frame Structure of EtherCAT
EtherCAT uses a standard Ethernet frame with an
Ethertype of 0x88A4. The EtherCAT-specific data is em-
bedded in the payload of the Ethernet Frame. As shown
in Figure 4, the EtherCAT-specific information starts with
the EtherCAT-header which is 2 bytes long. The device
user data is exchanged by so-called EtherCAT telegrams.
These are starting with a 10 bytes telegram header and
close with a working counter, which requires another 2
bytes. The working counter is automatically incremented
by all devices, that process the associated telegram. It pro-
vides an effective diagnostic tool. In order to reduce the
overhead of EtherCAT, it is possible, that all telegrams
share solely one telegram header and working counter.
The main advantage of EtherCAT is based on the possi-
bility to pack the individual data of several devices into
one single summation frame. The potential of merging
EtherCAT telegrams in one single frame reduces the over-
head of EtherCAT. The output data to the device sent by
the controller will be replaced by the input data of the de-
vice on the fly. Because of this method, the reserved space
in the telegram has to be determined by the controller or
the device data, depending on their size. In the case of the
amount of controller data exceeding the amount of device
data, the controller determines the telegram size and vice
versa.
2.3 Structure of a PROFINET Frame
The basic structure of a PROFINET frame is similar
to an EtherCAT frame (cf. Figure 5). The PROFINET-
specific overhead is also embedded in the payload of
2
x y y 211
APDU-Status
4
Ethernet-Overhead Payload Cycle Counter
Frame-ID IOPS Data-Status
PROFINET-data IOCS Transfer-Status
Figure 5. Structure of a PROFINET frame
a standard Ethernet frame and starts after the ethertype
0x8892 with a 2 byte Frame-ID, which defines the type of
PROFINET IO messages. Afterwards the payload of the
PROFINET device follows. The payload will be finalized
by one byte IOPS (IO-Data Object Producer Status) and
one byte IOCS (IO-Data Object Consumer Status) for ev-
ery submodule in the device. The IOCS and IOPS show
the validity of the cyclic data transfer. A PROFINET
telegram is completed by the APDU-status (Application
Layer Protocol Data Units). The APDU status comprises
a 2 byte cycle counter to control the timeliness of a frame
in a redundant wired system and an 1 byte data-status,
which shows whether the data is valid. The APDU-Status
is completed by an 1 byte Transfer-Status.

3 Concept for PROFINET Optimization

This chapter presents a concept to increase the per-
formance of PROFINET. It considers different ways to
decrease the propagation delay and the frame transfer
time. The propagation delay consists of the medium delay
(which cannot be affected significantly) and the forward-
ing delay of the involved nodes along the path from the
source node to the destination node. The optimization of
frame transfer time is based on the advantages of the indi- Figure 6. Tree topology
vidual and summation frame transfers.

3.1 Optimization of Forwarding Delays
In this subchapter various ways to decrease the for-
warding delay of PROFINET devices are described. On
an abstract level a PROFINET device can be considered
as a bridging device. The minimum forwarding delay of
a bridge consists of three components: a) the delay of the
physical layer (PHY), b) the minimum amount of data to
be received in order to determine the correct destination
and c) the logic delay for a correct forwarding of the in-
coming frame to the corresponding outgoing port. Thus
we focus on concepts to minimize the time needed for the
forwarding process.
3.1.1 Topology based Forwarding by using locally
administered MAC-Addresses
Regarding the forwarding delay one important building
block of a MAC-bridge is the Address lookup. Matured
searching algorithms are used, so that there is no signifi-
cant potential for the optimization of the logic delay. To
reduce the delay spent for the Address lookup, we pro-
pose a topology based algorithm. More complex networks
which are using multi-port bridges have to be supported
and require a solution not limited to line topologies. Fig-
ure 6 shows an example of a tree topology with a maxi-
mum depth of three levels. Every device is marked by a
number starting at the first device of a level with an ad-
dress equal to one. The basic idea of our address calcula-
tion algorithm is based on the concept that every level gets
an explicit byte and the next device in line shall receive the
value of the previous device incremented by one.
In the next step it is important to implement the respec-
tive hierarchy level of the topology. Figure 7 introduces
the different kinds of ports and the relation between the
address number and the level of a device. There are three
different port types. The primary port is connected to the
preceding neighbour on the same level n in the line. If it
is the first device of a line, it realizes the connection to the
higher level n 1, e.g. level 2 to level 1. The secondary
port is connected to the successor in this line. The next
lower level n + 1 can be reached via the branch port, e.g.
from level 1 to level 2. In the example shown in Figure 6,
the number of branches is limited to one port. However,
by using a coding shown later, it is also possible to use
more than one branch. Using the rules, it is now possible
to address an Ethernet device by using its position within
the hierarchy of a certain topology. Consequently, every
device will obtain a unique MAC address.
For example, a device with 1:2:2 can be reached from
the controller 0:0:0, by using the branch port of device 1
at level 1, the branch port of device 2 at level 2 and at level
Figure 7. Device address description
3 the device is addressed at position 2. In this case three
bytes are used to address the device, therefore it resides at
level 3.
The proposed hierarchical address scheme can be im-
plemented by using local MAC addresses [13]. Hence, it
is possible to address up to six levels (one level requires at
least one byte). Figure 8 shows an example of coding a six
byte local MAC address. The least significant bit (LSB) of
the first byte denotes the address type of the frame, if set
to one the frame is a multicast frame, if not it is a unicast
frame. The second bit defines the administry of the frame,
one indicates the frame is locally administered and zero
means globally administered. Because of these two bits,
the byte structure of the MAC-Address is not complete
free selectable and it is unfavourable to use the first byte
to describe a position for the introduced forwarding mech-
anism. Therefore and for future extensions the first byte is
reserved and can be used to implement status information.
The hierarchical address technique, which comprises the
position of a device and the respective level within the tree
topology, starts at byte two.
It can be seen in Figure 8 that every byte which de-
scribes the position does not only consist of the position in Figure 9. Tree topology with defined coding
the line. It also contains the branch for finding the correct
level by using bit six and seven. Exploiting two bits for
the branch decision, the addressing of up to three differ- and third byte contains the destination of the frame. The
ent branch ports is possible for building complex network destination device will be reached from level 1 via branch
structures. The destination level can always be identified 3 (branchcode 11) at position 2. On the next level the
by the vector 00 and defines also the last relevant address bitstream reaches the final destination at position 1, be-
byte. cause the branch code is 00. Therefore the analysed data
Figure 9 shows a tree topology with a depth of three is directly linked to the level of the bitstream. A device at
levels and uses the introduced address coding. As shown, level 1 has to analyse only one relevant byte to make a de-
bit 0 up to bit 5 contain the position within a level where cision about the correct outgoing port. A device at level 2
the branch information is evaluated. Bit 6 and 7 contain has to analyse two address bytes, a device at level 3 needs
information about the branch to be used or, in case of two to analyse three bytes, etc.
zeros, if the frame has reached the destination level. An
example MAC address, based on the introduced coding, 3.1.2 Decreasing the Forwarding Delay by a Short-
is shown in Figure 10. The bitstream is based on the ened Preamble
topology of Figure 9 and shall be forwarded to the de-
vice at destination C2:1:X. The first byte (status) marks Another approach to decrease the forwarding delay is to
the incoming MAC address to be locally administered, so shorten the preamble size. Because Realtime Ethernet
it shall use the introduced forwarding strategy. The second Standards like PROFINET requires a full-duplex connec-
tion (FDX) the purpose of a preamble is obsolete. This
has been disproved by means of some experiments with
commercial off the shelf (COTS) network interface cards
(NIC) from different vendors (Belkin and Marvel). The
NICs were not able to detect an incoming bitstream with-
out a preamble, indicating a principal necessity of the

Figure 10. Description of MAC address to

device C2:1:X
Figure 8. Local MAC address
preamble. However, sending a full length preamble is not
required. The preamble was shorten to 1 byte plus 1 byte
start of frame delimiter (SFD). With this modification ev-
ery frame was accepted by the commercial NICs. It can be
concluded that the preamble shall not be cut completely.
In case of minimizing the preamble to 2 bytes (incl. SFD),
the forwarding delay gains a benefit of 6 bytes.
To prevent a malfunction caused by the shortened
preamble, it is reasonable that every device negotiates the
minimum preamble length with its corresponding neigh-
bours by using a appropriate protocol, e.g. Link Layer Di-
covery Protocol (LLDP). The performance improvement
by using a shortened preamble is approximately six bytes
and saves 480ns (calculated for a Fast Ethernet network).
3.1.3 Expected Performance Benefit
This Subchapter analyses the gain of performance by us-
ing the introduced forwarding optimizations. Figure 11
shows an overview of the minimal forwarding time as
a function of the hierarchical level (with Fast Ethernet).
We assume a preamble length of 1 Byte plus 1 Byte for
the SFD. On the one hand the first graph with a delay of
1120ns represents the standard forwarding delay and the
other graphs of the diagram represents the optimized strat-
egy as a function of the hierarchical level 1 to 5. The best
result is given at level one with a delay of only 320ns.
Every additional level generates an additional overhead
of 1 byte which is equal to 80ns in a 100 Mbit/s net-
work. The upper limit of level is given by the length of the
MAC-Address itself. So, the maximum delay of 640ns is
reached at level 5.
3.2 Optimization of the Frame Transfer Time
This subchapter points out ways to decrease Frame
transfer time. The main challenge targets to minimize
the amount of overhead. For PROFINET with its individ-
ual frame approach, the minimum Frame size is 64 bytes.
If the cyclic data amount of a device is smaller than 46
bytes the difference to the minimum size has to be filled
up. These padding bytes are using bandwidth without any
value. Therefore a solution should be found to reduce the
ns
Figure 11. Forwarding performance gain by
using local MAC address coding and short-
ened preamble
padding overhead. As a result of this, the idea to pack the
cyclic data of small devices into one large frame was orig-
inated. We have to differentiate between the downstream
communication, which includes all communication rela-
tionships of the controller down to the devices, and the
upstream direction, which includes all the traffic from the
devices to the controller.
3.2.1 Downstream Communication
Our pack mechanism is based on the concept, that the con-
troller sends one larger frame with the cyclic data of ev-
ery participating device through a line topology. After the
first device has received the frame it will extract the data
of its respective datagram which contains the cyclic data.
To realize a unique datagram assignment and for diagnos-
tics, a datagram should contain a Datagram Header and a
own Datagram Check Sequence (FCS). The header con-
tains 1 byte to map the datagram to the specific device
and 1 byte to define the length of the datagram. By this
way, the boundaries of every datagram are well defined.
Furthermore the integrity of a datagram is constituted by
checking the datagram FCS. The slipstream-effect which
is introduced in [10] (first datagram contains the payload
of the last device in a line) could also be mapped to the
structure of the packing frame. Figure 12 shows an exam-
ple by using three devices.
Every device got a dedicated datagram by using the in-
troduced pack mechanism. Hence, it makes sense that a
participating device cuts its respective datagram out of the
total frame and thereby reduces the length of the frame.
Because of the special slipstream effect, a participating
Figure 12. Advanced packing optimization
and frame cutting (tdatagram > tperiph )
 the following formula:
|tperiph tf rame |
tan = ndevices
(1)

3.2.2 Upstream Communication

The upstream communication and the basic ideas for re-
ducing the frame transfer time are shown in Figure 14.
We assume that all devices start their frame transmission
at the same time (e.g. caused by a syncronization event).
After the successful transmission of the Datagram-FCS of
the respective devices, the first byte of the datagram of
the successor has to be received. The incoming frame is
directly passed after sending the own Datagram-FCS. By
using this pack mechanism the upstream frame grows af-
ter crossing a participating device. This could be easily
described like a train which links (on the fly) new wagons
as it passes through the various stations.
Figure 13. Advanced packing optimization
As shown in Figure 15 there might be a situation,
and frame cutting (tdatagram < tperiph )
where the frame of the previous device does not arrive
on time. This gives rise to a special situation between two
participating devices where the ratio of the payload is dis-
proportionally small in comparison to the medium delay.
device always cuts the last datagram of a packed frame, As a result of this delay, a gap appears between datagram
but by reducing the frame size the FCS becomes invalid. I and datagram II. To prevent this gap a sending offset
As a result of the frame manipulation the datagram FCS tof f set is introduced. This offset generates a delay which
has to take over the responsibility to check the integrity compensates the gap (Figure 15).
of the frame. Therefore the Datagram Check Sequence
has to start the calculation at the first byte of a frame (first 4 Performance Evaluation
byte of destination address). To prevent problems with
devices which dont support a Datagram FCS, it is still This chapter evaluates the minimum possible update
necessary to calculate a correct Frame FCS and place it time of PROFINET IRT, PROFINET IRT with our intro-
after the last Datagram FCS in case of cutting. Hence,
devices which dont support the cut feature receives a cor-
rect FrameFCS. The cut-functionality shall be considered
as an optional add-on. Further the minimal frame size (64
bytes) requirement is vital and hence if the payload in case
of cutting becomes too small the payload has to be filled
up to 46 bytes. By using this mechanism data which is
not necessary for the following devices will be cut and the
utilization of the available bitrate would be increased.
The sign of indicates the bottleneck of the minimum
possible update time. In case of Figure 12 and Figure 13
the bottleneck is defined by two time components: a) the
transmission time of a datagram tdatagram . It consists of
the sum of dDatagramHeader (2 byte), dDatagramP ayload
(n bytes) and dDatagramF cs (2byte) divided by bitrate b.
b) the delay tperiph which doesnt depends on the bitrate.
tperiph consists of the medium delay tmedium and the for-
warding delay tf wd . The forwarding delay comprises of
switch forwarding logic tlogic and PHY-delay tphy . To
sum it up the sign of depends on the ratio between
tperiph and tdatagram . If tdatagram is larger than tperiph
then the sign is positive, otherwise its negative. E.g. if
> 0 it is possible to decrease the update time by in-
creasing the bitrate b. The angle could be calculated by Figure 14. Inbound packing

Figure 15. Prevent gaps - Inbound packing
duced modifications benchmarked to EtherCAT using a)
payload per device and b) number of involved devices.
4.1 Update-Time Calculation
This subchapter introduces the update time calculation
of our enhanced PROFINET and EtherCAT by using line
topology.
4.1.1 Calculation of the PROFINET Update Time
The conclusion of [10] shows, that the possible bottle-
neck of a system could be defined by propagation delay
(tpropag ) and on the other hand by the frame transfer time
delay. The forwarding delay of tpropag is defined by the
following formula:
tpropag = tmedium + tP HY + tlogic + tf orward data
(2)
The calculations are based on the following assump-
tions: The length of copper-based segment between two
devices is set to 5 meters, which leads to a medium delay
of tmedium = 22, 7ns. The PHY delay based on a mea-
surement of a Broadcom PHY BCM5461S [14] is set to
320ns. The typical value of a cut-through Fast Ethernet
Switch (100 Mbit/s) [15] is about 3 s. To calculate the
logic delay the measured time is subtracted from the min-
imum forwarding delay of PROFINET (1120ns (Figure
11)) and the measured PHY delay 320ns. This results in
a delay of tlogic = 1560ns.
Based on the introduced optimizations tlogic and
tf orward data are minimized in comparison to standard
PROFINET. The logic delay tlogic is set to 160ns which
is verified by our FPGA-based Prototype using the opti-
mized PROFINET version. The minimum amount of data
for forwarding a frame is defined by tf orward data . The
medium delay and the PHY delay are not affected by the
enhancements and are equal to standard PROFINET.
Based on these assumptions the delay tpropag is set to
3227ns in case of standard PROFINET and to 987ns in
case of our enhanced concept.
The frame transfer time tf rame irt of standard
PROFINET consists of the transmitted data divided by
the given bitrate b and is calculated using the following
formula:
ndevices (dpayload +dethernet ov +dpn ov )
tf rame irt = b
(3)
The number of devices is represented by ndevices , the
net payload per device is defined by dpayload , the
overhead caused by Ethernet dethernet ov = 38bytes
(Destination-/Source-address, Ethertype, Frame Check
Sequence (FCS), Preamble and Inter Frame Gap (IFG))
and the PROFINET overhead dpn ov is set to 8 bytes
(FrameID, IOxS, APDU). Given by the Ethernet speci-
fication the minimum sum is set to 84 bytes (minimum
sized Frame + Preamble/SFD + IFG).
A difference between the calculation of the frame
transfer time of the standard and the enhanced PROFINET
version is given by the datagram overhead ddatag ov ,
which generates an additional overhead of 4 bytes (2 byte
datagram header and 2 byte datagram FCS). This add-on
is included in the following formula:
ndevices (dpayload +ddatag ov )
tf rame irt+ = b +
(4)
(dethernet ov +dpn ov )
b
A frame overflow, i.e. payload plus overhead exceeds
max. framesize, is not common by using simple sen-
sor/actor networks. Thus, the presented calculation targets
on scenarios with a payload equal to a standard Ethernet
frame.
 Under these conditions the minimum update time of 2,5

the enhanced and the standard PROFINET is calculated IRT+/ECAT

IRT/ECAT
using the following formula: 2

tf rame
tpn = max(ndevices tpropag + ndevices , (5)
tpropag + tf rame ) 1,5

The frame transfer time tf rame depends on the 1

PROFINET version. If the calculation based on the
standard version tf rame consists of tf rame irt and in
0,5
case of the enhanced PROFINET tf rame consists of
tf rame irt+ .
0
0 10 20 30 40 50
4.1.2 Calculation of the EtherCAT Update Time
The minimum update time of EtherCAT is calculated by
the following formula introduced in [10]: Figure 17. Update time as a function of the
payload with a bitrate of 100 MBit/s, 25 de-
tecat = ndevices (tecat + tmedium ) + tf rame (6)
f wd
vices in a line topology and an asymmet-
ric ratio of 25 % between the up and down-
The forwarding delay tecat f wd of an EtherCAT de- stream)
vice is mainly determined by the PHYs (forward and re-
verse channel). Additionally, the delay of the forward-
ing logic of the downstream and upstream channels are
payload per device for 25 devices in a pure line topology
assumed. The sum of the delays constitute the forward-
and a bitrate of 100 MBit/s. In comparison to Ether-
ing delay of EtherCAT, which is assumed to be 1.35 s.
CAT, PROFINET IRT has a perceptible performance lack
The medium delay tmedium between two nodes consists
in terms of payload size up to 38 bytes. The reason for
of 45, 4ns which represents the delay of two times (to and
this is because of the minimum Ethernet frame size of 64
from the controller to the devices) 5 meters . The delay
bytes. If we subtract the overhead of native Ethernet and
tf rame is a function of the bitrate b. It consists of an asym-
PROFINET the minimum payload per device is 38 bytes.
metric payload data distribution of 25% for input and out-
If the device payload doesnt exceed 38 bytes the pay-
put data and the overhead caused by native Ethernet and
load would be filled up by padding bytes. After the pay-
EtherCAT divided by the bitrate [10]. Figure 16 shows an
load exceeds 38 bytes the additional overhead is compen-
example of the payload of a summation frame considering
the asymmetric ratio. For system diagnostic a group of ten
devices shares one telegramm. Hence, an occuring prob-
lem could be match to a group and it shall be more easily 2,5

to isolate the cause of the problem. The calculation based

on dedicated EtherCAT nodes without special backplane 2
arrangements.
1,5
4.2 Results IRT+/ECAT
This subchapter shows the results of the calculations of IRT/ECAT
1
Chapter 4.1 for two different scenarios. The first scenario
in figure 17 shows the update time as a function of the
0,5

0
0 10 20 30 40 50

Figure 18. Performance comparison in

Figure 16. Example of a summation frame
considering the asymmetric ratio
terms of the number of devices using a bi-
trate of 100 MBit/s, a payload of 8 byte per
device, a line topology and an asymmetric
ratio of 25 % between the up and down-
stream
sated and standard PROFINET approximates to the per-
formance of EtherCAT. Our introduced concept, let it call
IRT+, solves the problem by packing the data of every de-
vice into one packed frame. In reference to our proposal,
PROFINET invert the lack into a performance advantage
of up to 130% in comparison to EtherCAT.
The scenario shown in Figure 18 investigates the mini-
mum possible update times of the systems by varying the
number of devices with a fixed payload (8 bytes), orga-
nized in a line topology. After a transient phase the ratio
between tecat and tpn approximates to a fixed value. This
scenario shows that the standard PROFINET reaches up to
35% of the EtherCATs performance, while the optimized
version of PROFINET gains a performance advantage of
up to 130% in comparison to EtherCAT.
5 Conclusion
Currently over 22 realtime Ethernet systems are estab-
lished. Regarding their performance they can be classified
in 3 main categories. Our work focuses on systems which
offer update times in the range below milliseconds. In
regard to the organisation of the frame transmission, two
concepts can be identified in this category: EtherCAT is a
prominent candidate of the summation frame approach,
while PROFINET IRT is an example of the individual
frame approach. A performance analysis of these systems
[10] shows an optimization potential for PROFINET com-
pared to EtherCAT in simple/actor networks with a pure
line topology and 100Mbit/s.
This paper introduces a new approach, to improve the
potential of PROFINET. In order to reduce the propa-
gation delay, a topology based forwarding algorithm us-
ing local MAC addresses is introduced. Additionally the
preamble length is shortened to the minimum size of two
bytes. Subsequently, we propose an intelligent frame
packing mechanism to reduce the frame transfer time as
the second important parameter determinating the achiev-
able performance.
Our analysis shows, that the enhanced PROFINET ver-
sion changes the lack of performance in comparison to
EtherCAT observed in [10] into a performance benefit.
As a result of our improvement, in comparison to Ether-
CAT PROFINET experiences a gain in performance up to
130%.
Acknowledgements
This work is funded by the German Federal Ministry of
Education and Research (BMBF) in the project ESANA
with the grant ID 1742X06.
References
[1] J.-D. Decotignie, Ethernet Based Real-Time and Indus-
trial Communications, Proceedings of the IEEE, vol. 93
issue 6, pp. 110217, 2005.
[2] M. Felser and T. Sauter, Standardization of Industrial
Ethernet the Next Battlefield?, in 5th IEEE Inter-
national Workshop on Factory Communication Systems
(WFCS2004), Sept. 2004, Vienna.
[3] M. Felser, Real-Time Ethernet - Industry Prospective,
Proceedings of the IEEE, vol. 93 issue 6, pp. 1118ff, 2005.
[4] E. Powerlink, Ethernet Powerlink Standardization Group,
www.ethernet-powerlink.org, 2007.
[5] EtherCAT, Ethernet Technology Group (ETG), www.
ethercat.org, 2007.
[6] IEC, IEC 61158-3-12, Digital data communications for
measurement and control- Fieldbus for use in industrial
control systems - Part 3-12: Data Link Layer service defi-
nition - Type 12 elements, 2006.
[7] IEC, IEC 61158-4-12, Digital data communications for
measurement and control- Fieldbus for use in industrial
control systems - Part 4-12: Data Link Layer protocol
specification - Type 12 elements , 2006.
[8] IEC, IEC 61158-5-10, Digital data communications for
measurement and control- Fieldbus for use in industrial
control systems - Part 5-10: ApplicationLayer service def-
inition - Type 10 elements, 2006.
[9] IEC, IEC 61158-6-10, Digital data communications for
measurement and control- Fieldbus for use in industrial
control systems - Part 6-10: ApplicationLayer protocol
specification - Type 10 elements, 2006.
[10] J. Jasperneite, M. Schumacher, and K. Weber, Limits of
Increasing the Performance of Industrial Ethernet Proto-
cols, in 12th IEEE Conference on Emerging Technologies
and Factory Automation, Sep 2007, pp. 17 27, Patras,
Greece.
[11] S. Ruping, E. Vonnahme, and J. Jasperneite, Analysis
of Switched Ethernet Networks with different Topologies
used inAutomation Systems, in D. Diedrich, P. Neu-
mann, and H. Schweinzer, editors, Field Bus Technology,
pp. 351358. Springer-Verlag, 1999.
[12] IEEE, Carrier sense multiple access with collision detec-
tion (CSMA/CD) accessmethod and physical layer speci-
fications, IEEE, New York, 2000, ANSI/IEEE Std 802.3-
2000 Edition (ISO/IEC 8802-3:2000(E)).
[13] ISO/IEC 15802, ISO/IEC 15802-1 - Information technol-
ogy Telecommunications and information exchange be-
tween systems Local and metropolitan area networks
Common specifications Part 1: Medium Access Control
(MAC) service definition.
[14] Broadcom, 5461S-PB06-R, www.broadcom.com/
collateral/pb/5461S-PB06-R.pdf.
[15] J. Jasperneite and S. Gamper, Echtzeit-Betrieb im Eth-
ernet - Industrial Ethernet Switches auf dem Prufstand-
Teil1/eng. Measurement and benchmarking on industrial
Ethernet Switches, Elektronik, vol. 7, pp. 5092, Apr
2007.