Verfahren und Vorrichtung zur Umsetzung eines Transaktionskonzepts bei OPC UA mittels Time-Out Mechanismus

OPC UA (OPC Unified Architecture ) ist ein industrielles Standardprotokoll der OPC Foundation zur hersteller-unabhängigen Kommunikation für den Austausch von Maschinendaten insbesondere in der Prozessautomatisierung.

OPC UA ist ein relativ neuer Standard, bei dem der ursprüngliche Fokus nicht auf der Steuerung einer Industrieanlage lag, sondern vielmehr beim standardisierten Informationsaustausch insbesondere zwischen Geräten unterschiedlicher Hersteller .

Inzwischen ist OPC UA auch direkt in automatisierungstechnischen Geräten integriert, sodass die Notwendigkeit zum konsistenten Schreiben von Daten entsteht.

In automatisierungstechnischen Anlagen besteht die Notwendigkeit, zwischen unterschiedlichen Geräten Prozessinformationen (wie Prozesswerte, Messwerte, Parameter, Steuerungsbefehle) auszutauschen. Hierbei ist es wichtig, dass die Informationen konsistent und fehlersicher zwischen den Teilnehmern übertragen werden. Dies ist insbesondere bei datenverändernden Aufrufen (d. h. dem Schreiben von Variablen) wichtig.

In der Praxis muss die Konsistenz über mehrere einzelne Aufrufe in der Anlage sichergestellt sein. So kann es sein, dass eine Veränderung im Prozess an mehreren Stellen in den Pro- zess eingreift, wobei die Ziele der Aufrufe unterschiedlich sind und durch unterschiedliche Aufrufe angesprochen werden müssen .

Andere Gründe für die Notwendigkeit mehrerer unterschiedlicher, aber logisch zusammenhängender Aufrufe wären zum Beispiel :

• Unterschiedliche Sicherheitseinstellungen,

• Unterschiedliche Art des Aufrufs (Write/Schreiben , Methodenaufruf) , • Organisatorische Gründe.

Bei OPC UA werden Variablen einzeln betrachtet (auch innerhalb eines Schreib-Aufrufs, eines sogenannten WRITE-Calls, mit mehreren Variablen) ; der Server teilt dies dem Client über einzelne Statuscodes (pro Variable) mit. Andere Möglichkeiten sind in der Spezifikation nicht vorgesehen.

Das durch die OPC UA spezifizierte Informationsmodell ist nicht mehr nur eine Hierarchie aus Ordnern, Items und Properties. Es ist ein sogenanntes Full-Mesh-Network aus Knoten (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 alle anderen Arten von Metadaten verwendet. Der damit modellierte OPC-Adressraum beinhaltet nun auch ein Typmodell, mit dem sämtliche Datentypen spezifiziert werden.

Ohne den OPC UA Standard zu verletzen könnten ein Client und ein Server (die aufeinander zugeschnitten sind) vereinbaren, dass der Server einen Write-Call als EINE konsistente

Schreiboperation auffasst und diesen Aufruf nur im Ganzen akzeptiert oder im Ganzen ablehnt.

In OPC UA ist ein Sitzungskonzept bekannt (Session) , das mit speziellen Service-Calls (BeginSession, ActivateSession, End- Session) implementiert wird. Es kann mehrere Sessions geben, die simultan auf einem Server existieren. Innerhalb einer OPC UA Verbindung ist aber zu einem Zeitpunkt immer nur eine sol- che Session aktiv. Unter anderem werden Sessions dazu verwendet, einen Benutzer bzw. eine Rolle eindeutig zuzuordnen.

Ohne den OPC UA Standard zu verletzen könnten ein Client und ein Server (die aufeinander zugeschnitten sind) vereinbaren, dass der Server einen Write-Call als genau eine konsistente Schreiboperation auffasst und diesen Aufruf nur im Ganzen akzeptiert oder im Ganzen ablehnt.

Dieser Mechanismus ist jedoch nicht - wie oben beschrieben - allgemeingültig, sondern funktioniert nur

- wenn Client und Server aufeinander zugeschnitten sind.

Client und Server müssen die Information austauschen, dass sie aufeinander zugeschnitten sind, d. h. diese Information muss z. B. im Anmeldeprotokoll übertragen werden.

- Wenn es sich um genau einen verändernden Aufruf handelt und/oder

- wenn die Ziele der Schreiboperationen auf demselben Zielsystem liegen (aggregierende Server könnten hiermit nicht behandelt werden) .

Wie bereits weiter oben ausgeführt reicht dies in der Praxis nicht aus, da konsistente Operationen häufig nicht mit einem einzigen verändernden Aufruf abgedeckt werden können.

Es ist daher Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung anzugeben, die die oben beschriebenen Probleme behebt .

Die beschriebene Aufgabe wird gelöst durch ein Verfahren und eine Vorrichtung gemäß einem der unabhängigen Patentansprüche .

Beansprucht wird ein Verfahren zur Kommunikation zwischen einem OPC-UA Client und einem OPC-UA Server eines

Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA wobei zur Interaktion des Clients mit dem Server OPC-UA Aufrufe verwendet werden. Die Ausführung der OPC-UA Aufrufe soll dabei transaktionsba- siert ausgeführt werden, wobei der OPC-UA Aufrufe eine Angabe enthält über einen frühesten Zeitpunkt der Ausführung des OPC-UA Aufrufs auf dem Server und der zumindest eine OPC-UA Aufruf vom Server empfangen und zunächst gespeichert werden.

Beansprucht werden auch die geeigneten Vorrichtung zur Durchführung des Verfahrens, nämlich ein Client und ein Server.

Im OPC UA Request Header existiert das Feld „TimeoutHint" , mit dem der Client angeben kann, ab wann er am Ergebnis einer Operation nicht mehr interessiert ist oder die Dauer, nachdem der Server eine (vermutlich "im Kreis laufende") Nachricht löschen darf.

Wenn diese Zeit abgelaufen ist, sendet der Server eine Antwort, dass die Ausführung der Operation abgebrochen wurde.

Erfindungsgemäß wird die Semantik des Feldes „TimeoutHint" im OPC UA Request Header anders verwendet, als es im Standard ursprünglich vorgesehen ist. Die Bedeutung des „TimeoutHint" wird dabei so geändert, dass er nicht mehr den spätesten Zeitpunkt angibt, zu dem eine Operation ausgeführt werden soll, sondern den frühesten.

Damit eine Operation ausgeführt wird, muss innerhalb der Zeit, die im „TimeoutHint" angegeben ist, eine spezielle Information (Trigger) vom Client zum Server übertragen werden, die die Ausführung der Operation auslöst.

Durch diesen Mechanismus können mehrere Operationen im Server gespeichert werden, die dann gleichzeitig beim Eintreffen des Triggers ausgeführt werden. Die vom Client gelieferten Informationen in den „TimeoutHints" und Zeitangaben (Timestamps) müssen korrelieren, um einen exakten Ausführungszeitpunkt zu definieren .

Trifft innerhalb der durch den „TimeoutHint" angegebenen Zeit kein passender Trigger ein, so werden die gespeicherten Operationen verworfen . Eine erste vorteilhafte Ausführungsform arbeitet in einem „Verzögerte-Antwort"-Modus .

Dabei hält der Server bis zum Eintreffen des Triggers die Anforderungen (Requests) fest und gibt dem Client erst dann ei- ne Antwort, wenn entweder der in „TimeoutHint" angegebene Zeitraum abgelaufen ist oder wenn vom Client ein geeigneter Trigger gesendet wird.

Dadurch erhält der Client für jedes Item, das er ändert, einen eigenen Statuscode. Die Antwort (Response) auf den Trig- ger, die vom Server zum Client geht , enthält das Gesamtergebnis der Operation. Zum Zeitpunkt der Trigger-Antworten werden auch die Antworten mit dem Detail-Informationen auf die vorher aufgesammelten Anforderungen (Requests) zum Client geschickt .

Die Operationen werden beim Eintreffen auf dem Server formal überprüft (existieren beispielsweise die gewünschten Netz- Knoten) . Im Fehlerfall erhält der Client sofort eine Antwort mit der Information über die aufgetretenen formalen Fehler. Der Preview-Modus wird als zweite vorteilhafte Ausführungsform vorgestellt.

Der Client erhält für jede gespeicherte Operation unmittelbar, d. h. nicht erst nach Eintreffen des Triggers, eine Antwort vom Server über den voraussichtlichen Ausgang der Opera- tion, unabhängig davon, ob die Operation erfolgreich wein wird oder nicht. Er erhält also eine Vorschau, was passieren würde, wenn die Operationen ausgeführt würden.

Wenn der Client feststellt, dass eine der durchgeführten Ope- rationen nicht zum gewünschten Ergebnis führen würde, kann er die Operationen verwerfen, indem er keinen Trigger sendet. Will der Client, dass die Operationen ausgeführt werden, so sendet er den Trigger. In der Antwort auf den Trigger erhält der Client die Information über das Gesamtergebnis aller aus- geführten Operationen. In einer vorteilhaften Ausführungsform können die tatsächli- chen Detailergebnisse der ausgeführten Operationen vom Server über den Event-Mechanismus gesendet werden.

Als weitere vorteilhafte Ausführungsform kann der Client über eine Abbruchnachricht vorzeitig die Operation abbrechen. Er muss so nicht den Timeout abwarten .

Der Ausführungszeitpunkt kann vorteilhafterweise entweder über einen Zeitpunkt, der mithilfe der Trigger-Operation mitgeteilt wird oder über den Timeout-Zeitpunkt der vorhergehenden Operationen festgelegt.

Wie oben ausgeführt, wird das Problem der konsistenten datenverändernden Mengenoperation heute von OPC UA nicht adressiert. Dies wird vermehrt in der Zukunft eine wichtige Anforderung sein, insbesondere in der Kommunikation zwischen Automatisierungssystemen .

Die Nutzung des Timeout-Mechanismus ist eine einfach zu implementierende und zu verwaltende Möglichkeit, Operationen in einer Transaktion zusammenzufassen. Die aufwändige Verwaltung einer Transaktion durch Transaktionskontexte etc. entfällt, da der Zusammenhalt der Operationen über einen Zeitpunkt synchronisiert wird.

Als nachteilig erscheint zunächst die fehlende Möglichkeit eines Rollbacks, wie er aus dem Transaktionskontext bekannt ist (und für diese elementar ist) . Bei genauerer Betrachtung - insbesondere im Umfeld von automatisierungstechnischen Lösungen - stellt man fest, dass diese Funktionalität nicht notwendig und oftmals auch nicht erreichbar ist. Wenn ein Ventil geöffnet wurde und hierfür ein Rollback gemacht werden soll, ist das physikalische Ereignis der Ventilöffnung bereits eingetroffen und kann nicht rückwirkungsfrei rückgängig gemacht werden.

Für die Kommunikation von Server und Client gemäß der Erfindung muss das OPC UA Protokoll nicht geändert werden. Allerdings müssen Client und Server dasselbe Verständnis über die Verwendung des „TimeoutHint"-Feldes haben. Die Synchronisati- on hierzu kann z. B. im Verbindungsaufbau ausgetauscht werden .

Im Folgenden wird die Erfindung durch Figuren dargestellt und weiter erläutert. Dabei zeigt

Figur 1 eine beispielhafte Anwendung der Erfindung im Automatisierungsumfeld,

Figur 2 eine beispielhafte Kommunikation zwischen Client und Server gemäß dem ersten Ausführungsbeispiel,

Figur 3 ein beispielhafte Kommunikation zwischen Client und Server gemäß dem zweiten Ausführungsbeispiel und

Figur 4 eine weitere beispielhafte Kommunikation mit simulierten Zwischenergebnissen.

Im Weiteren werden die bevorzugten Ausführungsbeispiele erläutert. Diese Beispiele sollen die Erfindung nur weiter klarstellen, jedoch nicht einschränkend wirken.

Die beispielhafte Aufgabe, die die Automatisierungsanlage ausführen soll, sei das Mischen von grüner Farbe aus gelben und blauen Flüssigkeiten, siehe Figur 1. In der Anlage gibt es drei OPC-UA Server: einen Server UA-S3 am blauen Tank B, einen Server UA-S2 am gelben Tank Y und einen Server UA-Sl am Mischtank G, in dem die grüne Farbe gemischt wird. Für die richtige Grün-Mischung müssen die Ventile VI, V2 vom gelben und blauen Tank gleichzeitig geöffnet werden. Wenn nun folgender Fehler auftritt, dass eines der Ventile VI, V2 nicht korrekt geöffnet oder geschlossen, V3, V4 werden kann, müssen zuerst alle geöffneten Zulaufventile VI, V2 wieder geschlossen werden, und dann am Mischtank G das Ventil V4 in Richtung Entsorgung R geöffnet werden, um die gesammelte Flüssigkeit zu entsorgen. Die Ansteuerung der Server UA-Sl, UA-S2 und UA- S3 erfolgt durch den Client UA-C .

Hier wäre ein Rollback zwar wünschenswert, er ist aber nicht möglich. Durch das Öffnen der Ventile ist aus den beiden oberen Tanks B, Y bereits Flüssigkeit ausgetreten und in dem unteren Tank G geflossen. Es kann nur ein definierter Zustand für die Ventile VI, V2 wieder hergestellt werden. Zusätzliche Arbeitsschritte, um den Ursprungszustand wiederherzustellen, also beispielsweise die Entsorgung der in den unteren Tank G eingetretenen Flüssigkeit, sind nicht abbildbar und müssen programmtechnisch gelöst werden.

In den Figuren 2 bis 4 sind nun beispielhafte Kommunikationsvorgänge zwischen Client UA-C und den Servern UA-Sl, UA-S2, UA-S3 gemäß der Erfindung aufgezeigt.

Figur 2 zeigt eine Kommunikation, bei dem die Ausführung der Operationen durch einen Trigger ausgelöst wird. Ein Client UA-C sendet eine erste Operation „Öffne Ventil-Blau",

01(OPEN_Vl, T) mit einem Timeout-Zeitpunkt T an den Server UA-S .

In einer Ausgestaltung der Erfindung überprüft der Server UA- S zunächst formal die Gültigkeit der Operation. Im Fehlerfall wird eine entsprechende Nachricht an den Client gesendet. An- derenfalls wird die Operation im Server gespeichert.

Der Client UA-C sendet eine zweite Operation „Öffne Ventil- Gelb", 02(OPEN_V2, T) mit demselben Timeout-Zeitpunkt T an den Server UA-S.

Bei der oben genannten Ausgestaltung wird nach Empfang der zweiten Operation 02 vom Server formal wiederum die Gültigkeit der Operation 02 überprüft. Im Fehlerfall wird eine entsprechende Nachricht an den Client gesendet. Anderenfalls wird die Operation ebenfalls im Server gespeichert.

Will der Client UA-C nun die beiden Operationen ausführen, sendet er die Trigger-Nachricht TRIGGER (T) an den Server UA- S. Der Server führt die Operationen aus und sendet zur Bestätigung eine Antwort RESULT(01, 02) an den Client zurück.

Figur 3 zeigt zunächst das gleiche Vorgehen:

UA-C sendet eine erste Operation „Öffne Ventil-Blau",

01(OPEN_Vl, T) mit einem Timeout-Zeitpunkt T an den Server UA-S. Dann sendet der Client UA-C eine zweite Operation „Öffne Ventil-Gelb", 02(OPEN_V2, T) mit demselben Timeout- Zeitpunkt T an den Server UA-S. Wird keine Trigger-Nachricht vom Client innerhalb des Zeitraums T gesendet, so werden nach Ablauf des im Feld

„TimeoutHint" des Operationsbefehls angegebenen Zeitraums die in den Servern gespeicherten Operationen verworfen und gegebenenfalls eine Fehler-Meldung RESULT(01, 02) an den Client UA-C zurück gesendet.

Figur 4 zeigt noch ein weiteres Ausführungsbeispiel. Nach Empfang der ersten Operation 01(OPEN_Vl, T) überprüft der Server UA-S gegebenenfalls formal die Gültigkeit der Operation und simuliert dann die angeforderte Operation. Der Client UA-C erhält als Antwort auf die Operation das Ergebnis dieser Simulation als Vorschau, SIM_RESULT (Ol ) . Es kann später nicht mehr das tatsächliche Ergebnis der Operation an den Client geliefert werden, da er die Antwort auf den Request bereits erhalten hat.

Nach Empfang der zweiten Operation 02(OPEN_V2, T) überprüft der Server UA-S formal die Gültigkeit der Operation und „simuliert" die Operation 02. Der Client UA-C erhält als Antwort auf die Operation das Ergebnis dieser Simulation als Vorschau, SIM_RESULT (02 ) . Es kann später nicht mehr das tatsächliche Ergebnis der Operation an den Client UA-C geliefert werden, da er die Antwort auf den Request ja bereits erhalten hat.

Ist der Client UA-C mit einem der gelieferten Vorschauergebnisse nicht zufrieden, kann er die Gesamtoperation durch Verstreichen der Timeoutzeit abbrechen.

Der Ausführungszeitpunkt kann entweder durch die Timeoutzeit oder durch eine Zeit T, die mit dem Trigger geliefert wird, vom Client UA-C festgelegt werden.