Integration von IO-Link in Steuerungssysteme

IO-Link ist der neue Standard in der unteren Feldebene und wird von allen führenden Automatisierungsherstellern in Europa unterstützt. IO-Link schließt den letzten Meter zur Anbindung von Sensoren und Aktoren in die vernetzte Automatisierung. Mit IO-Link werden neben den Prozessdaten auch Daten zur Parametrierung und zur Diagnose übertragen. Die wohl wichtigste Eigenschaft von IO-Link ist, dass diese Möglichkeiten mit einer zur heutigen Installation kompatiblen Verdrahtung erfolgt. Einfache ungeschirmte dreiadrige und meist vorkonfektionierte Standardkabel reichen aus. Geschirmte Kabel, vielpolige Steckverbinder, zusätzliche Eingänge für Diagnose usw. entfallen. Der Kundennutzen beginnt bei den Einsparungen in der Installation, über Parametrierung und Diagnose für flexible Fertigungslösungen und reicht bis hin zur zustandsgesteuerten vorbeugenden Instandhaltung. Keine Entwicklung in der industriellen Kommunikation und in den letzten Jahren konnte so mit Kostenersparnis und gleichzeitig erhöhter Funktionalität aufwarten. Auch auf der Seite des Engineerings zeigt sich diese Skalierbarkeit von IO-Link. IO-Link-Devices kön­nen in einem zu digitalen I/Os kompatiblen Mode betrieben werden. In diesem Fall kann die Parametrierung zum Beispiel mithilfe eines USB-IO-Link- Interfaces am PC erfolgen. In der SPS-Projektierung muss man dann gar nichts tun. Will man die Daten im SPS-Programm nutzen, reicht in vielen Fällen eine Projektierung über die bei den Feldbussystemen bekannten Mechanismen, wie GSD-Dateien und Funktionsbausteine. Wer z.B. für die Inbetriebnahme komfortable Bedientools erwartet, wird ebenfalls nicht enttäuscht. Bild 1 zeigt eine heute typische Anlagentopologie. Die SPS führt das Anwendungsprogramm aus und steuert die Maschine. Der Zugriff auf die Prozessperipherie erfolgt über den Feldbus. Der IO-Link-Master ist ein Gateway, das die Funktionalität der IO-Link-Devices über den Feldbus für die SPS zur Verfügung stellt. Dabei geschieht die Abbildung in der für den SPS-Programmierer gewohnten Art und Weise. Für die Integration reicht das aber bei Weitem nicht aus. Denn auch die der SPS überlagerten Systeme müssen direkt mit den IO-Link-Devices kommunizieren können. So erwartet der Anwender, dass er die IO-Link-Devices von der Engineering-Station aus parametrieren und Geräteinformationen und Diagnosen abrufen kann. In diesem Fall übernimmt die SPS eine weitere Gateway-Funktion. Diese wird dann auch für Fernwartung, z.B. über das Internet, oder zur Integration in die Visualisierung benötigt. Auf der Engineering-Station erwartet der Anwender eine komfortabel integrierte Lösung. So soll das Tool zur Bedienung des IO-Link-Devices direkt aus der grafischen Topologiesicht des SPS-Programmiersystems aufgerufen werden können. Dazu sind Software-Schnittstellen wie das Tool Calling Interface (TCI) oder auch FDT/DTM definiert. Andererseits kann es aber nicht sinnvoll und schon gar nicht wirtschaftlich darstellbar sein, dass jeder Sensor- oder Aktorhersteller Software mit komplexen Schnittstellen für seine Geräte entwickeln muss. Da IO-Link Devices eher einfach sind, liegt es nahe, diese auf einfache Art und Weise standardisiert zu beschreiben. Besonders wichtig ist, dass IO-Link in alle weltweit relevanten Kommunikations- und Steuerungssysteme integriert werden kann und soll. Das bedeutet, dass jeder der o.g. Aspekte spezifisch betrachtet werden muss und die Akzeptanz in den Zielbranchen und -regionen bei der Wahl der Lösung berücksichtigt werden muss. Für die meisten beteiligten Hersteller ist das eine völlig neue Herausforderung. Bisher wurden die Sensoren und Aktoren über 24V digital oder Standard Analogsignale wie 4 bis 20mA und ±10V an die Steuerung angeschlossen. Weder für die Entwicklung noch für Support und Vertrieb war Wissen über die Kommunikations- und Steuerungssysteme bzw. über die Engineering-Software erforderlich. Deshalb ist für den Erfolg von IO-Link maßgeblich entscheidend, dass die Integration aus Sicht der Sensoren und Aktoren mit einheitlichen Mitteln und sehr einfach erfolgen kann. Standardisierte Abbildung von IO-Link auf das jeweils überlagerte Bussystem Aktuell wird im IO-Link-Arbeitskreis an der Integration in Profibus, Profinet, Interbus, Ethercat, CANopen und AS-Interface gearbeitet. Kontakte zu weiteren Feldbusorganisationen wurden aufgenommen. Die Spezifikation betrifft zunächst nur die IO-Link-Mas­ter und hat keinen Einfluss auf die Implementierung der IO-Link-Devices. Programmierschnittstellen für die SPS (Funktionsbausteine) Wenn die Abbildung auf das jeweilige Feldbussystem bei verschiedenen IO-Link-Mastern einheitlich erfolgt, dann können auch einheitliche Software Schnittstellen für den SPS-Programmierer definiert werden. Die internationale Norm IEC61131 Teil 3 ist eine hinreichend gute Basis für diese Festlegung. Die Umsetzung auf die Spezifika des jeweiligen Systems ist meist leicht möglich. Für Profibus und Profinet wurden bereits Funktionsbausteine realisiert, die weitgehend für IO-Link verwendet werden können. Device-Tools Sollen Parameter z.B. für eine flexible Fertigung im laufenden Betrieb verändert werden, dann geschieht das in der Regel durch die o.g. Funktionsbausteine. Für Diagnose, Wartung und bei der Inbetriebnahme soll für das IO-Link-Device jedoch eine möglichst einfach zu bedienende Software zur Verfügung stehen. Diese Software muss in das SPS-Programmiersystem und den darin enthaltenen Netzwerkkonfigurator integrierbar sein. So haben Projekteure, Inbetriebsetzer und Servicepersonal eine durchgängige Sicht auf die gesamte Anwendung. IO-Link-Devices sind im Vergleich zu Feldgeräten in der Prozessautomatisierung oder zu Antrieben einfach und verfügen in der Regel nur über eine Handvoll Parameter. Für diese Geräte muss es möglich sein, innerhalb von einem Tag die Beschreibung für die Integration ins Engineering zu erstellen. Für die meisten Sensoren und Aktoren ist deshalb eine XML-Gerätebeschreibung ausreichend. Diese wird von Interpretern, die mittels TCI oder FDT/DTM in die Automatisierungssysteme integriert sind, interpretiert. Von der TMG in Karlsruhe steht das TMG-IO-Link-Device-Tools schon heute zur Verfügung, das z.B. im Zusammenspiel mit Step7, S7-Steuerungen, IO-Link-Mastern für Profibus und Profinet und IO-Link-Devices mehrerer Hersteller eingesetzt wird. Mit der gleichen Oberfläche kann auch das USB-IO-Link-Interface verwendet werden, um IO-Link-Devices direkt am PC parametrieren zu können.TMG zeigt in diesem Zusammenhang eben­falls, wie aus einer Microsoft Excel Mappe, in die alle benötigten Informationen zum IO-Link-Device eingetragen werden, die XML-Gerätebeschreibung per Macro erstellt werden kann. Als Integrationsstandard wird hier Tool Calling Interface (TCI) verwendet. TCI spezifiziert nicht die Art und Weise, wie ein Gerät beschrieben wird, sondern definiert ausschließlich die relativ einfache Softwareschnittstelle zwischen Engineeringsoftware und Device-Tool. Der Anwender sieht eine integrierte Lösung. Die unterlagerten \’Beschreibungstechniken\‘ bleiben verborgen. Standardisierte Gerätebeschreibung Für IO-Link wurde eine Gerätebeschreibung auf der Basis von XML spezifiziert, die in der Version 1.0 verabschiedet ist. In der ersten Stufe werden die für die Kommunikation relevanten Eigenschaften, das Prozessabbild, die Parameter, nicht zyklische Aktualwerte und die Diagnose beschrieben. Selbstverständlich können alle Texte mehrsprachig angeboten werden. Es ist vorgesehen, dass für elektrische und mechanische Eigenschaften Verweise auf andere Gerätebeschreibungen gemacht werden können, wie sie z.B. für CAE-Software oder für E-Commerce-Anwendungen spezifiziert werden. Neben dem Vorteil, eine für IO-Link angemessene Lösung sowohl aus technischer wie auch aus wirtschaftlicher Sicht zu bekommen, schafft die Vorgehensweise weltweite Offenheit und Akzeptanz für alle relevanten Kommunikations- und Automatisierungssysteme der Fertigungsautomatisierung. Vereinheitlichung der grundlegenden Funktionen (Profile) Grundsätzlich müssen eine Reihe von Festlegungen für IO-Link-Devices getroffen werden, damit die Bedienung über eine Gerätebeschreibung überhaupt möglich wird. Das sind zunächst einmal die Datentypen. Darüber hinaus sollten aber auch Themen vereinheitlicht werden, die jedes Gerät benötigt. Es ist für den Anwender wohl kaum einzusehen, warum Funktionen für Identifikation & Maintenance, Gültigkeit von Prozesswerten oder zur zentralen Datenhaltung von Device zu Device unterschiedlich sind. Erst dann kommt die Diskussion um Geräteprofile. Hier gibt es durchaus unterschiedliche Motivationen und Auffassungen. Aus meiner Sicht sollte man die Funktionen, die in einer Geräteklasse gemeinsam sind, standardisieren und herstellerspezifische Funktionen hinzufügen. In Letzteren stecken die Differenzierungsvorteile der einzelnen Geräte bzw. Hersteller. Auf die möchte weder der Anwender noch der Hersteller verzichten. Die Basis soll aber gleich sein. Den Ansatz der so genannten \’Profilgeräte\‘, die beliebig austauschbar sind, halte ich persönlich weder für realistisch noch für wünschenswert. Dafür gibt es zu viele Geräteeigenschaften, die über die im Profil beschriebenen hinausgehen und das Verhalten der Maschine nachhaltig verändern können. Mit dieser Begrifflichkeit von Profilen hoffe ich, dass sich möglichst viele Gerätehersteller zusammenfinden, um jeweils für ihre Geräteklassen sinnvolle Festlegungen zu machen. Wichtig in diesem Zusammenhang ist, dass keine Festlegungen für IO-Link-Devices gemacht werden, die direkt auf spezifische Funktionen eines Feldbussystems abzielen und dadurch bei anderen Systemen Probleme in der Abbildung verursachen. So ist z.B. die Abbildung der I&M-Funktionen bei Profibus Sache des IO-Link-Masters, der sich die benötigten Daten geeignet aus dem Device holt und entsprechend zusammenstellt. Sicherung aller Parametrierungen und Gerätetausch ohne Programmiergerät