OPC UA – der zentrale Standard für Industrie 4.0 im Überblick
- Digitalisierung
- Automatisierung
- 13.2.2023
- Lesezeit: {{readingTime}} min
- Artikel teilen
Inhalt
Schon früh im Zuge der Industrialisierung erkannten die wichtigsten Marktteilnehmer, dass es am Ende allen Seiten nutzt, wenn in bestimmten Punkten eher Kooperation statt Konfrontation geübt wird. So entstanden bereits gegen Ende des 19. Jahrhunderts erste Normungsgremien in Europa. Die erste Deutsche Industrie-Norm (DIN1) wurde 1918 erlassen.
Doch bis heute gibt es auch immer widerstrebende Interessen – schon innerhalb der Gremien für Normungen und Standards. Diese Konflikte sorgen dafür, dass oft nur ein Minimalkonsens erzielt werden kann. Dann sind zwar grundlegende Eigenschaften und Verfahren einheitlich geregelt. Jedoch können einzelne Hersteller weitere Funktionen und Optionen jenseits des Standards implementieren.
In der Folge sind Geräte und technische Komponenten unterschiedlicher Hersteller wieder nur zum Teil kompatibel. Wer nicht alles vom gleichen Anbieter bezieht, muss dann auf einen Teil der Funktionalität verzichten oder diese aufwendig selbst herstellen
Babylonische Industriekommunikation
Doch nicht nur die Begrenzung auf einen Minimalkonsens hemmt die Zusammenarbeit. Teils gibt es nicht einmal diesen, sondern konkurrierende Standards. In der Industrie betrifft dies insbesondere die Kommunikation. Für die Übertragung von Daten und Steuerbefehlen zwischen Sensoren, Aktoren und Steuerungen generierten zahlreiche Hersteller jeweils eigene „Standards“, wie etwa AS-i, CANopen, CC-Link, ControlNet, DeviceNet, Interbus und Profibus sowie zahlreiche weitere sogenannte Feldbusse.
Mit dem Voranschreiten des IP-Standards in der Vernetzung hätte diese babylonische Sprachverwirrung überwunden werden können. Doch das Standard-Ethernet genügte nicht den industriellen Anforderungen – und bei der Anpassung an die eigenen Bedürfnisse setzten die Innovationstreiber der industriellen Vernetzung wiederum jeder auf sein eigenes Pferd: Mitsubishi Electric auf CC-Link IE, Beckhoff auf Ethercat, Rockwell auf EtherNet/IP, Schneider Electric auf Modbus TCP, B&R auf Powerlink, Siemens auf Profinet und Bosch Rexroth auf Sercos.
So waren Kunden erneut gezwungen, sich entweder auf die geschlossene Welt eines einzelnen Herstellers einzulassen, oder die Offenheit teuer zu bezahlen. Sie benötigen Gateways, um die jeweils unterschiedlichen Netzwerkstränge mit unterschiedlichen Protokollen zu verbinden.
Von Industrie 3.0 zu Industrie 4.0
Sensor-Messwerte und einfache Steuerbefehle zu übertragen, war damit zwar möglich geworden. Doch mit dem nächsten Innovationssprung traten neue Probleme zutage. Industrie 4.0 zielt darauf ab, zahlreiche Komponenten miteinander zu vernetzen. Die vertikale Orientierung der „Automatisierungspyramide“ wurde aufgebrochen. Nun gibt es sowohl horizontale Verbindungen innerhalb der Pyramide, als auch Querverbindungen zwischen verschiedenen Maschinen, Anlagen und sogar weltweit verteilten Produktionsstandorten.
Ein sinnvoller Datenaustausch ist in diesem Rahmen nur auf Basis konsistenter Datenstandards möglich. Das Fehlen solcher Konventionen war eines der größten Hemmnisse für die Entwicklung von Industrie 4.0, da das Zusammenführen von Daten aus unterschiedlichen Quellen, die sogenannte „Homogenisierung“, einen enormen Programmieraufwand verursachte. Datenformate, Variablenbezeichnungen, Art und Umfang von Metadaten – die Zahl der möglichen Kombinationen ist unüberschaubar, sobald unterschiedliche Anbieterwelten aufeinandertreffen.
Ein zusätzliches Problem: Wie sind die Daten zu interpretieren? Denn auch was gleich „heißt“ (sprich: denselben Variablennamen trägt) und gleich aussieht (nach Datenformat, Wertebereich etc.) muss nicht die gleiche Bedeutung haben. Für die Entwicklung von datenbasierenden Services und Geschäftsmodellen, für maschinenübergreifende Steuerungen von Produktions- und Fertigungsprozessen oder die Auswertung von Daten mittels Künstlicher Intelligenz ist jedoch ein Verständnis der zu verarbeitenden Daten unerlässlich. Denn nur im richtigen Kontext werden aus Daten auch Informationen.
Eine erste Lösung bieten IoT-Plattformen mit umfangreichen Mapping-Services. Die Anbieter haben etliche unterschiedliche Formate analysiert und entsprechende Schnittstellen entwickelt, die es ermöglichen, Daten in ein gemeinsames Zielformat zu übertragen.
Die Alternative besteht darin, maschinenübergreifende Datenkommunikation eigenhändig anzupassen, was enormen manuellen Aufwand bedeutet. Jede Erweiterung des Maschinenparks und jeder Austausch einer Komponente birgt die Gefahr, dass wieder nachgearbeitet werden muss. Dementsprechend werden in solchen Fällen nur die wichtigsten Daten überhaupt berücksichtigt, um den Aufwand zu begrenzen. Damit geht aber ein Teil der Möglichkeiten von Industrie 4.0 verloren.
Zentraler Standard OPC UA
Eine Lösung für diese Probleme bietet die Open Platform Communications Unified Architecture (OPC UA). Dabei handelt es sich nicht um einen Kommunikationsstandard im engeren Sinne. Denn wesentliche Teile von OPC UA setzen erst oberhalb von Layer 7 des OSI-Schichtenmodells auf.
Vielmehr handelt es sich um einen Standard für den Datenaustausch als plattformunabhängige, service-orientierte Architektur (SOA), der nicht nur den Transport von Maschinendaten, wie Regelgrößen, Messwerte, Parameter etc. ermöglicht, sondern auch diese maschinenlesbar semantisch zu beschreiben. Dabei werden nicht nur Betriebsdaten berücksichtigt, sondern auch Spezifikationen und Fähigkeiten einer Maschine.
Auf diese Weise wird die Kommunikation zwischen unterschiedlichen Netzteilnehmern einfacher und effizienter, denn nicht nur die intelligenten Geräte können miteinander verbunden werden, sondern auch einfache Sensoren und Aktoren. Darüber hinaus werden nicht nur „Dinge“ im Rahmen des (Industrial) Internet of Things (IIoT / IoT) adressiert, sondern auch Dienste (Services).
Die OPC-Foundation, die den Standard trägt und weiterentwickelt, stellt folgende wesentliche Vorteile heraus, die in OPC UA verwirklicht wurden:
- Plattformunabhängigkeit: OPC UA kann von einem eingebetteten Mikrocontroller ebenso genutzt werden wie von einer Cloud-basierten Infrastruktur. Ebenso ist OPC UA unabhängig vom Betriebssystem;
- Sicherheit und Zuverlässigkeit: Verschlüsselung, Authentifizierung und Auditing sind enthalten. Die gesamte Entwicklung beruht auf dem Ansatz „Secure by Design“
- Erweiterbarkeit: Die Fähigkeit, neue Funktionen hinzuzufügen, ohne bestehende Anwendungen zu beeinträchtigen. Auf diese Weise hat sich in den vergangenen Jahren der Standard schnell weiterentwickelt;
- Robuste, umfassende Informationsmodellierung: Möglichkeiten zur Definition komplexer Informationen.
Die Entwicklung schreitet immer weiter voran. Eingebunden sind sowohl Hersteller wie Anwender, Forschungsinstitute und unterschiedliche Konsortien, wie Branchenverbände und Normungsgremien.
Als IEC-Norm doppelt geadelt
Vor OPC UA gab es bereits einen Vorläufer, der nicht plattformunabhängig war, genannt OPC Classic. Die Bindung an COM/DCOM hat zwar einen großen Beitrag zur Verbreitung von OPC geleistet, hatte jedoch auch entscheidende Nachteile. Daher hat man sich dazu entschieden, einen eigenen Kommunikationsstack für OPC UA zu entwickeln, welcher COM/DCOM ersetzt. Ein erster Entwurf von OPC UA wurde 2006 veröffentlicht und 2009 erstmals in weiten Teilen aktualisiert. 2016 wurden die Spezifikationen als IEC 62541 normiert. Seitdem hat sich OPC UA als ein De-facto-Standard für die Maschinenkommunikation etabliert.
Die enge Verknüpfung mit Industrie 4.0 beruht unter anderem auf der Konzeption des Referenz-Architektur-Modells Industrie 4.0 (RAMI 4.0). Diese Beschreibung des Industrie-4.0-Konzeptes als dreidimensionales Funktionsmodell ist in IEC PAS 63088 festgehalten. Die darin enthaltenen Funktionen verweisen wiederum auf die entsprechenden IEC-Normen. Als einziger Kommunikationsstandard, der die Anforderungen von RAMI 4.0 erfüllt ist, dort mit IEC 62541 OPC UA enthalten.
OPC UA: Kein Standard unter vielen, sondern zentraler Baustein der Digitalisierung
Wesentliche Eigenschaften von OPC UA
OPC UA ist unabhängig von der Transportmethode. Für unterschiedliche Anwendungsfälle wie Hochleistungsanwendungen oder Web-Browser-Zugriff stehen verschiedene Protokollbindungen zur Verfügung. IP-basierte Kommunikation, drahtlos oder über Industrial-Ethernet-Verkabelungen, WAN- und Cloud-Anbindungen, und sogar Feldbusprotokolle – alles das kann OPC UA als Transportschicht dienen. Für Client-Server-Verbindungen ist ein eigenes TCP-basiertes Binärprotokoll über den IANA-registrierten Port 4840 implementiert.
In Richtung Cloud setzt OPC UA auf gängige Protokolle wie MQTT und AMQP, im Feld werden zudem UDP, RAW Ethernet und Protokolle wie TSN oder 5G für die deterministische Kommunikation unterstützt. Weitere Protokolle wie das UDP-basierte QUIC können nachgerüstet werden, auf Client-Seite sind auch Websockets zulässig.
Der OPC-Standard als Service-Oriented Architecture enthält zum einen ein Server/Client-Modell, das einen Zugriff auf Informationsmodelle mittels Services zugrunde legt. Der objektorientierte Server-Adressraum stellt Metadaten und Objektbeschreibungen zur Verfügung. Objektstrukturen entstehen durch Referenzierung von Objektinstanzen und ihren zugrunde liegenden Typdefinitionen. Diese sind ebenfalls objektorientiert und können durch Vererbung erweitert werden.
Da OPC UA Server sowohl ihre Objektinstanzen als auch die zugehörigen Typobjekte mitführen, können OPC UA Clients im Adressraum eines beliebigen OPC UA Servers navigieren, um alle benötigten Instanz- und Typinformationen zu erhalten. Das gilt auch für Typen, die ihnen bisher unbekannt waren. Dies ermöglicht die Nutzung von Plug&Produce, ohne dass Geräte vorher konfiguriert werden müssten.
Daneben existiert seit wenigen Jahren ein Pub-Sub-Modell zur Verteilung von Daten im Netz. Das „Fire-and-forget“-Modell beruht darauf, dass eine Instanz (in der Regel OPC-UA-Server) Daten „veröffentlicht“ (Publication), die andere Seite (in der Regel OPC-UA-Clients) diese „abonniert“ (Subscription). Die Verbindung erfolgt über eine zwischengeschaltete Instanz, die Message Oriented Middleware. Sie entkoppelt die Herausgeber von den Abonnenten, sodass diese sich nicht kennen müssen. Auf diese Weise wird eine effiziente m-Kommunikation (Viele zu Viele) ermöglicht.
Ein wesentliches Element der OPC-UA-Kommunikation ist das hohe Sicherheitslevel. Das hat sich die OPC-Foundation vom BSI (Bundesamt für Sicherheit in der IT) bestätigen lassen. Integriert sind anerkannte Sicherheitskonzepte und -standards, die auch für die sichere Internetkommunikation verwendet werden, wie SSL, TLS und AES, Benutzer- und Anwendungsauthentifizierung sowie das Signieren von Nachrichten und Datenverschlüsselung.
Branchenspezifische Erweiterungen
Innerhalb unterschiedlicher Industriezweige – Kunststoffhersteller, Textilindustrie, Holzverarbeiter etc. – sind bestimmte Überschneidungen und Konventionen bei den Informationsmodellen zur Beschreibung von Maschinen, ihren Fähigkeiten und den anfallenden Daten üblich. Diese in OPC UA zu integrieren, erhöht den Mehrwert des Standards. Denn zum einen werden branchenspezifische Funktionen nutzbar, zum anderen erhöht sich der Druck, sich dem Standard anzuschließen.
Solche branchenspezifischen Erweiterungen sind im Rahmen von „Companion Specifications“ möglich. Mehr als ein Dutzend solcher Spezifikationen sind bereits verabschiedet, viele weitere sind bereits in Arbeit. Im deutschsprachigen Raum sind beispielsweise zahlreiche Arbeitsgruppen im VDMA mit der Entwicklung der branchenspezifischen Standards betraut. Sie werden wie alle anderen Informationsmodelle gemäß der OPC-UA-Spezifikationen definiert, verpackt und dokumentiert. Damit lassen sie sich sehr einfach den OPC-UA-Servern- und Clients im Netzwerk zur Verfügung stellen.
OPC UA: Kein Standard unter vielen, sondern zentraler Baustein der Digitalisierung
Es ist ein langer Weg vom ehemals isolierten Shop-Floor hin zur vernetzten globalen Produktion, die mittels Cloud-Anwendungen ein zentrales Monitoring und eine einheitliche Steuerung bietet. Der größte Teil der Industrie befindet sich in einem Entwicklungsstadium zwischen diesen beiden Extrempositionen. Doch die Probleme bei der Zusammenführung von Daten, der Entwicklung übergreifender Services und der Nutzung von intelligenten Funktionen sind stets die gleichen.
Der Maschinenbau befindet sich aktuell in einer schwierigen Übergangsphase. Auf der einen Seite steigen die Anforderungen der Kunden. Die verlangen flexiblere und intelligentere Maschinen und Anlagen, die sich einfach rekonfigurieren und über zentrale Anwendungen überwachen und sogar steuern lassen. Die engere Vernetzung bedeutet einen höheren Programmieraufwand, wobei Wiederverwertbarkeit und Skalierbarkeit des jeweiligen Codes nicht gewährleistet sind.
Auf der anderen Seite steht OPC UA als eine universelle Lösung, die eigentlich alle Probleme lösen kann. Doch auch hier schlägt zumindest initial ein hoher Aufwand zu Buche, bis die nötigen Kompetenzen aufgebaut, Tools und Bibliotheken eingerichtet und erste Projekte erfolgreich abgeschlossen sind. Angesichts der Wucht, mit der Branchenvertreter, Branchenverbände und Normungsgremien die Weiterentwicklung und Erweiterung von OPC UA vorantreiben, ist die Investition in entsprechendes Know-how mit Sicherheit gerechtfertigt.
OPC UA ist kein Standard unter vielen, dessen Zukunftsfähigkeit in Zweifel steht. Sondern ein zentraler Baustein für die zunehmende Vernetzung und Digitalisierung der Industrie, der irgendwann zum „Must-have“ jeder Maschine werden wird.
