OPC UA für Machine Vision?

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.

Seiten: 1 2Auf einer Seite lesen

Thematik: Allgemein
Bernecker & Rainer Industrie-Elektronik Ges.m.b.H.
www.ethernet-powerlink.org

Das könnte Sie auch Interessieren

Anzeige

Anzeige

Anzeige

Anzeige

Anzeige

Anzeige

Anzeige