Was ist OPC UA? Die wichtigsten Begriffe im Überblick

1. OPC Server

Der OPC Server ist die Basis der OPC Kommunikation. Dieser ist eine Software, welche den OPC Standard implementiert und damit die genormten OPC Schnittstellen nach außen bereitstellt. Im Inneren ist das proprietäre Kommunikationsprotokoll zur Steuerung des Herstellers umgesetzt. OPC Server werden von verschiedenen Parteien zur Verfügung gestellt.

OPC Server vom Hardware-Hersteller

Die Grundidee von OPC ist, dass der Hersteller der Hardware für sein System einen OPC Server liefert und damit den standardisierten Zugriff erlaubt. Der OPC Server vom Hersteller kann dabei als eigenständige Software geliefert werden oder aber als eingebetteter OPC Server auf dem Gerät oder der Maschinensteuerung.

Unabhängige OPC Server

Neben den OPC Servern von Herstellern selbst gibt es Anbieter, die unabhängige OPC Server entwickeln. Diese Server unterscheiden sich durch eine breitere Unterstützung von Kommunikationsprotokollen. Dadurch kann auch für Systeme OPC Kommunikation bereitgestellt werden, für die der Hersteller keinen eigenen OPC Server liefert. Außerdem bieten die Hersteller unabhängiger OPC Server mehr Funktionen, teilweise einfachere Bedienung und bessere Stabilität. Hersteller von unabhängigen OPC Severn sind unter anderen Kepware (über 150 Treiber verfügbar), Softing, INAT und Matrikon. Auch der OPC Router kann mit dem OPC UA Server Plug-in Daten als OPC Server bereitstellen.

2. OPC Client

Der OPC Client ist das logische Gegenstück zum OPC Server. Mit dem OPC Client kann der OPC Server verbunden werden und die Daten auslesen, welche der Server zur Verfügung stellt. Da die OPC Server die vorgebenen Schnittstellen des OPC Standards implementieren, kann jeder Client auf jeden beliebigen OPC Server zugreifen und gleichartig Daten mit dem Server austauschen.

Anwendungen als OPC Clients

Typische OPC Clients sind Anwendungen, die auf den Datenaustausch mit industriellen Systemen angewiesen sind. Was mit den Daten im Client geschieht, ist sehr anwendungsspezifisch. Verbreitete Anwendungen sind Visualisierungen und SCADA-Systeme (WinCC, InTouch, FAS inMOVE) oder auch MES-Systeme. Der OPC Router ist mit seinem OPC UA Client Plug-in ebenfalls ein Client mit einer Gateway-Funktion.

OPC Test Client

Es gibt am Markt viele freie OPC Test Clients, mit denen die Funktion und Konfiguration eines Servers sehr einfach und klar getestet werden kann. In kürzester Zeit können die vorhandenen Datenpunkte durchsucht, angebunden und die aktuellen Werte eingesehen werden.
Im operativen Einsatz ist es sehr wichtig, über eine unabhängige Anwendung die Funktion der Datenquelle “OPC” zu testen und damit von höher liegenden Anwendungen zu abstrahieren. Ein beliebter Test-Client ist der Test-Client von Unified Automation.
Der OPC Router selbst ist auch ein OPC Client. Die Funktionalität wird durch das OPC Client Plug-in umgesetzt.

3. OPC Classics vs. OPC UA

Der aktuelle Standard der OPC Spezifikation ist OPC UA (OPC Unified Architecture). Es ist der Nachfolger des alten OPC Standards, der als OPC Classic bezeichnet wird. Sehr viele Installationen von OPC Servern sind bis heute Classic OPC Server.  Der alte Standard löste bereits sehr erfolgreich die Aufgabe, den Datenaustausch in der Automatisierung herstellerunabhängig zu realisieren und definierte die grundlegenden Schnittstellen. Der Nachteil von OPC Classic war die fehlende Plattformunabhängigkeit. OPC Classic basiert auf die Microsoft Technologien COM und DCOM und damit waren OPC Server und OPC Client Installationen auf Microsoft Windows Betriebssysteme und Netzwerke beschränkt. Mit zunehmendem Erfolg anderer Plattformen (Linux, Web-Architekturen, Cloud, IoT Devices, CPS, …) war hierdurch der Verbreitung von OPC eingeschränkt.
Dies hat die OPC Foundation erkannt und hat den Nachfolger OPC UA ins Leben gerufen. OPC UA hat Plattformunabhängigkeit und Interoperabilität als oberstes Ziel. Technisch wurde der Standard auf Grundlage der Basis-Webtechnologien (TCP/IP, http/SOAP) aufgebaut. Die Basiskonzepte für den Datenaustausch wurden übernommen, vereint und um weitere ergänzt (s. Spezifikationen).

4. OPC UA Pub/Sub

Bei OPC UA Pub/Sub sind die Kommunikationsteilnehmer in Publisher und Subscriber aufgeteilt. Über einen Broker können somit Geräte und Software miteinander kommunizieren, ohne dabei auf die 1-zu-1 Beziehungen einer Client/Server Kommunikation angewiesen zu sein. Die interne Kommunikation kann beschleunigt und Prozessorkapazität gespart werden.

5. OPC Foundation

Die OPC Foundation ist die Organisation hinter dem Standard und ist mit zurzeit 678 Mitgliedern sehr breit aufgestellt. Mitglieder sind unter anderen die global Player der Automatisierungsbranche. Zum Beispiel: Siemens, Honeywell, Microsoft, Beckhoff, SAP, Yokogawa, ABB, Rockwell, Schneider Electric, Wago, Iconics. Alle Mitglieder der Foundation finden Sie in der OPC Foundation Mitglieder-Liste. Die Vereinigung wurde 1994 gegründet und hat 1996 die erste Version von OPC herausgegeben. Seitdem arbeitet sie sehr erfolgreich und aktiv an der Weiterentwicklung und Verbreitung des OPC Standards.

6. OPC Spezifikationen

Der Standard OPC UA setzt sich zusammen aus einzelnen Spezifikationen. Jede Spezifikation beschreibt eine Teilfunktion und gibt vor, welche Schnittstellen von Server und Client für diese Funktion implementiert werden müssen, um diese zu unterstützen. Es müssen von OPC Servern und Clients nicht alle Spezifikationen unterstützt werden. Je nach Anwendungsbereich sind oftmals nur einzelne Spezifikationen programmiert. Beim Einsatz eines OPC Servers und auch Clients muss daher beachtet werden, welche Spezifikationen benötigt werden und welche von Server und Client umgesetzt sind.

Aus diesen Spezifikationen setzt sich OPC UA zusammen:
1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
12. Discovery
13. Aggregates
14. PubSub

Für den operativen Einsatz ist es nicht notwendig die Spezifikationen im Einzelnen zu kennen. Die wichtigsten für das Projektgeschäft sind folgende:

Data Access

Die Data Access Spezifikation beschreibt den klassischen Austausch von aktuellen Daten. Bereits im OPC Classic Standard wurde festgelegt, dass der Datenaustausch datenpunktorientiert abläuft. Für jeden Datenpunkt kann ein Wert gelesen und geschrieben werden. Ein Datenpunktwert beschreibt sich über den tatsächlichen Wert, den Zeitstempel, zu dem der Wert aktuell war und durch die Qualität, die beschreibt, ob der Wert valide ist oder ob z. B. die Verbindung zur Steuerung unterbrochen war und der Wert dadurch nicht valide ist. Allein über diese Festlegung ist es möglich unabhängig vom dahinterliegenden System, Daten zu beziehen und zu verarbeiten.
Im aktuellen Standard sind die Möglichkeiten mit komplexen Datentypen (Strukturen) und mit Funktionen erweitert worden, um den neuen Anforderungen gerecht zu werden.

Historical Access

Über die Spezifikation Historical Access ist es möglich, Daten nicht nur mit dem aktuellen Wert zu lesen, sondern auch historische Werte abzufragen. Ein OPC Server, der diese Spezifikation implementiert, muss intern über einen Datenspeicher verfügen, um die Werte der Datenpunkte für eventuelle Historical Access Zugriffe bereitzustellen. Ein Client, welcher historische Datenpunkte über Historical Access liest, übergibt dem Server neben den Datenpunktinformationen auch die gewünschte Zeitspanne.

Alarms and Conditions

Die Alarms and Conditions-Spezifikation definiert ein standardisiertes Model für Alarmmeldungen und Alarmierungslogiken als Teil von OPC UA. Für OPC Client Anwendungen wird damit die Aufgabe aus Datenpunktwerten Alarme zu generieren stark vereinfacht, da die Logik durch den OPC Server implementiert werden kann und nicht herstellerspezifisch durch den Hersteller der Client-Software.

7. Companion Specifications

Die Companion Specifications sind Informations-Modelle, die von Industrie-Gruppen auf Basis des OPC UA Standard Models aufgebaut sind. Darin werden für branchenspezifische Anwendungen und Objekte definierte Datenpunktstrukturen festgelegt. Beispiel hierfür sind Modelle für Spritzgussmaschinen (Euromap 77), Werkzeugmaschinen/CNC (umati), Roboter, RFID und AutoID Syteme (AutoID) und viele Weitere.
Die bereits verabschiedeten Companion Specifications listet die OPC Foundation auf Ihrer Webseite auf. Viele weitere werden gerade durch Arbeitsgruppen erarbeitet und stehen kurz vor der Verabschiedung.
Durch OPC UA wird der einfache Datenaustausch mit Maschinen und Systemen standardisiert, durch die Companion Specifications werden zusätzlich die Datenmodelle für gleichartige Maschinen und Systeme standardisiert, in denen festgeschrieben wird, welche Daten ausgetauscht werden. Dies führt zu einer deutlichen Vereinfachung bei der Vernetzung nach der Industrie 4.0-Idee, da Maschinen verschiedener Hersteller die gleichen Datenstrukturen liefern und empfangen.
Vom OPC Router werden zur Zeit die Euromap 77 Spezifikation und die AutoID Spezifikation (RFID Teil) als Client implementiert. Weitere werden folgen.

8. Sicherheit von OPC UA

Bei der Entwicklung des OPC UA Standards wurde von Anfang an auf ein Höchstmaß an Sicherheit geachtet. OPC UA ist im Gegensatz zu OPC Classic “firewall-fiendly” entwickelt worden, das heißt es kann über Standard-Netzwerktechniken kontrolliert und gelenkt werden.
Auf der Transportschicht sind mehrere Protokolle zur Verfügung gestellt worden. So kann ein binäres Protokoll direkt auf TCP/IP für schnelle Anwendungen verwendet werden oder auch das plattformübergreifende SOAP mit HTTPS.
Für die Sicherung der Daten bei der Übertragung werden Verschlüsselungen von 128 oder 256 Bit verwendet, sowie auch eine Nachrichten-Signierung, Paket-Sequenzierung und Benutzer-Authentifizierung.
Zur weiteren Absicherung kommt bei OPC UA ein Zertifikatsaustausch zum Einsatz, so dass sich jeder Client mit einem Zertifikat authentifizieren muss. So kann kontrolliert werden, welcher Client sich mit dem Server verbinden darf.
Das BSI hat die Sicherheit von OPC UA untersucht und dabei keine systemischen Sicherheitslücken festgestellt.

9. Tunneling

Das Tunneling bezeichnet das Übertragen von OPC Daten aus einem Netzwerksegment in ein anderes. Der Begriff stammt aus der Zeit von OPC Classic, denn aufgrund der eingesetzten Technologie DCOM, ist die netzwerkübergreifende Kommunikation per OPC Classic sehr schwer oder nahezu unmöglich. Dafür haben einige Softwarehersteller eine Lösung geschaffen, indem sie den Datenverkehr gekapselt und in einfaches TCP/IP gewandelt haben, so dass der Datenverkehr den Weg durch die Firewall nehmen konnte. Im Ziel-Netzwerk wurde der Datenverkehr wieder entpackt und in einem OPC Classic Server bereitgestellt.
Mit der OPC UA Technologie ist ein Tunneling nicht mehr notwendig. Steht nur ein OPC Classic Server bereits und trotzdem soll netzwerkübergreifend kommuniziert werden, wird ein OPC Wrapper benötigt. Dazu wird ein OPC UA Server verwendet, z. B. der KEPServerEX, um zum einen als Client die Daten vom OPC Classic Server zu beziehen und zum anderen diese Daten dann per OPC UA Firewall-freundlich zur Verfügung zu stellen.

10. OPC UA over TSN

Für die Echtzeitkommunikation in der Feldebene zwischen Steuerungssystemen wurde OPC UA over TSN entworfen. Das TSN steht hier für Time Sensitive Network und beschreibt die Anforderungen von Maschinennetzwerken mit deterministischen Antwortzeiten. Im Gegensatz zum Client-Server Betrieb von OPC UA wird bei OPC UA over TSN nach dem Publisher-Subscriber-Verfahren kommuniziert. Für den Einsatz von OPC UA in normalen Ethernet-basierten, Nicht-Echtzeit Umgebungen spielt OPC UA over TSN derzeit keine Rolle.

11. OPC UA Pub/Sub over MQTT

Das Pub/Sub Prinzip wird nicht nur vom OPC UA Pub/Sub Plug-in benutzt, sondern auch von dem weitverbreiteten Nachrichtenprotokoll MQTT. Über beide Plug-ins kann der OPC Router als Publisher und als Subscriber betrieben werden. Der Unterschied zwischen dem OPC UA Pub/Sub Plug-in und dem MQTT Plug-in liegt darin, dass die Struktur von OPC UA Daten im OPC UA Pub/Sub Plug-in bereits vorhanden ist. Damit kann der OPC Router OPC UA Daten zur Weiterverarbeitung an andere Geräte oder Systeme publishen, oder OPC UA Daten von anderen subscriben. Die Implementierung von OPC UA Daten über MQTT wäre deutlich schwieriger, da die meisten Nachrichteninhalte bei MQTT in XML oder JSON geschrieben sind.

12. OPC XML

Die OPC XML Spezifikation war der erste Vorstoß der OPC Foundation, um eine Plattformunabhängigkeit zu erreichen und die Bindung an die Microsoft Technologie zu lösen. Dafür wurde das damals aufkommende Format XML in Verbindung mit Webtechnologien verwendet. Im Jahre 2003 wurde dann die OPC XML Spezifikation freigegeben. Drei Jahre später im Jahre 2006 war dann allerdings bereits die erste Version von OPC UA verfügbar, die OPC XML obsolet machte.

13. DCOM

Die Microsoft Technologie DCOM ist die Netzwerkversion der COM Technologie. COM steht für Component Object Model und ist die objektorientierte Technik im Hintergrund des Microsoft Betriebssystems. Sie dient dazu verschiedene Anwendungen intelligent miteinander arbeiten zu lassen. Da es zur Zeit der Erarbeitung des OPC Standards die führende Technologie war, hat man darauf aufgebaut. Der OPC Classic Server ist eine COM-Komponente und wird als solche vom Client angebunden. Wird ein OPC Classic Server über das Netzwerk angebunden, muss das Distributed COM (DCOM) Protokoll verwendet werden, welches tief im Windows Betriebssystem verankert ist. DCOM hat eine komplexe Authentifizierungslogik und verwendet mehrere und dynamische TCP/IP Verbindungen, wodurch es für eine Firewall nicht zu kontrollieren ist und damit kategorisch geblockt wird. In der Praxis wurde daher meist darauf verzichtet DCOM-Verbindungen aufzubauen.

14. Plattformunabhängigkeit und Interoperabilität

OPC UA ist durch TCP/IP und Web-Protokolle für die Kommunikation vollständig plattformunabhängig geworden. Ein OPC Server, welcher im Netzwerk seine Daten bereitstellt, kann über diese Protokolle angesprochen werden. Dabei ist es irrelevant, ob der OPC Server auf einem Windows Betriebssystem, einem Linux, UNIX oder Mac läuft. Selbst komplett eigene Plattformen mit TCP/IP-Stack können einen OPC Server implementieren. So können typische embedded-Systeme, Geräte und Steuerungen als Server dienen. Das Ziel der Plattformunabhängigkeit ist erreicht und führt zu einer schnellen Verbreitung von OPC UA. Die Interoperabilität ist die logische Folge der Infrastruktur mit verschiedensten OPC UA Teilnehmer im Netz.

15. OPC UA und Industrie 4.0

Im Jahre 2011 ist der Begriff Industrie 4.0 das erste Mal in einer Arbeitsgruppe verwendet worden. Lange vorher wurde OPC UA bereits als Standard definiert. Und trotzdem ist OPC UA eines der führenden Kommunikationsprotokolle für die Industrie 4.0. Bei der intelligenten Vernetzung von Fabriken ist eine gemeinsame Sprache notwendig. Genau das liefert OPC UA und ist damit ein wichtiges Instrument für die Realisierung von Industrie 4.0.

16. What is OPC UA? in a minute