Open Platform Communications

Ursprünglich stand das Akronym OPC für OLE for Process Control und war der Name für standardisierte Software-Schnittstellen, die den Datenaustausch zwischen Anwendungen unterschiedlichster Hersteller in der Automatisierungstechnik ermöglichen sollten. Durch die fortschreitende Weiterentwicklung dieser Schnittstellen und die damit einhergehende Abnahme der Relevanz des OLE-Objektsystems wurde der Standard im November 2011 in Open Platform Communications umbenannt. Deshalb wird heute zumeist die Bezeichnung OPC genutzt. Die aktuelle Spezifikation von OPC wird OPC Unified Architecture (OPC UA) genannt.

OPC ist der Versuch, industriellen Bussystemen und Protokollen eine universelle Möglichkeit zur Verständigung zu geben. Geschaffen wurde der Standard von der OPC Task Force, einem Zusammenschluss verschiedener großer Firmen der Automatisierungsindustrie wie Fisher-Rosemount, Intellution und Siemens, nachdem man erkannt hatte, welchen Aufwand die Anpassung der zahlreichen Herstellerstandards auf individuelle Steuerungs- und Überwachungs-Infrastrukturen verursacht hatte.

Kurz nach der Veröffentlichung der OPC Specification Version 1.0 im August 1996 wurde die OPC Foundation gegründet, die bis heute zuständig ist für die Pflege und Verbreitung des Standards. Ihr gehören mittlerweile über 920 (Stand: 7. Juni 2023) Unternehmen an.

Heute ist OPC der Standard zur herstellerunabhängigen Kommunikation in der Automatisierungstechnik. Die Zertifizierungssoftware OPC Compliance Test, die den OPC-Mitgliedern kostenlos zur Verfügung gestellt wird, stellt die Kompatibilität sicher. Die Hersteller von OPC-Servern können damit ihre Server schon während der Entwicklung testen. Diese Software testet die vollständige OPC-Funktionalität, simuliert Fehlverhalten eines Clients und überprüft alle Fehlercodes. Zusätzlich werden noch logische Tests, Stress- und Performance-Tests durchgeführt. Diese Testreihe deckt mehr Tests ab, als man mit einem normalen Client erreicht. Nach bestandenem Test können die Hersteller die Ergebnisse an die OPC Foundation senden und erhalten das Zertifikat Compliance Tested. Es ist zu empfehlen, nur Server zu kaufen, die dieses Zertifikat besitzen.

OPC wird dort eingesetzt, wo Sensoren, Regler und Steuerungen verschiedener Hersteller ein gemeinsames Netzwerk bilden. Ohne OPC benötigten zwei Geräte zum Datenaustausch genaue Kenntnis über die Kommunikationsmöglichkeiten des Gegenübers. Erweiterungen und Austausch gestalten sich entsprechend schwierig. Mit OPC genügt es, für jedes Gerät genau einmal einen OPC-konformen Treiber zu schreiben. Idealerweise wird dieser bereits vom Hersteller zur Verfügung gestellt. Ein OPC-Treiber lässt sich ohne großen Anpassungsaufwand in beliebig große Steuer- und Überwachungssysteme integrieren.

OPC unterteilt sich in verschiedene Unterstandards, die für den jeweiligen Anwendungsfall unabhängig voneinander implementiert werden können. OPC lässt sich damit verwenden für Echtzeitdaten (Überwachung), Datenarchivierung, Alarm-Meldungen und neuerdings auch direkt zur Steuerung (Befehlsübermittlung).

OPC gliedert sich in die folgenden Spezifikationen:

• OPC DA (Data Access): Spezifikation zur Übertragung von Echtzeitwerten über OPC (DCOM basierend). Aktueller Stand der Spezifikation ist 3.0. OPC DA war die erste OPC Spezifikation.
• OPC AE (Alarms and Events): Spezifikation zur Übertragung von Alarmen und Ereignissen (Alarms & Events).
• OPC HDA (Historical Data Access): Spezifikation zur Übertragung historischer Werte.
• OPC DX (Data eXchange): Spezifikation zur direkten Kommunikation zwischen OPC Servern.
• OPC Command: Spezifikation zur Ausführung von Befehlen (= Kommandos).
• OPC XML DA: Spezifikation zur XML-basierten Übertragung von Echtzeitwerten. Diese Spezifikation ist der Vorläufer von OPC UA. Da früh bekannt wurde, dass eine DCOM-unabhängige Spezifikation in Form von OPC UA geplant ist, verbreiteten sich OPC XML DA Server nur gering.

Die Spezifikation OPC Unified Architecture (OPC UA) ersetzt alle bisherigen Spezifikationen (OPC DA, OPC HDA, OPC A/E) plattform- und DCOM-unabhängig. Die Kernelemente dieser Spezifikation wurden Anfang 2009 zur endgültigen Abstimmung als IEC-Norm (IEC 62541) angenommen. Lediglich die Ereignismodelle für „OPC UA Alarms“ sowie „OPC UA Discovery“ liegen bislang noch als Konzept vor.

Die Spezifikationen wurden bislang nur Mitgliedern der OPC Foundation zugänglich gemacht. Daneben wurde im Mai 2015 beschlossen die Spezifikation und gewisse Stacks von OPC UA als Open-Source auch Nicht-Mitgliedern zugänglich zu machen.

Für die Kommunikation zwischen den Anwendungen benutzt OPC derzeit hauptsächlich Microsofts DCOM-Technologie (Distributed Component Object Model). Dank DCOM ist es für OPC-Anwendungen transparent, ob die über OPC ausgetauschten Daten von einer Anwendung im eigenen Adressraum, von einem fremden, lokalen Prozess oder auch von einem entfernt über TCP/IP angebundenen Rechner kommen. Die Übertragungs- und Zugriffsgeschwindigkeiten werden dabei DCOM-üblich kaum von unnötigem Verwaltungsaufwand ausgebremst. Die Kommunikationswege sind im folgenden Bild dargestellt:

DCOM macht anderen Anwendungen, (kompilierte) Funktionen und Objekte zugänglich. Der OPC-Standard definiert nun bestimmte DCOM-Objekte, d. h. die Funktionen/Schnittstellen, die ein OPC-Teilnehmer (über DCOM) zur Verfügung stellen muss, um mit anderen OPC-Anwendungen Daten austauschen zu können. Die für eine Implementierung notwendigen genauen Spezifikationen lassen sich frei auf der Seite der OPC Foundation herunterladen.

Die wenigsten am Markt vorhandenen OPC-Server und OPC-Clients sind durch die OPC Foundation zertifiziert, da dieser Prozess Geld kostet. Der größte Kostenblock ist der jährliche Mitgliedsbeitrag an die OPC Foundation. Das Werkzeug zur eigenen Zertifizierung eines OPC-Server ist im Rahmen der Mitgliedschaft kostenlos erhältlich. Die Liste der zertifizierten Server/Clients ist auf der Seite der OPC Foundation zu finden. Zum Debuggen der Kommunikation zwischen Client und Server gibt es kostenlose Software, die sich als Sniffer zwischen den Kommunikationspartnern einklinkt.

Mit OPC XML-DA wurde die erste Webservice-basierte Schnittstelle geschaffen. Die Funktionalität ist ähnlich der normalen Data-Access-Schnittstelle, welche die erste und immer noch wichtigste Schnittstelle bei OPC ist. Mit dem Webservice steht OPC auch auf anderen Plattformen wie z. B. Linux zur Verfügung. Mit Webservice-Toolkits wie gSOAP, EasySoap++, Qt etc. für C/C++ oder Java kann man so sehr schnell OPC XML-DA Client und Server entwickeln. Viele Hersteller von OPC-Servern haben als ersten Schritt Adapter entwickelt, welche OPC XML-DA Aufrufe einfach auf die vorhandenen COM OPC DA Server abbilden. Im Gegensatz zu DCOM verwenden Webservices Port 80 (HTTP), was es ebenfalls einfacher macht, durch Firewalls zu kommunizieren oder den Datenverkehr zu tunneln (SSH).

OPC Unified Architecture beschreibt eine neue Generation von OPC-Servern. Diese Spezifikation befindet sich noch in Entwicklung und soll die bisherigen Spezifikationen Data Access, Alarm & Events, Historical Data Access, Data eXchange, Batch und Security vereinheitlichen. Es wird nur noch einen Adressraum mit Objekten geben, die Werte beinhalten, Alarme senden, eine Historie besitzen und wie bei DX verschaltet werden können. Die bisher recht unterschiedlichen Browse-Interfaces werden so durch ein einheitliches Browsing ersetzt. Diese neue Spezifikation beschreibt kein COM-Interface mehr, sondern eine WSDL (Web Services Description Language), die nach COM und in verschiedene Webservice-Protokolle umgesetzt werden kann, womit die Portabilität sichergestellt wird. Ebenso wird verstärkt auf Skalierbarkeit und Sicherheit Wert gelegt.

OPC basiert (bis auf wenige Spezifikationen) auf Microsofts DCOM-Spezifikation. Eine Kommunikation über die Grenzen von Firewalls oder Domänen ist im günstigsten Fall unter Einsatz sogenannter OPC-Tunnel möglich. Diese Softwareprodukte wandeln die OPC-Kommunikation in „normale“ TCP/IP-Kommunikation um, transportieren sie übers Netz und wandeln im Zielrechner die TCP/IP- wieder in OPC-Kommunikation um. Dies erleichtert wesentlich die allgemeine Konfiguration.

OPC kann jedoch auch ohne OPC-Tunnel über Router und Firewalls hinweg kommunizieren, selbst wenn sich Server und Client nicht in derselben Domäne befinden. Die Authentifizierung erfolgt über die lokale Benutzertabelle. Nachteil: Dazu muss auf beiden Endgeräten (Server und Client) ein identischer lokaler Benutzer vorhanden sein, unter dem die OPC- bzw. DCOM-Kommunikation abgewickelt wird (Server und Client müssen unter diesem Benutzer laufen). Auch das Passwort muss identisch sein. Dies erweist sich in vielen Szenarien jedoch als äußerst unpraktikabel.

Des Weiteren ist es sinnvoll oder sogar nötig, die DCOM-Kommunikationsports zu beschränken; dies ist über einen Windows-Registry-Eintrag möglich. Die Anzahl benötigter Ports hängt von der Applikation selbst ab.

• Feldbus
• VARAN
• EtherCAT
• Ethernet Powerlink
• Profibus
• Controller Area Network (CAN)
• Local Control Network (LCN)
• Local Operating Network (LON)
• Europäischer Installationsbus (EIB)
• BACnet

• Frank Iwanitz, Jürgen Lange: OPC: Grundlagen, Implementierung und Anwendung. Hüthig Verlag, Heidelberg ISBN 3-7785-2903-X.
• Udo Enste, Jochen Müller: Datenkommunikation in der Prozessindustrie. Oldenbourg Industrieverlag, ISBN 978-3-8356-3116-8.
• Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag, ISBN 978-3-540-68898-3 (englisch).

• OPC Foundation
• OPC Foundation Europe (Memento vom 31. Dezember 2008 im Internet Archive)
• FatRat Library – freies (BSD) OPC-Servertoolkit
• OpenOPC – Open Source OPC client development in Python