OPC Foundation

OLE for Process Control (OPC) war der ursprüngliche Name für standardisierte Software-Schnittstellen, die den Datenaustausch zwischen Anwendungen unterschiedlichster Hersteller in der Automatisierungstechnik ermöglichen. Durch die fortschreitende Weiterentwicklung dieser Schnittstellen und der damit einhergehenden Abnahme der Relevanz des OLE-Objektsystems wird heute lediglich die Bezeichnung OPC, ohne auf eine Abkürzung hinzuweisen, genutzt.

Entstehung

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 Pflege und Verbreitung des Standards. Ihr gehören mittlerweile 448 (Stand: 8. Januar 2008) Unternehmen an.

Heute ist OPC der Standard zur herstellerunabhängigen Kommunikation in der Automatisierungstechnik. Die Zertifizierungssoftware OPC Compliance Test welche 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.

Einsatzgebiet

OPC wird dort eingesetzt, wo Sensoren, Regler und Steuerungen verschiedener Hersteller ein gemeinsames, flexibles 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).

Spezifikationen

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 A/E (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 Spezifikationen in Form von OPC UA geplant ist, verbreiteten sich OPC XML DA Server nur gering.
• OPC UA (Unified Architecture): Spezifikation, die alle bisherigen Spezifikationen (OPC DA, OPC HDA, OPC A/E) plattform- und DCOM- unabhängig umsetzen soll. Bisher (Stand Juni 2007) ist diese Spezifikation noch nicht abgeschlossen.

Funktionsweise

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.

Kritikpunkte

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 Kommunikation 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 Server und Client nicht in derselben Domäne sind. 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 (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/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.

Literatur

• [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 (angekündigt für Jan 2009; Sprache: Englisch)

Siehe auch

• Feldbus
• Profibus
• CAN
• Local Control Network (LCN)
• LON
• EIB
• BACnet

Weblinks

• OPC Foundation
• OPC Foundation Europe
• OPC Training Institute
• OPC Programmers' Connection mit "free stuff"-Bereich und nützlichen Tipps
• LightOPC - kostenloses OPC-Servertoolkit
• FatRat Library - kostenloses OPC-Servertoolkit
• Zehn Jahre OPC: Von Data Access zu Unified Architecture, Artikel in der Zeitschrift SPS Magazin, 8/2005
• OPC Handbuch
• M-Bus, S-Bus und Modbus OPC Server
• OPC Unified Architecture e-Book