Q&A zur Themenwelt OPC UA

iStock / masterzphotois

Hier finden Sie Antworten auf häufig gestellte Fragen rund um die verschiedenen Themenfelder des Schnittstellenstandards OPC UA.

OPC UA Technologie

OPC UA ist kein Protokoll. OPC UA ist eine Kommunikationsarchitektur, die neben dem Transport auch die Datenmodellierung ermöglicht. Hinsichtlich des Transports von Daten bietet OPC UA ein abstraktes Kommunikationsmodell, das Mappings zu diversen Protokollen zulässt.

Eine vergleichbare Basistechnologie mit einem Durchdringungsgrad, wie ihn OPC UA derzeit bietet, ist nicht erkennbar. Gerade für die Standardisierung ist die Kombination aus Semantik und Implementierung von großem Vorteil. Auch hier gibt es punktuell Marktbegleiter (etwa im amerikanischen Raum, oder Initiativen zur Standardisierung auf ISO-Ebene), welche jedoch sicherlich nicht dieselbe Durchschlagskraft entwickeln.

OPC UA wird bereits in vielen Maschinenbaubereichen erfolgreich angewendet. Bisher allerdings zumeist mit herstellerspezifischen Informationsmodellen. OPC UA Companion Specifications sind daher der Weg, diese Schnittstellen zu vereinheitlichen. So gibt es nun bspw. bereits im Bereich der Kunststoffmaschinen, der Roboter und der Werkzeugmaschinen den erfolgreichen Einsatz von Companion Specifications. Weitere Branchen sind in der Finalisierung ihrer Arbeiten und werden in Kürze erste Produkte auf dem Markt haben.

OPC UA ist von Design aus sehr skalierbar. Das bedeutet, dass sich ein OPC UA Server bereits auf kleinsten eingebetteten Systemen befinden kann. Gleichermaßen kann der Server auf gesamten Maschinen wie auch SCADA- oder MES-Systemen betrieben werden.

OPC UA unterstützt zu diesem Zeitpunkt noch keine deterministische Echtzeit. Seit 2016 wird mit "OPC UA over TSN" in der OPC Foundation an einer echtzeitfähigen Lösung gearbeitet. Ende 2018 wurden erste, funktionsfähige Prototypen vorgestellt.

Companion Specifications (CS)

In OPC UA Companion Specifications werden Informationen für einen bestimmten Anwendungsbereich zum Austausch auf einer Schnittstelle einheitlich definiert. In einer Companion Specification finden sich die Beschreibung des Anwendungsbereichs in Form eines Scopes und die Definition der Informationen in Form von Objekten, Methoden, Variablen, Events und anderen Mechanismen der Technologie OPC UA. Neben dem menschenlesbaren Dokument (pdf) wird die Informationsmodellierung auch in einem maschinenlesbaren Format (xml) dokumentiert.

Es ist sogar notwendig mehrere Spezifikationen in einer Maschine umzusetzen. Denn vielfach bauen die Spezifikation aufeinander auf. Um ein Beispiel zu geben: Um die Companion Specification für Werkzeugmaschinen zu unterstützen, müssen neben der OPC UA Basisspezifikation auch Teile der OPC UA for Device Information Model und die OPC UA for Machinery implementiert sein. Auch eine zunehmende horizontale Integration wird erfordern, dass auf Komponentenebene unterschiedliche CS implementiert sind, deren Signale dann in eine übergeordnete Datenausgabe zusammengeführt werden.

In Companion Specifications werden eine Vielzahl an Objekten, Variablen und Methoden beschrieben. In Typdefinitionen werden diesen OPC UA Elementen sogenannte „Modelling Rules“ zugeordnet. Diese entscheiden darüber, ob bei der Instanziierung eines Typen das jeweilige Element mandatorisch oder optional enthalten ist. Dementsprechend sind nicht alle standardisierten Objekte, Variablen oder Methoden im herstellerspezifischen Informationsmodell auszufüllen. Lediglich solche, die eine mandatorische „Modelling Rule“ besitzen.

Die OPC UA Basistechnologie erlaubt die Formulierung von sogenannten Profiles. Diese setzen sich aus mehreren testbaren Einheiten (Conformance Units) zusammen. Diese ermöglichen das Testen von OPC UA Produkten hinsichtlich ihrer Funktionalität. Profiles sind derzeit allerdings recht selten in Companion Specifications beschrieben. Eine rasche Verbreitung ist dennoch zu erwarten.

Darauf aufbauend ist es eine Kernaufgabe von umati Klarheit und Transparenz zu schaffen, damit Endkunden genau wissen, was sie brauchen um ihre Maschinen einfach anbinden zu können. Die umati Community hat das Ziel diese Herausforderung bereits von Seiten der Maschinenbauer zu lösen. Dafür werden zukünftig z.B. Produktlabels spezifiziert werden, mit denen ein definierter Funktionsumfang nachgewiesen werden kann. (für mehr Informationen: s. „Was ist umati?“)

OPC UA Arbeitskreise im VDMA

Einen Übersichtsartikel über alle bestehenden VDMA-Arbeitskreise gibt es hier:

https://opcua.vdma.org/viewer/-/v2article/render/43354439

Die entsprechenden Ansprechpartner können hier ermittelt werden:

https://opcua.vdma.org/viewer/-/v2article/render/47865665

Die Arbeitskreise des VDMA erarbeiten OPC UA Companion Specifications. In diesen wird beschrieben, welche Daten auf der Schnittstelle ausgetauscht werden. Es geht also um die standardisierte Modellierung von Informationen. Somit werden digitale Inhalte, aber keine physischen Erzeugnisse definiert.

Unter der Abkürzung JWG wird der Begriff Joint Working Group verstanden. Wie der Name bereits vermuten lässt, handelt es sich dabei um eine zusammengesetzte Arbeitsgruppe aus mehreren Parteien. Im Fall der OPC UA Arbeitskreise sind diese Parteien der VDMA und die OPC Foundation. Darüber hinaus können weitere Organisationen, wie beispielsweise EUROMAP, beteiligt sein. Folglich dürfen in der JWG Mitglieder aller beteiligten Organisationen mitarbeiten.

OPC UA for Machinery

Bei OPC UA for Machinery handelt es sich um eine Companion Specification, welche als Basisspezifikation für den gesamten Maschinen- und Anlagenbau vorgesehen ist. Sie enthält Building Blocks zur Abdeckung von allgemeinen Anwendungsfällen. Diese Building Blocks können von anderen branchenspezifischen Companion Specifications oder zur Erweiterung von proprietären Informationsmodellen genutzt werden.

OPC UA for Machinery definiert Building Blocks, die vom gesamten Maschinen- und Anlagenbau verwendet werden können. Diese modularen, harmonisierten Bausteine beschreiben diverse Themen wie die Identifikation, den Zustand oder den Auftrag einer Maschine.

Dies wird in OPC UA mittels AddIns ermöglicht. Damit können mehrfach verwendete Funktionalitäten in üblichen Typdefinitionen beschrieben werden. Über die „HasAddIn“-Referenz können diese Features an jegliche branchen- oder herstellerspezifischen Typdefinitionen angehängt werden. Dies ermöglicht eine einfache Integration der OPC UA for Machinery. Sogar bestehende Companion Specifications können hiermit ohne einen Breaking Change (dem ungültig werden der Vorgängerversion einer CS) die Ergebnisse verwenden.  

Bisweilen veröffentlichte Companion Specifications werden von der OPC UA for Machinery nicht sofort beeinflusst. Es ist allerdings zu erwarten, dass im Zuge einer Überarbeitung eine Integration der OPC UA for Machinery Ergebnisse stattfindet. Seitens der Arbeitsgruppe für die OPC UA for Machinery wird stets darauf geachtet, Breaking Changes zu verhindern (s. „Was sind Building Blocks?“).

Auf den ersten Blick sehen OPC 40001-1 (Machinery) und OPC 10000-100 (Devices) ähnlich aus, was das Thema Identification betrifft. Dieser Eindruck ensteht dadurch, dass OPC UA for Machinery auf OPC UA for Devices aufbaut. 

Es ist das Ziel der OPC UA for Machinery Arbeitsgruppe einen möglichst hohen Grad an Interoperabilität zu erreichen. Nachdem der Use-Case der eindeutigen Identifizierung einer Maschine festgelegt war, wurden veröffentlichte OPC UA Standards betrachtet. Die OPC UA for Devices Spezifikation beschreibt bereits einen Teil zur Identifizierung. Nach Analyse der Machinery-Arbeitsgruppe erfüllte diese nicht vollumfänglich die Anforderungen, konnte jedoch als Ausgangspunkt übernommen werden. Daher verwendet OPC UA for Machinery die Parameter aus OPC UA for Devices und spezifiziert sie weiter. Zum einen wurden Parameter hinzugefügt zum anderen wurden sogenannte ModelingRules geändert, um eine global eindeutige Identifizierung von Maschinen zu ermöglichen. 

Uniform Resource Identifier (URI) sind Identifikatoren, bestehend aus einer Zeichenfolge, die die Identifizierung von abstrakten oder physischen Ressourcen ermöglichen. Diese sind per Definition eindeutig. Im Gegensatz zu einem Globally Unique Identifier (GUID) lässt die URI zu, menschenlesbare Informationen mit einzukodieren.

Das häufig verwendete OPC UA for Devices Information Model beschreibt ein Modell zur Identifizierung mittels URIs. Diese erfüllen die Anforderungen zur eindeutigen Identifizierung, wie sie die OPC UA for Machinery Arbeitsgruppe stellte. Folglich entschied man sich hier dieses Modell zu referenzieren, um die Interoperabilität zu erhöhen.

Ja, der Arbeitskreis OPC UA for Machine Tools hat im Rahmen seiner Erarbeitung eine Referenzimplementierung erstellt. Diese zeigt die Anwendung von OPC UA for Machinery in einem Server. Diese kann mit einem OPC UA Client über folgende URL eingesehen werden:

opc.tcp://opcua.machinetool.app:4840

(Ansprechpartner: Götz Görisch, VDW, g.goerisch@vdw.de)

Ebenso kann sich bei der Anwendung der Companion Specification an dem im Anhang beschriebenen Modell orientiert werden (s. VDMA 40001-1, Annex B)  

Industrielle Bildverarbeitung

Die Arbeitsgruppe der industriellen Bildverarbeitung bewies mit ihrem Demonstrator, dass OPC UA for Machine Vision in der Praxis funktionieren kann. 

Mitgliedsunternehmen des Arbeitskreises liefern bereits seit Mitte 2020 IBV-Systeme mit OPC UA Schnittstellen aus. 

Hersteller industrieller Bildverarbeitungssysteme heben besonders hervor:

Die OPC UA for Machine Vision Spezifikation ist darauf ausgelegt, einen „Transitionspfad“ für die Einführung der neuen Schnittstelle aufzuzeigen. Der Standard definiert erstmals, international durch die BV Community gestützt, wie sich ein IBV System sich nach außen darstellen und verhalten soll.

Hersteller können beispielsweise über ein passendes „Abstraktionslayer“, die Schnittstelle an ihr Bildverarbeitungsframework anpassen. Darauf lassen sich technologieunabhängig neue Scnittstellen schaffen oder bestehende weiterentwickeln. So sollen erste OPC UA Projekte mit bedeutend geringerem Aufwand an bestehende Software angebunden werden können. 

Gleichzeitig ist die OPC UA for Machine Vision kein monolithischer Block. Einzelne Teile der Spezifikation können nach und nach umgesetzt werden. Eine Richtschnur bieten die in der Spezifikation definierten Profiles & Facets.

Die OPC UA for Machine Vision spezifiziert keine Dateninhalte. Deshalb werden auch keine Codierungen von Bilddaten vorgegeben. 

In der BV sind die Formate der Bilddaten eng mit der Sensortechnologie verknüpft. Da die Sensorik sich ständig weiterentwickelt, kommen regelmäßig neue Formate heraus. Generell sollten Bilddaten nicht als „Foto“ verstanden werden. Die Rede ist von abstrakten, 1- bis N-dimensionalen Datensätzen  (Zeilenkamera, Matrixkamera, 3D-Scan, Multi-Spektral-Kamera, Ultraschall etc.). Daher ist es nicht zielführend in einer CS zu definieren, dass „Bilddaten“ als JPG oder PNG zu codieren sind. Diese Überlegung bestärkte die Arbeitsgruppe den „Black-Box“-Ansatz zu verfolgen. 

Wie die Daten („Black-Box“) zu übertragen sind, ist in der OPC UA for Machine Vision Spezifikation beschrieben. Dies wird über den OPC Mechanismus „Temporary File Transfer“ realisiert. Die konkrete Übertragung hingegen ist in der OPC UA Basis-Spezifikation beschrieben (OPC 10000-5).

Anmerkung:

In der OPC UA Basis Spezifikation gibt es einfache „Bildformate“ wie BMP, JPG oder PNG. (OPC 10000-3, Kapitel 8.20- 8.23). Diese Typen können in Ergebnisdaten direkt verwendet werden und jeder OPC Client sollte sie verstehen können. 

Die Arbeitsgruppe prüft hinsichtlich Part 2 der OPC UA for Machine Vision, inwiefern weitere IBV-spezifische Typen benötigt werden. Als Orientierung dienen dabei die Definitionen in GENICAM. Aufgrund der rapiden Entwicklung neuer „Bildformate“, tendiert die Arbeitsgruppe momentan zu einem einfachen „String“ für die Benennung des Bilddatenformats, dessen nähere Bedeutung nicht durch die CS definiert wird.

Die Arbeitsgruppen Robotics und Machine Vision arbeiten bei der Erstellung ihrer Companion Specifications (CS) eng zusammen. Daher werden die grundlegenden Konzepte sehr ähnlich ausfallen.

Das Verbinden beider Systeme ist stark applikationsabhängig.

Ist der Roboter ein Teil (bzw. eine Komponente) des Bildverarbeitungssystems, würde das BV-System einen OPC Client benötigen, der die Robotics CS versteht und darüber mit dem Roboter kommuniziert. Nach außen würde sich das BV-System über einen OPC Server darstellen, der die OPC Vision CS umsetzt. Der Roboter müsse nach außen nicht in Erscheinung treten.

Werden die Rollen getauscht und das BV-System als „End of Arm Tool“ zur Komponente des Roboters gemacht, nutzt der Roboter die OPC UA for Machine Vision CS, um das BV-System zu steuern, welches nach außen nicht in Erscheinung treten muss.

Eine weitere Möglichkeit wäre es, die Systeme BV und Roboter nebeneinander zu betreiben und von einer zentralen PLC aus zu steuern. Dies ist aktuell die häufigste Variante, die in Projekten auftritt. Hier müsste die PLC einen Client für beide CS umsetzen.

Die OPC UA for Machine Vision spezifiert hierzu nicht genau. "Ergebnisdaten" werden generell nicht addressiert. 

Allgemein ist OPC UA flexibel und kann nahezu alles abbilden. Insbesondere ist es protokollunabhängig. Derzeit ist zwar kein Streaming-Protokoll im OPC UA Portfolio, dies kann künftig jedoch erweitert werden. 

Aktuell ist keine öffentliche Referenzimplementierung verfügbar. Dies wird in der Arbeitsgruppe weiter erarbeitet. 

Für die SPS 2019 wurde ein „Proof-of-Conept"-Demonstrator entwickelt, welcher weiterhin auf relevanten Fachmessen zu finden ist. 

OPC UA for Robotics

Beim Zusammenbau von Automatiisierungskomponenten muss oft "ein Versatz" berücksichtigt werden, welcher zumeist "statisch" ist (z.B. Roboter steht auf einer "massiven Tonne", Tool-WechselEinheit zwischen Roboter Flansch und Werkezug). Mit dem Offset Frame können solche "Versätze" beschrieben werden. 
Aus Standardisierungs- und Konzept-Sicht war es sinnvoll das GeoObject-Addin mit einem Mandatory "OffsetFrame" zu definieren und mind. einen weiteren (mandatory) Frame. Falls der Offset nicht vorhanden ist und dementsprechend (0,0,0,0,0,0) gesetz ist, hat er auch keine Auswirkungen. Über die Variablen Constant und FixedBase informiert der Frame darüber, ob er statisch ist oder sich seine Base ändern könnte. Dies ist bei der Umsetzung mit einem Client hilfreich, da "Constant" Frames nur einmal gelesen werden müssen.
GeoObjects basiert auf der Definition von Frames und deren mathematischer Definition und Nutzung wie definiert in Amendment 11 – Spatial Types (OPC 10001-11, Annex G).

Die Singularität bei der Ansteuerung einer Roboterkinematik tritt innerhalb der Bahnplanung und Achstransformation der Robotersteuerung auf und wird dort berücksichtigt.  GeoObjects basiert auf der Definition von Frames und deren mathematischer Definition und Nutzung wie definiert in Amendment 11 – Spatial Types (OPC 10001-11, Annex G)

 

Es galt als Konsens in der Robotics-Arbeitsgruppe, dass diese Referenzen "hierarchischer Natur" sind und haben sie auch dementsprechend modelliert. Laut OPC UA Experten können bei hierarchischen Referenzen sogenannte "Loops" auftreten, allerdings müsse ein OPC UA Client damit umgehen können. In einer Überarbeitung der OPC UA for Robotics Spezifikatoin soll der Hinweis auf "Umgang mit hierarchischen Referenzen in Bezug auf Loops" hinzugefügt werden. 

Anmerkung: 

Auch mit nicht-hierarchischen Referenzen können Loops entstehen.

Die Implementierung ist aktuell in Entwicklung. Die ROS-Version ist noch ungeklärt. 

Unterstützung hierbei liefern OPC UA SDKs je nach Betriebssystem. Diese bieten Interfaces für die Integration von Informationsmodellen. Zur Programmierung bzw. Anbindung des Servers werden entsprechende Klassen erzeugt, gegen die programmiert werden kann. 

Für Robotics ist dies insofern nicht relevant, da keine Schnittstelle (im Informationsmodell)angeboten wird, welche einen Achszugriff erlaubt.
Die FLC Motion Gruppe behandelt derzeit die "heutigen Anforderungen" bzgl. Motion in der Automatisierungsindustrie. Dort ist es eine "grundlegende Anforderung" Antriebe voll synchronisiert (via OPC UA Pub/Sub "via TSN") zu betreiben. 

Ja, erste Mitglieder des Arbeitskreises haben bereits Produkte mit OPC UA Servern inklusive einer Umsetzung der OPC UA for Robotics Spezifikation. 

Part 1 ist eine OPC UA CompanionSpecification mit dem dementsprechenden NodeSet, welche es ermöglicht standardisierte Teile des Robotersystems (incl. Daten/Merkmalen) zu beschreiben.
Part 2..n sind "Platzhalter" für weitere Features, welche die Arbeitsgruppe hinzufügen möchte. Es wäre ebenso möglich Part 1 erweitern, aber die Arbeitsgruppe erachtet die Erweiterungen um "modulare Parts" als verständlicher und transparenter.
Part n könnte dementsprechend die Erweiterung mit GeoObjects sein, Part n+1 eine RemoteControl, usw...

 

Ja, gemeinsam mit der Umati-Community wurde ein Beispielserver entwickelt. Dieser kann mit einem OPC UA Client über folgende URL eingesehen werden:

opc.tcp://robotics.umati.app:4840 

(Ansprechpartner: Suprateek Banerjee, VDMA, suprateek.banerjee@vdma.org)

umati

Die Abkürzung bedeutet „universal machine technology interface“ und steht für das Leistungsversprechen einer interoperablen Produktion. umati bezeichnet eine Marke und ein Label für eine Community, die sich für die Verbreitung der OPC UA-Standards im Maschinen- und Anlagenbau zusammengeschlossen hat. Sie bildet einen Rahmen für gemeinsames Marketing, Öffentlichkeitsarbeit, die Demonstration von Use Cases und die Ansprache von Endkunden. Basis dafür ist die eigentliche OPC UA-Schnittstellenstandardisierung in vielfältigen Zweigen des Maschinen- und Anlagenbaus. 

Nein, OPC UA for Machinery wird die Basis Companion Spec für den Maschinen und Anlagenbau. umati hingegen ist kein Standard, sondern die Community aus Herstellern von Maschinen und Software, um die gemeinsam erarbeiteten Standards gleichförmig zur Anwendung zu bringen. Gleichzeitig sorgt umati für die Sichtbarkeit im Markt und einfachere Ansprache von Endkunden.

Industrie 4.0-Umfeld

Der VDMA arbeitet mit anderen Organisationen zusammen. Der Hauptfokus liegt darin, die Standards in die Umsetzung zu bringen und für den Endkunden nutzbar zu machen. Dafür werden mit der umati Community alle Stakeholder vernetzt, um das Plug and Play Versprechen für den Kunden einzulösen.