| Real Time Automation | 1-800-249-1612 |  |
Contact Us | |
Support |
 |
 |
 |
 |
 |
|
SYNOPSIS This paper 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 DCOM-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 in another paper. 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. PROFINET IO uses three different communication channels to exchange data with programmable Controllers and other devices. The standard TCP/IP channel is used for parameterization, configuration and acyclic read/write operations. The RT or Real Time channel is used for standard cyclic data transfer and alarms. RT communications bypass the standard TCP/IP interface to expedite the data exchange with Programmable Controllers. The third channel, Isochronous Real Time (IRT) is the very high speed channel used for Motion Control applications. IRT is implemented using a custom ASIC and is not the subject of this paper. A LITTLE BACKGROUND 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 IP, the Internet Protocol; TCP, the Transport Control Protocol; 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 with prices falling, PCs with inherent Ethernet capability moving in droves onto the factory floor and intelligent switches and routers, Ethernet is gaining acceptance. Only the lack of a widely accepted, flexible application layer targeted to Industrial Automation has prevented its complete acceptance. Important PROFNET Terms 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.
PROFINET IO Benefits PROFINET IO is a unique industrial Ethernet application layer. It offers many benefits over competing application layers including:
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:
A PROFINET IO system requires at least one IO-Controller and one IO-Device. Systems can be configured 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. PROFINET IO Network Representation 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. Except for 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 16 discrete 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 points or channels for the subslots assigned to that Programmable Controllers is 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 4 bytes in the direction of the Programmable Controller and 2 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. Configuring PROFINET Devices PROFINET IO devices are configured using a configuration tool which 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 (See a later section for more information on the GSDML file). 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
Alarm vs. Diagnostic Data 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 (Record Data Object) 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 many other reasons (See Table 2 ). 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 issued 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 (RT) data issued by the device and is specifically acknowledged by the Programmable Controller. PROFINET GSDML File The GSDML (Generic Station Description Markup Language) file is an XML (eXtensible Markup Language) file that describes the expected implementation of a PROFINET IO device. Table 3 describes the top level elements of a PROFINET IO GSDML file.
The Profile Body details the device implementation in three main elements. Table 4 describes these elements.
The Application Process is composed of two very important elements described in Profile Body details the device implementation in three main elements.
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. PROFINET IO Constant Data Every PROFINET IO device uses a number of constant values. Table 6 defines these values and lists their sources:
PROFINET Runtime Structure The PROFINET Runtime Software or "PROFINET Core" is the software made available by Profibus International to developers. This software is only one of a number of components necessary to implement a PROFINET device. Figure 1 graphically represents the core and the additional components required to construct a PROFINET device.  USER APPLICATION ( yellow ) 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. RTOS - Real Time OS ( cyan ) The Real Time Operating System performs task management. At the minimum, PROFINET IO runs in one task, there is the user application task and there is a data exchange task. PROFINET IO ( green ) 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 sub components:
The Interface modules provide the interface 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 maps the OS calls of the PROFINET core to the OS calls of the RTOS and is specific to the RTOS. The abstraction layer is specific to an implementation of the RTOS. PROFINET Configuration Structure 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. Figure 2 graphically represents the structure of this system.  WHERE DOES PROFIBUS FIT IN? Profibus ® is a worldwide standard for 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. Profibus is at its core an RS485-based communication standard with a maximum baud rate of 12M. At the core of PROFINET is Ethernet, another worldwide standard 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 3.  PROFINET CERTIFICATION 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 . A US Test Center opened in 2005. Certification of a PROFINET IO device is a three step process:
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, Context Manager, Sockets Interface, Discovery Protocol, 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, COM, 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. FOR MORE INFORMATION Profibus International, PROFINET Application Layer Service Definition , Version 1.95, November 2004 Profibus International, PROFINET Application Layer Protocol Specification , Version 1.95 Real Time Automation, Inc. (RTA, Inc.) is a member of the Profibus Trade Organization (PTO) and an authorized implementation vendor and member of ODVA. For more information see the following: Or contact John Rinaldi or call 1-800-249-1612. |
1. Synopsis 2. A Little Background 3. Important PROFNET Terms 4. PROFINET IO Benefits 5. PROFINET Device Classification 6. PROFINET IO Network Representation 7. Configuring PROFINET Devices 8. Alarm vs. Diagnostic Data 9. PROFINET GSDML File 10. PROFINET IO Constant Data 11. PROFINET Runtime Structure - User Application - RTOS - Real Time OS - PROFINET IO 12. PROFINET Configuration Structure 13. Where Does Profibus Fit In? 14. PROFINET Certification 15. How To Get Started 16. For More Information Sign up for our FREE recurring newsletter to stay up to date on topics such as:
» Networking Technology » Latest Industry News 
» I want this file in PDF Format » I need to PROFINET IO-enable My Product For Your Immediate Needs Call: John Rinaldi Networking Project Manager 1-800-249-1612 1-262-439-4999 |
RTA, Inc. - The Industrial Networking Home for DeviceNet, EtherNet/IP, LonWorks,
Modbus TCP,
Modbus RTU, PROFINET CBA, PROFINET IO, BACnet, IEC 61131-3,
IEEE 1588, AS-Interface, PROFIBUS, EtherCAT, CoDeSys and other networks.
© 2009 Real Time Automation, Inc.
www.rtaautomation.com
Real Time Automation, Inc. 150 South Sunny Slope Road. Suite 130 Brookfield WI 53005 © Real Time Automation, Inc. All Rights Reserved. | http://www.rtaautomation.com |
(262) 439-4999 (V) (262) 439-4989 (F) www.rtaautomation.com |