Sie sind auf Seite 1von 6


From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality
standards. No cleanup reason has been specified. Please help improve this
article if you can. (July 2011) (Learn how and when to remove this template

PROFINET (profinet acronym for Process Field Net) is an industry technical standard for data
communication over Industrial Ethernet, designed for collecting data from, and controlling,
equipment in industrial systems, with a particular strength in delivering data under tight time
constraints (on the order of 1ms or less).[1] The standard is maintained and supported by Profibus
& Profinet International, an umbrella organization headquartered in Karlsruhe, Germany.


o 2.1IO connection life-cycle
2.1.1Address resolution
2.1.2Connection establishment
2.1.4Process IO data exchange / alarm handling
3IO addressing
4Real Time
5Isochronous communication
o 5.1Synchronization
o 5.2Bandwidth Reservation
o 5.3Scheduling
o 6.1PROFIsafe
8See also
11Further reading
12External links

Three protocol levels are defined:

TCP/IP for non time-critical data and the commissioning of a plant[2] with reaction times in the
range of 100 ms
RT (Real-Time) protocol for PROFINET IO applications[2] up to 10 ms cycle times
IRT (Isochronous Real-Time) for PROFINET IO applications in drive systems[2] with cycles
times of less than 1 ms
The protocols can be recorded and displayed using an Ethernet analysis tool such as
PRONETA[3] or Wireshark.[2]

Interfacing to peripherals is implemented by PROFINET IO.[2][4] It defines the communication with
field connected peripheral devices. Its basis is a cascading real-time concept. PROFINET IO
defines the entire data exchange between controllers (devices with "master functionality") and
the devices (devices with "slave functionality"), as well as parameter setting and diagnosis.
PROFINET IO is designed for the fast data exchange between Ethernet-based field devices and
follows the provider-consumer model.[2] Field devices in a subordinate PROFIBUS line can be
integrated in the PROFINET IO system seamlessly via an IO-Proxy (representative of a
subordinate bus system). A device developer can implement PROFINET IO with any
commercially available Ethernet controller.[2] It is well-suited for the data exchange with bus cycle
times of a few ms. The configuration of an IO-System has been kept similar to PROFIBUS.
PROFINET IO always contains the real-time concept.
A PROFINET IO system consists of the following devices:

The IO Controller, which controls the automation task.

The IO Device, which is a field device, monitored and controlled by an IO Controller. An IO
Device may consist of several modules and sub-modules.
The IO Supervisor is software typically based on a PC for setting parameters and diagnosing
individual IO Devices.[4]
An Application Relation (AR) is established between an IO Controller and an IO Device. These
ARs are used to define Communication Relations (CR) with different characteristics for the
transfer of parameters, cyclic exchange of data and handling of alarms.[2]
The characteristics of an IO Device are described by the device manufacturer in a General
Station Description (GSD) file. The language used for this purpose is the GSDML (GSD Markup
Language) - an XML based language. The GSD file provides the supervision software with a
basis for planning the configuration of a PROFINET IO system.[2][4]
IO connection life-cycle[edit]
The PROFINET IO connection life-cycle describes the connection between a PROFINET IO
Controller and IO Device. The connection allows the cyclic exchange of process IO data, and the
acyclic handling of alarms. The PROFINET IO connection life-cycle consists of address
resolution, connection establishment, parameterization, process IO data exchange / alarm
handling, and termination.[2]
Address resolution[edit]
A PROFINET IO device is identified on the PROFINET network by its station name.[note
Connection establishment, parameterization and alarm handling are implemented with User
Datagram Protocol (UDP), which requires that the device also be assigned an IP address. After
identifying the device by its station name, the IO controller assigns the pre-configured IP address
to the device.[2]
Connection establishment[edit]
Connection establishment starts with the IO Controller sending a connect request to the IO
Device. The connect request establishes an Application Relationship (AR) containing a number
of Communication Relationships (CRs) between the IO Controller and IO Device.[4] The connect
request defines some CRs within the AR. The following CRs are supported:

1. IO data CRs support the point-to-point exchange of cyclic input and output process data
between the IO Controller and IO Device.
2. A record data CR supports the exchange of log data.
3. An alarm CR supports the handling of alarms.
4. A multicast CR allows cyclic process data to be published by one node for consumption
by any number of consumers.[2]
In addition to the AR and CRs, the connect request specifies the modular configuration of the
IODevice, the layout of the process IO data frames, the cyclic rate of IO data exchange and the
watchdog factor.
Acknowledgement of the connect request by the IO Device allows parameterization to follow.
From this point forward, both the IO Device and IO Controller start exchanging cyclic process I/O
data frames. The process I/O data frames don't contain valid data at this point, but they start
serving as keep-alive to keep the watchdog from expiring.
The IO Controller writes parameterization data to each IO Device sub-module in accordance with
the General Station Description Mark-up Language (GSDML) file. Once all sub-modules have
been configured, the IO Controller signals that parameterization has ended. The IO Device
responds by signalling application readiness, which allows process IO data exchange and alarm
handling to ensue.[2][4]
Process IO data exchange / alarm handling[edit]
The IO Device followed by the IO Controller start to cyclically refresh valid process I/O data. The
IO Controller processes the inputs and controls the outputs of the IO Device.[4]Alarm notifications
are exchanged acyclically between the IO Controller and IO Device as events and faults occur
during this phase in the PROFINET IO connection life-cycle.[2]
The connection between the IO Device and IO Controller terminates when the watchdog
expires.[4] Watchdog expiry is the result of a failure to refresh cyclic process I/O data by the IO
Controller or the IO Device.[2] Unless the connection was intentionally terminated at the IO
Controller, the IO Controller will try to restart the PROFINET IO connection life-cycle.

IO addressing[edit]
Every module within a PROFINET network has three addresses:

MAC address
IP address
Device name, a logical name for the module within the total configuration
Because PROFINET uses TCP/IP a MAC and IP address are used. A MAC address changes if
the device is replaced. An IP address is a form of dynamic addressing. Because there was a
need for a fixed address a device name is used.
For allocation of the IP address, subnet mask and default gateway two methods are defined:

DCP: Discovery and Configuration Protocol

DHCP: Dynamic Host Configuration Protocol

Real Time[edit]
Within PROFINET IO, process data and alarms are always transmitted in real time (RT). Real
time in PROFINET is based on definitions of IEEE and IEC, which allow for only a limited time for
execution of real-time services within a bus cycle. The RT communication represents the basis
for the data exchange for PROFINET IO. Real-time data are treated with a higher priority than
TCP(UDP)/IP data. RT provides the basis for the real-time communication in the area of
distributed periphery and for the PROFINET component model. This type of data exchange
allows bus cycle times in the range of a few hundred microseconds.
PROFINET IO data communicated over PROFINET RT uses EtherType 0x8892.

Isochronous communication[edit]
Isochronous data exchange with PROFINET is defined in the Isochronous Real-Time (IRT)
concept. The data exchange cycles are usually in the range of a few hundred microseconds up
to a few milliseconds. The difference to real-time communication is essentially the high degree of
determinism, so that the start of a network cycle is maintained with high precision. The start of a
network cycle can deviate up to 1 s (jitter). IRT is required, for example, for motion control
applications (positioning control processes) because these devices need to be synchronized.
Coexistence with PROFINET RT and TCP/IP frames on the same cabling is still maintained.
PROFINET IRT uses the transparent clock mechanism to synchronize PROFINET IRT devices.
The transparent clock mechanism is specified in IEEE 1588-2008 (1588 V2). This creates one
control loop between the master clock and slave clocks.
Bandwidth Reservation[edit]
The bandwidth reservation method reserves time (bandwidth) on the network for PROFINET
frames sent via IRT. A separate time domain is created at the beginning of a network cycle,
during which all IRT frames are sent. After the IRT time domain is completed, PROFINET RT
and finally non-time-critical TCP/IP frames are sent.
Because the controller knows the topology of the network via LLDP, it sends IRT frames based
on this topology. IRT frames destined for IRT devices furthest from the controller are sent first in
the IRT time domain.

Profiles are pre-defined configurations of the functions and features available from PROFINET
for use in specific devices or applications. They are specified by PI working groups and published
by PI. Profiles are important for openness, interoperability and interchangeability, so that the end
user can be sure that similar equipments from different vendors perform in a standardised way.
There are PROFINET profiles for encoders, for example. Other profiles have been specified for
motion control (PROFIdrive) and Functional Safety (PROFIsafe). A special profile for trains also
Another profile is PROFIenergy which includes services for real time monitoring of energy
demand. This was requested in 2009 by the AIDA group of German automotive Manufacturers
(Audi, BMW, Mercedes-Benz, Porsche and VW) who wished to have a standardised way of
actively managing energy usage in their plants. High energy devices and sub-systems such as
robots, lasers and even paint lines are the target for this profile, which will help reduce a plant's
energy costs by intelligently switching the devices into 'sleep' modes to take account of
production breaks, both foreseen (e.g. weekends and shut-downs) and unforeseen (e.g.
PROFIsafe (PROFIBUS safety or PROFINET safety) is a safety communication technology for
distributed automation. Its specification for PROFIBUS DP and PROFIBUS PA was published
first in 1999. Extensions for the Ethernet based PROFINET IO followed in 2005.
The IEC 61508 standard specified how microcontrollers and software can be used in safety
automation. This triggered the development of PROFIsafe, which was to integrate safety into the
existing standard PROFIBUS fieldbus technologies. PROFIsafe is designed as a separate layer
on top of the fieldbus application layer to reduce the probability of data transmission errors.
PROFIsafe messages use standard fieldbus cables and messages. PROFIsafe does not depend
on error detection mechanisms of underlying transmission channels, and thus supports securing
of whole communication paths, including backplanes inside controllers or remote I/O. PROFIsafe
coined the term "Black Channel" for this concept, which was adopted by other safety fieldbusses.
PROFIsafe can be used in safety applications up to Safety Integrity Level 3 (SIL) according to
IEC 61508, Performance Level "e" (PL) according to ISO 13849, or Category 4 according to EN
PROFIsafe uses error and failure detection mechanisms such as:

Consecutive numbering
Timeout monitoring
Source/destination authentication
Cyclic redundancy checking (CRC)
PROFIsafe was standardized in IEC 61784-3-3 and Chinese standard (GB/Z 20830-2007).
PROFIsafe runs its own web portal with more details on the technology and hints for device
developers, integrators and end users. The PROFIsafe standard is maintained, updated and
marketed by PROFIBUS International, a non-profit organisation administered from Karlsruhe in
Germany. PROFIBUS International is also responsible for the development of PROFIBUS and
PROFINET, an Ethernet based fieldnetwork.

PROFINET is defined by PROFIBUS and PROFINET International (PI) and backed by the
INTERBUS Club and, since 2004, is part of the IEC 61158 and IEC 61784 standards.

See also[edit]

1. Jump up^ The station name is a user-configurable alpha-numeric description of up to 240

1. Jump up^ "Archived copy" (PDF). Archived from the original (PDF) on 2015-04-02. Retrieved 2015-
2. ^ Jump up to:a b c d e f g h i j k l m n o PROFINET System Description, Version April 2009, PROFIBUS
Nutzerorganisation e.V., 2009
3. Jump up^
4. ^ Jump up to:a b c d e f g Industrial communication with PROFINET, Manfred Popp, Order no.: 4.182,
PROFIBUS Nutzerorganisation e.V. (PNO)

Further reading[edit]
Raimond Pigan, Mark Metter: Automating with PROFINET, 2nd rev. and enl. edition.
2008, ISBN 978-3-89578-294-7

External links[edit]
PROFIBUS & PROFINET International (PI)
PROFINET Technology Page
PROFIBUS International
PROFIsafe web portal