OPC Unified Architecture
OPC Unified Architecture (OPC UA) ist ein Standard für den Datenaustausch als plattformunabhängige, service-orientierte Architektur (SOA)[1]. Sie führt die Fähigkeit ein, Maschinendaten (Regelgrößen, Messwerte, Parameter usw.) nicht nur zu transportieren, sondern auch maschinenlesbar semantisch zu beschreiben.
OPC UA ist die neueste Generation aller Spezifikationen der Open Platform Communications (OPC) von der OPC Foundation. 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 bis 5 und 8 sowie die erste Version der Teile 6 und 7 veröffentlicht. Seitdem wurden diese Teile aktualisiert und weitere Teile veröffentlicht.
Neuerungen
[Bearbeiten | Quelltext bearbeiten]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 Betriebssystem Windows
- Sicherheitsschwächen, da die Authentifizierung über die lokale Benutzertabelle erfolgte
- 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:
- Neben einer portablen ANSI-C Implementierung werden sowohl eine C++ als auch eine Java-Implementierung unterstützt.
- Skalierbarkeit von eingebetteter Steuerungssoftware bis hin zu betrieblichen bzw. Management-Informationssystemen
- 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äten ist.
- Eine eigene Security-Implementierung, basierend auf den neuesten Standards
- Konfigurierbarkeit von Timeouts für jeden Serviceaufruf
- Chunking von großen Datenpaketen
Die OPC UA-Architektur ist eine Service-orientierte Architektur (SOA), deren Struktur aus mehreren Schichten besteht.
![](http://upload.wikimedia.org/wikipedia/de/thumb/f/f0/UA_Architecture_1024.png/220px-UA_Architecture_1024.png)
Alle von OPC definierten grundlegenden Dienste (Base-Services) sind abstrakte Methodenbeschreibungen, die protokollunabhängig sind, und stellen die Grundlage für die gesamte OPC UA-Funktionalität bereit.
Durch die Transportschicht werden diese Methoden mittels eines Protokolls ausgeführt, das die Daten serialisiert/deserialisiert und über das Netz sendet. Momentan sind zwei Protokolle dafür vorgesehen: ein hoch optimiertes und performantes TCP-Protokoll mit Binärkodierung und ein auf Webservices 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 Properties. Es ist ein sogenanntes Full-Mesh-Network aus Nodes, mit dem neben den Nutzdaten eines Nodes auch Meta- und Diagnoseinformationen repräsentiert werden. Ein Node ähnelt einem Objekt aus der objektorientierten Programmierung. Ein Node kann Attribute besitzen, die gelesen werden können (Data Access (DA), Historical Data Access (HDA)). Es ist möglich, Methoden zu definieren und aufzurufen. Eine Methode besitzt Aufrufargumente und Rückgabewerte. Sie wird durch einen Command aufgerufen. Weiterhin werden Events unterstützt, die versendet werden können (AE (Alarms & Events), DA DataChange), um bestimmte Informationen zwischen Geräten auszutauschen. Ein Event besitzt unter anderem einen Empfangszeitpunkt, eine Nachricht und einen Schweregrad. Die o. g. 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 spezifiziert 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 Features von OPC UA sind
- Redundanz
- Heartbeat zur Verbindungsüberwachung in beide Richtungen, d. h. sowohl Server als auch Client bemerken Unterbrechungen.
- Pufferung von Daten und Acknowledgements von übertragenen Daten. Verbindungsunterbrechungen führen nicht mehr zu Datenverlust. Verlorene Daten können erneut angefordert werden.
Eine Entwicklung hin zu Echtzeitfähigkeit ist OPC UA over TSN.
Protokolle
[Bearbeiten | Quelltext bearbeiten]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.
- 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.
- Webservice (SOAP)
- beste Tool-Unterstützung. Kann z. B. auch leicht aus Java und .Net-Framework bzw. .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
[Bearbeiten | Quelltext bearbeiten]Die OPC UA-Spezifikation ist eine Multipart-Spezifikation und besteht aus den folgenden Teilen:
- Concepts
- Security Model
- Address Space Model
- Services
- Information Model
- Mappings
- Profiles
- Data Access
- Alarms and Conditions
- Programs
- Historical Access
- Discovery
- Aggregates
- PubSub
- OPC UA Safety
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 Personen, 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-Kommunikationsstack
[Bearbeiten | Quelltext bearbeiten]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 UA Server auf einer Beckhoff-PLC (basierend auf Windows XP embedded) und von EUROS Embedded Systems GmbH auf einem Embedded-Testboard (basierend auf dem eigenen Echtzeitbetriebssystem EUROS) vorgestellt.
Im Oktober 2012 zeigte das Fraunhofer IOSB-INA und das Institut für industrielle Informationstechnik der Technischen Hochschule OWL, dass OPC UA derart skalierungsfähig ist, dass sich ein Server mit nur 15 Kilobytes RAM und 10 Kilobytes ROM direkt auf einem Chip implementieren lässt.[2]
UA Security
[Bearbeiten | Quelltext bearbeiten]UA Security beinhaltet Authentifizierung und Autorisierung, Verschlüsselung und Datenintegrität durch Signieren. Sie orientiert sich 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 für den 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 X.509-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 Directory zu verwenden.
OPC UA APIs
[Bearbeiten | Quelltext bearbeiten]Für UA-Entwickler wird es die Möglichkeit geben, direkt auf einer C-API aufzusetzen, einer komfortableren C++-API oder einer .NET-API. Alle APIs werden dieselbe Funktionalität aufweisen, und, soweit es die Programmiersprachen erlauben, ähnlich in der Anwendung sein.
Der Kommunikationsstack und diese APIs werden von der OPC Foundation zur Verfügung gestellt.
Einige Hersteller von APIs
[Bearbeiten | Quelltext bearbeiten]Die Frameworks der verschiedenen Hersteller haben jeweils Vor- und Nachteile. Meist können Trial-Versionen zum Testen heruntergeladen werden. Feinheiten sind in der Architektur, der Dokumentation der Software und im Preismodell zu finden. Es lohnt sich ein entsprechender Vergleich und Test. Teilweise sind in den Downloads schon Beispiele zur Implementierung und Testapplikationen hinterlegt, welche einem den Einstieg erleichtern. Funktionell sollte die OPC UA Schnittstelle danach überall das Gleiche leisten können (konform mit der Spezifikation).
Unified Automation
[Bearbeiten | Quelltext bearbeiten]Unified Automation hat seinen Sitz in Deutschland und bietet Schulungen zum Thema an, sowie auch Workshops zum Einsatz ihrer APIs für ANSI C, .NET, C++ oder Java. Bei der Installation der angebotenen APIs sind verschiedene Testapplikationen (Client und Server) vorhanden, sowie der UAExpert (ein OPC UA Client), der gute Dienste zum Kennenlernen der OPC UA Umgebung und zum Test eigener Applikationen leistet.
Softing
[Bearbeiten | Quelltext bearbeiten]Softing, ein deutsches Unternehmen, welches stark mit Siemens zusammen arbeitet und APIs für C++ oder .NET anbietet.
OPC Labs
[Bearbeiten | Quelltext bearbeiten]OPC Labs ist ein Unternehmen mit Hauptsitz in Tschechien, das für die unterschiedlichsten Plattformen und Programmiersprachen APIs für OPC UA anbietet.
C/C++-Implementierung
[Bearbeiten | Quelltext bearbeiten]Es existieren diverse Implementierungen unter einer Open-Source-Lizenz. Als Referenz-Implementierung führt die OPC Foundation den Ansi-C-Stack, welcher unter einer dualen Lizenz (proprietär für Mitglieder, GPL alle anderen) steht.[3]
Das open62541-Projekt bietet eine nahezu komplette Implementierung der OPC UA-Spezifikation in C und ist unter der Mozilla Public License lizenziert. Es unterstützt neben Linux und Windows auch OS X, QNX und diverse eingebettete Systeme.[4]
Das ASNeG-Projekt stellt einen C++ OpenSource OPC UA Application Server und einen OPC UA Web Server (im Beta-Zustand) zur Verfügung (bisher nur mit Unterstützung der Basis-Funktionalitäten).[5]
.NET-Implementierung
[Bearbeiten | Quelltext bearbeiten]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 in .NET und führt somit direkt zu .NET-Objekten. Dieses Vorgehen ist performanter gegenüber der Deserialisierung in eine C-Struktur und anschließendes Kopieren in ein .NET-Objekt.
Java-Implementierung
[Bearbeiten | Quelltext bearbeiten]Es existieren inzwischen eine Reihe von Java Implementierungen. Der OPC UA Stack wird inzwischen als Java Implementierung von der OPC Foundation bereitgestellt, welche annähernd den vollen Funktionsumfang bereitstellt. Ebenso existieren inzwischen eine Reihe von Java SDKs von den Firmen Unified-Automation, HB-Softsolution oder Prosys. Das Projekt opcua4j stellt ein OpenSource-SDK (bisher nur mit Unterstützung der Basis-Funktionalitäten) auf Basis des offiziellen OPC UA Stacks bereit.[6] Die Firma Ignition hat den OPC UA Stack und ein SDK (im Beta-Zustand) komplett in Java re-implementiert und stellt es als Open-Source bereit. Außerdem gibt es seit 2016 eine von der Eclipse Foundation unter dem Namen "Milo" entwickelte Open-Source Implementierung.[7]
JavaScript-Implementierung
[Bearbeiten | Quelltext bearbeiten]Eine spezielle Variante bietet das Projekt node-opcua. Es hat den OPC UA Stack in JavaScript implementiert, so dass es auf der Basis von NodeJS in der V8 JavaScript-RuntimeEngine genutzt werden kann.[8]
Python-Implementierung
[Bearbeiten | Quelltext bearbeiten]- python-opcua ist eine Python Implementierung von OPC UA Client und Server für Python 2 und 3 und ist unter der LGPL 3.0 Lizenz verfügbar. Das entsprechend Python-Projekt wurde früher "freeopcua" genannt.[9][10] Das Projekt ist seit 2018 in maintainance-mode und verweist auf die asynchrone Version opcua-asyncio.[11]
- opcua-asyncio ist der asynchrone Nachfolger von python-opcua, welcher Python >= 3.7 supportet und auf die Python implementierte Bibliothek asyncio setzt. Sie ist unter der LGPL 3.0 Lizenz verfügbar.
- Die S2OPC C-Implementierung beinhaltet einen Python wrapper PyS2OPC.
Siemens Simatic Implementierung
[Bearbeiten | Quelltext bearbeiten]Der OPC UA-Server einer SIMATIC S7-1200 / S7-1500 bietet diese Typendefinitionen an. Hierbei werden einige SIMATIC Datentypen direkt mit den Basisdatentypen von OPC UA (ns=0) abgebildet, während andere SIMATIC Datentypen eine eigene Typendefinition (ns=3) im Adressraum erhalten. Die folgende Tabelle listet die wichtigsten SIMATIC Datentypen und die dazugehörigen Node Ids der Typendefinitionen, sowie die Zuweisung zwischen SIMATIC und OPC UA Datentypen auf:[12]
SIMATIC Datentyp | Node Id | OPC UA Datentyp | S7-1200 | S7-1500 |
Bool | ns=0;i=1 | Boolean | x | x |
Int | ns=0;i=4 | Int16 | x | x |
SInt | ns=0;i=2 | SByte | x | x |
DInt | ns=0;i=6 | Int32 | x | x |
LInt | ns=0;i=8 | Int64 | x | |
USInt | ns=0;i=3 | Byte | x | x |
UDInt | ns=0;i=7 | UInt32 | x | x |
UInt | ns=0;i=5 | UInt16 | x | x |
ULInt | ns=0;i=9 | UInt64 | x | x |
Real | ns=0;i=10 | Float | x | x |
LReal | ns=0;i=11 | Double | x | x |
Byte | ns=3;i=3001 | "BYTE" | x | |
Word | ns=3;i=3002 | "WORD" | x | |
DWord | ns=3;i=3003 | "DWORD" | x | |
DWord | ns=0;i=19 | StatusCode | x | |
LWord | ns=3;i=3004 | "LWORD" | x | |
Char | ns=3;i=3012 | "CHAR" | x | |
WChar | ns=3;i=3013 | "WCHAR" | x | |
WString | ns=0;i=12 | String | x | x |
String | ns=3;i=3014 | "STRING" | x | |
LDT | ns=0;i=13 | DateTime | x | |
Date_And_Time | ns=3;i=3011 | "DT" | x |
OPC UA Wrapper
[Bearbeiten | Quelltext bearbeiten]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.
Normen
[Bearbeiten | Quelltext bearbeiten]OPC UA wurde als Normenreihe IEC 62541 veröffentlicht.
Nummer | Ausgabedatum | Englischer Titel | Deutscher Titel | Edition |
---|---|---|---|---|
IEC/TR 62541-1 | Oktober 2016 | OPC Unified Architecture – Part 1: Overview and Concepts | OPC Unified Architecture – Teil 1: Übersicht und Konzepte | 2.0 |
IEC/TR 62541-2 | Oktober 2016 | OPC Unified Architecture – Part 2: Security Model | OPC Unified Architecture – Teil 2: Modell für die IT-Sicherheit | 2.0 |
IEC 62541-3 | Juli 2020 | OPC Unified Architecture – Part 3: Address Space Model | OPC Unified Architecture – Teil 3: Adressraummodell | 3.0 |
IEC 62541-4 | Juli 2020 | OPC Unified Architecture – Part 4: Services | OPC Unified Architecture – Teil 4: Dienste | 3.0 |
IEC 62541-5 | Juli 2020 | OPC Unified Architecture – Part 5: Information Model | OPC Unified Architecture – Teil 5: Informationsmodell | 3.0 |
IEC 62541-6 | Juli 2020 | OPC Unified Architecture – Part 6: Mappings | OPC Unified Architecture – Teil 6: Protokollabbildungen | 3.0 |
IEC 62541-7 | Juni 2020 | OPC Unified Architecture – Part 7: Profiles | OPC Unified Architecture – Teil 7: Profile | 3.0 |
IEC 62541-8 | Juni 2020 | OPC Unified Architecture – Part 8: Data Access | OPC Unified Architecture – Teil 8: Datenzugriff | 3.0 |
IEC 62541-9 | Juni 2020 | OPC Unified Architecture – Part 9: Alarms and conditions | OPC Unified Architecture – Teil 9: Alarme und Zustände | 3.0 |
IEC 62541-10 | Juli 2020 | OPC Unified Architecture – Part 10: Programs | OPC Unified Architecture – Teil 10: Programme | 3.0 |
IEC 62541-11 | Juni 2020 | OPC Unified Architecture – Part 11: Historical Access | OPC Unified Architecture – Teil 11: Historischer Zugriff | 2.0 |
IEC 62541-12 | Juni 2020 | OPC Unified Architecture – Part 12: Discovery and global services | OPC Unified Architecture – Teil 12: Erkundung | 1.0 |
IEC 62541-13 | Juni 2020 | OPC Unified Architecture – Part 13: Aggregates | OPC Unified Architecture – Teil 13: Berechnungen | 2.0 |
IEC 62541-14 | Juli 2020 | OPC Unified Architecture – Part 14: PubSub | OPC Unified Architecture – Teil 14: PubSub | 1.0 |
IEC 62541-100 | 2015 | OPC Unified Architecture – Part 100: Devices | OPC Unified Architecture – Teil 100: Geräte | 1.0 |
Literatur
[Bearbeiten | Quelltext bearbeiten]- Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag, 2009, ISBN 978-3-540-68898-3 (englisch)
- J. Lange, F. Iwanitz, T. Burke: OPC Von Data Access bis Unified Architecture, VDE Verlag, 2010, ISBN 978-3-8007-3217-3 (deutsch)
- M. Schleipen (Hrsg.): Praxishandbuch OPC UA, Vogel Communications Group, 2018, ISBN 978-3-8343-3413-8 (deutsch)
Weblinks
[Bearbeiten | Quelltext bearbeiten]- OPC Foundation: offizielle Website
- Einführung in OPC UA auf Basis des offenen open62541 Stacks (englisch)
- OPC UA als Wegbereiter der Industrie 4.0. (PDF; 5,1 MB) OPC Foundation; Broschüre.
- OPC Unified Architecture e-Book
- Industrie 4.0: OPC mit SystemModeler (englisch)
- VDMA OPC Surface Technology
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Unified Architecture. In: OPC Foundation. Abgerufen am 25. Januar 2019 (amerikanisches Englisch).
- ↑ Kleinster OPC-UA Server kommt aus Lemgo. 2011, archiviert vom (nicht mehr online verfügbar) am 21. Juli 2015; abgerufen am 18. Juli 2015.
- ↑ OPC Foundation AnsiC Stack. Abgerufen am 4. April 2017.
- ↑ open62541 OPC UA Stack. Abgerufen am 4. April 2017.
- ↑ ASNeG – open source OPC UA Application Server. Abgerufen am 11. September 2015.
- ↑ opcua4j – open source implementation of an opc ua server in java. code.google.com, abgerufen am 15. November 2014.
- ↑ milo: Eclipse Milo™ - an open source implementation of OPC UA (IEC 62541). In: GitHub.com. Eclipse Foundation, 2. Februar 2018, abgerufen am 6. Februar 2018.
- ↑ node-opcua – pure nodejs OPCUA SDK. Abgerufen am 15. November 2014.
- ↑ python-opcua. Abgerufen am 15. Januar 2020.
- ↑ freeopcua. Abgerufen am 15. Januar 2020.
- ↑ FreeOpcUa/python-opcua. Abgerufen am 22. September 2020 (englisch).
- ↑ SIOS. Abgerufen am 5. Juli 2023.