Sämtliche Feldbusse geben sich große Mühe, den Anwendern und Geräteherstellern bestmögliche Integrationsmethoden für die Feldgeräte zu bieten. Dies beginnt bereits bei der Netzkonfiguration und der entsprechenden Versorgung mit den Kommunikationsparametern (Übertragungsraten, Adressen etc.). Diese lassen sich um einige Gerätekonfigurationsund schließlich noch um Basisparameter für die Technologiefunktionen ergänzen, die der Feldgerätehersteller samt Einstellmöglichkeiten über eine standardisierte Beschreibungssprache definieren kann. Bei Profibus und Profinet sind diese Angaben in einer Gerätestammdaten-Datei (GSD) gespeichert. Die Einstellungen kann der Anwender über das Engineeringsystem vornehmen. Nach Abschluss der Konfiguration und Parametrierung gelangen diese Daten in die CPU, die sie an die Feldbus-Steuerung weitergibt. Beim Hochlauf erhält jedes Feldgerät dann seinen Datensatz zugeteilt.

So weit, so gut: Bei der Vielzahl unterschiedlichster Feldgerätetechnologien ist es jedoch nicht möglich, sämtliche Bedürfnisse über die GSD-Technologie abzuwickeln – sei es wegen der Menge von Parametern, deren Komplexität oder den Abhängigkeiten untereinander. Ergänzend zur GSD gibt es daher zwei grundsätzliche „Angebote“ an die Feldgerätehersteller: eine Schnittstellen- und Kommunikationstechnologie zur Ankopplung bereits existierender Programme zur Gerätekonfiguration, Parametrierung und Diagnose, sowie eine Interpretationstechnologie für Gerätebeschreibungen, die sich aus der Weiterentwicklung der HART-Gerätebeschreibung ergeben hat. – Folgende Beispiele verdeutlichen die Lage, in der sich Gerätehersteller befinden, die ihr Gerät in den Feldbus integrieren möchten:

Individuelle Geräteparameter können auf vielfältige Art und Weise in ein Feldgerät gebracht werden: über Laptop mit individuellen Kabeln und eine Punkt-zu-Punkt-Verbindung wie RS232 oder USB, über die azyklische Feldbus-Kommunikation, über einen Web-Browser, oder auch über Kleingeräte mit Funk- beziehungsweise Infrarot- Verbindung.

Da ist zunächst der Laserscanner in der Sicherheitstechnik zu nennen, der klassisch nur über Relais-Signale mit den Automatisierungssystemen verbunden ist. Zur Konfiguration, Parametrierung und Diagnose solch eines relativ komplexen Gerätes ist ein PC-Programm (CPD-Tool) und eine Anbindung über eine PC-Schnittstelle (RS232, USB etc.) das Mittel der Wahl. Kommt nun als Gerätevariante der Feldbus-Anschluss hinzu, wird der Hersteller wegen der zunächst geringeren Stückzahlanteile versuchen, die Investitionen in das PC-Programm zu retten und allenfalls die Schnittstellen- und die Kommunikationsalternative wählen.

Beim Remote-I/O-Hersteller gibt es dagegen einen fließenden Übergang. Er kann mit einfachen digitalen und analogen I/O-Modulen beginnen, wofür die Mittel der GSD genügen. Bei der Erweiterung um Motorstarter-Module kann dies ausreichend sein. Spätestens aber, wenn komplexere Frequenzumrichter-Module hinzukommen, ist in der Regel ein Bruch nicht zu vermeiden. Diese „Antriebe“ werden normalerweise in anderen Bauformen auch als separate Feldbus-Geräte angeboten, und daneben noch für mehrere Feldbus-Alternativen. Zunehmend werden dem Anwender hier auch lokale speicherprogrammierbare Steuerungsfunktionen zur Verknüpfung von Signalen offeriert, so dass zusätzlich zu den Parametern ganze SPS-Programme anfallen. Wie beim Scanner ist das PC-Programm und die Punkt-zu-Punkt-Anbindung das Mittel der Wahl. Mit steigenden Stückzahlen kommt die Kommunikations-Alternative über Feldbus als Komfortstufe hinzu.

Als drittes Beispiel sei die Integration anderer Kommunikationssysteme genannt. Neben bekannten Feldbussen zählen hierzu etwa HART oder IO-Link. Die entsprechenden Gateways können sowohl in Form eines in die Remote-IO-Komponenten integrierten Moduls als auch als Kompaktgerät auftreten und bringen in der Regel ihr Konfigurations- und Parametriersystem als PC-Programm mit. Die entsprechenden Parameter für das Kommunikations- Subsystem werden normalerweise im Gateway-Modul abgelegt und beim Hochlauf in die Geräte des Subsystems geladen. Bei Profinet mit Ethernet als Basis – um ein viertes Beispiel anzuführen – tauchen als zusätzliche Spielart webbasierte Verfahren für die Parametrierung auf. Jeder, der sich zuhause einen Router installiert hat, kennt das Vorgehen: Browser aufrufen, IP-Adresse eingegeben und schon ist der Zugang zum Gerät hergestellt.

Viele Wege - ein gemeinsames Problem

Die Beispiele zeigen, dass es zahlreiche Wege gibt, wie die anfallenden gerätebeziehungsweise herstellerspezifischen Feldgerätedaten – im folgenden seien diese durch ihren Bezug zur individuellen Gerätetechnologie kurz iParameter genannt – in Feldbus-Geräte gelangen. Es ist müßig, diese Wege eindämmen und auf eine Methode zwingen zu wollen, da die Hersteller den unterschiedlichsten ökonomischen und technischen Sachzwängen ausgesetzt sind.

Der iPar-Server-Mechanismus besteht aus dem allgemeinen Teil des Sicherns (Hochladen) und Rückspeicherns (Runterladen) von iParametern und einem diversitären Datenintegritätsverfahren über CRC-Signatur für Geräte der funktionalen Sicherheit (Profisafe).

Doch was passiert, wenn das Gerät ausfällt und auszutauschen ist? Muss das Wartungspersonal die zugehörigen PC-Programme kennen und damit umgehen können, und findet es die richtigen Projektdaten? Und wie sieht das Ganze aus, wenn Sicherheitsgeräte betroffen sind? Die Menge von iParametern fängt bei wenigen Byte an und kann die MByte- Grenze überschreiten. Es geht also darum, ein „beliebig“ großes Paket von unstrukturierten Daten außerhalb des Feldgerätes zu sichern und zum Beispiel nach einem Gerätetausch in das Ersatzgerät wieder zurück zu laden. Sinnvollerweise befindet sich ein entsprechender Mechanismus an der gleichen Stelle im Feldbus-System – oder wird zumindest dort „verwaltet“ –, wo auch die Versorgung mit GSD-Daten erfolgt. Solch ein Mechanismus ist in der Profibus- und Profinet-Welt unter der Bezeichnung iPar-Server spezifiziert und funktioniert wie nachfolgend beschrieben (siehe dazu Bild links).

Im ersten Schritt wird zusammen mit der Netzwerkkonfiguration und der Basisparametrierung (GSD) der iPar-Server für das Feldgerät implizit oder explizit als Funktionsbaustein eingerichtet 1. Vom Engineering-Tool aus startet der Anwender ein CPD-Tool über die jeweils passende Schnittstelle 2, zum Beispiel das Tool-Calling-Interface (TCI). Dabei wird mindestens die Netzadresse des konfigurierten Gerätes übergeben. Das CPD-Tool ermöglicht dann die Parametrierung, gegebenenfalls Programmierung, die Inbetriebnahme und den Test 3. Nach Beendigung dieser Vorgänge ist das Feldgerät in der Lage, selbstständig das Hochladen (Save) zu seiner iPar-Server- Instanz anzufordern 6. Es bedient sich dabei einer speziellen Diagnosemeldung (Notification), die aber im Gegensatz zu einer normalen Diagnosemeldung nicht angezeigt wird (keine rote LED). Der iPar-Server wertet die Notification aus und führt den Hochladevorgang aus 7. Dabei werden die iParameter unter Verwendung von azyklischen Diensten (Read Record) als Instanz-Daten im iPar- Server gespeichert. 

Nach dem Entfernen einer defekten Komponente erhält das Tauschgerät seine GSD-basierten Parameter direkt beim Hochlauf 5. Aufgrund eines vom Gerätehersteller zu definierenden oder in einem Applikationsprofil wie Profisafe vereinbarten Kriteriums erkennt das neue Feldgerät falsche oder fehlende iParameter. Als Konsequenz fordert es die gespeicherten iParameter bei der iPar-Server-Instanz an (Restore-Notification), wobei wieder die spezielle Diagnosemeldung bemüht wird 6. Der iPar-Server liest die Anfrage aus der Notification und führt den Lade- Prozess (Write Record) durch 8. Dank dieses Transfers erhält das Tauschgerät auf einfachem Weg ohne jeglichen Tool- Einsatz seine iParameter und kann den regulären Betrieb aufnehmen. Für größere Datenmengen bietet der iPar-Server auch die Möglichkeit des segmentierten Sicherns und Zurückladens.

Safety: Datenintegrität ist sichergestellt

Für die funktional sichere Kommunikation gemäß Profisafe sind zwei zusätzliche Schritte vorgesehen, die auf diversitärem Weg die Prüfung auf korrekte iParameter ermöglichen. Nach dem Parametrieren und der Verifikation bietet das CPD-Tool eine CRC-Signatur über die iParameter. Diese Signatur trägt der Benutzer in das Feld eines GSD-basierten Parameters (F_iPar_ CRC) im Engineering-Tool ein 4. Beim Hochlauf gelangt dieser Parameter in das Feldgerät. Somit lässt sich die Überprüfung der lokal gespeicherten iParameter nach jedem Einschalten durchführen – also auch nach dem Austausch eines defekten Gerätes. Ab da wird der bereits beschriebene – auch von nicht-sicherheitsbezogenen Geräten nutzbare – Mechanismus in Anspruch genommen.

Die iPar-Server-Funktion ist in der Profibus/ Profinet-Welt zumindest in der Sicherheitstechnik für Steuerungen vorgeschrieben (F-Host Conformance Class). Durch die applikative Lösung sind bestehende Steuerungen und Anlagen nachrüstbar. Hierzu müssen mindestens 32 kByte iParameter pro Gerät/Modul abspeicherbar sein. Dadurch ist der Gerätehersteller in den meisten Fällen von Logistik-Aufwendungen für diese Funktion befreit. Die Problematik von „Speicherkärtchen“ bei IP67-Feldgeräten besteht für ihn somit nicht mehr. Weitere Applikationsprofile wie IO-Link machen bereits Gebrauch vom iPar-Server, so dass hierfür zur Hannover Messe 2009 mit einer eigenständigen Spezifikation zu rechnen ist. Feldgerätehersteller sind bereits mit SPS-Pilotsoftware versorgt, um die Ergänzungen nachrüsten zu können.

Der iPar-Server ist grundsätzlich von allen Feldgeräten nutzbar, auch von solchen mit Anwenderprogrammen. Durch den offensichtlichen Nutzen der Gerätetauschmöglichkeit im Fehlerfall ohne Engineering- Tools ergeben sich weitere Sekundär- Effekte. Und zwar wirkt der iPar- Server wie eine lineare Erweiterung der GSD-basierten Parametrierung. Bei Serienmaschinen beispielsweise kann einfach ein Anwenderprogramm mit den vorbesetzten iParameter-Daten in die SPS geladen werden, so dass die vollständige Parametrierung der Feldgeräte (GSD-basiert und iParameter) automatisch abläuft. Flexible Fertigung ist einfach durch den Tausch des Anwenderprogramms möglich: Die Grundparametrierung erfolgt beim Hochlauf, die Versorgung mit iParametern nach Bedarf. Gleiches gilt für Rezepturfertigungen. Gerätehersteller, die ein vom Anwenderprogramm gesteuertes Umparametrieren des Feldgerätes benötigen, können den iPar-Server-Mechanismus nutzen, für die SPS aber anstelle des iPar-Server-Bausteins einen eigenen Funktionsbaustein mit entsprechenden Ergänzungen anbieten.

Autor: Wolfgang Stripf ist innerhalb der Profibus Nutzerorganisation für die internationale Standardisierung von Profisafe und Security zuständig.