Profinet
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.
Technology
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]
Peripherals
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
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
A PROFINET IO device is identified on the PROFINET network by its station name.[note 1] 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
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:
- IO data CRs support the point-to-point exchange of cyclic input and output process data between the IO Controller and IO Device.
- A record data CR supports the exchange of log data.
- An alarm CR supports the handling of alarms.
- 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.
Parameterization
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
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]
Termination
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
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:
Real Time
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
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.
Synchronization
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
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.
Scheduling
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
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 exists.
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. breakdowns).
PROFIsafe
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 954-1.
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.
Organization
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
Notes
- ^ The station name is a user-configurable alpha-numeric description of up to 240 characters
References
- ^ "Archived copy" (PDF). Archived from the original (PDF) on 2015-04-02. Retrieved 2015-03-10.
{{cite web}}
: Unknown parameter|deadurl=
ignored (|url-status=
suggested) (help)CS1 maint: archived copy as title (link) - ^ 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
- ^ http://w3.siemens.com/mcms/automation/en/industrial-communications/profinet/productportfolio/proneta/Pages/proneta.aspx
- ^ a b c d e f g Industrial communication with PROFINET, Manfred Popp, Order no.: 4.182, PROFIBUS Nutzerorganisation e.V. (PNO)
Further reading
- Raimond Pigan, Mark Metter: Automating with PROFINET, 2nd rev. and enl. edition. 2008, ISBN 978-3-89578-294-7