OPC UA Buch

Das erste OPC Unified Architecture Buch, geschrieben von Wolfgang Mahnke, Stefan-Helmut Leitner und Matthias Damm, einem der Gründer von ascolab.

OPC UA Konzepte

OPC-UA ist serviceorientiert

Die OPC UA Architektur ist eine serviceorientierte Architektur (SOA) und ist aufgeteilt in mehrere logische Ebenen. Alle von OPC definierten grundlegenden Dienste (Base Services) sind abstrakte Methodenbeschreibungen. Diese sind protokollunabhängig und stellen die Grundlage für die gesamte OPC-UA-Funktionalität bereit.

uaapplications

Transport

Die Transportschicht setzt diese Methoden in ein Protokoll um, d. h. sie serialisert/deserialisiert die Daten und sendet diese über das Netz. Momentan sind zwei Protokolle dafür spezifiziert, die beide auf TCP/IP aufsetzen: ein hoch optimiertes und performantes TCP-Protokoll mit Binärkodierung und ein auf Webservices basierendes Protokoll. Das Binärprotokoll ist vorgeschrieben (mandatory) und wird von allen UA Stacks unterstützt. Weiterhin gibt es eine Kombination der beiden Protokolle, das sogenannte Hybrid-Profil. Hier wird eine binär kodierte (unverschlüsselte) Nachricht über einen verschlüsselten Transportkanal (HTTPS) versendet (Hybrid = binary über https). Weitere Protokolle sind möglich und können bei Bedarf ergänzt werden.

Datenmodell

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 ein Command aufgerufen. Weiterhin werden Events unterstützt, die versendet werden können (AE, 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 für alle anderen Arten von Metadaten verwendet. Der damit modellierte OPC-Adressraum beinhaltet nun auch ein Typmodell, mit dem sämtliche Datentypen spezifiziert werden.

Erweiterbarkeit

Darauf aufsetzend spezifizieren verschiedene andere Organisationen ihre eigenen Informationsmodelle, die sogenannten Zusatzspezifikationen (companion specifications). Die wichtigste dieser Spezifikationen ist das DI-Modell (device integration). Sie beschreibt Geräte und dient als Basis für weitere Zusatzspezifikationen, wie z. B. ADI, PLCopen oder FDI, die ihrerseits eigene Informationsmodelle definieren. Clients haben die Möglichkeit, zu überprüfen, welche sogenannten „Profile“ ein Server unterstützt. Damit kann ermittelt werden, ob ein Server nur DA-Funktionalität unterstützt oder aber auch A&C (alarms and conditions), HA (historical access) etc. Es kann aber auch ausgelesen werden, ob ein Server z. B. das DI-Profil unterstützt, wodurch ein Client weiß, dass auch DI-spezifische Gerätebeschreibungen, Konfigurations- und Diagnoseinformationen verfügbar sind.

Weitere neue und wichtige Features von OPC UA sind:

  • Serviceorientierte Architektur (SOA) mit asynchronem Request/Response Paradigma
  • Vereinigung aller Funktionen der bisherigen „OPC-Classic“-Spezifikationen
  • Mengenoperationen für alle Zugriffsoperationen
  • bandbreitenschonende Übertragung (token based subscription)
  • Redundanz, client- und serverseitig sowie Mehrfachredundanz
  • Heartbeat zur Verbindungsüberwachung in beide Richtungen, d. h. sowohl Server als auch Client bemerken Unterbrechungen
  • Pufferung von Daten und Acknowlegements von übertragenen Daten
  • Verbindungsunterbrechungen ohne Datenverlust:Verlorene Daten können erneut angefordert werden