_____________________________________

PROFINET Basics

PROFINET Basics

Chapter 3

_____________________________________
V1.0
3 - 1
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 2
_____________________________________
PROFINET Basics

Real-Time Capability
In general, Ethernet is not real-time capable
The CSMA/CD procedure is the reason for this.
Carrier Sense Multiple Access / Collision Detection
Switched Ethernet enables real-time capability
Full Duplex (FD)
CSMA/CD procedure disabled
PNO recommends managed switches
Prioritization of PROFINET data
Topology detection
PROFINET prohibits the use of hubs!

In the past Ethernet was hardly established in the field but fully established in the office world due to
its missing real-time capability. In the office world, Ethernet was well-established. However in the
field, mostly a great variation of fieldbus systems was used. For a long time, Ethernet could not
conquer the field level.

The standard Ethernet is based on the CSMA/CD procedure that can lead to collisions on the
Ethernet cables. These collisions in turn lead to delays for the transmission of individual data
packets which make it impossible to guarantee real-time.

The introduction of Switched Ethernet radically changed this situation: the full duplex operating
mode that is implemented as a standard nowadays, disables the CSMA/CD procedure. Since hubs
operate using the CSMA/CD procedure, it is prohibited to apply them within PROFINET networks.

The PNO (PROFINET User Organization) recommends the use of managed switches within
PROFINET networks since managed switches provide further useful functions in the PROFINET
context alongside the prioritization of PROFINET data packets and the topology detection in
Ethernet-based networks.

_____________________________________
IT200803_0003/1
3 - 3
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 4
_____________________________________
PROFINET Basics

PROFINET Variants

_____________________________________
3 - 5
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 6
_____________________________________
PROFINET Basics

Profinet Variants

PROFINET

PROFINET IO PROFINET CBA

Decentral Periphery Distributed Automation

Different available user profiles for PROFINET enable the user to select exactly the functionality
needed for his application.
PROFINET discerns between the PROFINET IO and the PROFINET CBA user profile.

PROFINET IO
PROFINET IO describes a system to connect the decentral periphery. It is suitable for cyclic data
exchange between controls and field devices with bus cycle times of only a few milliseconds. This
system is comparable with the common fieldbus technology where a master exchanges IO data
with several different slaves. The main difference lies in the fact that PROFINET IO is based on
Ethernet and not on conventional bus technology.
PROFINET IO also includes the PROFINET IRT variant. This variant can realize clock-synchronous
data transmission as needed for drive control.

PROFINET CBA (Component Based Automation)

The PROFINET CBA concept stands for a function-oriented view on an automation system, the
automation system being subdivided into individual modules. Through the corresponding
descriptions of these modules, the so-called PCD files (PROFINET Component Description), the
user receives another abstraction level on which he can view the individual modules. Through
graphic connection of individual modules within a corresponding configuration software the
communication paths within a system are defined. The ever shorter product life cycles require such
a modular system topology. Thus this PROFINET variant is especially suitable for modular system
concepts.

_____________________________________
IT200803_0007/1
3 - 7
_____________________________________
PROFINET Basics

PROFINET IO: Vertical Communication

To distinguish the PROFINET IO user profile from the PROFINET CBA user profile, it is sufficient to
have a look at the respective form of communication. Here, PROFINET IO is mainly characterized
by vertical communication within the network.

The term of vertical communication comprises the communication between the control and the
individual IO modules. The control is on a higher level than the individual IO modules. This structure
leads to the term of vertical communication as visualized by the red arrows.

_____________________________________
IT200803_0008/1
3 - 8
_____________________________________
PROFINET Basics

PROFINET CBA: Horizontal Communication

Compared to vertical communication via PROFINET IO, PROFINET CBA offers horizontal
communication because of its modular structure. Here, individual controllers communicate with
each other. Since the controllers are on the same level within the network, we speak of horizontal
communication here.

The basic idea of PROFINET CBA is to pool logic units (modules) to form an entire system. These
modules themselves are already completely automated and thus operate independently. Via
defined interfaces they are able to communicate with the other modules.

_____________________________________
IT200803_0009/1
3 - 9
_____________________________________
PROFINET Basics

Modular Machine Concept

In order to visualize the PROFINET CBA concept we chose the example of a bottling system.
Several different working steps along the production line are summarized here to individual logic
units.

Machine 1 cleans and bottles the individual bottles. As soon as these working steps have been
finished, the bottles are then shut in machine 2. After that, these bottles are packed into boxes by
machine 3.

The machines in the example are to visualize the individual modules in the PROFINET CBA
concept. This is what a modular system structure can look like.

_____________________________________
IT200803_0010/1
3 - 10
_____________________________________
PROFINET Basics

PCD* Files

*PROFINET Component Description (PCD)

Certain facts have to be specified and determined so that the system modules can communicate
with each other. These specifications are determined in the so-called PCD files. The PCD files
describe how a module can communicate with its outer world.

Thanks to the standard PDC file format it is possible to create an abstract description that is valid
for all individual system modules. They can only be used in manufacturer-independent software.

Due to the additional abstraction level with PCD files, the structure of the individual machine
components is completely irrelevant to the communication of the individual system modules with
each other. For this communication of the modules with each other it is of course the Ethernet
connection as well as the PCD file of the respective system module only that is required. Thus
PROFINET CBA supports independency when it comes to selecting the machine constructor(s) for
the individual system parts. All individual system modules can be manufactured by different
machine constructors. Thanks to the provision of the PCD file from the side of the respective
machine constructor, the communication within the system is guaranteed via PROFINET CBA.

_____________________________________
IT200803_0011/1
3 - 11
_____________________________________
PROFINET Basics

Configuration Software

The PCD files of the individual system modules can be imported into a manufacturer-independent
software. In a graphic software editor, the interfaces of the individual modules can then be linked to
each other. In the most simple case, a module sends the message that its working step is finished
so that the next module knows that it can continue the process by starting its own step.

If a system module is replaced or if the sequence of modules is changed - should the application
allow for this only the new PCD files need to be imported into the software and the modules in the
graphic editor can be linked again. This also enables a flexible handling of complex, modular
manufacturing systems.

_____________________________________
IT200803_0012/1
3 - 12
_____________________________________
PROFINET Basics

PROFINET Variants in Comparison

PROFINET IO PROFINET CBA
Same IO view as in fieldbus Higher-level system view
technology
Assigning IO signals to Definition of communication
controllers within process image interfaces
Configuration in manufacturer- Configuration using
specific tool with hardware manufacturer-independent
configuration and programming tools on system-level
languages
Reusability of modules Reusability on machine level

IO connection Machine/machine
communication

When comparing both concepts PROFINET IO and PROFINET CBA these are the essential
differences:

PROFINET IO contains the basic features of fieldbus technology. The selection of the configuration
software depends on the controller used. Due to function blocks, complex facts can be simplified on
an additional abstraction level and thus can be reused in the near future. PROFINET IO serves to
connect individual IO modules to a higher-level control.

PROFINET CBA provides the user with a higher-level system view. Thanks to the modularization,
the user gains a better overview of the manufacturing system. An additional abstraction level thanks
to the PCD files enables a simple and manufacturer-independent system management within a
software. The individual modules can be replaced more easily within PROFINET CBA without re-
adapting the entire manufacturing system afterwards.
PROFINET CBA is a concept to support the machine-to-machine communication.

_____________________________________
IT200803_0013/1
3 - 13
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 14
_____________________________________
PROFINET Basics

Communication

_____________________________________
3 - 15
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 16
_____________________________________
PROFINET Basics

Communication Channels

Ethernet

Real-time

In PROFINET, 3 different communication channels for the exchange of data between IO controllers
and individual IO devices are available.

The NRT channel

The NRT (Non-Real-Time) communication is used for the transmission of non-time-critical data.
The system startup, parameterization and the reading of diagnoses are realized via this
communication channel.

The RT channel
The RT (Real-Time) communication is used for the transmission of cyclic input and output data.
Also the acyclic data such as alarms or packets for address and name assignment are transmitted
via the RT channel.

The IRT channel

The IRT (Isochronous Real-Time) communication is the clock-synchronous data transmission. The
most important feature of IRT is a jitter < 1 s for the transmission of data packets. In this way it is
ensured that all IO devices are simultaneously receiving their data. This fact is especially important
for control engineering systems.

All communication channels, however, have in common that they are completely based on standard
Ethernet. Starting from NRT via RT to IRT channels, real-time capabilities of the respective
communication increases. This means that different communication models have to be available for
different requirements regarding the real-time capability of a system. Thus PROFINET is a scalable
real-time solution based on Ethernet in accordance with IEEE 802.3.

_____________________________________
IT200803_0017/1
3 - 17
_____________________________________
PROFINET Basics

NRT Communication (Non-Real-Time)

Connection-oriented communication
Exchange of non-time-critical information such as:
Parameterization during system startup
Structure of the communication relations
Reading diagnose information
Exchanging general device information
Reading / changing device parameters

NRT communication is connection-oriented communication. Here, the reception of individual

transmitted data packets is acknowledged by the recipient. In this way, the sender receives a
confirmation of the successful transmission of the corresponding information of each packet. For
certain pieces of information such as for example for device parameterization, it is especially
important that this complete information reaches the recipient. To be able to ensure this,
corresponding confirmations must be sent for those pieces of information. For this reason, the NRT
channel is used for these data packets.

The pieces of information for device parameterization or for the establishment of communication
relations are only sent once as opposed to the transmission of cyclic IO data. For this reason, it is
all the more important that a data packet reaches the recipient and is not lost on its way. The
protocol must ensure that data packets that got lost are re-sent.

On the NRT channel, secure data transmission has first priority as opposed to the time response.

_____________________________________
IT200803_0018/1
3 - 18
_____________________________________
PROFINET Basics

RT Communication (Real-Time)
Cyclic data exchange
User data traffic
Communication monitoring
Provider consumer model
Acyclic data exchange
Alarms
Identification
Address and name assignment

The RT communication regulates the time-critical exchange of cyclic and acyclic data.

The cyclic data represent the main user data traffic. This user data traffic takes place according to
the provider consumer model. Here, one device provides the data source (provider) and the other
side provides the data sink (consumer). This means that the provider generates data and then
cyclically transmits them to the consumer. This data exchange functions in both directions. Each
device thus is a provider and a consumer of the respective user data.
Since the provider consumer model does not transmit confirmations for the reception of individual
messages, the communication is monitored via cyclic data transmission. In this way, each device
monitors whether or not it still cyclically receives user data from the respective communication
partner. If individual packets are missing, the connection is aborted after a settable time during
which no other packets can be received.

The acyclic data exchange of the IO device with the IO controller occurs in the event of e.g., error
states.
Moreover, it comprises identification of individual IO devices during system startup as well as
address and name assignment to the individual IO devices. In this context, the required address
parameters are transmitted to all PROFINET devices within the network. Using these parameters,
the IO controller can then establish the communication to the respective IO devices.

_____________________________________
IT200803_0019/1
3 - 19
_____________________________________
PROFINET Basics

IRT Communication
(Isochronous Real-Time)
Clock-synchronous data transmission
Features
Jitter < 1 s
Hardware support via switch-ASIC
Cycle synchronization in accordance with IEEE 1588
Typical fields of application
Control engineering applications
Motion control applications
Separate time windows for real-time and TCP/IP

IRT communication is a clock-synchronous transmission of data at IO devices within the network.

The IRT communication has specific time behavior requirements. The most important request is a
jitter shorter than a microsecond. This means that the points in time at which the IO devices receive
their output data must not vary longer than one microsecond maximum.
Such time requirements, however, cannot be realized within the devices using a standard Ethernet
infrastructure due to the too long delay times. For this reason, a special hardware support via
corresponding switch ASICs is required for IRT communication. These switch ASICs distribute the
IRT data in the network taking into consideration the time requirements mentioned above. The
ASICs must be integrated into each device in the IRT network.

IRT communication is interesting in systems where several drives need to be controlled

synchronously. Typical application fields for IRT communication are control engineering
applications and motion control applications.

_____________________________________
IT200803_0020/1
3 - 20
_____________________________________
PROFINET Basics

Scheduling With PROFINET IRT

In order to be able to meet the time requirements within IRT communication, the general functional
principle of the standard Ethernet switches is not sufficient any more. For this reason, the IRT
switches use a special procedure for the distribution of data packets. Here, the so-called scheduling
is introduced that subdivides the processing of data packages within a switch into individual cycles.
These cycles behave analog to the cyclic data exchange via PROFINET. In each cycle we
distinguish between an IRT channel and an open channel. An IRT channel is always followed by an
open channel which then in turn in followed by an IRT channel.

The IRT channel always begins with a synchronization phase during which the different devices
within the network synchronize. As soon as the synchronization is finished, the deterministic
communication regarding IRT data starts. The terms of deterministic communication means that
there is a precisely specified schedule according to which data are transmitted within the network. It
is determined at which point in time an IRT telegram arrives at a switch and at which port is must be
forwarded. Within the switch, the IRT data are thus forwarded directly and without delay. It is in this
way only that PROFINET can meet the time requirements for IRT communication.

Subsequent to the IRT channel there is the open channel. In open communication, standard
TCP/IP data are transmitted as usual. Furthermore, the RT data described above as well as
anything else that is exchanged in a common Ethernet network is transmitted as well following the
rules of the standard Ethernet switch.

_____________________________________
IT200803_0021/1
3 - 21
_____________________________________
PROFINET Basics

Position in the Protocol Stack

In the protocol stack, PROFINET is positioned in the application layer (layer 7 of the ISO/OSI
model). Thus PROFINET is an application protocol such as for example the HTTP protocol that is
responsible for the access of websites on the Internet. PROFINET behaves like the corresponding
application protocols out of the IT world (HTTP, SNMP, DHCP, FTP, etc.) and is based on the
TCP/UDP, IP and Ethernet layers from the TCP/IP protocol stack. In this context, the individual
layers of the TCP/IP protocol stack are used by PROFINET for data transmission within the network
only.

For the non-time-critical data in the NRT channel, PROFINET is based on the TCP/UPD layer. For
transmission purposes, the standard data are packed into a UDP, an IP and an Ethernet frame and
are then transmitted within the network.

For time-critical real-time data, the IP and TCP/UDP layers are not used. The real-time channel is
based directly on the Ethernet layer thus optimizing the time behavior during data transmission.

_____________________________________
IT200803_0022/1
3 - 22
_____________________________________
PROFINET Basics

PROFINET Devices

_____________________________________
3 - 23
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 24
_____________________________________
PROFINET Basics

Device Types
PROFINET distinguishes between three device types:
PROFINET supervisor (programming devices / PC)
Startup
System diagnose
IO controller (control / PLC)
Processing the application program
Calculating the output signals
IO device (field device)
Reading the input signals
Setting the output signals

PROFINET Supervisor

The PROFINET supervisor mainly is a programming device via which the application program for
the IO controller is generated. Furthermore, the PROFINET supervisor is also used for system
diagnose for different visualization systems.

IO Controller
The IO controller represents the PLC within the PROFINET network. On the IO controller, the
application program is processed calculating the output signals for the respective IO modules
depending on the input signals.

IO Device
IO devices are interfaces to the sensors and actuators within the network. Via these IO devices,
input signals are read and transmitted to the IO controller. Simultaneously, the individual IO devices
receive output data from the IO controller thus setting the outputs of the IO devices.

In a system part there is a least one controller together with several IO devices exchanging data
among themselves.
One or more IO supervisors are usually integrated temporarily only for startup and for
troubleshooting within the network. However, in the context of system diagnostics, IO supervisors
often are an integral part of the automation system.

_____________________________________
IT200803_0025/1
3 - 25
_____________________________________
PROFINET Basics

Device Communication

The 3 device types mentioned above that are defined in the PROFINET specification, exchange
information during operation.

The following communication variants are available in practical applications:

IO Controller IO Device
Between the IO controller and the IO device, mainly the process data themselves are exchanged.
However, before they can be exchanged, certain IO devices might have to be configured. These
configuration settings are transmitted from the IO controller to the IO device. During operation, the
IO device might fall into error states on which the IO controller is to be informed. These alarms are
transmitted acyclically by the IO device to the IO controller, if required.

IO Controller PROFINET Supervisor

Between the IO controller and the PROFINET supervisor mainly information regarding the
application program is exchanged. In this way, the application program after it has been finished or
modified is loaded into the IO controller by the PROFINET supervisor. Furthermore, both device
types transmit diagnose information. With the help of the visualization software on the PROFINET
supervisor, these pieces of information are then visualized.

PROFINET Supervisor IO Device

Via the IO device also, diagnostic information is requested by the PROFINET supervisor in order to
visualize them. Moreover, in individual cases the status of IO devices is monitored or the IO devices
receive parameterization data from the PROFINET supervisor.

_____________________________________
IT200803_0026/1
3 - 26
_____________________________________
PROFINET Basics

Device Model of IO Devices

The IO device structuring is similar to the modular structure of a device in which the slots via their
subsets and their channels form the real interfaces to the process. Here, each slot may contain
several subslots and each subslot in turn can contain several channels. Via the device name, the
slot number, the subslot number and the channel number, each IO interface on an automation
system can be uniquely identified.

The option to uniquely identify all IO interfaces within a network simplifies the network diagnostics.
To locate an error at an IO interface, the physical position within the network can be clearly
identified. In this way, the errors within a PROFINET network can easily be corrected and
maintenance times as well as downtimes of automation systems are reduced. The device model of
the IO devices thus is a basis for the diagnostic concept for PROFINET providing the user with the
best support for maintenance and serving of automation systems.

The difference between a modular and a compact IO device is the following: a compact IO device
has pre-defined virtual slots and subslots that cannot be modified according to the specific system
requirements as it is possible for the modular IO devices.

_____________________________________
IT200803_0027/1
3 - 27
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 28
_____________________________________
PROFINET Basics

Integrating Fieldbus Technology

_____________________________________
3 - 29
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 30
_____________________________________
PROFINET Basics

Integrating Fieldbus Systems

The PROFINET proxy concept enables seamless integration of existing fieldbus systems into the
PROFINET network. The conversion from common fieldbus technology to PROFINET can thus be
realized gradually. It is not necessary to replace the entire fieldbus system for the entire PROFINET
system at once.

The proxy integrates the fieldbus system into the PROFINET system. The proxy is a proxy for the
lower-level bus system. This proxy provides the PROFINET system with fieldbus data in a suitable
form. Within the PROFINET network, the proxy has the role of a simple IO device. Within the lower-
level fieldbus system the proxy has the role of a master. Via data mapping of the lower-level
fieldbus system to the device model in PROFINET, the proxy presents the lower-level fieldbus to
the higher-level PROFINET system.

_____________________________________
IT200803_0031/1
3 - 31
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 32
_____________________________________
PROFINET Basics

Data Frames in PROFINET IO

_____________________________________
3 - 33
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 34
_____________________________________
PROFINET Basics

RT Frame Structure in Profinet IO

Ethernet frames are between 64 and 1518 Bytes long

Ethertype for RT frames has a value of 0x8892

The structure of real-time data packets for the exchange of PROFINET data does not differ from the
structure of common Ethernet telegrams.

The most striking feature of PROFINET data packets are additional pieces of VLAN information
consisting of 2 Bytes for Ethertype 0x8100 (Ethertype for VLAN) and 2 Bytes for the VLAN tag. The
VLAN tag contains priority information used to preferentially forward PROFINET telegrams within
the network.

The VLAN tag is followed by Ethertype 0x8892 characterizing the PROFINET telegrams. Actually
the prioritization of the PROFINET telegrams within the network is to take place using PROFINET
Ethertypes. However, since there might be older network infrastructure devices (switches) within
the network, that might not be able to recognize PROFINET Ethertype, a detour takes place via the
VLAN tag with the priority information contained therein.

The prioritization of data telegrams is not only guaranteed via managed switches within the
network. For this reason, PNO recommends the use of managed switches only within PROFINET
networks.

_____________________________________
IT200803_0035/1
3 - 35
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 36
_____________________________________
PROFINET Basics

Device Description

_____________________________________
3 - 37
_____________________________________
PROFINET Basics

Notes:

_____________________________________
Notiz/1
3 - 38
_____________________________________
PROFINET Basics

GSDML File
Device description of a PROFINET IO device
Each PROFINET IO device has a GSDML file
The file contains all pieces of information required regarding the
following:
Configuration
Data exchange
Diagnostics
Generic Station Description Markup Language (GSDML)
XML-based

Each PROFINET field device is described by GSDML file. This file contains all relevant data for
engineering and data exchange.

Each manufacturer of a PROFINET IO field device (controller and device) must provide a
corresponding GSDML file that is available and is tested via the certification test. The PROFINET
user organization provides the manufacturer with an XML scheme for the description of PROFINET
IO field devices. In this way, it is easy to create and test a GSDML file.

_____________________________________
IT200803_0039/1
3 - 39
_____________________________________
PROFINET Basics

Name Scheme of a GSDML File

The name assignment for GSD file is standardized and corresponds to the scheme shown above.
In this way, the following information can already be derived from a GSDML file name:

GSDML Scheme Version

The GSDML scheme version contains the version identification of the GSDML scheme used.

Manufacturers Name
The manufacturers name is name of the device manufacturer. Hyphens and spaces are
admissible. The manufacturers name is the first option to discern whether the device and the
GSDML file belong together.

Product Family Name

The name defines which device family is described in the GSD. It is also admissible to directly
indicate the IO device. Hyphens and spaces are admissible. The name allows for the direct
assignment of the corresponding GDSDML file to the device.

Release Date
The release date of the GSDML file is to be indicated in the yyyymmdd format. The manufacturer
must guarantee that there are no different GSDML files available with the same date for the same
device family. If there are several GSDML file for one IO device, the release date helps to find out
the most current GSDML file.

_____________________________________
IT200803_0040/1
3 - 40
_____________________________________
PROFINET Basics

Device Identification
Unique device ID for each PROFINET IO device
Device ID consists of:
16-bit vendor ID
Manufacturers identification (assigned by the PNO)
16-bit device ID
Device identification (assigned by the device manufacturer)

Each PROFINET IO field device is clearly identified by its device identification. During startup, the
IO device compares the device identification sent by the IO controller with its own identification. The
device identification structure is defined as follows:

Vendor-ID: 16-Bit identification representing a unique reference to the manufacturer. This

identification is provided by the PNO for each manufacturer. Thus a manufacturer only needs to
receive this ID once.

Device-ID: The device ID also is 16 Bit long and helps to distinguish between the IO field devices
in detail. It can be determined manufacturer-specifically (e.g., device class and device family).

_____________________________________
IT200803_0041/1
3 - 41
_____________________________________
PROFINET Basics

Device Import

The controller is provided with the device information by the GSDML files described above. In the
figure above, usually only item 4 to 7 are of any significance. For each PROFINET IO device (7),
the device manufacturer must provide a corresponding GSDML file to be able to operate this
device. Usually the device manufacturers provide the GSDML files for their IO devices on their
homepages. Such a GSDML file then needs to be imported into the configuration software (4). Via
the project download to the controller (5), all required pieces of information required for the
communication with the IO device (6) are available.

The principle of the device description files works down to the field level (1) where device
description files are used for the fieldbus devices also. Via the so-called PROXY configuration tool
(2), these fieldbus-specific device description files can be converted to the GSDML format and can
thus be used in the PROFINET system.

_____________________________________
IT200803_0042/1
3 - 42
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 43
_____________________________________
PROFINET Basics

Notes:

_____________________________________
3 - 44