Parameter und Kommunikationsdienste bei Profinet IO

Feldbusgestützte Geräte sind aus den Techniken zahlreicher Branchen nicht mehr wegzudenken, sodass sich eine schier endlose Vielfalt an Applikationen und Komponenten bietet, die für Anlagen verwendet werden. Besonders beliebt sind hierbei Technologien, die gemeinhin als standardisiert gelten, sodass somit eine Herstellerunabhängigkeit besteht und Systeme unterschiedlicher Art aneinander gekoppelt werden können. Innerhalb dieser Systeme bedarf es jedoch verschiedener Einheiten, die die Kommunikation abwickeln oder Daten definieren. Hierzu zählen die Parameter und Kommunikationsdienste, die am Beispiel von PROFINET IO näher erläutert werden sollen.

Die unterschiedlichen Parameter von PROFINET IO

Bei Parametern müssen verschiedene Kategorien unterschieden werden, damit diese klar definiert und beschrieben werden können:

• Geräte-und Modulparameter: 
  Unter diesem Parameter lassen sich alle Gerätestammdaten definieren, die über die Engineering-Werkzeuge des jeweiligen Systemherstellers eingestellt werden. Um dies zu erreichen bedarf es keiner weiteren Tools, sodass die GSD-Daten direkt zur Verfügung stehen. Sobald ein Neustart initialisiert wird, wird eine Steuerung, bei welcher es sich in der Regel um einen IO-Controller handelt, beim Verbindungsaufbau der Parameter in das IO-Device umgeschrieben.
  
• Individuelle Parameter: 
  Bei komplexen Feldgeräten sind individuelle Parameter erforderlich, um diese noch weiter einzustellen. Dabei können jedoch die verschiedenen Schnittstellen und Werkzeuge unterschiedliche Einstellungen gewählt werden. Wird ein System neu gestartet oder kommt es um Austausch von Geräten, so können die individuellen Parameter ohne spezielle Maßnahmen neu geladen werden.

Besonderheiten bei den individuellen Parametern

Kommt es zu einem Neustart oder Gerätetausch innerhalb eines Netzwerks können sich die individuellen Parameter neu laden lassen. Damit dies automatisch vonstattengeht werden zwei unterschiedliche Herangehensweisen gewählt:

• Proxy-Funktionsblock: 
  Sind alle individuellen Parameter innerhalb des IO-Device eingestellt, so werden diese durch die Steuerung eingelesen und abgespeichert. Kommt es zu einem Austausch von Geräten oder besteht ein entsprechender Bedarf, so können die gespeicherten Parameter vom IO-Controller zurück in das Feldgerät geschrieben werden. Unterstützt wird diese Funktion, indem die Hersteller der IO-Devices Proxy-Funktionsblöcke bereitstellen, die als Stellvertreter für die Steuerung eingesetzt werden kann und hierdurch den Aufwand zum Programmieren des Systems reduziert wird.
• iPar-Server: 
  Diese Methode steht für eine Funktion innerhalb eines Teilnehmers der Netzwerktopologie. Daneben lässt sich der Server auch in einem IO-Controller oder einem IO-Supervisor integrieren. Die individuellen Parameter sind im Server abgelegt und können bei einem Neustart oder dem Bedarf nach diesen angefordert werden. Der Vorteil dieser Vorgehensweise besteht darin, dass die Steuerung kein spezielles Programm braucht, um funktionieren zu können. Dennoch erhält der IO-Controller in Form von Diagnose-Statusmeldungen Informationen zu neu geladenen Parametern.

Kommunikationsdienste

Damit zyklische und azyklische Daten zwischen einem Supervisor und einem IO-Device ausgetauscht werden können, muss der entsprechende IO-Controller die hierfür erforderlichen Kommunikationswege während des systeminternen Hochlaufs aufbauen. Hierfür richtet der Controller eine Verbindung ein, die auf der Basis derjenigen Daten arbeitet, welche von dem Engineering-System zur Verfügung gestellt werden. Dabei entspricht diese Verbindung der „Application Relation“ (kurz AR), welche alle Daten beinhaltet, die zum Aufbau dieser Verbindung erforderlich sind, damit ein Datenaustausch erfolgen kann. Diese Relation kann flexibel gestaltet werden und lässt sich zudem zum besseren Verständnis in mehrere Kommunikationsbeziehungen unterteilen:

• eine oder mehrere Kommunikationsbeziehungen, die sich in Input, Output und Querverkehr aufteilen
• Eine Kommunikationsbeziehung, die dem Versenden eines Alarmsignals und der Weitergabe von Ereignissen dient
• Eine „Record-Data“ Kommunikationsbeziehung die dem Austausch von azyklischen Datensätzen dient

Der zyklische Datenaustausch bei PROFINET IO

Der Austausch von Informationen zwischen den Teilnehmern einer Netzwerktopologie kann zyklisch verlaufen und wird über einen RT-Kanal abgewickelt, der die Prozesssignale und die hochprioritären Alarme übermittelt. Für diese Form des Datentransfers sieht PROFINET IO drei verschiedene Möglichkeiten vor:

• RT-Kommunikation innerhalb eines Netzwerks – hierbei kommt der schnelle RT-Kanal zum Einsatz, sodass es keiner Verwendung von UDP/IP bedarf
• RT-Kommunikation zwischen Netzwerken – um dies zu realisieren wird der Protokollmechanismus über einen RT-Kanal und UDP/IP abgewickelt
• IRT-Kommunikation – diese Methode steht für die deterministische und zum Takt synchrone Datenübertragung zur Verfügung

Neben dem zyklischen Datenaustausch gibt es auch den Daten-Querverkehr, bei welchem eine RT-Kommunikation und IRT-Relation verwendet wird. Zudem existieren ein Provider der Daten am Bus veröffentlichen kann und ein oder mehrere Consumer die die Daten verarbeiten.

Der azyklische Datenaustausch

Bei dieser Form der Übertragung spielen die Record Daten eine entscheidende Rolle. Zudem können die Vorgänge des Lesens und Schreibens durch den Anwender auch azyklisch realisiert werden. Zu solchen Diensten zählen bei PROFINET IO folgende Funktionen:

• Das Parametrieren von einzelnen Submodulen während sich das System im Hochlauf befindet
• Das Auslesen der Diagnoseinformationen
• Das Auslesen von Informationen zur Identifikation 
• Das Rücklesen der IO-Daten

Ob Daten nun zyklisch oder azyklisch gelesen und geschrieben werden, hängt davon ab, wie dies in der Adressierung durch den Index bestimmt wurde. Hierbei gelten viele der vorhandenen Dienste als standardisiert.