Introduction
PROFINET is an open industrial Ethernet standard. Its design is utmost modular making it possible to create functionality which is defined by the user. PROFINET IO (PNIO) is real-time capable, so it can be used in almost all fields of automation technology. In a PNIO network you can find three types of devices that interact in a master-slave-relationship:
IO Controller; master
IO Device; slave
IO Supervisor; used for setup and diagnosis
During startup of automation equipment (assuming a complete configuration) an application relationship (AR) is created between a controller and a device. It is a kind of channel where both can communicate with each other. Within an AR three types of communication relationships are usable and have to be defined by the user:
IO Data CR
Record Data CR
Alarms CR
The IO Controller
The controller has master status in the network. It receives and transmits IO Data from the devices and controls the whole process. The user has to inform the controller about the devices that are in the network by installing a device specific GSD file in the controller. Based on the information that are provided to the controller within this file, the controller automatically creates the AR for every device that is modeled by the user.
The IO Device
The device has slave status in the network. It receives and transmits IO Data from the controller and provides process information. It is common for device hardware to be to be very modular, which is reflected in the device software model and addressing concept. Within the device model there is a differentiation between addressing and functionality.
A module (or submodule) is hardware with a special functionality and parameters while a slot (or subslot) only represents an address. The module (and submodule) becomes accessible by the controller when it is linked to a slot (and subslot) inside the device software definition, even if the device hardware is not modular. Sometimes it is necessary to submit data in a special structure. If so, different user profiles can be applied which are identified by the Application Process Identifier (API). API 0 is manufacturer specific.
According to this concept a value is addressed inside the device by its API number, slot number, subslot number and in some cases its index.
The Supervisor
The Supervisor is used to for setting up the controller, e.g. setting IP addresses and installing GSD files, as well as for diagnosis purposes. It is usually not permanently included in the network. If necessary, the supervisor is able to act as controller just as well.
The IO Data
From the controller’s point of view received data is always input data and sent data is always output data.
The IO Data CR is used to send and receive process data cyclically. The user can choose different real-time classes that provide diverse options, e.g. isochronous real-time communication.
IO data frames are submitted without handshake due to performance. In case a network member aborts sending IO data to the controller, the application produces an error.
To find out if the submitted data is valid, the process data is followed by a status information inside the submitted frame. IO data are followed by an IO provider status (IOPS) or an IO consumer status (IOCS).
The user has to setup this communication relationship inside the GSD file. Inside the device configuration the adequate IO data objects have to be created that are intended as a kind of link between the process data itself and its corresponding address (api, slot, subslot).
The IO Record Data
These data objects are sent acyclically and with handshake. Record data objects are used for parameterization of the device or reading parameters from the device. Parameters are usually written by the controller during startup and submitted as record data objects. Inside the device a parameter is addressed by api, slot, subslot and additionally by an index.
The user has to setup this communication relationship also inside the GSD file.
The Alarm Data Objects
These data objects are sent acyclically and with handshake. They are sent with high priority on occurring events.
There are two main types of alarms:
Process Alarms
Diagnosis Alarms
Process alarms are used when a special event in the process occurs. This might be exceeding of a critical value for example. In this case the device itself is still running without errors. Diagnosis alarms in contrast are caused by events or errors corresponding to the IO device. This might be malfunction of attached periphery or pulling and plugging of modules if the device hardware is modular.
Both kinds of alarms can be sent at different priority levels.
Slots and Modules
If your device hardware is modular (meaning you are able to plug and unplug several modules) you will easily understand the software model. If it is not you have to know that the software model is derived from modular hardware. A module is the interface to your process and it usually has some characteristics and parameters you want to change. This can be done when it is addressable by the controller. A module becomes addressable by the controller when you plug it into a slot, since a slot represents an address. See Figure 1 for a visual representation. Plugging a module means linking the structures of modules and slots within the software model using pointers.
Figure 1 shall only be considered as example. You can create a lot more slots and subslots inside your device.
Figure 1: PROFINET device model
Please notice: Slot 0 is pre-defined as Device Access Point (DAP). It represents the device’s bus interface and shall not be changed.
Subslots, Submodules and IO Data
It is analogue to the slot and module issue, only one addressing level deeper. Within the submodule definition, it has to be declared as Input (from the controller’s point of view, the IO device is provider), Output (from the controller’s point of view, the IO device is consumer) or none.
Please notice: For a proper configuration, a slot must have at least one subslot defined.
Parameters
Parameters belong to a certain submodule. They are addressed on the submodule by an index. To have them written or read by the controller they have to be linked in the software model to their corresponding Record Data Objects.
General Device Information
There is an amount of general information such as the device or the device ID and vendor ID. For a successful ident request, at least the mac address and the name of the device have to be set by the user. Other device parameters like the IP address can be set by a hardware configuration tool once the device is working.