suchen
 OPC UA Spezifikationen minimieren

OPC UA wird in einer Reihe aufeinander aufbauender Parts (Teile) spezifiziert. Die Beschreibung erfolgt dabei bewusst abstrahiert (technologie- und sprachunabhängig), um eine lange Lebensdauer von OPC UA über die Lebensdauer einer Basistechnologie wie DCOM hinaus zu gewährleisten. Lediglich in ausgewählten Abschnitten wird ein konkreter Bezug zu einer bestehenden Technologie hergestellt, auf der OPC UA Software entwickelt werden kann.
Die Parts der OPC UA Specifications sind in drei zentrale Themenbereiche unterteilt:
• Core Specifications (Kernspezifikationen)
• Access Type Specifications (Zugriffstypspezifikationen)
• Utility Specifications (Dienstespezifikationen) 
 

Abb. 1 Die OPC UA Specification mit ihren 13 Parts

Part 1 - Overview and Concepts
Dieser Abschnitt erläutert die Zielsetzung von OPC UA und führt in die Modelle ein, die zur Erreichung dieses Zieles dienen.

Part 2 - Security Model
OPC UA trifft Maßnahmen zur Abwehr von Risiken, denen Systeme ausgesetzt sein können, in welchen die OPC UA Technologie verwendet wird. Es wird beschrieben, auf welche Weise sich OPC UA auf andere Sicherheitsstandards z.B. die des World Wide Web (w3c) Konsortiums oder der OASIS Organisation stützt. Die vorgeschlagene Architektur setzt sich aus einer Anwendungs- und einer Kommunikationsschicht zusammen. Die eingeführten Sicherheitsverfahren (Security Policy) sind Teil einer Endpoint Description und legen die zu verwendenden Sicherheitsmechanismen fest.

Part 3 - AddressSpace Model
Es gibt keinen Zweifel daran, dass die Informationstechnologie und die Prozessleittechnik integriert werden müssen. Auf diese Weise können Vorteile aus der Optimierung von Prozessen sowie Synergieefferkte, die sich aus der Integration ergeben. genutzt werden. Entsprechend der Spezifikation wird eine Reihe von Objekten, die ein unterlagertes (Echtzeit-) System repräsentieren, von einem OPC UA Server als sogenannter AddressSpace veröffentlicht. Die besondere Funktion des AddressSpace-Konzepts ermöglicht, dass sowohl die reale Prozessumgebung als auch ein (Echtzeit-) Prozessverhalten repräsentiert werden können – und zwar auf einheitliche Weise, die für verschiedene Systeme verständlich ist. Dazu besteht der AddressSpace aus einem Satz von Nodes (Knoten), die über References (Referenzen) miteinander verbunden sind.

Part 4 - Services
Bei den OPC UA Services handelt es sich um eine Reihe abstrakter Remote Procedure Calls (RPCs), die durch die Server implementiert und durch die Clients aufgerufen werden. Die Services werden als abstrakt bezeichnet, da in diesem Abschnitt keine bestimmte Implementierung in einer konkreten Technologie definiert wird. Die Trennung von Definition und Implementierung der Services ermöglicht die problemlose Verwendung neu entstehender Technologien, indem entsprechende neue Mappings erstellt werden.

Part 5 - Information Model
Um die durch den AddressSpace veröffentlichten Daten für unterschiedliche Systeme verständlich und nutzbar zu machen, werden die Informationen im Abschnitt für das Information Model in standardkonforme, computeroptimierte Daten konvertiert. Zur Verbesserung der Interoperabilität definiert das Information Model den Inhalt des AddressSpace eines leeren OPC UA Servers. Die in diesem Abschnitt bereitgestellten Definitionen werden als abstrakt angesehen, da sie keine bestimmte Repräsentation in der Umsetzung definieren.

Part 6 - Mappings
Dieser Abschnitt definiert die Abbildung (Mapping) abstrakter Definitionen in der Spezifikation (bspw. in den Abschnitten Information Model, Services, Security Model), auf reale Technologien, die für deren Implementierung verwendet werden können. Mappings sind in drei Gruppen unterteilt: Datenkodierungen, Sicherheits- und Transportprotokolle. Verschiedene Mappings werden zusammengefasst, um sogenannte Stack-Profiles zu erstellen.

Part 7 - Profiles
Die OPC UA Profiles werden hier als Gruppen von Services oder Funktionen dargestellt, die für die Konformitätsebenen-Zertifizierung verwendet werden können. Einzelne Funktionen werden in Konformitätseinheiten gruppiert, die wiederum weiter in Profiles unterteilt werden. Alle OPC UA Anwendungen müssen mindestens ein Stack-Profile implementieren. Sie können ausschließlich mit anderen OPC UA Anwendungen kommunizieren, bei denen das gleiche Stack-Profile implementiert wurde. Server und Clients werden anhand dieser Profiles zertifiziert. Server und Clients tauschen während des Verbindungsaufbaus die von ihnen unterstützten Profiles als Teil ihres Software Zertifikats aus.

Part 8 - Data Access
Das Information Model, das für den Zugriffstyp Data Access (DA) vorgesehen ist. enthält vor allem eine zusätzliche Definition von Variablentypen sowie eine ergänzende Beschreibung von AddressSpace-Objekten. Neben der Darstellung dieses Modells enhält der Abschnitt Erläuterungen zu den für DA benötigten Node-Klassen und Attributes sowie eine Beschreibung der DA-spezifischen Verwendung von Services für den Zugriff auf Prozessdaten.

Part 9 - Alarms and Conditions
Alarms and Conditions beschreibt die Repräsentation von konfigurierten Zuständen im OPC UA AddressSpace. Es werden die Konzepte Condition, Dialog, acknowledgeable Condition (quittierbare Bedingung), confirmable Condition (bestätigbare Bedingung) und Alarm vorgestellt. Zur Veröffentlichung dieser Informationen wird das in anderen Teilen der OPC UA Specification definierte Information Model erweitert und auf die alarmspezifische Verwendung der Services eingegangen.

Part 10 - Programs
In diesem Abschnitt wird das Konzept der Programs als komplexe, zustandsgesteuerte Funktionen in einem Server oder unterlagertem System eingeführt, die durch OPC UA Clients aufgerufen und verwaltet werden können. Die bereitgestellten Definitionen beschreiben die Standardrepräsentation von Programs im AddressSpace eines Servers. Es werden Methoden dargelegt, mit denen Programs verwaltet werden können.

Part 11 - Historical Access
Das Information Model, für Historical Access (HA), das in diesem Abschnitt erläutert wird, enthält vor allem zusätzliche und ergänzende Definitionen der Repräsentation historischer Seriendaten sowie historischer Eventdaten. Außerdem behandelt dieser Abschnitt die HA-spezifische Verwendung von Services für die Ermittlung und den Zugriff auf historische Daten und Events.

Part 12 - Discovery
Die wichtigste Zielsetzung dieses Abschnitts ist die Behandlung des Discovery-Prozesses, der es Clients ermöglicht, zunächst Server im Netzwerk zu ermitteln, um dann eine Möglichkeit zur Herstellung einer Verbindung zu finden. Es wird dargelegt, wie UA Clients und Server zusammenarbeiten, um Informationen auszutauschen, die in einem Netzwerk verteilt, auf verschiedenen Ressourcen vorhanden sind. Zur Erreichung dieses Ziels werden zwei Konzepte vorgestellt: Ein Discovery Server, der allgemeine Informationen verwaltet, sowie ein lokaler Discovery Server, dessen Hauptaufgabe in der Bereitstellung von Informationen liegt, die für lokale Ressourcen von Bedeutung sind. Abschließend wird auf die Erkennung von OPC UA-Anwendungen bei Verwendung allgemeiner Verzeichnisdienstprotokolle wie UDDI oder LDAP eingegangen.

Part 13 - Aggregates
Dieser Abschnitt spezifiziert das Information Model für Aggregates (Berechnungen) und beschreibt die Berechnung und Rückgabe von Aggregates wie Minimum, Maximum, Durchschnitt usw. Aggregates können sowohl mit Basis- (Live-) Daten als auch mit historischen (HA) Daten verwendet werden. Außerdem wird die aggregatspezifische Verwendung von Services behandelt.

In kompakter Form veröffentlicht im österreichischen Fachmagazin für Automatisierung, http://www.austromatisierung.at/

Teil 1: Status OPC UA
Teil 2: Entstehung und Ziele
Teil 3: 10 Gründe für OPC UA
Teil 5: Companion Standards
Teil 6: OPC UA Compliance Test
Teil 7: Toolkits
Teil 8: Ausblick

    
Copyright 2017 Buxbaum Automation GmbH