IO-Link – der Integrations-Aspekt

Mit IO-Link haben mehrere Automatisierungsanbieter vor gut einem Jahr eine Initiative zur herstellerunabhängigen Anbindung von Sensoren und Aktoren gestartet. Die eigentliche Kommunikationsschnittstelle ist mittlerweile exakt definiert. Jetzt geht es darum, IO-Link-fähige Komponenten nahtlos in bestehende Netzwerke und Steuerungssysteme zu integrieren.

Mit IO-Link haben mehrere Automatisierungsanbieter vor gut einem Jahr eine Initiative zur herstellerunabhängigen Anbindung von Sensoren und Aktoren gestartet. Die eigentliche Kommunikationsschnittstelle ist mittlerweile exakt definiert. Jetzt geht es darum, IO-Link-fähige Komponenten nahtlos in bestehende Netzwerke und Steuerungssysteme zu integrieren.

INHALT:

Die Abbildung auf das überlagerte Bussystem
Einfache Software-Bedienung als Ziel
Gerätebeschreibung und Profile
Der Parameter-Server
Kompetenzen bleiben gewahrt
Autor
nähere Informationen

Eine typische Anlagentopologie sieht heute wie folgt aus: Die SPS führt das Anwendungsprogramm aus und steuert die Maschine. Der Zugriff auf die Prozessperipherie erfolgt über den Feldbus. Mit IO-Link tritt nun eine neue Technologie in der unteren Feldebene an, die den „letzten Meter“ zwischen den binären Sensoren und Aktoren und der vernetzten Automatisierung standardisieren soll. Der große Vorteil von IO-Link: Neben den eigentlichen Prozessdaten lassen sich damit auch Daten zur Parametrierung und Diagnose-Daten übertragen – und das über ein einfaches ungeschirmtes dreiadriges Standardkabel. Geschirmte Kabel, mehrpolige Steckverbinder oder zusätzliche Eingänge für Diagnose können damit entfallen. In den Ankündigungen der Anbieter heißt es immer wieder, dass IO-Link nahtlos in bestehende Netzwerke und Steuerungssysteme integrierbar ist. Doch was heißt „Integration“ eigentlich in diesem Zusammenhang?

Gegenstand der folgenden Betrachtungen ist der IO-Link-Master. Dabei handelt es sich um ein Gateway, das die Funktionalität der IO-Link-Devices über den Feldbus für die SPS zur Verfügung stellt. Ziel muss sein, dass die Abbildung in einer für den SPS-Programmierer gewohnten Art und Weise erfolgt, und dass sich IO-Link-Devices über das Prozessabbild und Funktionsbausteine genau so programmieren lassen, als wären sie direkt Teilnehmer am Feldbus.


Für eine wirkliche Integration reicht das aber bei Weitem nicht aus: Denn auch die der SPS überlagerten Systeme müssen direkt mit den IO-Link-Komponenten kommunizieren können. Hierzu ist es erforderlich, dass sich die IO-Link-Geräte direkt von der Engineeringstation aus parametrieren und darüber hinaus Geräte-Informationen sowie Diagnosemeldungen abrufen lassen, die dann auch für die Fernwartung oder die Visualisierung verwendbar sind. Für die SPS heißt das: Sie übernimmt in diesem Fall eine weitere Gateway-Funktion.

Auf der Engineeringstation erwartet der Anwender kein Sammelsurium an verschiedenen, nicht harmonisierten Programmen, sondern eine komfortabel integrierte Lösung. So soll das Tool zur Bedienung des IO-Link-Device direkt aus der grafischen Topologiesicht des SPSProgrammiersystems aufgerufen werden können. Dabei kann es nicht sinnvoll sein und es ist auch nicht wirtschaftlich darstellbar, dass jeder Sensor- oder Aktorhersteller Software mit komplexen Schnittstellen für seine Geräte entwickeln muss. Da IO-Link-Devices eher einfach aufgebaut sind, liegt es nahe, diese standardisiert und einfach – zum Beispiel in XML – zu beschreiben. Damit können dann auch generische IO-Link-Device-Tools verwendet werden.

Soviel grundsätzlich zum Thema „Integration“. Im Detail gilt es zu berücksichtigen, dass IO-Link in alle weltweit relevanten Kommunikations- und Steuerungssysteme integriert werden soll. Das bedeutet, dass jeder der genannten Aspekte spezifisch zu betrachten ist und die Akzeptanz in den Zielbranchen und -Regionen bei der Wahl der Lösung berücksichtigt werden muss. Für die meisten Hersteller ist das eine völlig neue Herausforderung: Bisher wurden die Sensoren und Aktoren über 24 V digital oder über Standard-Analogsignale (4 bis 20mA/±10 V) an die Steuerung angeschlossen. Weder für die Entwicklung noch für Support und Vertrieb war Wissen über die Kommunikations- und Steuerungssysteme beziehungsweise die Engineeringsoftware erforderlich. Deshalb ist es für den Erfolg von IO-Link entscheidend, dass die Integration aus Sicht der Sensoren und Aktoren mit einheitlichen Mitteln und ohne großen Aufwand erfolgen kann.

In den bisherigen Ausführungen ist eine Thematik bisher außen vor geblieben, die aber zunehmend gefordert und in manchen Anwendungen sogar vorgeschrieben ist: Wenn Anlagen immer flexibler werden und selbst relativ einfache Sensoren parametrierbar sind – wie ist dann noch nachvollziehbar, was in einer Anlage verändert wurde und mit welchem Aufwand sich ein ausgefallenes Gerät tauschen lässt?

Device-Tools, gleichgültig auf welcher Technologie sie basieren, erheben in der Regel den Anspruch, Einstellwerte zu speichern und so die Nachvollziehbarkeit und auch den Gerätetausch zu ermöglichen. Was aber passiert, wenn die Einstellung über Tasten am Gerät lokal erfolgte? Oder wenn der Bediener in der Nachtschicht einen Sensor ohne Engineeringstation tauschen soll? Hier kommt der so genannte „Parameter-Server“ ins Spiel. Die Idee dahinter ist, dass nur das IO-Link-Device weiß, dass seine Parametrierung verändert wurde. Dabei spielt es keine Rolle, wie die Änderung der Parametrierung erfolgte – lokal, per Tool oder per Funktionsbaustein von der SPS. In jedem Fall löst die IO-Link-Komponente eine Benachrichtigung an den IO-Link-Master aus, um das Sichern der Parameter anzufordern. Dieser holt sich die erforderlichen Daten und speichert sie entweder selbst oder gibt sie mit dem sinngemäß gleichartigen Mechanismus an einen zentralen Anlagenserver weiter. Für den Sonderfall des Gerätetauschs erkennt der IOLink-Master an einer Check-Summe das getauschte IO-Link-Gerät und kann die gespeicherten Parameter wiederherstellen.

Für Profibus und Profinet ist der Parameterserver im Zusammenhang mit dem sicherheitsgerichteten Übertragungsprotokoll Profisafe als „iPar-Server“ bereits spezifiziert und auf Anwendungsebene realisierbar. Systemhersteller wie Siemens werden den Parameterserver, den alle unterlagerten Feldgeräten nutzen können, zur Verfügung stellen. Grundsätzlich kann aber jeder IO-Link-Masterhersteller oder sogar der Anlagenbauer selbst den Parameterserver implementieren. Auch für alle anderen Feldbus-Systeme ist eine solche Lösung realisierbar. Der Mechanismus zwischen IO-Link-Master und IO-Link-Device muss dazu nicht verändert werden.