Beim Besuch von IFM in Kressbronn, sprach Frank Nolte (links) mit Joachim Uffelmann, Vice President Technical Management von IFM Ecomatic und Sprecher der IO-Link Steering Committes über die Entwicklungen der offenen Punkt-zu-Punkt-Verbindung. – Bild: TeDo Verlag GmbH 
Bild: ifm electronic gmbh 
Bild: ifm electronic gmbh
Herr Uffelmann, was steckt hinter der IO-Link-Strategie von IFM?
Joachim Uffelmann: Die Kernidee ist denkbar einfach: Wir wollen möglichst alle Geräte, bei denen es technisch sinnvoll ist, mit einer IO-Link-Schnittstelle ausstatten – und zwar ausschließlich mit dieser. Das bringt uns zwei Vorteile mit einer Entscheidung. Erstens erreichen wir über die verfügbaren Master und Gateways nahezu jedes gängige Feldbussystem, ohne für jeden Bus ein eigenes Gerät entwickeln zu müssen. Zweitens können wir unsere gesamte Entwicklungskapazität auf das konzentrieren, was den Kunden wirklich interessiert: die Messaufgabe selbst, den Sensor oder den Aktor. Die Kommunikation im Hintergrund ist dabei nur das Transportmittel – ob das Bit gelb oder grün übertragen wird, dafür zahlt uns kein Anwender Geld.
Der zweite Pfeiler dieser Strategie ist interne Standardisierung. Wir sind in verschiedene Unternehmensbereiche aufgeteilt, und trotzdem soll ein Techniker, der fünf IFM-Sensoren aus unterschiedlichen Sparten vor sich hat, überall das gleiche Bedienkonzept vorfinden. Schaltpunkt ist Schaltpunkt, Hysterese ist Hysterese – das klingt trivial, macht aber auf der Baustelle, wo die Bedienungsanleitung als Erstes beiseitegelegt wird, den entscheidenden Unterschied.
Wo hört das auf – gibt es Sensor-typen, für die IO-Link nicht passt?
Ja, das muss man ehrlich einschränken. Eine 3D-Kamera, die Bilder überträgt, braucht eine leistungsfähigere Hauptschnittstelle. IO-Link war und ist nicht für die Übertragung großer Datenmengen ausgelegt. Was wir uns überlegen: Könnte man bei einer solchen Kamera eine zusätzliche IO-Link-Schnittstelle vorsehen, die ausschließlich das Ergebnis der Bildverarbeitung – Muster erkannt, ja oder nein – überträgt? Das wäre denkbar. Aber Bildübertragung über IO-Link macht keinen Sinn.
IO-Link ist schon länger am Markt und wächst. Trotzdem heben bei Veranstaltungen oft nur wenige Teilnehmer die Hand, wenn man fragt, wer es tatsächlich einsetzt. Woran liegt das?
Das beschäftigt mich auch. Das Wachstum ist objektiv gut, aber wir erreichen offensichtlich nicht alle. Eine Beobachtung meiner Marketing-Kollegen: Auf Messen wie der Automatica in München und den AAAs verteilt in Deutschland, die eine völlig andere Besucherstruktur haben als die SPS in Nürnberg, kommen Leute, die ein konkretes Problem lösen müssen. Die kennen vielleicht den Begriff IO-Link, haben ihn aber nie angewendet, weil es in ihrer Firma schlicht kein strategisches Thema ist. Das heißt: Wir müssen IO-Link von unten in die Unternehmen tragen, direkt zu den Anwendern, nicht nur auf den großen Plattformen.
Ein weiteres Hemmnis ist der Vergleich mit der klassischen 4…20mA-Schnittstelle, bei dem oft das Argument kommt: „Das war immer so und ist viel einfacher“. Dabei lässt es sich gut entkräften. Ein kaputter Temperatursensor mit analoger Schnittstelle? Da klemmt der Instandhalter im schlimmsten Fall einen Widerstand rein, damit die Anlage weiterläuft, und irgendwann crasht es richtig. Mit IO-Link verhindert die Geräteidentifikation genau das: Das System erkennt, ob der richtige Sensor eingebaut ist. Das klingt nach einer Kleinigkeit, ist aber organisatorisch ein erheblicher Vorteil. Im Bereich der Profilierung kann IO-Link noch nicht ganz mit der 4…20mA-Technologie mithalten. Solange Geräteprofile noch Hersteller-IDs beinhalten, ist der Tausch eines Sensors gegen ein Fremdgerät nicht ganz so reibungslos wie bei der analogen Schnittstelle. Aber daran arbeiten wir. Wobei auch der Tausch eines Sensors mit analoger Schnittstelle nicht immer völlig reibungslos verläuft, denn im Detail gibt es auch hierbei Unterschiede zwischen ähnlichen Sensoren verschiedener Hersteller.
Stichwort Profile: Das Smart Sensor Profile ist in der zweiten Edition erschienen. Was kommt als Nächstes?
Wir haben gelernt. Das Smart Sensor Profile war ein wichtiger erster Schritt, aber wir haben im Nachhinein zu viele Varianten und Ausprägungen zugelassen – schmale Prozessdaten, breite Prozessdaten, herstellerspezifische Ergänzungen. Das macht die Implementierung aufwendiger, als es sein müsste. Der nächste Schritt ist das Smart Device Profile, das die Daten stärker standardisiert, aber noch eine Hersteller-ID enthält. Daneben laufen gerade auch das Smart Power Profile und das Smart Indicator Profile in der Ausarbeitung.
Das eigentliche Ziel sind jedoch Applikationsprofile: vollständig standardisierte Datenbeschreibungen für bestimmte Geräteklassen, sodass ein Drucksensor von IFM und einer von einem anderen Hersteller bei 0bar exakt den gleichen Prozesswert liefern. Ein Gespräch mit Kollegen aus der VW-Instandhaltung hat mir gezeigt, wie relevant das ist: Wenn ein OEM einen Anlagenteil für Audi und einen baugleichen für VW liefert, aber unterschiedliche Sensorik vorgeschrieben ist, muss das SPS-Programm angepasst werden – und das will niemand. Mit einem sauberen Applikationsprofil entfällt das. Bis dahin ist es aber noch ein Weg von zwei bis drei Jahren, denn die Diskussionen in der Community sind intensiv. Jeder Hersteller hat Angst, sich durch zu starke Standardisierung austauschbar zu machen. Meine persönliche Erfahrung sagt: Diese Angst ist weitgehend unbegründet. Ein Kunde, der IFM-Sensoren einsetzt, wechselt nicht, weil die Parameter einheitlich heißen.
Kommen wir zu IO-Link Safety. Das hat die Community mehrfach angekündigt. Produkte gibt es bisher jedoch noch nicht so viele.
Die Notwendigkeit, IO-Link safety-fähig zu machen, war spätestens 2012 klar – der Markt hat das verlangt. Der erste Gedanke war naheliegend: Man nimmt ein bereits zertifiziertes, sicherheitsgerichtetes Protokoll vom Markt und baut es auf IO-Link auf. Dann haben wir festgestellt, dass einzelne Hersteller bei bestimmten Protokollen den Zugang zu den notwendigen Chipsätzen nicht bekommen – wegen Wettbewerbskonflikten. Das hat uns gezwungen, ein eigenes sicherheitsgerichtetes Protokoll zu entwickeln, das auf dem Standard-IO-Link-Protokoll aufsetzt und es um einen Safety-Frame erweitert, rückwärtskompatibel über den bekannten OSSD-Ausgang.
Das klingt schlanker, als es war. Das Protokoll zu spezifizieren war der einfache Teil. Ein sicherheitsgerichtetes Parametrierwerkzeug zu entwickeln, das Datensätze im Gerät und im Master so hinterlegt und bei jedem Anlauf auf Korrektheit prüft, ist erheblicher Aufwand. Dazu kommt die Zertifizierung – der TÜV Süd ist heute unser auditiertes Labor für IO-Link Safety-Kommunikation. Das hat gedauert. Wir haben mehrfach Prototypen auf Messen gezeigt, jedoch gab es noch keine Serienartikel, was innerhalb der Community und auch von mir selbst sehr kritisch gesehen wird. Somit waren wir in Zugzwang, serienreife Artikel an den Markt zu bringen. Jetzt aber sind Testtools und Tooling fertig, und auf der SPS im vergangenen Jahr wurden die ersten serienreifen Fremdprodukte präsentiert.
Was IFM selbst angeht: Wir werden noch in diesem Jahr einen Safety-Master auf den Markt bringen. Gerätetechnisch sind wir Safety bislang konservativ angegangen. Wir haben ein paar induktive Sensoren und Zuhaltungen. Das war eine unternehmerische Entscheidung, aber der Markt macht jetzt deutlich, dass wir das ändern müssen. Und wir sind dabei das zu tun.
IO-Link Wireless – gut spezifiziert, aber kaum präsent. Woran liegt es?
Die Spezifikation ist tatsächlich sehr sauber ausgearbeitet. Das grundlegende Problem ist aber: Wireless kommt nur in Frage, wenn wirklich keine Leitung gelegt werden kann. Und wenn man schon kabellos überträgt, stellt sich sofort die nächste Frage: Warum nicht auch die Energieversorgung kabellos? Dann wird der Aufwand deutlich größer. Wir haben mit unserem IO-Key erste Erfahrungen gesammelt, aber wir haben noch nicht alle Anwendungen gesehen, für die sich Wireless wirklich eignet. Der Markt wird das zeigen.
Was erwarten Sie in den nächsten Jahren vom IO-Link-Ökosystem?
Konkret: Unsere Drehzahlwächter-Familie DW3000 (DW3003/DD3003/DD3005) ist IO-Link-fähig, die Device Description ist seit der Hannover Messe verfügbar. Den Safety-Master erwarten wir 2027. Und wir sehen zunehmend Anwendungsfelder, die IO-Link bislang wenig im Blick hatte – Food & Beverage und die Windenergie, um zwei zu nennen. Das sind Bereiche mit spezifischen Anforderungen an Robustheit und Diagnose, in denen IO-Link seine Stärken ausspielen kann. Auch Fernzugriffe bis zum Endgerät in der Windenergie ist mittlerweile ein neuer Trend. Die eigentliche Arbeit liegt aber in der Community: Standardisierung konsequent voranzutreiben, ohne den Mut zu verlieren, auch Dinge loszulassen.
