OPC UA für Machine Vision?
Expertenrunde SPS und Bildverarbeitung
Bereits 2014 wurde auf der SPS IPC Drives über das Thema Bildverarbeitung und SPS diskutiert und was dazu notwendig sei, damit beide Welten zusammen wachsen (s. inVision 1/15, S.23ff). Auf der SPS IPC Drives 2015 hat inVISION dann nochmals auf dem VDMA-Forum nachgefragt, wie es inzwischen mit der Beziehung beider Technologien aussieht, und wie eine Kommunikation zwischen den Welten stattfinden könnte. Dabei kam es zu interessanten Ausblicken über die gemeinsame Zukunft. Stark im Fokus beider Seiten: OPC UA.
Warum sind die Welten Bildverarbeitung und Steuerungen immer noch getrennt?
Gehlen: Anfang der 90er Jahre waren die Anfänge der Bildverarbeitung. In dieser Zeit war die Rechenleistung der begrenzende Faktor für die Bildverarbeitung und eine SPS konnte diese Leistung nicht bereitstellen. Zudem war es die Zeit der Analogtechnik – Bilder mussten effizient zu einem Rechner übertragen und digitalisiert werden. Bis vor fünf Jahren haben uns diese Themen geprägt, sodass von Seiten der Bildverarbeitungshersteller eine SPS ausschließlich als Bindeglied für die Automatisierung wichtig war.
Schönegger: Ich glaube, dass beide Welten gar nicht so weit auseinander liegen, wie es den Eindruck erweckt. Wir haben z.B. bereits seit einigen Jahren Lösungen geschaffen, die es möglich machen, alles aus einer Hand zu bekommen. Ob dies bedeutet, dass alles auf derselben Rechnerarchitektur läuft, spielt erst einmal keine Rolle. Was zählt, ist Usability und Integration.
Munkelt: Hardware ist ein wichtiger Punkt, weil wir vor ein paar Jahren noch die Situation hatten, dass wenig Rechenpower auf der SPS-Seite gefordert war, aber viel auf Seiten der Bildverarbeitung. Heute haben wir Hardware, die wesentlich kostengünstiger ist, genügend Rechenpower für die Bildverarbeitung bereitstellt und zudem genügend Platz für die SPSler lässt.
Hoppe: Also ich glaube, dass Steuerungshersteller inzwischen Bildverarbeitung in die SPS integriert haben bzw. auf dem Weg dorthin sind. Letztlich reden wir irgendwann über funktionelle Softwaremodule, also Funktionalitäten, die in Hardware gegossen, extern laufen oder in einer SPS integriert sind. Wir kommen dann aber relativ zügig auf Schnittstellenthemen und wie man beide Seiten mit wenig Aufwand miteinander verheiraten kann. Es gibt heute bereits intelligente Kameras, die man aus einer SPS aufrufen kann, diese eine Bildauswertung machen und das Ergebnis dann in die SPS zurückschicken.
Schönegger: Das Problem liegt mehr in der Software, als in der Rechenarchitektur. Wir haben schon seit Jahren die Möglichkeiten, selbst in vermeidlich physikalisch kleinen SPSen Rechenpower zu integrieren, aber der Schlüssel ist die Softwareintegration.
Wie viel Ahnung muss der heutige SPS-Programmierer von Bildverarbeitung haben?
Hoppe: Ich habe in der Vergangenheit bereits selber ein Projekt betreut, wo eine Firma eine intelligente Kamera hergestellt hat, in die man OPC UA integriert hat. Aus der Steuerung heraus konnte man dann über einen genormten PLC Open OPC UA Client-Funktionsbaustein die Kamerafunktionalität abrufen, d.h. einen standardisierten Aufruf über ein standardisiertes Protokoll in eine intelligente Kamera gab es schon, er muss nur noch semantisch standardisiert werden. Ein SPS-Programmierer, der diese Funktionalität aufruft, muss daher von der Kamera relativ wenig wissen. Er muss nur wissen, wie er einen Funktionsbaustein aufruft und welche Parameter er zurück bekommt. Die Details, wie die Kamera das intern macht, muss er nicht verstehen.
Schönegger: Die klassischen Automatisierer sind das Arbeiten mit Funktionsblöcken und einfachen PLC Open-Bausteinen gewohnt. Was ein Problem darstellt, ist die eigentliche Bildverarbeitungsapplikation: Das, was man messen, prüfen oder auswerten will, ist heute noch bei vielen Bildverarbeitungssystemen ein sehr komplexer Prozess, der ein komplexes Know-how erfordert und sehr oft das Hinzuziehen von Systemintegratoren benötigt.
Gehlen: Nehmen wir z.B. einen Barcode-Leser. Dies ist ein Sensor, der das Bild eines Codes liest und in Textzeichen wandelt. Dieser Sensor ist ein integriertes Bildverarbeitungssystem, dass weiterhin über Schnittstellen mit einer SPS kommuniziert. Auf der anderen Seite haben wir aber auch hochkomplexe Systeme, wie Druckbildkontrollen oder Robot-Vision-Anwendungen, die auf einer Sensor- oder SPS-Ebene nicht mehr umsetzbar sind.
Noffz: Da die Rechenleistungen stark gestiegen sind, sind wir inzwischen in der Lage Dinge zu machen, für die man früher große Systeme brauchte. Dies kann jetzt bereits auf relativ kompakten Kameras erfolgen, die dank Embedded Vision eine erheblichere Rechenleistung haben. Allerdings brauchen wir für die Automatisierer eine Software und Ansteuerung mit einfacher Bedienbarkeit.
Schönegger: Man kann heute einfache Dinge bereits sehr einfach umsetzen, aber für komplexe Anwendungen braucht man Spezialisten? Dem kann ich nicht zustimmen. Man muss die Usability der Systeme verbessern und Ziel muss dabei sein, 100% der Bildverarbeitungsanwendungen zu lösen. Ziel muss es aber auch sein, komplexe Themen beherrschbar zu machen. Da stehen auch die Steuerungshersteller in der Verantwortung, ihren Kunden die Bildverantwortung innerhalb ihrer Systemlösungen zugänglich zu machen. Das dies möglich ist, zeigt die erfolgreiche Integration der Robotersteuerung in die Maschinensteuerung. Man kann mittlerweile mit einfachsten Methoden aus einer Steuerung heraus einen Roboter bedienen und mit einer Bildverarbeitung soll das nicht funktionieren?
Hoppe: Vor 20 Jahren gab es noch für jede Funktionalität eine eigene Hardware: Den Controller für die Achsfunktionalität, die SPS für die Logik, den Visualisierungs-PC und jeder Roboter hatte seine eigene Steuerung. Diese ganzen Funktionalitäten sind mittlerweile in die SPS gewandert. Heute brauchen sie zwar weiterhin einen Motion-Spezialisten, der das letzte Optimum aus dem jeweiligen Profil heraus holt, aber die Funktionalität wird in der SPS gerechnet. Warum soll dann nicht auch die Bildverarbeitung in eine SPS rein wandern?
Munkelt: Sofern man alles in einen billigen ´Block´ bekommt, bei dem ein Bild reinkommt und hinten ein String raus, ist alles gut. Aber so ist die Wirklichkeit nicht. Es gibt kein System, wo Sie ein Bild einlesen und dann für Sie analysiert wird, welche Schriftzeichen in dem Bild gelesen worden sind. Somit müssen Sie das Bild irgendwie vor-verarbeiten. Diese beschreibende Tätigkeit muss der Automatisierer machen. Die Bildverarbeitung hat es leider noch nicht geschafft, Systeme so zu vereinfachen, dass deren Usability einfach genug ist. Wir müssen zukünftig von der Usability in der Lage sein, das so zu präsentieren, dass es intuitiv zu bedienen ist. Sie haben alle für ihr Smartphone keine Schulung gehabt oder ein Handbuch gelesen. Genau dahin müssen wir kommen, alles so einfach zu machen, wie eine App auf ihrem Smartphone.
Noffz: Ein Schlüssel in der Vereinfachung der Systeme ist es, diese in verschiedene Funktionseinheiten zu zerlegen. Damit bekomme ich immer einfachere Funktionen in meinen Devices. Dies sehen wir auch in der Bildverarbeitung, weil man immer mehr in den einzelnen Recheneinheiten machen kann. Wir haben uns – getragen vom VDMA IBV – bereits damit auseinandergesetzt, was dies für die Standards in der Bildverarbeitung bedeutet, und sind zu dem Schluss gekommen, dass es drauf ankommt, die Softwaresichtweisen zu vereinheitlichen. Wir brauchen mehr gemeinsame Standards, denn je mehr wir die Systeme kapseln, um so näher kommen wir an die SPS.
Wie hilft OPC UA bei der Verbindung beider Welten?
Hoppe: Das geht heute tatsächlich nur für intelligente Kamerasysteme, die eine eigenständige Auswertefunktionalität haben. Wenn die Systeme eine UA-Schale nach außen anbieten, könnten das die Steuerungshersteller bereits aufrufen. Was nicht geht ist, dass wir Kamerasysteme haben, die Bilder über OPC UA streamen. Aber der eigentliche Transport-Layer ist erweiterbar. Heute werden die Daten noch per TCP und HTTP verteilt, aber aktuell arbeitet die OPC Foundation daran sogenannte Publisher Subscriber Datenmechanismen zur Verfügung zu stellen, damit zukünftig Daten per UDT-Streaming verteilt werden. Also Daten aus einer Steuerung dann, z.B. über einen integrierten UA-Server, im Netzwerk an viele Teilnehmer per Broadcast identisch verteilen. Diesen Basismechanismus wollen wir auf der Hannover Messe 2016 erstmals zeigen. Ziel ist es, OPC UA mit Echtzeitfunktionalität zu erweitern, d.h. OPC UA mit harter Echtzeit basierend auf TSN IEEE. Dazu müssen wir aber erst unsere Hausaufgabe machen. Dann haben wir die Voraussetzungen, um Kamerabilder zu streamen, so dass die Auswertesoftware dann auf einer SPS oder einem anderen intelligenten Gerät läuft. Das wird aber noch dauern.
Gehlen: Der Schlüssel, dass dies funktioniert, ist die Semantik. Wenn man unterschiedliche Bildverarbeitungsanwendungen betrachtet, gibt es durchaus solche, bei der eine standardisierte Kommunikation und Semantik ableitbar ist. Ein gutes Beispiel ist die optische Identifikation. Aber es gibt andere Beispiele, wie eine Druckbildkontrolle, bei der eine herstellerübergreifende Beschreibung von Fehlern schwierig ist. Wie schaffen wir es, Klassen von Problemen so zu strukturieren, dass sich diese Vereinheitlichung lohnt. Vor zehn Jahren war ich aktiv im Bereich der Gesichtserkennung. Wir haben damals mit anderen Unternehmen einen Standard definiert, Gesichtsbilder so zu speichern, dass diese mit unterschiedlichsten Geräten weltweit lesbar wurden. Das Ergebnis war ein erweitertes JPG-Datenformat mit definierten Kompressionsfaktoren. Wie schaffen wir es auch in der Automatisierung, solche Use-Cases zu definieren, dass sich eine semantische Schnittstelle lohnt.
Schönegger: Für die Produktivität von Produktionsanlagen ist eine reibungslose Kommunikation zwischen den einzelnen Teilsystemen und Komponenten entscheidend. Dabei ist es Maschinen- und Anlagenbauern sehr wichtig, dass ihre Möglichkeiten nicht durch proprietäre Lösungen eingeschränkt werden. OPC UA bietet sich für die Kommunikation von der Feldebene bis zu ERP-Systemen als ideale Ergänzung zu Powerlink an. Zukünftig kann OPC UA auch vollständig in das Powerlink-Protokoll integriert werden. Damit entfallen sämtliche Schnittstellen.
Noffz: Wir sehen als Bildverarbeiter OPC UA nicht nur auf der Ebene oberhalb der Devices, sondern als Möglichkeit, verschiedene Devices zu integrieren. Auch auf der semantischen Ebene, nicht unbedingt auf der Ebene der Bildübertragung. Wir sehen das als Vorteil in der Integration von Bildverarbeitungs-Devices in komplexere Systeme.
Hoppe: Wenn ich hochdynamische Applikationen habe, mit einer SPS die im µs-Takt läuft und ich muss einen getakteten Zyklus deterministisch abarbeiten, d.h. SPS-Logik, Kameraaufnahme, Bild bekommen und auswerten sowie dann Entscheidungen treffen, geht das auch weiterhin nur über dedizidierte Feldbussysteme, wie Ethercat, Powerlink, Profinet, usw. Deshalb wird es auch zukünftig hochdynamische Kameras geben, die diese Feldbusstandards unterstützen. Aber auch diese Kamerasysteme benötigen eine Konfigurationsschnittstelle, um auf Informationen von außerhalb zugreifen zu können. Die Kameras wollen vielleicht wissen: Wie viele Aufnahmen habe ich gemacht und ihre Daten an irgendwelche Cloud- oder Condition-Monitoring-Systeme weiterleiten. Dort sind dann nicht µs-Performances die Frage, sondern die Schnittstellenproblematik.
In der Bildverarbeitung gibt es neben dem GeniCam-Standard, bei dem es um die Standardisierung von Kameraparametern geht, auch standardisierte Interfaces wie z.B. GigE Vision usw. Wird zukünftig neben diesen Kamera-Standards, die sich um Bits und Pixel kümmern, OPC UA für die größere Semantik zuständig sein?
Hoppe: Aus heutiger Sicht ja, da OPC UA Informationsmodelle transportiert und nicht ein auf Bits und Byts optimiertes Protokoll ist. Dennoch haben sich die Steuerungshersteller in einer Arbeitsgruppe zusammen getan, obwohl es proprietäre Feldbusse gibt, denn sie brauchen auch eine horizontale Kommunikation zwischen den Steuerungen über OPC UA, die nicht unbedingt echtzeitfähig sein muss. Der Vorteil ist, dass die Steuerungshersteller jetzt nicht mehr aus einer Steuerung mit Protokoll A die Daten herausholen, konvertieren und mit einem anderen Protokoll wieder herunterschicken müssen. Dadurch ergeben sich Vorteile in der Performance und eine Reduzierung des Engineering-Aufwands.
Schönegger: OPC UA wird die Feldbusse nicht verdrängen, dafür wurde es aber auch nicht gemacht. Es ist ein IT-Standard, der es geschafft hat, die gesamte Fabrik zu durchdringen, über alle Feldbusse hinweg. Egal, ob wir von der Feldebene mit einer OPC-UA-Semantik sprechen oder über den mittleren Bereich der Steuerungssysteme oder ob wir irgendwann auch über dedizierte Vision-Interfaces sprechen. Was wirklich einen Nutzen für den Anwender bringen wird, ist eine einheitliche Semantik mittels OPC UA über alle physikalischen Layer und Feldbusse hinweg.
Wie sehen die Hausaufgaben für die Bildverarbeitung aus?
Noffz: Die Bildverarbeitung hat eine semantische Definition, an der wir bereits seit Jahren sitzen. Wir haben ausgefeilte Software-Standards, die sehr genau Bildaufbau, Parametrierung, Erkennung von Kameras, Einbindung in Systeme usw. beschreiben. Was wir machen müssen, ist dies alles in einer Verbindung zu OPC UA zu sehen. Das hätte den Vorteil, dass wir auf der semantischen Ebene eine ganz natürliche Verbindung zwischen der Bildverarbeitung und der SPS-Welt über OPC UA hätten. Kameras wären programmierbar über OPC UA und gleichzeitig auch die SPS. Unsere Hausaufgabe ist es, dass wir in der Bildverarbeitung diese Semantik bisher im wesentlichen nur für einfache 2D-Bilder machen, wir aber zunehmend eine komplexere Welt bekommen. Wir haben 3D-Anwendungen und müssen diese in unsere Standardisierungen und semantische Beschreibung integrieren, was bereits passiert. Wie kann man aber diese Komplexität in den Griff bekommen? Wir schauen uns die wichtigsten Anwendungen – auch getrieben von Kundenseite – an und sagen: Hier ist Interesse und hier müssen wir standardisieren. Wir machen das alles also Schritt für Schritt und versuchen die Bildverarbeitung immer mehr in verschiedene Anwendungen und Messaufgaben zu erweitern. Mit OPC UA hat man eine Klammer, mit der diese Dinge eben nicht nur für die Bildverarbeitung, sondern auch der gesamten Fabrikautomation, zugänglich sind.
Hoppe: Viele Gerätehersteller haben Sorgen, wenn alles über OPC UA standardisiert wird, hätten sie kein Alleinstellungsmerkmal mehr. Wenn man sich aber auf bestimmte Teilsemantiken einigt, heißt das nicht, dass Kamera A oder B parallel nicht noch zusätzliche Funktionalitäten anbietet kann. So haben z.B. die RFID-Hersteller Standardfunktionalitäten, wie man eine Information in einen RFID-Tag reinschreibt bzw. ausliest standardisiert, aber trotzdem haben ihre Geräte noch spezielle Funktionalitäten, die auch per OPC UA abgreifbar sind.
Munkelt: Ich hatte immer diese Vorstellung, wenn ich mit OPC UA arbeite, kann ich sowohl oberhalb von den 2µs liegen als auch in den 2µs-Takt. Aber Sie haben eben eine Trennung vollzogen, wo OPC UA hingehört: nämlich oberhalb der SPS. Aus der Sicht der Bildverarbeitung ist es so, dass viele unserer Kunden aber z.B. Positionsbestimmungen machen, die in 0,5µs ablaufen. Wenn Sie das nicht schaffen, brauchen sie gar nicht erst anzutreten. Ich möchte aber OPC UA nutzen, um in meiner Entwicklung entsprechend schlank sein zu können.
Hoppe: Nach heutigem Stand geht das noch nicht mit OPC UA. Zwar wächst OPC UA weiter runter in den Sensor – der kleinste UA-Server ist derzeit ca.10kByte und kann Sensorsignale liefern – aber eben nicht deterministisch im Echtzeitmodus. Wenn Sie einen super synchronisierten Zyklus benötigen, wie z.B. im Tabak-Maschinenbereich – bei dem eine Maschine 20.000 Zigaretten/min herstellt – dann brauchen Sie Aufnahmen und Sensorik, die super schnell ausgewertet werden, um die fehlerhafte Zigarette auszuschleusen. Was sie dagegen gerne hätten -eine Kamera die in wenigen Mikrosekunden Logik, Aufnahmen und Auswertung macht, geht nach heutigem Stand mit OPC UA noch nicht. Wir glauben aber, dass die Erweiterung mit OPC UA auf Publisher Subscriber und dann später auch mit TSN, das Thema Echtzeit zumindest ein Stück näher bringt.
Fanuc lässt seit Jahren Roboter-Steuerung und Bildverarbeitung auf dem gleichen Controller laufen. Wieso geht das heute noch nicht bei einer klassischen SPS?
Schönegger: Das Thema Robotik ist sicher ein ganz zentraler Einsatzbereich für die Bildverarbeitung. Dort hat der Markt auch den größten Handlungsbedarf, wobei Hersteller wie B&R zum Beispiel bereits über einen großen Erfahrungsschatz beim Einsatz integrierter Bildverarbeitungssysteme an den Steuerungen verfügen. Wenn wir das Beispiel Fanuc nehmen und fragen: Warum ist das nicht durchgängig bei allen Anbietern so, muss ich leider sagen: Fanuc hat es einfach. Auf der einen Seite ist er ein Roboter-Steuerungshersteller, dann ist er Maschinenbauer, sein eigener Kunde und letztendlich auch sein eigener Systemintegrator. Wenn man die gesamte Wertschöpfungskette bis zur finalen Applikation selbst im Griff hat, tut man sich deutlich leichter, die zugehörigen Bildverarbeitungslösungen zu entwickeln. Wir als Steuerungshersteller befinden uns da natürlich in einer anderen Konstellation: Wir wissen nicht, wer morgen unsere Kunden sind oder welche Maschinen unsere Bestandskunden übermorgen bauen. Der Kunde weiß wiederum nicht, welcher Systemintegrator seine Maschine in ein Produktionswerk integrieren wird. Das macht es deutlich komplexer, als die Situation, die Fanuc vorfindet.
Hoppe: Also ich finde nicht, dass die Robotik der Automatisierung voraus ist. Jeder Roboterhersteller hat sein eigenes API für seine Bedienoberfläche oder Teach-Elemente. Also von Standardisierung und das alles zu vereinheitlichen, habe ich bisher noch nichts mitbekommen.
Munkelt: Letztendlich bereichert Standardisierung den Markt und lässt dennoch Platz für genügend Mitspieler. Im Gegenteil, sie öffnet den Markt für Kunden, die wir bislang noch nicht hatten, und schafft so einen Mehrwert. Es ist kein Zufall, dass Standardisierung häufig aus Europa getrieben wird, weil wir uns besser darauf verstehen, uns gemeinsam an einen Tisch zu setzen und miteinander zu reden, und zwar solange bis wir ein Stückchen weiter gekommen sind, und eine Lösungen haben, die einen Mehrwert für unsere Kunden bietet.
Noffz: Über Standardisierung werden Innovationspotenziale freigesetzt. Man muss sich nicht mehr um banale Dinge, wie z.B. Parameter-Übertragung usw. kümmern, sondern kann sich mit neuen Ideen für die Bildverarbeitung beschäftigen.
Gehlen: Im Sinne einer klaren Migration sind wir alle – Bildverarbeitungs- und Steuerungshersteller – gut beraten, an einem Strang zu ziehen.
Hoppe: Die ganzen Steuerungshersteller haben bei OPC UA die Hand gehoben, die MES-Hersteller haben es getan und mittlerweile tun es auch die ersten Cloud-Anbieter. Es wäre idiotisch, wenn sich dann ausgerechnet die Bildverarbeitung etwas anderes ausdenkt.
