This webpage presents an overview of PROFINET IO, a high-level network for industrial automation applications. Built on standard Ethernet technologies, PROFINET IO uses traditional Ethernet hardware and software to define a network that structures the task of exchanging data, alarms and diagnostics with programmable controllers and other automation controllers.
PROFINET IO is one of two open Ethernet standard automation “views” from Profibus International. While PROFINET IO focuses on programmable controller data exchange, PROFINET CBA (Component Based Automation) focuses on distributed automation systems. PROFINET CBA provides a Distributed Component Object Model-based system for organizing automation systems into networks of peer devices that can automatically exchange data using predefined relationships between the interfaces of the automation components. PROFINET CBA is thoroughly discussed elsewhere on this site. Let’s talk about IO.
PROFINET IO is very similar to PROFIBUS® on Ethernet. While PROFIBUS uses cyclic communications to exchange data with programmable controllers at a maximum speed of 12Meg baud PROFINET IO uses cyclic data transfer to exchange data with programmable controllers over Ethernet. As with PROFIBUS, a programmable controller and a device must both have a prior understanding of the data structure and meaning. In both systems data is organized as slots containing modules with the total number of I/O points for a system the sum of the I/O points for the individual modules.
Subscribe to our Automation Education email series to learn the ins and outs of PROFINET IO and the top industrial protocols in a byte-size weekly format!
An ever-increasing number of minute-long videos introducing PROFINET from the basics to the esoteric.
This library contains a myriad of documents pertaining to a wide range of topics. Some are technical in nature and go into depth on a particular feature. Others provide side-by-side comparisons of competing technologies or present cases studies.
RTA is a proud member of PI. For more information, visit their site: profibus.com
Most people who work in an office associate the term “Ethernet” with the physical cable behind their desk. This cable connects their office PC to the printers and servers of the local network and the infinite web sites on the Internet. This cable is only the physical part of Ethernet, the media carrying Ethernet messages to your PC. On this wire are a whole series of communication protocols, such as the Internet Protocol (IP), the Transmission Control Protocol (TCP) and various Microsoft protocols, such as NetBEUI. This suite of protocols works well for the office environment. It allows users to share files, access printers, send email, search the Internet and perform all the other communications used in the office environment.
The needs of the factory floor are much different with some very special requirements. Instead of accessing files and printers, factory floor controllers must access data embedded in drive systems, operator workstations and I/O devices. Instead of letting a user wait while a task is being performed, factory floor data communications needs are real-time or very close to real time. Terminating the fill operation on a bottle requires much more time-precise communications than accessing the next page of an internet site.
Traditionally, Ethernet had only limited acceptance in industrial automation. Until recently, the expense, lack of sophisticated switches and routers and the domination of large vendors with proprietary protocols prevented the wide acceptance of Ethernet on the factory floor. Now, Ethernet is gaining acceptance with prices falling, PCs with inherent Ethernet capability moving in droves onto the factory floor and intelligent switches and routers more readily available. Only the lack of a widely accepted, flexible application layer targeted to industrial automation has prevented its complete acceptance.
PROFINET IO, like many other networking systems, has a set of unique terminology. Table 1 contains a few of the terms commonly used when discussing PROFINET IO.
|AR||Application Relationship – The relationship between a PROFINET IO controller and an I/O device. A PROFINET IO device can support more than one application relationship.|
|AP||Application Process – The application process running in the IO device. PROFINET supports a default application processes and additional, profile specific application processes.|
|Channel||A single I/O point. A channel can be discrete or analog.|
|Subslot||A group of one or more channels. Subslots can be real or virtual.|
|Slot||A group of one or more subslots. Slots can be real or virtual.|
|Module||Modules are user defined components that plug into slots. Modules can be real or virtual.|
|Submodule||A component of a module that is plugged into a subslot. A submodule is real or virtual.|
|Cyclic Communications||Scheduled, repetitive communications. I/O data and alarm transfers are cyclic.|
|Acyclic Communications||Unscheduled, on demand communications. Diagnostic messages from an IO-Supervisor to an I/O device are acyclic.|
|GSD||Stands for Generic Station Description.|
|GSDML||Stands for Generic Station Description Markup Language, the file containing the XML description of the PROFINET IO device.|
|Provider Status||This is the status an I/O device provides to an IO-Controller with the data transferred to the controller.|
|Consumer Status||This is the status an I/O device provides to an IO-Controller for the data it consumes from the IO-Controller.|
|RT||Stands for Real-Time, or the Real Time PROFINET IO channel. I/O and alarm data are transferred over the RT Channel.|
PROFINET IO is a unique industrial Ethernet application layer. It offers many benefits over competing application layers including those listed below.
PROFINET IO classifies devices into three types; IO-Controllers, IO-Devices and IO-Supervisors. IO-Controllers are devices that execute an automation program. Controllers, functionally similar to a PROFIBUS Class 1 Master, exchange data with IO-Devices. IO-Devices are distributed sensor/actuator devices connected to the IO-Controller over Ethernet. In Profibus terms, IO-Devices are similar to PROFIBUS slaves. IO-Supervisors are HMIs, PCs or other commissioning, monitoring or diagnostic analysis devices. These devices are similar to Class 2 PROFIBUS Masters.
IO-Controllers map IO data from PROFINET IO devices into the process image of the controller. In Siemens S7 programmable controllers, I/O data, alarms and status data is mapped into the process image in much the same way it is done for PROFIBUS devices. These data values are then available for use by the control program. IO-Controllers must support the following kinds of services:
IO-Supervisors are used for commissioning and diagnostic data collection. IO-Supervisors can read and write internal diagnostic data associated with the PROFINET IO stack or diagnostic data provided by the application program of a device. IO-Supervisors can also read and write configuration data using special, non-cyclic record data object services. These types of devices may only be used during the commissioning process or they may be used as an HMI to display diagnostic data to the end user.
A PROFINET IO system requires at least one IO-Controller and one IO-Device. Systems can be assembled in various configurations: multiple IO-Controllers for a single IO-Device; single IO-Controllers for multiple IO-Devices and multiple IO-Controllers with multiple IO-Devices.
The network representation of a device is the view of the device from the network. In Modbus and Modbus TCP, devices are represented as a series of registers (16-bit integers) and coils (bits). In EtherNet/IPT and DeviceNetT devices are represented as objects. Other networks have other network configurations. In LonworksT, data is represented by a series of data tags that the device provides to the outside world. In every case above, the device presents some view of itself to the outside world. That representation is the network representation.
The PROFINET IO network representation is very similar to PROFIBUS. It consists of a device with slots, subslots and channels. Subslots are subcomponents of a slot. Each subslot is assigned a number of I/O points or channels. A channel is the PROFINET IO term which refers to one physical discrete input, discrete output, analog input or analog output. A device can have almost any number of slots, subslots and channels.
Aside from slot zero, every other slot and subslot contains status, diagnostic and alarm data for the channels of that slot. For points transferred to an IO-Controller, provider status and diagnostic information is automatically transferred on every I/O scan cycle. For points transferred to an IO-Device, consumer status is returned to the IO-Controller.
Even though PROFINET IO devices and GSD files refer to slot zero, there is no slot zero. The first I/O slot of a device is slot one. Instead of referring to an actual slot, slot zero refers to the device itself. No I/O data is contained in slot zero. In place of I/O data, slot zero manages all the generic device data like the vendor name, product catalog number and software and hardware version information and other similar information.
Modules are specific functional components that can be associated with a slot. Modules can be virtual or real. A module, real or virtual, must be plugged into a slot before the I/O device goes online. The module gives the slot a specific identity. For example, a 16 discrete input module gives the slot a 16 discrete input identity. In the same way that modules provide identity to slots, sub-modules provide subslot identity. The 16 discrete input module can be composed of one discrete 16-input sub-module, two 8-input sub-modules or four 4-input sub-modules.
IO-Controllers associate to a device and all the slots and subslots. The current version of PROFINET IO only supports devices associated to one IO-Controller at a time. Future versions of PROFINET IO may lift this restriction and associate to IO-Controllers by slot.
In an IO-Controller, like a Siemens 317 programmable controller, the I/O channels for the subslots assigned to that programmable controller are collected and that data group forms the I/O data image that is transferred between the IO-Device and the IO-Controller. For example, if you have a PROFINET IO device with four input slots (16 inputs each) and two output slots (16 outputs each), the I/O image transferred between the controller and device is four bytes in the direction of the Programmable Controller and two bytes in the direction of the IO-Device.
Internally, in an IO-Controller, all PROFINET IO inputs are assigned to the Input data table and all outputs are assigned to the output data table, just as is done for PROFIBUS.
PROFINET IO devices are configured using a configuration tool that acts as the IO-Supervisor. The IO-Supervisor uses a GSD file similar to the GSD files common to PROFIBUS. Unlike PROFIBUS GSD files, PROFINET IO GSD files are XML based and carry much more information than the PROFIBUS GSD. Because they are XML based, PROFINET GSD files are called GSDML files. (More information on GSDML file is covered in a later section.)
Configuration is transferred from the IO-Supervisor using the Record Data Object (RDO) services. These services allow an external device to read and write data maintained by either the PROFINET IO stack or the application. Record data is non-real time data. It includes data like configuration, diagnostic and status data. Record data is always transferred acyclically in a connection oriented, queued transmission mode. Record data can consist of the following elements.
The IP Address of the PROFINET IO device is stored in persistent memory in the device. It can be modified by an IO-Supervisor using RDO services. A PROFINET IO device can also be configured to obtain an IP Address automatically from a bootp or DHCP server.
Alarms and diagnostic data in a PROFINET IO system are related and easily confused by the PROFINET IO novice. Diagnostic data is data associated with a channel or I/O point. For example, an analog input can have an overlimit diagnostic or a discrete input can have a short circuit diagnostic. Diagnostic data is always transferred acyclically using record data communications over the Non-Real Time (NRT) channel. An IO-Supervisor must specifically request the diagnostic data from the device using RDO services.
Alarm data is very different. While one type of alarm is an alert that diagnostic data exists on a specific channel there are many more reasons why a device would signal an alarm. Alarms are signaled when a module or submodule is plugged or pulled, when the wrong module or submodule is plugged, when a process limit is reached, when the device state changes or for any number of other reasons (see table below ).
|Module/Submodule Pull Alarm|
|Module/Submodule Plug Alarm|
|Supervisor Control Alarm|
|Supervisor Release Alarm|
|Wrong Submodule Alarm|
|Diagnostic disappears alarm|
|Multicast communications mismatch|
|Port Data Change Notification Alarm|
|Sync Data Change Notification Alarm|
|Isochronous Mode Notification Alarm|
Unlike diagnostic data, alarm data is transmitted on the Real Time (RT) channel and only to the programmable controller linked to that module. For example, a device with two modules attached to two different programmable controllers issues module alarm data only to the programmable controller exchanging data with the module enabling the alarm.
A unique feature of PROFINET IO alarms is that alarms are not only issued on failures but are also issued when the alarm condition is cleared. For example, when an alarm is issued on an input short circuit, another alarm is issued when the short circuit disappears. Almost the same thing happens when an alarm indicates that diagnostic data exists for a channel (I/O point). Instead of issuing the alarm for every channel with diagnostic data, an alarm is issued when the first diagnostic data entry is created and when the last diagnostic data entry is released.
Both alarm data and diagnostic data are acknowledged. Diagnostic data is acknowledged simply because the IO-Supervisor receives a response message to the diagnostic data read request. Alarm data is part of the Real-Time data issued by the device and is specifically acknowledged by the programmable controller.
The Generic Station Description Markup Language (GSDML) file is an eXtensible Markup Language (XML) file that describes the expected implementation of a PROFINET IO device. The table below describes the top-level elements of a PROFINET IO GSDML file.
|Profile Header||Describes the XML file itself including its version number, the device type and description.|
|Profile Body||Details the actual device implementation.|
The Profile Body details the device implementation in three main elements. The table below describes these elements.
|Device Identity||The device identity identifies the device in terms of the vendor ID assigned by Profibus International, the text description of the name and the text string that describes the device.|
|Device Function||Specifies the text description of the family name for this device.|
|Application Process||Describes the application of the device and the number of slots, subslots, modules and submodules that the device can have.|
The Application Process is composed of two very important elements described in the table below.
|Device Access Point List||This describes the general configuration of the device. It describes the maximum number of modules, the maximum I/O size and the module in slot zero. Slot zero module data includes its manufacturer ID, the vendor name, its description, version number and the order number.|
|Module List||This describes all the modules and submodules which are valid for this application process. The actual channel data is described for each of the possible submodules that may be installed in the device.|
For I/O data, the GSDML file describes the structure of the cyclic input and output data transferred between the programmable controller and the PROFINET IO device. Any mismatch between the size or structure of the input and output data and the actual internal device structure generates an alarm to the controller.
Every PROFINET IO device uses a number of constant values. The table below defines these values and lists their sources:
|Vendor ID||Unique value identifying an authorized PROFINET IO vendor. This value is assigned by Profibus International.||Static Constant|
|Device ID||Unique value identifying a PROFINET IO device. This value is assigned by the device manufacturer.||Static Constant|
|Module ID||Unique value identifying a specific module type. This value is assigned by the device manufacturer. When the PROFINET IO device plugs in a module, the module ID must agree with the module ID specified in the GSDML file.||Static Constant|
|Submodule ID||Unique value identifying a specific submodule type. This value is assigned by the device manufacturer. When the PROFINET IO device plugs in a submodule, the submodule ID must agree with the submodule ID specified in the GSDML file.||Static Constant|
|Product Family||A manufacturer-specific text string describing the product family.||Static Constant|
|Station Name||A text string describing the function of the station in the application. The PROFINET IO device is delivered with a default station name. An IO-Supervisor or IO-Controller can send a new station name to the PROFINET IO device.||Stored in Persistent Memory in the PROFINET IO device|
|IP Address||This is the actual IP Address of the device. It can be changed by an IO-Controller or IO-Supervisor or by a DHCP server. Every PROFINET IO device is shipped with a default IP address.||Stored in Persistent Memory in the PROFINET IO device|
The PROFINET Runtime Software or PROFINET Core is the software made available by Profibus International to developers. This software is one of a number of components necessary to implement a PROFINET device. The figure below graphically represents the core and the additional components required to construct a PROFINET device.
The user application plugs the modules into the slots on power on, starts the PROFINET task, generates diagnostic data, issues and releases alarms and maps the I/O data between physical device I/O and PROFINET IO.
The RTOS performs task management. When PROFINET IO runs in one task, at a minimum there is the user application task and the data exchange task.
The PROFINET IO kernel is the software provided by Profibus International to developers. This software must not be changed. It consists of the following major subcomponents.
The interface modules provide the connection between the PROFINET IO kernel and the RTOS. These are mostly standard RTOS components but some must be modified to support PROFINET IO operation. The OS abstraction layer is the only one that is not at least partially provided by the RTOS vendor. The abstraction layer is specific to an implementation of the RTOS. It maps the OS calls of the PROFINET core to the OS calls of the RTOS and is specific to the RTOS.
PROFINET IO devices are typically configured by Siemens Step 7 software. Using Step 7, devices descriptions are loaded from the GSDML files. I/O configurations are mapped into the I/O tables of the Siemens IO Controller and IP addresses are assigned to each PROFINET IO device. The figure to the right graphically represents the structure of this system.
PROFIBUS is a worldwide standard for the transmission of process data between field level devices and programmable controllers. How can I/O data and other information travel between PROFIBUS and PROFINET IO? At the physical level these two communication networks are completely incompatible. At its core, PROFIBUS is an RS-485-based communication standard with a maximum baud rate of 12M. At the core of PROFINET is Ethernet, another worldwide standard but with baud rates of 100M and beyond.
Are they at all compatible at the protocol level? PROFIBUS is I/O driven. Data is transferred as blocks of inputs and outputs which are interpreted by agreement between the PROFIBUS master and the slave. PROFINET is also I/O driven with data transferred in blocks of inputs and outputs. In both systems, there is a master or IO-Controller and one or more IO devices.
Since a PROFIBUS master device can access all the data of the PROFIBUS network the logical place for a communications gateway is as the master device of the PROFIBUS network. This is illustrated in the figure to the left.
Unlike PROFIBUS , all PROFINET IO devices must pass certification prior to product launch. The Certification Office of the Profibus User Organization is responsible for establishing test centers where PROFINET IO devices can be certified. The first PROFINET IO test center is located in Germany. The first US test center opened in 2005.
Certification of a PROFINET IO device is a three-step process
PROFINET IO certification generally takes up to 8 weeks from commencement. One working device must be presented to the Test Center which maintains strict confidentiality.
The PROFINET Runtime Core software can be downloaded free of charge (membership required) from Profibus International as a zip file. Porting PROFINET to a specific RTOS requires the developer to port each PROFINET component. The components to port include the RPC, CM, Sockets Interface, DCPl, Alarm Handler Interface and the Ethernet Device Driver. The PROFINET Integration manual provides individual instructions for the porting of each of these components.
Prior to starting this effort the developer should have a background in the Microsoft RPC, Component Object Model, Sockets and C++. An extensive background in the specific operation of your RTOS, the operation of your TCP/IP stack and the fundamentals of your processor are also important.
PROFINET implementation is not without challenges. Porting of your PROFINET core to your embedded RTOS is a significant challenge. The PROFINET core is designed for Net OS from NetSilicon. Other cores may be available.