IEC 62541

OPC Unified Architecture, kurz OPC UA, ist die neuste aller OPC-Spezifikationen der OPC Foundation und unterscheidet sich erheblich von ihren Vorgängern. Nach über drei Jahren Spezifikationsarbeit und einem Jahr Prototypimplementierung wurde die erste Version der Unified Architecture im Herbst 2006 verabschiedet. Im Februar 2009 wurde eine überarbeitete Version der Teile 1-5 und 8 sowie die erste Version der Teile 6 und 7 veröffentlicht.

Neuerungen

Die ursprüngliche Bindung an COM/DCOM hat zwar einen großen Beitrag zur Verbreitung von OPC geleistet, hatte jedoch auch entscheidende Nachteile:

• Häufige Konfigurationsprobleme von DCOM
• Keine konfigurierbaren Timeouts
• Bindung an das Windows-Betriebssystem
• Keine "echte" Security
• Keine Kontrolle, was passiert (COM/DCOM ist eine Blackbox, Entwickler haben keinen Quellcode und sind Fehlern ausgeliefert)

Aus diesen und weiteren Gründen hat man sich dazu entschieden, einen eigenen Kommunikationsstack für OPC UA zu entwickeln, welcher COM/DCOM ersetzt. Die wichtigsten Merkmale dieses Kommunikationsstacks sind

• Portable ANSI-C-Implementierung
• Skalierbarkeit von Embedded-Controllern bis zu Mainframes
• Der Stack kann sowohl für Multithreaded-Betrieb als auch für den Singlethreaded/Singletask-Betrieb kompiliert werden, was wichtig für die Portierung auf Embedded-Geräte ist.
• Eine eigene Security-Implementierung, basierend auf den neuesten Standards, sorgt für "echte" Security.
• Konfigurierbare Timeouts für jeden Service
• Chunking von großen Datenpaketen

Dieser Kommunikationsstack stellt aber nur den Anfang vieler Neuerungen dar. Die OPC-UA-Architektur ist eine Service-orientierte Architektur (SOA) und ist aufgeteilt in mehrere logische Ebenen.

OPC-UA-Architektur

Alle von OPC definierten Base-Services sind abstrakte Methodenbeschreibungen, sind protokollunabhängig und bilden die Basis für die gesamte OPC-UA-Funktionalität.

Die Transportschicht setzt diese Methoden in ein Protokoll um, d. h. es serialisert/deserialisiert die Daten und sendet dieses über das Netz. Momentan sind zwei Protokolle dafür vorgesehen: ein binäres, hoch optimiertes und performantes TCP-Protokoll und ein auf Webservice basierendes Protokoll. Weitere Protokolle sind möglich und können bei Bedarf ergänzt werden.

Das OPC-Informationsmodell ist nicht mehr nur eine Hierarchie aus Ordnern, Items und Propertys. Es ist ein sogenanntes Full-Mesh-Network aus Nodes, mit dem nun auch alle Arten von Metainformationen und Diagnoseinformationen übertragen werden können. Ein Node lässt sich am ehesten mit einem Objekt in der objektorientierten Programmierung vergleichen. Ein Node kann Attribute besitzen, die gelesen werden können (Data Access (DA), Historical Data Access (HDA)), Methoden, die aufgerufen werden können (Commands), und Events, die geschickt werden können (AE, DA DataChange). Diese Nodes werden sowohl für die Nutzdaten als auch alle anderen Arten von Metadaten verwendet. Der damit modellierte OPC-Adressraum beinhaltet nun auch ein Typmodell, mit dem sämtliche Datentypen beschrieben werden.

Darauf aufsetzend spezifizieren verschiedene andere Organisationen wie z. B. EDDL eigene Informationsmodelle. Clients haben die Möglichkeit, zu überprüfen, welche sogenannten "Profile" ein Server unterstützt. Damit kann überprüft werden, ob ein Server nur DA-Funktionalität unterstützt oder aber auch AE, HDA etc. Es kann aber auch gelesen werden, ob ein Server z. B. das EDDL-Profil unterstützt, und somit weiß ein Client, dass auch EDDL-spezifische Gerätebeschreibungen verfügbar sind.

Weitere neue und wichtige Feature von OPC UA sind

• Redundanz Unterstützung
• Heartbeat zur Verbindungsüberwachung in beide Richtungen, d. h. sowohl Server als auch Client bemerken Unterbrechungen.
• Buffering von Daten und Acknowlegements von übertragenen Daten. Verbindungsunterbrechungen führen nicht mehr zu Datenverlust. Verlorene Daten können erneut angefordert werden.

Protokolle

Wie schon erwähnt gibt es zwei Protokolle. Als Anwendungsentwickler bemerkt man das nur an der zu übergebenden URL: opc.tcp://Server für Binärprotokoll und http://Server für Webservice. Ansonsten funktioniert OPC UA völlig transparent an der API.

1. Binärprotokoll

• beste Performance, am wenigsten Overhead
• Verbraucht am wenigsten Ressourcen (kein XML-Parser, SOAP und HTTP notwendig -> wichtig für embedded-Geräte)
• beste Interoperabilität (binär ist genau spezifiziert, nicht so viele Freiheitsgrade wie mit XML)
• Ein einziger TCP-Port (4840) wird für die Kommunikation verwendet und kann auch leicht getunnelt oder in einer Firewall freigeschaltet werden.

2. Webservice (SOAP)

• beste Tool-Unterstützung. Kann z. B. auch leicht aus Java und .net verwendet werden.
• Firewall-freundlich. Port 80 (http) und 443 (https) funktionieren meistens ohne weitere Konfiguration.

Da der zur Verfügung gestellte ANSI-C-Stack beide Protokolle beherrscht, wird erwartet, dass die meisten Produkte mit dem effizienten Binärprotokoll kommunizieren werden.

Spezifikationen

Die OPC-UA-Spezifikation ist eine Multipart-Spezifikation und besteht aus den folgenden Teilen:

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

Im Gegensatz zu den auf COM basierenden Spezifikationen sind die UA-Spezifikationen keine reinen Anwenderspezifikationen. Sie beschreiben großteils UA-Interna, die vom Kommunikationsstack gehandelt werden, und sind nur interessant für Leute, die den Stack portieren oder einen eigenen UA-Stack implementieren wollen.

Die OPC-UA-Anwendungsentwickler setzen auf einer OPC-UA-API auf und werden deshalb hauptsächlich die API-Dokumentation verwenden. Interessant für Anwender sind jedoch Part 3, 4, und 5.

OPC UA Kommunikations Stack

Der Aufbau einer UA Applikation, egal ob Server oder Client, gliedert sich in folgende Schichten.

Die grünen Teile entsprechen den ehemaligen COM Proxy/Stubs und werden von der OPC Foundation zur Verfügung gestellt. Neu ist die Portierungsschicht, welche es ermöglicht auf einfache Weise den UA ANSI C Stack auch auf andere Plattformen zu portieren. Ein Portlayer für Windows und Linux wird ebenfalls von der OPC Foundation zur Verfügung gestellt. Auf der API aufbauend werden die Applikationen entwickelt, ähnlich wie es auch bei COM der Fall war.

Auf der OPC UA DevCon im Oktober 2006 in München wurden bereits erste Prototypen demonstriert. Die Firma ascolab GmbH, welche auch den ANSI C Stack für die OPC Foundation entwickelte, führte verschiedene Prototypen vor und demonstrierte die Interoperabilität zwischen einem Windows/.NET UA Client und einem Linux UA Server.

Weiter wurden verschiedene UA Server auf einer Beckhoff PLC (SPS) und auf einem Embedded Testboard von Euros vorgestellt. Wobei die Beckhoff PLC auf Windows XP embedded basierte und der Embedded Controller auf dem Echtzeit Betriebssystem Euros.

UA Security

UA Security beinhaltet Authentifizeriung und Autorisierung, Verschlüsselung und Datenintegrität durch Signieren. Die OPC Foundation hat dabei das Rad nicht neu erfunden, sondern orientiert sich dabei an den Web Service Security Spezifikationen. Für Web Services wird direkt WS Secure Conversation verwendet und ist somit kompatibel zu .Net und anderen SOAP Implementierungen. Für die binäre Variante wurden die Algorithmen von WS Secure Conversation übernommen und ebenfalls in ein binäres Äquivalent umgesetzt. Dieses wird nun als UA Secure Conversation bezeichnet.

Wie man dem Bild entnehmen kann gibt es auch eine Mischvariante, bei der zwar binär kodiert wird, jedoch SOAP als Transport verwendet wird. Dies stellt einen Kompromiss aus effizienter binärer Kodierung und Firewall-freundlicher Übertragung dar. Binäre Kodierung erfordert immer auch UA Secure Conversation.

Für die Authentifizierung werden x509 Zertifikate verwendet. Es obliegt dem Anwendungsentwickler an welchen Zertifikatsspeicher die UA Applikation angebunden wird. Es ist z.B. möglich die Public Key Infrastructure (PKI) eines Active Directories zu verwenden.

OPC UA APIs

Für UA Entwickler wird es die Möglichkeit geben direkt auf einer C API aufzusetzen, einer komfortableren C++ API oder eine .NET API. Alle APIs werden dieselbe Funktionalität unterstützen, und soweit es die Programmiersprachen erlauben, ähnlich in der Anwendung sein.

Der Kommunikationstack und diese APIs werden von der OPC Foundation zur Verfügung gestellt.

.NET Implementierung

Die .NET Implementierung verwendet nur den untersten Teil des ANSI C Stacks, und implementiert ansonsten den restlichen Stack in .NET. D.h. nur das Socket-Handling und Message-Chunking wird vom ANSI C Stack übernommen, das Deserialisieren erfolgt direkt in .NET und wird somit direkt in .NET-Objekte umgesetzt. Dieses Vorgehen ist performanter gegenüber der Deserialisierung in eine C-Struktur und anschließendes Kopieren in ein .NET-Objekt.

Java-Implementierung

Verschiedene Prototypen für Java sind schon in Entwicklung. Dabei gibt es wie auch bei .Net grundsätzlich 3 Varianten. Momentan kann man schwer abschätzen welche die schnellste Variante ist.

1. Die schnellste (im Sinne von Entwicklungszeit) Variante momentan ist, den kompletten ANSI C Stack zu verwenden und diesen via JNI zu kapseln.

• - Ein Nachteil ist, man verliert damit die einfache Java Portabilität. Der Stack kann zwar auf verschiedene Betriebssysteme portiert werden, muss dazu aber neu kompiliert werden.
• - Die Daten müssen an der JNI Grenze kopiert werden.
• + Man nützt die Geschwindigkeitsvorteile von C bei der Deserialisierung.

2. Man setzt wie bei der momentanen .Net Implementierung direkt auf der Netzwerkschicht auf und deserialsiert in Java.

• + Man spart sich einmal umkopieren
• - weiterhin abhängig vom C Stack.

3. Komplette Implementierung in Java.

• + Beste Portabilität
• - Am meisten Aufwand

Alternativ gibt es noch die einfache Variante nur das WebService Protokoll zu unterstützen. Dazu benötigt man ein SOAP Toolkit welches auch WS-Security unterstützt.

OPC UA WRAPPER

Zur Verwendung bereits vorhandener DCOM OPC Geräten und Software stellt die OPC Foundation sogenannte Wrapper zur Verfügung. Diese "übersetzen" DCOM OPC in OPC UA sowie OPC UA in DCOM OPC um.

Normung

OPC UA soll auch als IEC-Normenreihe IEC 62541 veröffentlicht werden. Bisher liegen Teil 1 bis 10 als Ed. 1.0 vor.

Literatur

• Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag, 2009; englisch, ISBN 978-3-540-68898-3

Weblinks

• OPC Foundation
• OPC Foundation Europe
• OPC Unified Architecture e-Book