DE102007062986A1

DE102007062986A1 - Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA

Info

Publication number: DE102007062986A1
Application number: DE102007062986A
Authority: DE
Inventors: Wolfgang Dr.-Ing. Mahnke
Original assignee: ABB Research Ltd Switzerland; ABB Research Ltd Sweden
Current assignee: ABB Schweiz AG
Priority date: 2007-12-21
Filing date: 2007-12-21
Publication date: 2009-06-25
Anticipated expiration: 2027-12-22
Also published as: WO2009083133A1; US8549065B2; DE102007062986B4; CN101903837B; US20100306313A1; CN101903837A

Abstract

Die Erfindung bezieht sich auf ein Verfahren und eine entsprechende Einrichtung zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, und wobei zur Interaktion eines OPC UA Clients (1, 7) mit einem OPC-UA-Server (5, 8) OPC UA Serviceaufrufe verwendet werden. Zur Integration eines Transaktions-Kontexts in OPC-UA-Serviceaufrufen werden alle OPC UA Server (5, 8) des Systems mittels einer Transaktionsverwaltungskomponente (6) ergänzt, und für eine Durchführung von Transaktionen ertüchtigte OPC UA Clients (7) kommunizieren jeweils mit einem OPC UA Server (5) unter Verwendung von Transaktionen.

Description

Die Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zur Kommunikation zwischen Clients und Servern gemäß dem Standardprotokoll OPC UA. Das Verfahren und die Einrichtung sind für unterschiedliche Anwendungen geeignet, insbesondere zur Kommunikation in Systemen der Automatisierungstechnik.
OPC UA ist ein neues Standardprotokoll zur Hersteller-unabhängigen Kommunikation, insbesondere in der Prozessautomatisierung, spezifiziert durch die OPC Foundation. Der ursprüngliche Name für OPC war zwar OLE for Process Control, OPC wird aber inzwischen ohne einen Hinweis auf eine Abkürzung benutzt. UA steht für Unified Architecture. Nachstehend werden häufig englischsprachige Begriffe benutzt, da sie bestimmte im Standard definierte Funktionen oder Spezifikationen umschreiben.
In 1 und 2 sind bekannte Anordnungen zur Interaktion gemäß OPC-UA-Spezifikation dargestellt. Dabei zeigt 1 einen OPC-UA-Client 1, der unter Verwendung des OPC-UA-Protokolls und eines Kommunikationssystems 2 eine Interaktion mit einem OPC UA Server 3 mittels OPC-UA-Serviceaufrufen durchführt. Ein OPC UA Server kann aber gegenüber weiteren Servern auch als Client wirken und deren Daten zusammentragen und in seinem Adressraum Clients zur Verfügung stellen. In 2 ist eine solche Anordnung dargestellt, wobei ein OPC-UA-Client 1 eine Interaktion mit einem als Aggregating OPC UA Server 4 bezeichneten Server durch führt, der wiederum über das Kommunikationssystem 2 mit zwei OPC UA Server 3 kommuniziert.
Client-Server-Betrieb gemäß OPC-UA-Standard findet in vielen Gebieten, wie beispielsweise in Fertigungsmanagementsystemen oder in der Produktionsplanung Anwendung, und allgemein in der Leittechnik, wobei Client- und Serverfunktionen z. B. in Geräten und Controllern implementiert sind. OPC UA ermöglicht in solchen Anordnungen nicht nur das Lesen und Schreiben von Daten, sondern auch Organisationsstrukturen für Daten zu ändern. Dadurch sind OPC UA Clients in der Lage, sowohl komplexe Konfigurationsaufgaben, als auch Engineering-Aufgaben oder andere Aufgaben zu lösen, die Daten schreiben und/oder Strukturänderungen erfordern. Es hängt von solchen Tasks ab, ob ein OPC UA Client entweder alle oder keine Änderungen an mehreren OPC UA Serviceaufrufen durchzuführen hat. Dies ist besonders von Bedeutung, wenn mehrere OPC UA Clients zugleich Änderungen an einem OPC UA Server vornehmen. Eine lange von Datenbanksystemen bekannte Lösung für solche Probleme ist die Nutzung von Transaktionen. Für OPC UA ist aber bisher kein Transaktions-Kontext spezifiziert. Die Granularität von Datenmanipulationsaktionen erfordert mehrere OPC UA Serviceaufrufe, wobei selbst für ein einzelner OPC UA Serviceaufruf kein Transaktions-Kontext spezifiziert ist. Es kann sogar bei einem einzelnen OPC UA Serviceaufruf, der z. B. Schreiben auf mehreren Werten enthält, der Fall eintreten, dass einzelne Schreibvorgänge erfolgreich sind und andere nicht.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren und eine Einrichtung anzugeben, mit denen eine Möglichkeit zur Durchführung von Transaktionen im Rahmen von OPC-UA-Serviceaufrufen erreicht wird.
Diese Aufgabe wird gelöst durch ein Verfahren zur Kommunikation zwischen Clients und Servern unter Verwendung des OPC-UA-Protokolls, das die im Anspruch 1 angegebenen Merkmale aufweist. Vorteilhafte Ausgestaltungen und eine entsprechende Einrichtung sind in weiteren Ansprüchen angegeben.
Mit der Erfindung wird demnach vorgeschlagen, zur Integration eines Transaktions-Kontexts in OPC UA Serviceaufrufen alle OPC UA Server des Systems mittels einer Transaktionsverwaltungskomponente zu ergänzen. Zur Durchführung von Transakti onen ertüchtigte OPC UA Clients sind dadurch in der Lage jeweils mit einem OPC UA Server unter Verwendung von Transaktionen zu kommunizieren.
Eine weitere Erläuterung der Erfindung und deren Vorteile ergibt sich aus der nachstehenden Beschreibung eines Ausführungsbeispiels anhand der Zeichnungsfiguren.
Es zeigen:
1 eine Anordnung mit OPC UA Client und OPC UA Server gemäß dem Stand der Technik,
2 eine OPC-UA-Client/Server-Anordnung mit eingefügtem Aggregating OPC UA Server gemäß dem Stand der Technik,
3 eine erfindungsgemäße Anordnung mit OPC UA Client und einem zur Durchführung von Transaktionen eingerichteten OPC-UA-Server,
4 eine erfindungsgemäße Anordnung mit OPC UA Client, zur Durchführung von Transaktionen eingerichtetem Aggregating OPC UA Server, sowie ebenfalls für Transaktionen eingerichteten OPC UA Servern,
5 einen erfindungsgemäßen OPC UA Server, und
6 ein Ablaufdiagramm für eine beispielhafte Transaktion.
Die Anordnung gemäß 3 enthält einen OPC UA Server 5, der mittels einer Transaktionsverwaltungskomponente 6 zur Durchführung von Transaktionen ertüchtigt ist. Grundsätzlich kann jeder generische OPC UA Client 1 über das Kommunikationssystem 2 mit dem OPC UA Server 5 kommunizieren. Die Durchführung von Transaktionen ist allerdings nur mit einem für Transaktionen eingerichteten OPC UA Client 7 möglich. Einzelheiten hierzu sind weiter unten erläutert.
4 zeigt ähnlich wie 2 eine Anordnung mit einem Aggregating OPC UA Server, wobei in 4 jedoch ein Aggregating OPC UA Server 8 eingesetzt ist, der eine Transaktionsverwaltungskomponente 6 enthält. Wie bei der Anordnung gemäß 3 werden Transaktionen im Fall einer Kommunikation mit einem für Transaktionen eingerichteten OPC-UA-Client 7 unterstützt, und so auch wenn OPC-UA-Server 5, die jeweils mittels einer Transaktionsverwaltungskomponente 6 zur Durchführung von Transaktionen ertüchtigt sind und ein Zweiphasen-Commit-Protokoll unterstützen, mit dem Aggregating OPC UA Server 8 kommunizieren.
5 zeigt beispielhaft wie eine Transaktionsverwaltungskomponente 6 in einem OPC UA Server 5 implementiert sein kann. Der OPC UA Server 5 erhält seine Daten unter Verwendung der strukturierten Abfragesprache SQL aus einer Konfigurationsdatenbank 9 und außerdem Echtzeitdaten von Controllern 10 und daran angeschlossenen Geräten 11. Die Konfigurationsdatenbank 9 ist dafür eingerichtet, Transaktionen zu unterstützen, so dass der OPC UA Server 5 Transaktionen an die Konfigurationsdatenbank 9 weiterleiten kann. Die Controller 10 und Geräte 11 unterstützen typisch keine Transaktionen, weshalb die Transaktionsverwaltungskomponente 6 mittels einer Einrichtung 12 zur Transaktion von Echtzeitdaten dies berücksichtigt. Aufgrund interner Kenntnisse kann sie prüfen, ob bestimmte verlangte Änderungen zulässig sind und die Durchführung der Änderungen verzögern, bis der jeweilige OPC UA Client 7 die Transaktion bestätigt. In Verbindung mit einem Cache-Speicher 13 und unter Verwendung von Caching-Mechanismen speichert der OPC UA Server 5 potentiell geänderte Daten, um dem OPC-UA-Client 7 eine korrekte Darstellung der Daten im Transaktions-Kontext zu geben. Falls es nötig ist, dass der OPC UA Server 5 Daten in einem Gerät 11 unverzögert ändert, kann er Kompensationsmechanismen nutzen, um die Daten außerhalb einer Transaktion zu ändern, wenn ein OPC UA Client 7 eine Transaktion abbricht.
Wenn ein Zugriff eines OPC UA Clients 7, bzw. typisch eines OPC UA Clients 1 nicht in einem Transaktionskontext erfolgt, umgeht der OPC UA Server 5 die Transaktionsverwaltungskomponente 6 und greift direkt auf die Konfigurationsdatenbank 9 oder Daten von Controllern 10 bzw. Geräten 11 zu.
Verfahrenscharakteristiken und typische Ablaufschritte sind nachstehend anhand eines in 6 dargestellten beispielhaften Ablaufdiagramms beschrieben. In 6 sind vier an einer Transaktion beteiligte Komponenten dargestellt, nämlich ein OPC UA Client 7, ein OPC UA Server 5, eine Transaktionsverwaltungskomponente 6 und ein Lieferant von Echtzeitdaten, z. B. ein Controller 10. Vor der Erläuterung der dargestellten Ablaufschritte werden zunächst allgemein Charakteristiken der erfindungsgemäßen Nutzung von Transaktionen beschrieben.
Der Adressraum eines für die Durchführung von Transaktionen eingerichteten OPC UA Servers 5 enthält zusätzliche OPC-UA-Methoden, die aufgerufen werden für den Start, zum Abschluss oder für den Abbruch einer Transaktion. Die Methodenparameter unterscheiden sich je nach gewählter Transaktionsart, wobei z. B. unterschiedliche Isolation Levels oder verschachtelte Transaktionen unterstützt werden.
Ein OPC UA Client 7, der einen OPC-UA-Serviceaufruf in einem Transaktionskontext durchführen möchte, ruft eine Methode für den Start einer Transaktion auf. Im Rahmen einer als OPC-UA-Session bestehenden Sitzung eines OPC UA Clients 7 bewirkt dies einen Wechsel des OPC UA Servers 5 in einen Transaktionskontext. Daraufhin wird jede OPC-UA-Service-Anforderung des OPC UA Clients 7 bezüglich Datenzugriff und Datenmanipulation im Rahmen der OPC-UA-Session vom OPC UA Server 5 im Transaktionskontext durchgeführt.
Abhängig von Sperrmechanismen, die im OPC-UA-Server 5 implementiert sind, kann der OPC UA Client 7 spezielle Status-Codes für OPC-UA-Service-Anforderungen gemeldet bekommen, wenn Aktionen wegen locking restrictions oder timeouts fehlschlagen. Auch OPC UA Clients die nicht Transaktionen nutzen, können solche Status-Codes erhalten, weil bestimmte Werte blockiert sein können.
Ein OPC UA Client 7 kann auch Status-Codes gemeldet bekommen, die diejenigen Teile einer OPC-UA-Service-Anforderung identifizieren, die zur Fehlermeldung geführt haben. Wenn beispielsweise fünf Werte geschrieben werden sollten, kann gemeldet werden, dass das Schreiben des zweiten und vierten Werts fehlgeschlagen ist.
Falls ein OPC UA Client 7 eine Transaktion abbrechen möchte, ruft er eine Methode für den Abbruch der Transaktion auf. In diesem Fall werden alle bereits erfolgten Änderungen am System zurückgenommen, beispielsweise der OPC UA Server 5 in den Status vor den Änderungen zurückgesetzt. Abhängig vom gewählten Sperrmechanismus könnten aber OPC UA Clients betroffen sein, wenn sie während der Änderung auf Daten zugegriffen haben.
Um gegebenenfalls eine Transaktion zu bestätigen, kann ein OPC UA Client 7 eine Methode zur Bestätigung einer Transaktion aufrufen. In diesem Fall versucht der OPC UA Server 5 alle Änderungen persistent zu machen. Wenn die Änderungen nicht dauerhaft übernommen werden können, bricht der OPC UA Server 5 die Transaktion ab und gibt die Bestätigungsmethode zusammen mit einem entsprechenden Status-Code zurück. Wenn alle verlangten Änderungen persistent werden können, meldet der OPC UA Server 5 ein entsprechendes Ergebnis zurück.
Wenn ein OPC UA Client 7 einige OPC-UA-Service-Anforderungen ohne Transaktionskontext und andere mit Transaktionskontext aufrufen möchte, muss er mehrere OPC UA Sessions einrichten.
Gemäß einer vorteilhaften Ausgestaltung kann der OPC UA Server 5 geschachtelte Transaktionen unterstützen. In diesem Fall kann der OPC UA Client 7 eine Methode für den mehrfachen Start einer Transaktion aufrufen, und mit einem Vorgang eine geschachtelte Transaktion insgesamt abbrechen. Ohne eine solche Unterstützung geschachtelter Transaktionen würde ein OPC UA Client 7 eine Fehlermeldung erhalten, wenn er eine Methode zum Starten einer Transaktion ein zweites mal anfordern würde, ehe er die erste Transaktion abgebrochen oder bestätigt hat.
Gemäß einer weiteren Ausgestaltung kann der OPC UA Server 5 Informationen über unterstützte Berechtigungsstufen (Isolation Levels) in seinem Adressraum enthalten, und Methoden zur Durchführung von Transaktionen könnten die gewählte Berechtigungsstufe als Eingangsparameter verwenden. Falls der OPC UA Server 5 jedoch nur eine Berechtigungsstufe unterstützt, ist diese Ausgestaltung nicht erforderlich.
Das in 6 dargestellte Ablaufdiagramm bezieht sich auf Interaktionen, wie oben bereits allgemein beschrieben, zwischen einem OPC UA Client 7 und einem OPC UA Server 5 zur Durchführung von Datenmanipulationsmaßnahmen in einem Transaktionskontext. Dabei sind Rückmeldungen des Servers an den Client zur Vereinfachung der Darstellung nicht gezeigt. In einem ersten Schritt 20 wird eine OPC UA Session eingerichtet. In einem zweiten Schritt 21 ruft der OPC UA Client 7 eine Methode zum Beginn einer Transaktion auf. in einem dritten Schritt 22 erhält die Transaktionsverwaltungskomponente 6 erforderliche Informationen, wie beispielsweise über den Start der Transaktion und den aufrufenden Client. In einem vierten Schritt 23 verlangt der OPC UA Client 7 eine Manipulation erster Daten. Diese Aufforderung wird in einem fünften Schritt 24 vom OPC UA Client 7 an die Transaktionsverwaltungskomponente 6 weitergeleitet, in der die Zulässigkeit der verlangten Änderung in einem sechsten Schritt 25 geprüft wird. Im dargestellten Beispiel verlangt der OPC UA Client 7 in einem siebten Schritt 26 innerhalb der bestehenden Transaktion eine Manipulation zweiter Daten, die in einem achten Schritt 27 an die Transaktionsverwaltungskomponente 6 weitergeleitet und dort in einem neunten Schritt 28 geprüft wird. Um die Transaktion abzuschließen, ruft der OPC UA Client 7 in einem zehnten Schritt 29 eine Methode zur Bestätigung der Transaktion auf. In einem elften Schritt 30 wird der Bestätigungsauftrag an die Transaktionsverwaltungskomponente 6 weitergeleitet, die schließlich in einem zwölften Schritt 31 die gewünschte Manipulation der ersten und zweiten Daten im Controller 10 veranlasst.
Als alternative Lösung zum vorstehend beschriebenen Verfahren könnten zusätzliche Services definiert werden, die im Kontext von OPC UA Sessions benutzt werden, um Transaktionen einzurichten, abzubrechen oder abzuschließen. Allerdings müssten dafür dem OPC UA Service Framework entsprechende zusätzliche Services hinzugefügt und sowohl in Clients als auch in Servern benötigte Funktionen implementiert werden.
Eine andere, in der Nutzung von Transaktionen allerdings weniger flexible alternative Lösung könnte darin bestehen, generische Methoden mit allen erforderlichen Änderungen in einer Transaktion zu definieren. Eine solche Methode enthielte als Input ein Array von zu schreibenden Werten, sowie Arrays von Nodes, z. B. als Teil der Adressraumstruktur in OPC UA oder z. B. für Löschvorgänge.

Claims

Verfahren zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, und wobei zur Interaktion eines OPC UA Clients (1, 7) mit einem OPC UA Server (5, 8) OPC UA Serviceaufrufe verwendet werden, dadurch gekennzeichnet, dass zur Integration eines Transaktions-Kontexts in OPC UA Serviceaufrufen alle OPC UA Server (5, 8) des Systems mittels einer Transaktionsverwaltungskomponente (6) ergänzt werden, und für eine Durchführung von Transaktionen ertüchtigte OPC UA Clients (7) jeweils mit einem OPC UA Server (5) unter Verwendung von Transaktionen kommunizieren.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass auch Aggregating OPC UA Server (8) jeweils mit einer Transaktionsverwaltungskomponente (6) ergänzt werden, und sowohl mit ertüchtigten OPC UA Clients (7), als auch in einer Client-Funtion mit OPC UA Servern (5) Transaktionen durchführen.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die OPC UA Server (5, 8) dafür eingerichtet werden, auch mit OPC UA Clients (1), die nicht zur Durchführung von Transaktionen ertüchtigt sind, ohne Nutzung von Transaktionen zu kommunizieren.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zur Durchführung einer Kommunikation zwischen einem OPC UA Client (7) und einem OPC UA Server (5) unter Verwendung von Transaktionen – in einem ersten Schritt (20) eine OPC-UA-Sitzung eingerichtet wird, – in einem zweiten Schritt (21) vom OPC UA Client (7) eine Methode zum Beginn einer Transaktion aufgerufen wird, – in einem dritten Schritt (22) die Transaktionsverwaltungskomponente (6) des OPC UA Servers (5) erforderliche Informationen über den Beginn einer Transaktion erhält, – in weiteren Schritten (23–28) vom OPC UA Client (7) Manipulationen von Daten vorgenommen und deren Zulässigkeit von der Transaktionsverwaltungskomponente (6) geprüft werden, und schließlich zum Abschluss der Transaktion – vom OPC UA Client (7) eine Methode zur Bestätigung der Transaktion aufgerufen wird (Schritt 29), und nach entsprechender Prüfung durch die Transaktionsverwaltungskomponente (6) die gewünschten Manipulationen von Daten in einer adressierten Einrichtung (10) veranlasst werden.
Einrichtung zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, und wobei zur Interaktion eines OPC UA Clients (1, 7) mit einem OPC UA Server (5, 8) OPC UA Serviceaufrufe verwendet werden, dadurch gekennzeichnet, dass zur Integration eines Transaktions-Kontexts in OPC UA Serviceaufrufen alle OPC UA Server (5, 8) des Systems mittels einer Transaktionsverwaltungskomponente (6) ergänzt sind, und zur Durchführung von Transaktionen ertüchtigte OPC UA Clients (7) im System vorhanden sind.
Einrichtung nach Anspruch 5, dadurch gekennzeichnet, dass auch Aggregating OPC UA Server (8) im System jeweils mit einer Transaktionsverwaltungskomponente (6) ergänzt und dafür eingerichtet sind, sowohl mit ertüchtigten OPC UA Clients (7), als auch in einer Client-Funtion mit OPC UA Servern (5) Transaktionen durchzuführen.
Einrichtung nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass der OPC UA Server (5) mit implementierter Transaktionsverwaltungskomponente (6) dafür eingerichtet ist, erforderliche Konfigurationsdaten aus einer Konfigurationsdatenbank (9) und außerdem Echtzeitdaten von Controllern (10) und daran angeschlossenen Geräten (11) oder anderen Datenquellen zu übernehmen, bzw. dort Daten zu manipulieren, und die Konfigurationsdatenbank 9 dafür eingerichtet ist, Transaktionen zu unterstützen.
Einrichtung nach Anspruch 7, dadurch gekennzeichnet, dass der OPC UA Server (5) mittels einer Einrichtung (12) zur Transaktion von Echtzeitdaten dafür eingerichtet ist zu prüfen, ob bestimmte verlangte Änderungen zulässig sind und die Durchführung der Änderungen zu verzögern, bis der jeweilige OPC UA Client 7 die Transaktion bestätigt.
Einrichtung nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass der OPC UA Server (5) mittels einem Cache-Speicher (13) und unter Verwendung von Caching-Mechanismen dafür eingerichtet ist, potentiell geänderte Daten zu speichern, um dem OPC UA Client 7 eine korrekte Darstellung der Daten im Transaktions-Kontext zu geben.
Einrichtung nach einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, dass der OPC UA Server (5) dafür eingerichtet ist, geschachtelte Transaktionen zu unterstützen.