DE102007062985B4

DE102007062985B4 - Verfahren und Einrichtung zur Kommunikation gemäß dem Standardprotokoll OPC UA in einem Client-Server-System

Info

Publication number: DE102007062985B4
Application number: DE102007062985.2A
Authority: DE
Inventors: Dr.-Ing. Mahnke Wolfgang
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: 2014-01-02
Anticipated expiration: 2027-12-22
Also published as: WO2009083091A2; US20100281097A1; WO2009083091A3; US8423608B2; DE102007062985A1; CN101981897A; CN101981897B

Abstract

Verfahren zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, wobei zur Interaktion eines OPC UA Clients mit einem OPC UA Server eine OPC UA Session eingerichtet wird und im Rahmen einer solchen OPC UA Session OPC UA Serviceaufrufe aus einem Satz von im OPC-UA-Standard definierten OPC UA Services verwendet werden, dadurch gekennzeichnet, dass zur Integration von zusätzlichen Services in das Rahmenwerk von OPC UA Services
• der standardgemäße OPC UA Stack sowohl auf der Client- wie auch auf der Server-Seite erweitert ist,
• die zusätzlichen Services innerhalb der OPC UA Session mittels eines, den Standard-Client (44) ergänzenden Client-Teils (45) für die Nutzung der zusätzlichen Services aufgerufen werden, und
• die zusätzlichen Services mittels eines, den Standard-Server (46) ergänzenden Server-Teils (47) zur Bereitstellung der zusätzlichen Services behandelt werden.

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 ist eine bekannte Anordnung zur Interaktion gemäß OPC-UA-Spezifikation zwischen einem OPC UA Client 1 und einem OPC UA Server 3 unter Verwendung eines Kommunikationssystems 2, typisch eines Netzwerks, dargestellt. Dabei benutzt der OPC UA Client 1 zur Interaktion OPC UA Serviceaufrufe aus einem Satz von OPC UA Services die im OPC-UA-Protokoll spezifiziert sind, wie z. B. beschrieben in Leitner, S.-H.; Mahnke, W.: OPC UA – Service-oriented Architecture for Industrial Applications. In: Softwaretechnik-Trends, Band 26, 2006, Heft 4, ISSN 0720-8928. Es existieren unterschiedliche Technologie-Abbildungen (Mapping) für die Übertragung von OPC UA Serviceaufrufen über Kommunikationssysteme. Zur Zeit existiert ein TCP-basiertes Mapping und ein Mapping auf Basis von Web Services.
Zur Kommunikation eines OPC UA Clients 1 mit einem OPC UA Server 3 muss der OPC UA Client 1 eine OPC UA Session einrichten und im Rahmen einer solchen Sitzung OPC UA Services aufrufen. Solche OPC UA Serviceaufrufe innerhalb einer OPC UA Session bewirken einen Austausch von Nutzer-Kontext innerhalb der betroffenen Einrichtungen sowie einen Ablauf im Sicherheits-Kontext der OPC UA Session.
2 zeigt einen solchen typischen Ablauf einer OPC UA Session. Dabei ist dargestellt, dass ein OPC UA Client 1 in einem ersten Schritt 21 die Einrichtung einer OPC UA Session veranlasst, und in einem zweiten Schritt 22 OPC UA Services aufruft. Als dritten Schritt 23 sind Aktionen des OPC UA Server 3 zur Verifikation der Anforderungen des OPC UA Client 1 bezeichnet. In einem vierten Schritt 24 wird die OPC UA Session geschlossen. Rückmeldungen des OPC UA Servers 3 an den OPC UA Client 1 sind in 2 nicht dargestellt.
Der OPC-UA-Standard ermöglicht es einem OPC UA Client sogenannte Subscriptions zu verwenden, die vom OPC UA Server verwaltet werden und möglicherweise auch über die Dauer einer OPC UA Session hinaus gültig bleiben. Auf diese Weise kann ein OPC UA Client eine OPC UA Session abschließen und später eine OPC UA Session neu eröffnen, Subscriptions in die neue OPC UA Session transferieren, und alle Resultate aus der früheren OPC UA Session übernehmen.
Im OPC-UA-Standard ist ein Satz von OPC UA Services für unterschiedliche Aufgaben in der Prozessautomation und anderen Anwendungen definiert. Ein Nachteil besteht jedoch darin, dass für manche Anwendungen zusätzliche Services für komplexe Aufgaben benötigt werden, beispielsweise für komplexe Konfigurations- oder Engineering-Aufgaben, die mittels der definierten OPC UA Services nicht oder nur sehr umständlich lösbar sind. Außerdem können bereits sogenannte Legacy Services definiert sein, wobei solche älteren Mechanismen gegebenenfalls auch dann – im Rahmen von sogenannten zusätzlichen Services – weiterverwendet werden sollen, wenn ansonsten das OPC-UA-Protokoll benutzt wird.
3 zeigt eine Möglichkeit gemäß dem Stand der Technik zur Nutzung zusätzlicher Services. Dargestellt ist ein Client 31, der sowohl als OPC UA Client 33, als auch als Client 35 für die Verwendung von zusätzlichen Services eingerichtet ist. Ein Server 32 hat sowohl die Funktion eines OPC UA Servers 34, als auch die eines Servers 36 für die Bereitstellung von zusätzlichen Services. Der OPC UA Client 31 und der OPC UA Server 34 kommunizieren gemäß OPC-UA-Protokoll. Die Kommunikation zwischen dem Client 35 für die Verwendung von zusätzlichen Services und dem Server 36 für die Bereitstellung von zusätzlichen Services erfolgt völlig separat mittels Legacy Serviceaufrufen.
Diese bekannte Lösung zur Verwendung von zusätzlichen Services hat sowohl für die Entwicklung als auch für die Anwendung eines entsprechenden Systems einige Nachteile und Grenzen. Das Gesamtsystem wird komplex und teuer, weil mehrere Komponenten zur Verwaltung der Kommunikation dupliziert werden müssen, wie z. B. solche für die Implementierung von Sicherheitsmechanismen oder zur Codierung oder Verschlüsselung von Daten. Der Client muss eine OPC UA Session einrichten um OPC UA Services zu nutzen und zusätzlich etwas ähnliches um zusätzliche Services nutzen zu können, wobei zusätzliche Sicherheitsmaßnahmen erforderlich sind. Während der Dauer der beiden parallelen Sitzungen werden sowohl auf Client- als auch Server-Seite zusätzlich Ressourcen belegt, was sich beispielsweise auf benötigte Speicherkapazität, Verarbeitungsgeschwindigkeit und Netzwerkbelegung auswirkt.
Davon ausgehend liegt der Erfindung die Aufgabe zugrunde, ein Verfahren und eine Einrichtung anzugeben, um eine Möglichkeit zur Integration von zusätzlichen Services in das Rahmenwerk von OPC UA Services zu schaffen.
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 werden demnach ein Verfahren und eine Einrichtung vorgeschlagen, bei denen vom OPC UA Client zusätzliche Services innerhalb einer OPC UA Session aufgerufen werden, wobei zur Integration der zusätzlichen Services in das Rahmenwerk der OPC UA Services der standardgemäße OPC UA Stack sowohl auf der Client- wie auch auf der Server-Seite erweitert ist, die zusätzlichen Services innerhalb der OPC UA Session mittels eines, den Standard-Client ergänzenden Client-Teils für die Nutzung der zusätzlichen Services aufgerufen werden, und die zusätzlichen Services mittels eines, den Standard-Server ergänzenden Server-Teils zur Bereitstellung der zusätzlichen Services behandelt werden.
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 einen typischen Ablauf einer OPC UA Session,
3 eine Möglichkeit zur Nutzung zusätzlicher Services gemäß dem Stand der Technik,
4 eine erfindungsgemäße Lösung zur Integration von zusätzlichen Services in das Rahmenwerk von OPC UA Services, und
5 ein beispielhaftes Ablaufdiagramm im Fall der Nutzung von integrierten zusätzlichen Services.
4 zeigt eine erfindungsgemäße Anordnung mit einem Client 41 und einem Server 43, die mittels einer Kommunikationseinrichtung 42 verbunden sind. Der Client 41 enthält einen ersten OPC-UA-Client-Teil 44 für den Aufruf von OPC UA Services und einen zweiten Client-Teil 45 für die Nutzung von zusätzlichen Services. Entsprechend enthält der Server 43 einen ersten OPC-UA-Server-Teil 46 zur Bereitstellung von OPC UA Services und einen zweiten Server-Teil 47 zur Bereitstellung von zusätzlichen Services. Die zusätzlichen Services oder Legacy Services sind in das OPC UA Service Framework integriert. Dadurch kann der Aufruf von zusätzlichen Services im Rahmen einer eingerichteten OPC UA Session erfolgen. Es werden auch OPC-UA-Sicherheitsmechanismen und gegebenenfalls auch die Codierung der Daten für die Übertragung benutzt. Trotzdem passen die Parameter für Aufrufe durch den Client und Antworten des Servers zu den Parametern der zusätzlichen Services. Der Client 41 ruft daher mittels seines zweiten Client-Teils 45 und unter Verwendung der korrespondierenden Parameter die zusätzlichen Services auf, und erhält eine Reaktion des zweiten Server-Teils 47.
In 5 sind beispielhaft Sequenzen des Ablaufs einer OPC UA Session dargestellt, wobei Antworten des Servers nicht gezeigt sind. In einem ersten Vorgang 51 nimmt der Client 41 mit dem Server 43 Kontakt auf, um eine OPC UA Session einzurichten. In einem zweiten Schritt 52 ruft der Client 41 mittels seines ersten OPC-UA-Client-Teils 44 standardgemäß OPC UA Services auf, die vom ersten OPC-UA-Server-Teil 46 des Servers 43 in einem dritten Schritt 53 behandelt werden. Es ist weiter dargestellt, dass der Client 41 im Rahmen der bestehenden OPC UA Session z. B. in einem vierten Schritt 54 auch zusätzliche Services aufrufen kann, die in einem fünften Schritt 55 an den zweiten Server-Teil 47 weitergegeben und von diesem in einem sechsten Schritt 56 behandelt werden. In einem siebten Schritt 57 ruft der Client 41 dann nochmals OPC UA Services auf, die in einem achten Schritt 58 vom ersten OPC-UA-Server-Teil 46 behandelt werden. Im neunten Schritt 59 wird in üblicher Weise die OPC UA Session beendet.
In ähnlicher Weise wie die oben genannten Subscriptions, die auch über die Dauer einer OPC UA Session hinaus gültig bleiben können, können auch zusätzliche Services einen entsprechenden Status verwalten. Auch im erfindungsgemäßen System kann der Client 41 eine neue OPC UA Session einrichten und Subscriptions in die neue OPC UA Session transferieren. Auf diese Weise hilft die Nutzung von OPC UA als Zwischenebene oder Intermediate Layer die Funktionalität von Legacy Services zu erweitern.
Zur Realisierung der vorstehend erfindungsgemäß vorgeschlagenen Integration von zusätzlichen Services in das OPC UA Service Framework muss die Komponente, welche die Kommunikation gemäß OPC-UA-Standard verwaltet, also der OPC UA Stack sowohl auf der Client- wie auch auf der Server-Seite erweitert werden, um den Aufruf von zusätzlichen Services zu unterstützen. Trotz der Erweiterung des OPC UA Stack können der Client und der Server auch mit nicht erweiterten Servern bzw. Clients im System zusammenarbeiten. Es versteht sich allerdings, dass ein erweiterter Client nur die OPC UA Services eines nicht erweiterten Servers, also daraus keine zusätzlichen Services aufrufen kann. Entsprechend kann ein erweiterter Server keine Aufrufe von zusätzlichen Services erhalten, wenn der aufrufende Client nicht erweitert ist.
Die Art und Weise wie ein erweiterter OPC UA Client mit einem erweiterten OPC UA Server zusammenarbeitet lässt sich durch die nachstehenden Charakteristiken beschreiben:

– Der Client initiiert eine OPC UA Session. Dies schließt eine Information über den Nutzer, Client-Zertifikate, Sicherheitsangaben und Codierungen ein, wobei einige solcher settings bei OPC UA durch das standardgemäße Secure Channel establishment vorgenommen werden.
– Der Client kann ebenso wie nicht erweiterte Clients OPC UA Services benutzen.
– Optional können die zusätzlichen Services im Address Space von OPC UA aufgeführt werden. So kann z. B. ein Client mittels der Standard-OPC-UA-Kommunikation Information erhalten über verfügbare zusätzliche Services.
– Der Client kann entweder – wie vorgenannt – Information über zusätzliche Services aus Angaben im Adressraum erhalten, wenn diese Option eingerichtet ist, oder aus anderen Quellen.
– Der Client kann zusätzliche Services innerhalb einer OPC UA Session aufrufen.
– Optional kann der Client den Cancel Service von OPC UA auch zum Beenden eines Aufrufs von zusätzlichen Services nutzen.
– Optional kann der OPC-UA-Server OPC UA Events nutzen, um dem Client Daten eines zusätzlichen Serviceaufrufen zu zeigen. Diese Daten können beispielsweise Information darüber enthalten wie weit der Service vorangeschritten ist und welche Zwischenergebnisse es gibt.
– Der Client kann eine OPC UA Session abschließen. Je nach zusätzlichem Service kann die Lebensdauer solcher Services von der Dauer einer Session unabhängig sein, und somit noch existieren nachdem eine Session geschlossen ist, oder kann gelöscht werden nach Abschluss der Session.

Wie oben dargelegt, ist zur Realisierung der Erfindung eine Erweiterung des OPC UA Stack erforderlich. Um den damit verbundenen Entwicklungsaufwand zu vermeiden wäre eine alternative Lösung zusätzliche Services in OPC UA Methods zu packen, ohne Erweiterung des Protokolls. In diesem Fall würden vom Server bereitzustellende zusätzliche Services in eine sogenannte Wrapper Komponente gebracht. Solche Services könnten z. B. in WSDL (Web Services Description Language) definierte Web Services sein. Für Aufruf- und Antwort-Teile der Services käme – beispielsweise automatisiert – eine Abbildung in Input- und Output-Parameter von OPC UA Methods in Frage. Das Abbrechen von Services die mittels OPC UA Methods aufgerufen wurden könnte durch Abbrechen beziehungsweise Abbruch des Method Serviceaufrufs von OPC UA erfolgen. Der Client benötigt bei dieser Lösung ebenfalls eine Wrapper oder Wrapping Komponente um Serviceaufrufe in eine OPC UA Method zu packen und um Output-Parameter des Aufrufs in eine Service-Antwort zu wandeln. Aus mehreren Gründen – wie z. B. zusätzlicher Overhead für die Abbildung und ungünstige Darstellung der Services im OPC-UA-Adressraum – wird die erfindungsgemäße Lösung zur Integration von zusätzlichen Services in das OPC UA Service Framework als vorteilhafter erachtet.

Claims

Verfahren zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, wobei zur Interaktion eines OPC UA Clients mit einem OPC UA Server eine OPC UA Session eingerichtet wird und im Rahmen einer solchen OPC UA Session OPC UA Serviceaufrufe aus einem Satz von im OPC-UA-Standard definierten OPC UA Services verwendet werden, dadurch gekennzeichnet, dass zur Integration von zusätzlichen Services in das Rahmenwerk von OPC UA Services • der standardgemäße OPC UA Stack sowohl auf der Client- wie auch auf der Server-Seite erweitert ist, • die zusätzlichen Services innerhalb der OPC UA Session mittels eines, den Standard-Client (44) ergänzenden Client-Teils (45) für die Nutzung der zusätzlichen Services aufgerufen werden, und • die zusätzlichen Services mittels eines, den Standard-Server (46) ergänzenden Server-Teils (47) zur Bereitstellung der zusätzlichen Services behandelt werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die zusätzlichen Services im Address Space von OPC UA aufgeführt werden und der Client (41) mittels Standard-OPC-UA-Kommunikation eine Information über verfügbare zusätzliche Services erhält.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der OPC UA Client (41) den standardgemäßen OPC UA Cancel Service zum Beenden eines Aufrufs der zusätzlichen Services benutzt.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass – in einem ersten Schritt (51) die OPC UA Session eingerichtet wird, – in einem der weiteren Schritte (54) vom Client (41) die zusätzliche Services aufgerufen werden, – ein solcher Aufruf des Clients (41) vom Server (43) in einem weiteren Schritt (55) an seinen Server-Teil (47) zur Bereitstellung der zusätzlichen Services weitergegeben wird, – vom Server-Teil (47) der Aufruf der zusätzlichen Services in einem weiteren Schritt (56) behandelt wird, und – vom Client (41) durch standardgemäßen Aufruf (59) einer Methode zum Beenden der OPC UA Session alle Transaktionen, auch solche unter Nutzung von zusätzlichen Services, geschlossen werden.
Einrichtung zur Kommunikation zwischen Clients und Servern eines Client/Server-Systems unter Verwendung des Standardprotokolls OPC UA, wobei ein OPC UA Client zur Interaktion mit einem OPC UA Server die Einrichtung einer OPC UA Session veranlasst und im Rahmen einer solchen OPC UA Session OPC UA Serviceaufrufe aus einem Satz von im OPC-UA-Standard definierten OPC UA Services benutzt, dadurch gekennzeichnet, dass zur Integration von zusätzlichen Services in das Rahmenwerk von OPC UA Services • der standardgemäße OPC UA Stack sowohl auf der Client- wie auch auf der Server-Seite erweitert ist, • die zusätzlichen Services innerhalb der OPC UA Session mittels eines, den Standard-Client (44) ergänzenden Client-Teils (45) für die Nutzung der zusätzlichen Services aufrufbar sind, und • im Server (43) ein den Standard-Server (46) ergänzender Server-Teil (47) zur Bereitstellung und Behandlung der zusätzlichen Services implementiert ist.
Einrichtung nach Anspruch 5, dadurch gekennzeichnet, dass der Server (43) OPC UA Events nutzt, um dem Client (41) Daten eines zusätzlichen Serviceaufrufs zu zeigen, wobei die Daten eine Information darüber enthalten, wie weit der Service vorangeschritten ist und welche Zwischenergebnisse es gibt.