WO2015197115A1 - Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus - Google Patents

Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus Download PDF

Info

Publication number
WO2015197115A1
WO2015197115A1 PCT/EP2014/063376 EP2014063376W WO2015197115A1 WO 2015197115 A1 WO2015197115 A1 WO 2015197115A1 EP 2014063376 W EP2014063376 W EP 2014063376W WO 2015197115 A1 WO2015197115 A1 WO 2015197115A1
Authority
WO
WIPO (PCT)
Prior art keywords
opc
server
call
client
open
Prior art date
Application number
PCT/EP2014/063376
Other languages
English (en)
French (fr)
Inventor
Karl-Heinz Deiretsbacher
Markus Erlmann
Sven Kerschbaum
Frank Volkmann
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to CN201480080128.1A priority Critical patent/CN106462473A/zh
Priority to US15/322,019 priority patent/US20170161122A1/en
Priority to PCT/EP2014/063376 priority patent/WO2015197115A1/de
Priority to EP14735499.7A priority patent/EP3140741A1/de
Priority to RU2017102174A priority patent/RU2676423C2/ru
Publication of WO2015197115A1 publication Critical patent/WO2015197115A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/34—Director, elements to supervisory
    • G05B2219/34263—OLE object linking and embedding, OPC ole for process control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/541—Client-server

Definitions

  • OPC UA OPC Unified Architecture
  • OPC Foundation OPC Foundation for vendor-independent communication for the exchange of machine data, especially in process automation.
  • OPC UA is a relatively new standard, where the original focus was not on the control of an industrial plant, but rather on the standardized exchange of information, especially between devices from different manufacturers.
  • OPC UA is also integrated directly into automation devices, creating the need for consistent data writing.
  • process information such as process values, measured values, parameters, control commands
  • process information such as process values, measured values, parameters, control commands
  • variables are considered individually (even within a write call, a so-called WRITE call, with several variables);
  • the server informs the client about individual status codes (per variable).
  • Other options are not provided in the specification.
  • the information model specified by OPC UA is no longer just a hierarchy of folders, items, and properties. It is a so-called full mesh network of nodes that, in addition to the payload of a node, also represents meta and diagnostic information.
  • a node is similar to an object from object-oriented programming.
  • a node can have attributes that can be read (Data Access DA, Historical Data Access HDA). It is possible to define and call methods.
  • a method has call arguments and return values. It is called by a command.
  • events that can be sent (AE, DA DataChange) are supported in order to exchange certain information between devices. An event has among other things a time of reception, a message and a severity level.
  • AE DA DataChange
  • Nodes are used for both payload and all other types of metadata.
  • the modeled OPC address space now includes a type model that specifies all data types.
  • a client and a server could agree that the server perceives a write call as just one consistent write and only accepts or rejects this call as a whole.
  • client and server are tailored to each other.
  • Client and server must exchange the information that they are tailored to each other, d. H. this information must be z. B. in the log.
  • a method for communication between an OPC UA client and an OPC UA server is required
  • Client / server system using the OPC-UA communication protocol calls being used to interact with the client with the OPC-UA server.
  • the execution of the OPC-UA calls is thereby to be carried out transaction-based, wherein the OPC-UA calls contain an indication of an earliest time of execution of the OPC-UA call on the server and the at least one OPC-UA call is received by the server and initially saved.
  • the "TimeoutHint" field exists in the OPC UA request header, with which the client can specify when it is no longer interested in the result of an operation or the duration after which the server is allowed to delete a message (presumably "circulating").
  • the server sends a response that the operation was aborted.
  • the semantics of the "TimeoutHint" field in the OPC UA request header are used differently than originally provided in the standard.
  • the meaning of the "TimeoutHint” is changed so that it no longer specifies the latest time at which an operation is executed should be, but the earliest.
  • This mechanism allows multiple operations to be stored in the server, which are then executed concurrently upon the arrival of the trigger.
  • the information provided by the client in the "TimeoutHints" and timestamps must correlate to define an exact execution time.
  • a first advantageous embodiment operates in a "delayed response" mode.
  • the server keeps the requests until the trigger arrives and only gives the client an answer when either the time period specified in "TimeoutHint" has expired or when a suitable trigger is sent by the client.
  • the client has the client its own status code for each item that it modifies.
  • the response to the trigger that goes from the server to the client contains the overall result of the operation.
  • the responses with the detail information are also sent to the previously collected requests to the client.
  • the operations are formally checked when they arrive on the server (for example, the desired network nodes exist).
  • the client In the event of an error, the client immediately receives a response with the information about the formal errors that have occurred.
  • the preview mode is presented as a second advantageous embodiment.
  • the client receives for each stored operation immediately, d. H. not only after the arrival of the trigger, a response from the server about the expected outcome of the operation, irrespective of whether the operation is successful or not. So he gets a preview of what would happen if the operations were done.
  • the client determines that one of the operations performed would not produce the desired result, it can discard the operations by not sending a trigger. If the client wants the operations to be executed, it sends the trigger. In response to the trigger, the client receives the information about the overall result of all executed operations. In an advantageous embodiment, the actual detailed results of the executed operations can be sent by the server via the event mechanism.
  • the client can prematurely abort the operation via an abort message. He does not have to wait for the timeout.
  • the execution time may advantageously be set either over a time notified by means of the trigger operation or over the timeout time of the preceding operations.
  • time-out mechanism is an easy way to implement and manage operations in a single transaction.
  • the complex management of a transaction by transaction contexts, etc. is eliminated, since the cohesion of operations is synchronized over a time.
  • the OPC UA protocol does not have to be changed.
  • the client and server must have the same understanding of how to use the TimeoutHint field. on this can z. B. be replaced in the connection setup.
  • FIG. 1 shows an exemplary application of the invention in the automation environment
  • FIG. 2 shows an exemplary communication between client and server according to the first exemplary embodiment
  • Figure 3 shows an exemplary communication between client and server according to the second embodiment
  • FIG. 4 shows another exemplary communication with simulated intermediate results.
  • the exemplary task which the automation system is to perform is the mixing of green color from yellow and blue liquids, see FIG. 1.
  • valves VI, V2 must be opened simultaneously from the yellow and blue tanks. Now, if the following error occurs that one of the valves VI, V2 can not be properly opened or closed, V3, V4, first all open inlet valves VI, V2 must be closed again, and then open the mixing tank G, the valve V4 in the direction of disposal R. to dispose of the collected liquid.
  • the control of the servers UA-Sl, UA-S2 and UA-S3 is performed by the client UA-C.
  • FIGS. 1-10 Exemplary communication processes between client UA-C and servers UA-Sl, UA-S2, UA-S3 according to the invention are now shown in FIGS.
  • Figure 2 shows a communication in which the execution of the operations is triggered by a trigger.
  • a client UA-C sends a first operation "open valve blue",
  • the server UA-S first formally checks the validity of the operation. In the event of an error, a corresponding message is sent to the client. Otherwise, the operation is stored in the server.
  • Client UA-C sends a second operation "Open Valve Yellow", 02 (OPEN_V2, T) to server UA-S at the same timeout point T.
  • the validity of the operation 02 is formally checked again after reception of the second operation 02 by the server. In the event of an error, a corresponding message is sent to the client. Otherwise, the operation is also stored in the server.
  • the client UA-C If the client UA-C now wants to perform the two operations, it sends the trigger message TRIGGER (T) to the server UA-S.
  • the server carries out the operations and sends a response RESULT (01, 02) to the client for confirmation back.
  • FIG. 3 initially shows the same procedure:
  • Figure 4 shows yet another embodiment.
  • the server UA-S After receiving the first operation 01 (OPEN_Vl, T), the server UA-S optionally checks formally the validity of the operation and then simulates the requested operation.
  • the client UA-C receives in response to the operation the result of this simulation as a preview, SIM_RESULT (Ol).
  • SIM_RESULT The actual result of the operation can not be delivered to the client later because it has already received the response to the request.
  • the server UA-S After receiving the second operation 02 (OPEN_V2, T), the server UA-S formally checks the validity of the operation and "simulates" the operation 02.
  • the client UA-C receives in response to the operation the result of this simulation as a preview, SIM_RESULT (FIG. 02) It is no longer possible to deliver the actual result of the operation to the client UA-C since it has already received the response to the request.
  • the client UA-C may abort the overall operation by elapsing the timeout period.
  • the execution time can be set by the client UA-C either by the timeout time or by a time T delivered with the trigger.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

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. 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. 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.

Description

Beschreibung
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.

Claims

Patentansprüche
1. Verfahren zur Kommunikation zwischen einem Client (UA-C) und einem Server (UA-Sl, UA-S2, UA-S3) eines Client/Server- Systems unter Verwendung des Kommunikationsprotokolls OPC-UA wobei zur Interaktion des Clients (UA-C) mit dem Server zumindest einen OPC-UA Aufruf (01(0PEN_V1, T) , 02(OPEN_V2, T) ) verwendet wird, wobei die Ausführung der OPC-UA Aufrufe transaktionsbasiert ausgeführt werden soll,
dadurch gekennzeichnet, dass
der zumindest eine OPC-UA Aufruf (Ol, 02) eine Angabe enthält über einen frühesten Zeitpunkt (T) der Ausführung des OPC-UA Aufrufs auf dem Server (UA-S) und
der zumindest eine OPC-UA Aufruf (Ol, 02) vom Server empfangen und zunächst gespeichert werden.
2. Verfahren gemäß Patentanspruch 1,
dadurch gekennzeichnet, dass
für die Angabe über den frühesten Ausführungszeitpunkt das im OPC-UA Standard definierte Feld „TimeoutHint" verwendet wird.
3. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
die Ausführung des zumindest einen OPC-UA Aufrufs
(01(OPEN_Vl, T) , 02(OPEN_V2, T) ) beim Server (UA-S) zunächst simuliert wird und
das Ergebnis der Simulation (SIM_RESUL (Ol ) , SIM_RESUL (02 ) ) an den Client (OA-C) gesendet wird.
4. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
die Ausführung des zumindest einen OPC-UA Aufrufs
(01(OPEN_Vl, T) , 02(OPEN_V2, T) ) beim Server (UA-S) erst ein- geleitet wird, wenn eine mit dem Ausführungszeitpunkt (T) korrelierte Triggermeldung (TRIGGER T) vom Server (UA-S) empfangen wird.
5. Verfahren gemäß einem der Patentansprüche 1 bis 3, dadurch gekennzeichnet, dass
die Ausführung des zumindest einen OPC-UA Aufrufs
(01(OPEN_Vl, T) , 02(OPEN_V2, T) ) beim Server (UA-S) eingelei- tet wird, wenn der im dem OPC-UA Aufruf gekennzeichnete Ausführungszeitpunkt (T) erreicht wurde.
6. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
der zumindest eine OPC-UA Aufruf (01(OPEN_Vl, T) , 02(OPEN_V2, T) ) erst formal geprüft wird, und falls die Prüfung einen Fehler ergibt, der Server (UA-S) eine Fehlermeldung an den Client (UA-C) sendet.
7. Verfahren gemäß Patentansprüche 1 oder 2,
dadurch gekennzeichnet, dass der Server nach Ausführung des zumindest einen OPC-UA Aufrufs (01(OPEN_Vl, T) , 02(OPEN_V2, T) ) einen Ergebnisaufruf mit den Sammelergebnissen aller in der Session ausgeführten Aufrufe an den Client sendet
(Result (Ol, 02) ) .
8. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
die Ausführung des zumindest einen OPC-UA Aufrufs
(01(OPEN_Vl, T) , 02(OPEN_V2, T) ) beim Server (UA-S) durch eine geeignete Abbruch-Meldung verhinderbar ist.
9. Vorrichtung (UA-C) zur Kommunikation mit einem Server (UA- Sl, UA-S2, US-S3) eines Client/Server-Systems unter Verwen- dung des Kommunikationsprotokolls OPC-UA geeignet zur Durchführung des Verfahrens gemäß den Merkmalen eines der Patentansprüche 1 bis 8,
wobei
zur Kommunikation zwischen der Vorrichtung (UA-C) und dem Server (UA-Sl, UA-S2, UA-S3 ) des Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA zumindest ein OPC-UA Aufruf (01(0PEN_V1, T), 02(OPEN_V2, T) ) übertragen werden, und die Kommunikation transaktionsbasiert ausgeführt wird wobei
der zumindest eine OPC-UA Aufruf (Ol, 02) eine Angabe enthält über einen frühesten Zeitpunkt (T) der Ausführung des OPC-UA Aufrufs auf dem Server (UA-S) und
der zumindest eine OPC-UA Aufruf an den Server (UA-Sl, UA-S2, UA-S3) gesendet und dort gespeichert wird.
10. Vorrichtung (UA- Sl, UA-S2, US-S3) zur Kommunikation mit einem Client (UA-C) eines Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA geeignet zur Durchführung des Verfahrens gemäß den Merkmalen eines der Patentansprüche 1 bis 8,
wobei zur Kommunikation zwischen der Vorrichtung (UA-Sl, UA- S2, UA-S3 ) und dem Client (UA-C) des Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA zumindest ein OPC-UA Aufruf (01(0PEN_V1, T) , 02(OPEN_V2, T) ) verwendet werden, und die Kommunikation transaktionsbasiert ausgeführt wird und
der zumindest eine OPC-UA Aufruf (Ol, 02) eine Angabe enthält über einen frühesten Zeitpunkt (T) der Ausführung des OPC-UA Aufrufs auf der Vorrichtung (UA- Sl, UA-S2 , US-S3) und der zumindest eine OPC-UA Aufruf von der Vorrichtung (UA-Sl, UA-S2, UA-S3) empfangen und dort gespeichert wird.
PCT/EP2014/063376 2014-06-25 2014-06-25 Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus WO2015197115A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN201480080128.1A CN106462473A (zh) 2014-06-25 2014-06-25 用于借助超时机制在opc ua中转换事务概念的装置和方法
US15/322,019 US20170161122A1 (en) 2014-06-25 2014-06-25 Method and device for implementing a transaction concept in opc ua by means of a timeout mechanism
PCT/EP2014/063376 WO2015197115A1 (de) 2014-06-25 2014-06-25 Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus
EP14735499.7A EP3140741A1 (de) 2014-06-25 2014-06-25 Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus
RU2017102174A RU2676423C2 (ru) 2014-06-25 2014-06-25 Способ и устройство для реализации концепции транзакций в opc ua посредством механизма таймаута

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2014/063376 WO2015197115A1 (de) 2014-06-25 2014-06-25 Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus

Publications (1)

Publication Number Publication Date
WO2015197115A1 true WO2015197115A1 (de) 2015-12-30

Family

ID=51063412

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/063376 WO2015197115A1 (de) 2014-06-25 2014-06-25 Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus

Country Status (5)

Country Link
US (1) US20170161122A1 (de)
EP (1) EP3140741A1 (de)
CN (1) CN106462473A (de)
RU (1) RU2676423C2 (de)
WO (1) WO2015197115A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017092879A1 (de) 2015-11-30 2017-06-08 Siemens Aktiengesellschaft Verfahren zur industriellen kommunikation über tsn
CN107920120A (zh) * 2017-11-22 2018-04-17 北京小米移动软件有限公司 业务处理方法、装置及计算机可读存储介质
DE102018101203A1 (de) * 2018-01-19 2019-07-25 Wago Verwaltungsgesellschaft Mbh Automatisierungsgerät und Verfahren zum optimierten Zugriff auf eine Variable

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6122673A (en) * 1998-07-22 2000-09-19 Fore Systems, Inc. Port scheduler and method for scheduling service providing guarantees, hierarchical rate limiting with/without overbooking capability
EP1410204B1 (de) * 2001-06-22 2016-11-09 Wonderware Corporation Überwachungsprozesssteuer- und herstellungsinformationssystemanwendung mit erweiterbarem komponentenmodell
AU2003216451A1 (en) * 2002-03-01 2003-09-16 Fisher-Rosemount Systems, Inc. Integrated alert generation in a process plant
EP1372346B8 (de) * 2002-06-04 2006-06-14 Telefonaktiebolaget LM Ericsson (publ) Betrieb eines Vermittlungsknotens in einem Kommunikationsnetz mit sowohl einer geschichteten als auch einer nicht-geschichteten Architekturumgebung
US7496668B2 (en) * 2002-06-28 2009-02-24 Honeywell International Inc. OPC server redirection manager
US7152111B2 (en) * 2002-08-15 2006-12-19 Digi International Inc. Method and apparatus for a client connection manager
US8942834B2 (en) * 2005-06-27 2015-01-27 Rockwell Automation Technologies, Inc. Method and apparatus for communicating transactions between an industrial controller and a programming interface
WO2007004310A1 (ja) * 2005-07-06 2007-01-11 Luke19 Co., Ltd. 試供品提供管理システム及び、試供品提供管理サーバ、試供品提供管理方法
US20070027913A1 (en) * 2005-07-26 2007-02-01 Invensys Systems, Inc. System and method for retrieving information from a supervisory control manufacturing/production database
US8782249B1 (en) * 2006-09-28 2014-07-15 Rockwell Automation Technologies, Inc. Message engine
US8195581B2 (en) * 2007-05-21 2012-06-05 Honeywell Asca Inc. Apparatus and method for simulating multi-dimensional non-linear multivariable processes
DE102007062986B4 (de) * 2007-12-21 2013-12-24 Abb Research Ltd. Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA
DE102007062985B4 (de) * 2007-12-21 2014-01-02 Abb Research Ltd. Verfahren und Einrichtung zur Kommunikation gemäß dem Standardprotokoll OPC UA in einem Client-Server-System
CN102918820B (zh) * 2010-05-25 2015-11-25 西门子公司 在自动化网络的两个设备之间交换数据的方法和装置
CN102907070B (zh) * 2010-05-25 2015-06-17 西门子公司 用于交换数据的方法和装置,以及网络
US20140095658A1 (en) * 2012-10-02 2014-04-03 Transocean Sedco Forex Ventures Limited Information Aggregation on a Mobile Offshore Drilling Unit
US9842134B2 (en) * 2014-12-12 2017-12-12 Schneider Electric Software, Llc Data query interface system in an event historian

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
OPC FOUNDATION: "OPC Unified Architecture Specification - Part 4: Services - Release Candidate 1.01.30", 10 March 2008 (2008-03-10), XP002728532, Retrieved from the Internet <URL:http://web24267.5udns.cn/attachment.aspx?attachmentid=658> [retrieved on 20140815] *
WIKIPEDIA: "OPC Unified Architecture", 12 October 2013 (2013-10-12), XP002728079, Retrieved from the Internet <URL:http://de.wikipedia.org/wiki/OPC_Unified_Architecture> [retrieved on 20140731] *
WOLFGANG MAHNKE, STEFAN-HELMUT LEITNER, MATTHIAS DAMM: "OPC Unified Architecture", 19 March 2009, SPRINGER VERLAG, Berlin Heidelberg, ISBN: 978-3-540-68898-3, XP002728533 *

Also Published As

Publication number Publication date
US20170161122A1 (en) 2017-06-08
RU2017102174A3 (de) 2018-07-25
RU2017102174A (ru) 2018-07-25
CN106462473A (zh) 2017-02-22
RU2676423C2 (ru) 2018-12-28
EP3140741A1 (de) 2017-03-15

Similar Documents

Publication Publication Date Title
DE102007062986B4 (de) Verfahren und Einrichtung zur Client-Server-Kommunikation gemäß dem Standardprotokoll OPC UA
EP3137999B1 (de) Verfahren und vorrichtung zur transaktionserweiterung bei opc ua
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
DE102008014153B4 (de) Verfahren, Steuergerät und Steuerungssystem zur Steuerung eines Automatisierungssystems
WO2015197115A1 (de) Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus
WO2016188731A1 (de) Maschinenwartung in der getränkemittelindustrie
EP2226693A1 (de) Programmiergerät zur Projektierung einer Kommunikationsverbindung zwischen Automatisierungskomponenten in einer industriellen Automatisierungsanordnung
WO2015169355A1 (de) Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe
DE602005000715T2 (de) System und Verfahren zur Auswahl einer aktiven Verbindung
DE102013211080A1 (de) Verfahren zur Steuerung eines Kraftfahrzeuggetriebes
EP2283426A1 (de) Verfahren und vorrichtung zur korrektur von digital übertragenen informationen
WO2010149440A1 (de) Verfahren zum ermitteln einer übermittelbaren telegramm-datenlänge
DE10246895B3 (de) Verfahren zur Änderung eines Parameters für den Betrieb eines Netzwerks sowie Teilnehmer zur Durchführung des Verfahrens
EP3800864B1 (de) Verfahren zum konfigurieren eines opc ua pubsub teilnehmers, automatisierungssystem, computerprogramm und computerlesbares medium
WO2007118642A2 (de) Verfahren zur prüfung von bacnet-einrichtungen auf konformität, interoperabilität und performance
EP3836489B1 (de) Dynamische zuordnung von automatisierungseinheiten zu automatisierungsservern
EP1703667A1 (de) Netzwerkmanagement unter Verwendung eines Master-Replica-Verfahrens
DE102021210453A1 (de) Steuergerät, system und verfahren zum konfigurieren von geräten eines feldbusnetzwerks
EP1435026A2 (de) System und verfahren zur datenausgabe eines geräts, insbesondere eines automatisierungsgerät über eine standardisierte schnittstelle mit variablenersetzung über einen echoserver
EP4216489A1 (de) Verfahren zur änderung eines ist-zugangsschlüssels in einem feldgerät der automatisierungstechnik
DE10353532A1 (de) Verfahren und Vorrichtung zur Übertragung von Daten
DE102006062093B4 (de) Automatisierungsanlage und Verfahren für exklusive Verbindungen zu Clientrechnern
DE102017108506A1 (de) MIB-orientiertes Protokoll für hochwirksame http-Verwaltungsprozeduren
DE10036686A1 (de) Verfahren zum Konfigurieren einer Netzschnittstelle sowie Netzelement
DE102018115076A1 (de) Objektorientierte CAN Bridge

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14735499

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2014735499

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014735499

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15322019

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017102174

Country of ref document: RU

Kind code of ref document: A