WO2015169355A1 - Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe - Google Patents

Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe Download PDF

Info

Publication number
WO2015169355A1
WO2015169355A1 PCT/EP2014/059359 EP2014059359W WO2015169355A1 WO 2015169355 A1 WO2015169355 A1 WO 2015169355A1 EP 2014059359 W EP2014059359 W EP 2014059359W WO 2015169355 A1 WO2015169355 A1 WO 2015169355A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
opc
calls
client
call set
Prior art date
Application number
PCT/EP2014/059359
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 PCT/EP2014/059359 priority Critical patent/WO2015169355A1/de
Publication of WO2015169355A1 publication Critical patent/WO2015169355A1/de

Links

Classifications

    • 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
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0421—Multiprocessor system
    • 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
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/056—Programming the PLC
    • 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
    • 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
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network

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.
  • 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.
  • variables are considered individually (even within a write call, a so-called WRITE call, with several variables); the server shares z. For example, the result is communicated to the client via individual status codes (per variable). Other options are not provided in the specification.
  • a client and a server suitably tailored to one another could agree that the server perceives a WRITE call as just one consistent write and only accepts or rejects this call as a whole.
  • Each data-modifying call to OPC UA has as information all objects (their identities) that are to be changed as call parameters.
  • OPC-UA server calls are used for the interaction of a client with a server OPC-UA, wherein at least two in the sense of an operation logically related OPC UA server calls are summarized by the client to a server call set, and wherein the individual OPC UA server calls the server call set are transmitted independently of each other or the OPC UA server.
  • Each call is to be given in an advantageous embodiment, an additional identity (ID) as the first object.
  • ID is used to associate this call as a whole with a set of calls.
  • the identity of these calls from the OPC-UA client means that they belong together. marked as belonging together by the OPC-UA server.
  • the OPC-UA client can now identify several changing operations with the same identity, whereupon the server also recognizes them as belonging together.
  • the client can use a new changing call with the above-mentioned identity and a corresponding specially defined value in one step to execute all set operations belonging to this identity (trigger operation). There are other defined values for discarding a set operation.
  • the server gets operations with an identity tag, it collects them and does not execute them until it receives the trigger operation.
  • the operations are formally checked when they arrive on the server.
  • the OPC-UA client immediately receives a response with the information about the formal errors that have occurred.
  • a so-called preview mode can be performed.
  • Each operation with a set identity is formally checked and then simulated.
  • the simulated result or the result of the formal review is immediately sent to the client.
  • the client thus receives a preview of the result of the operations.
  • the client determines that one of the operations performed would not produce the desired result, e can discard the operations by discarding the set operation. If the client wants the bulk operation to be executed, it sends the trigger operation. In response to the trigger operation, the client receives the information about the overall result of the operations.
  • the actual detailed results of the executed operations can be sent by the server via the event mechanism.
  • the identity instead of the first object ID can also be transmitted in the request header of the OPC-UA data packet, for example as a request ID or additional header.
  • the execution is independent in time since no explicit start / end times are defined. Increasing the number of sets is possible without further increasing the complexity of the communication.
  • the paradigm used in practice results in a different paradigm than that for data-changing operations between client and server as known from data technology.
  • the client combines all the operations of a task into a set. This set of operations is successively transferred to the server.
  • the server In the server, a set of all operations of a task are consistently executed.
  • FIG. 1 shows an exemplary application of the invention in the automation environment
  • FIG. 2 shows an exemplary communication change upon successful execution of a task / set of operations
  • FIG. 3 shows an exemplary change of communication when an error occurs after execution of a task / set of operations.
  • the exemplary task that the automation plant should perform is to mix green color from yellow and blue liquids.
  • a server UA-S3 on the blue tank B a server UA-S2 on the yellow tank Y and a server UA-Sl on the mixing tank G, in which the green color is mixed.
  • valves VI, V2 must be opened simultaneously from the yellow and blue tanks. If the following error occurs: a valve can not be opened correctly, all open inlet valves VI, V2 must first be closed again, and then the mixing tank G must be opened in the direction of disposal in order to dispose of the collected liquid.
  • FIGS. 2 and 3 show by way of example the communications between client UA-C and servers UA-Sl, UA-S2, UA-S3.
  • An OPC-UA client UA-C sets up a set of changing operations 0PEN_V1 (ID), OPEN_V2 (ID) in the sense of this invention by opening the blue valve VI open request and the yellow valve open request V2 in a crowd ID and sent to the responsible server (s) UA-S2, UA-S3. If the operations of this set are performed consistently (ie open both valves), then everything is fine and confirmation messages OK are sent back.
  • Figure 3 shows alternatively the case of a fault, the valve V2 to the yellow tank G has not opened properly. This is reported back to the client in an ERR error message.
  • valves VI, V2 are reset to their initial state by means of a second operation set ID1 (ie closed: CLOSE_V1 (ID1), CLOSE_V2 (ID1) ).
  • a second operation set ID1 ie closed: CLOSE_V1 (ID1), CLOSE_V2 (ID1)
  • the responsible for the collection tank G OPC UA server UA-Sl now dispose of the contents of the tank. This additional step is necessary after occurrence of this error, since the resulting mixture is not suitable for further processing (and thus discharge by means of valve W to a next step of the system):
  • OPEN_V3 (ID0). Troubleshooting is not solvable via a normal rollback mechanism.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Verfahren zur Kommunikation zwischen Client (UA-C) und Server (UA- S1, UA-S2, US-S3) eines Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA wobei zur Interaktion eines Clients (UA-C) mit einem Server OPC-UA Serveraufrufe (OPEN, CLOSE) verwendet werden, dadurch gekennzeichnet, dass zumindest zwei im Sinne einer Operation logisch zusammengehörige OPC-UA Serveraufrufe (OPEN V1, OPEN V2) durch den Client (UA-C) zu einer Serveraufruf-Menge (ID, ID1) zusammengefasst werden, wobei die einzelnen OPC-UA Serveraufrufe der Serveraufruf-Menge unabhängig voneinander übertragen werden.

Description

Beschreibung
Verfahren und Vorrichtung für Konsistente Mengenoperationen datenverändernder OPC UA Aufrufe
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 nun 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 ,
Call/Methodenaufruf) , • andere Organisatorische Gründe.
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.
Bei OPC UA werden Variablen einzeln betrachtet (auch innerhalb eines Schreib-Aufrufs, eines sogenannten WRITE-Calls, mit mehreren Variablen); der Server teilt z. B. das Ergebnis dem Client über einzelne Statuscodes (pro Variable) mit. Andere Möglichkeiten sind in der Spezifikation nicht vorgesehen .
Gemäß dem OPC UA Standard könnten ein Client und ein Server, die in geeigneter Weise 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 beide diese Funktionalität implementiert und eine Vereinbarung über die Nutzung derselben getroffen haben. Client und Server müssten dann die Information über ihre diesbezüg- liehe Kompatibilität beispielsweise im Anmeldeprotokoll übertragen .
Auch wenn es sich um genau einen verändernden Aufruf handelt, ist die beschriebene Vorgehensweise anwendbar.
Wenn die Ziele der Schreiboperationen auf demselben Zielsystem liegen (aggregierende Server könnten hiermit beispielsweise nicht behandelt werden) . Wie bereits 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.
Jeder datenverändernde Aufruf bei OPC UA hat als Information alle Objekte (ihre Identitäten), die verändert werden sollen als Aufrufparameter .
Es ist daher Aufgabe der Erfindung, ein Verfahren und Vor richtungen anzugeben, die die oben beschriebenen Probleme heben .
Die beschriebene Aufgabe wird gelöst durch ein Verfahren und eine Vorrichtung gemäß einem der unabhängigen Patentansprüche .
Erfindungsgemäß wird bei dem Verfahren zur Kommunikation zwischen einem Client und einem Server eines Client/Server- Systems unter Verwendung des Kommunikationsprotokolls OPC-UA wobei zur Interaktion eines Clients mit einem Server OPC-UA Serveraufrufe verwendet werden, wobei zumindest zwei im Sinne einer Operation logisch zusammengehörige OPC-UA Serveraufrufe durch den Client zu einer Serveraufruf-Menge zusammengefasst werden, und wobei die einzelnen OPC-UA Serveraufrufe der Serveraufruf-Menge unabhängig voneinander an den oder die OPC-UA Server übertragen werden .
Jedem Aufruf soll in einer vorteilhaften Ausgestaltung eine zusätzliche Identität (ID) als erstes Objekt mitgegeben werden. Diese Identität wird dazu verwendet, diesen Aufruf als Ganzes einer Menge von Aufrufen zuzuordnen. Durch die Identität werden diese Aufrufe vom OPC-UA Client als zusammengehö- rig gekennzeichnet und vom OPC-UA Server als zusammengehörig erkannt .
Es gibt mindestens eine ausgezeichnete Identität im Sinne des obigen Absatzes, die aussagt, dass diese Operation nicht Teil einer Mengenoperation ist.
Der OPC-UA Client kann nun mehrere verändernde Operationen mit derselben Identität kennzeichnen woraufhin der Server diese ebenfalls als zusammengehörig erkennt.
In einem zweiten Schritt kann der Client durch einen neuen verändernden Aufruf mit der oben genannten Identität und einem dazugehörigen speziell definierten Wert in einem Schritt alle zu dieser Identität gehörenden Mengenoperationen ausführen lassen (Triggeroperation) . Es gibt weitere definierte Werte zum Verwerfen einer Mengenoperation.
Wenn der Server Operationen mit einer Identitätskennung bekommt, sammelt er diese zusammen und führt sie erst aus, wenn er die Triggeroperation empfängt.
Hierfür sind im Wesentlichen zwei Betriebsmodi vorstellbar:
Bei einem Modus mit verzögerten Antworten werden die Operationen mit Eintreffen der Triggeroperation bei den OPC-UA Servern ausgeführt und die Ergebnisse der Operationen sowie der Triggeroperation dem OPC-UA Client über die entsprechenden Antworten mitgeteilt. Dadurch erhält der OPC-UA Client für jede Operation, die er ausführt, einen eigenen Statuscode. Die Antwort auf den Trigger, die vom Server zum Client geht, enthält das Gesamtergebnis der Operationen.
Die Operationen werden beim Eintreffen auf dem Server formal überprüft. Im Fehlerfall erhält der OPC-UA Client sofort eine Antwort mit der Information über die aufgetretenen formalen Fehler .
Alternativ kann ein sogenannter Preview-Modus durchgeführt werden. Jede Operation mit einer Mengen-Identität wird formal geprüft und danach simuliert. Das simulierte Ergebnis bzw. das Ergebnis der formalen Überprüfung wird sofort an den Client geschickt. Der Client erhält also eine Vorschau auf das Ergebnis der Operationen.
Wenn der Client feststellt, dass eine der durchgeführten Ope rationen nicht zum gewünschten Ergebnis führen würde, kann e die Operationen verwerfen, indem er die Mengenoperation verwirft. Will der Client, dass die Mengenoperation ausgeführt wird, so sendet er die Triggeroperation. In der Antwort auf die Triggeroperation erhält der Client die Information über das Gesamtergebnis der Operationen.
Die tatsächlichen Detailergebnisse der ausgeführten Operatio nen kann der Server über den Event-Mechanismus senden.
In einem weiteren Ausführungsbeispiel kann die Identität anstelle der ersten Objekt-ID auch im RequestHeader des OPC-UA Datenpakets übertragen werden, zum Beispiel als Request-ID oder zusätzlicher Header.
Wie bereits weiter oben ausgeführt, wird das Problem der kon sistenten datenverändernden Mengenoperation heute von OPC UA nicht adressiert. Das wird aber in der Zukunft eine wichtige Anforderung, speziell in der Kommunikation zwischen Automati sierungssystemen .
Im OPC UA Standard sind bereits sogenannte Transaktionen vor gesehen, die über einen zeitlich vorgegebenen Ablauf verfügen :
BeginTransaction ...
Work ...
EndTransaction/AbortTransaction ...
Rollback .
Im Sinne der Erfindung werden zusammenhängende Operationen nun als Mengen aufgefasst. Die Zugehörigkeit einer Operation zu einer Menge ist hierbei eine statische Eigenschaft, die der OPC-UA Client festlegt. Somit wird kein Transaktionskontext im OPC-UA Server benötigt.
Nach der Zuordnung der Operationen zu verschiedenen Mengen sind atomare Operationen auf diesen Mengen möglich. Hiermit erreicht man dieselbe Funktionalität wie bei Transaktionen, jedoch mit den folgenden Vorteilen.
Das Handling wird einfacher, da keine Transaktionen ausgehandelt werden müssen. Es ist außerdem weniger Kontext im Server erforderlich.
Die Durchführung wird zeitlich unabhängig da keine expliziten Start-/End-Zeitpunkte definiert sind. Die Erhöhung der Anzahl von Mengen ist ohne weitere Erhöhung der Komplexität der Kommunikation möglich.
Allerdings hat diese Methode im Gegensatz zu der aus dem Stand der Technik bekannten Transaktion nicht die Möglichkeit eines Rollbacks, also der Rückgängigmachung des kompletten Vorgangs. Bei näherer Betrachtung stellt man jedoch fest, dass dieses Zurückdrehen, insbesondere in der Automatisierungstechnik, oftmals weder notwendig noch umsetzbar oder gar sinnvoll ist. Wenn ein Ventil erst geöffnet ist, kann der Zustand vor Öffnen des Ventils nicht mehr hergestellt werden, weil z. B. bereits Flüssigkeit aus einem Behälter ausgetreten ist. Das heißt, neben dem Schließen des Ventils (Herstellung des Ausgangszustands aus Sicht des Ventils) müsste noch ein weiterer, neuer Schritt („Cleanup") durchgeführt werden. Daher ist ein aus dem klassischen Datenbankumfeld bekannter Rollback in der Automatisierungstechnik nicht möglich,
Zusammenfassend kann gesagt werden, aus der ausgeführten Sichtweise ergibt sich in der Praxis ein anderes Paradigma als das für datenverändernde Operationen zwischen Client und Server als aus der Datentechnik bekannte. Der Client fasst alle Operationen einer Aufgabe zu einer Menge zusammen. Diese Menge von Operationen wird sukzessive zum Server übertragen. Im Server wird eine Menge aller Operationen einer Aufgabe konsistent ausgeführt. 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 einen beispielhaften Kommunikationswechsel bei erfolgreicher Ausführung einer Aufgabe / Menge von Operationen und
Figur 3 einen beispielhaften Kommunikationswechsel bei Auf- treten eines Fehlers nach Ausführuhrung einer Aufgabe / Menge von Operationen.
Die beispielhafte Aufgabe, die die Automatisierungsanlage ausführen soll, sei das Mischen von grüner Farbe aus gelben und blauen Flüssigkeiten. 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: ein Ventil kann nicht korrekt geöffnet werden, müssen zuerst alle geöffneten Zulaufventile VI, V2 wieder geschlossen werden, und dann am Mischtank G das Ventil R in Richtung Entsorgung geöffnet werden, um die gesammelte Flüssigkeit zu entsorgen.
Hier wäre ein Rollback zwar wünschenswert, er ist aber nicht möglich. Durch das Öffnen der Ventile ist in den beiden oberen Tanks B, Y bereits Flüssigkeit ausgetreten und in dem un- teren 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 und 3 sind beispielhaft die Kommunikationsvorgänge zwischen Client UA-C und den Servern UA-Sl, UA-S2, UA-S3 aufgezeigt.
Ein OPC-UA Client UA-C richtet eine Menge ID von verändernden Operationen 0PEN_V1 (ID) , OPEN_V2 (ID) im Sinne dieser Erfindung ein, indem er den Öffnen-Auftrag für das blaue Ventil VI und den Öffnen-Auftrag für das gelbe Ventil V2 in einer Menge ID vereint und an den / die zuständigen Server UA-S2, UA-S3 sendet. Werden die Operationen dieser Menge konsistent ausgeführt (d. h. beide Ventile öffnen), so ist alles in Ordnung und es werden Bestätigungsnachrichten OK zurück gesendet. Figur 3 zeigt alternativ den Fall eines Fehlers, das Ventil V2 zum gelben Tank G hat nicht ordnungsgemäß geöffnet. Dies wird in einer Fehlermeldung ERR an den Client zurück gemeldet .
Unabhängig von dem Ergebnis der Ausführung der ersten Opera- tionen-Menge ID werden zunächst in einem nächsten Schritt mittels einer zweiten Operationen-Menge ID1 beide Ventile VI, V2 wieder auf ihren Ausgangszustand gesetzt (d. h. geschlossen: CLOSE_Vl (ID1) , CLOSE_V2 (ID1) ) . Danach (nicht mehr Teil der Mengenoperation) kann der für den Sammeltank G zuständige OPC-UA Server UA-Sl nun den Inhalt des Tanks entsorgen. Dieser zusätzliche Schritt ist nach Auftreten dieses Fehlers notwendig, da das so entstandene Gemisch nicht für die Weiterverarbeitung (und damit Ablass mittels Ventil W zu einem nächsten Arbeitsschritt der Anlage) geeignet ist:
OPEN_V3(ID0) . Über einen normalen Rollback-Mechanismus ist die Fehlerbehebung nicht lösbar.

Claims

Patentansprüche
1. Verfahren zur Kommunikation zwischen Client (UA-C) und Server (UA-Sl, UA-S2, US-S3) eines Client/Server-Systems unter Verwendung des Kommunikationsprotokolls OPC-UA wobei zur Interaktion eines Clients (UA-C) mit einem Server OPC-UA Serveraufrufe (OPEN_, CLOSE_) verwendet werden,
dadurch gekennzeichnet, dass
zumindest zwei im Sinne einer Operation logisch zusammengehörige OPC-UA Serveraufrufe (0PEN_V1, OPEN _V2) durch den Client (UA-C) zu einer Serveraufruf-Menge (ID, ID1) zusammen- gefasst werden, wobei die einzelnen OPC-UA Serveraufrufe der Serveraufruf-Menge unabhängig voneinander übertragen werden.
2. Verfahren gemäß Patentanspruch 1,
dadurch gekennzeichnet, dass
die logisch zusammengehörenden OPC-UA Serveraufrufe basierend auf einer durchzuführenden Operation vom Client zusammenge- fasst werden.
3. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
jeder OPC-UA Serveraufruf um eine zusätzliche Identitäts- Kennung der Serveraufruf-Menge (ID) ergänzt wird.
4. Verfahren gemäß Patentanspruch 3,
dadurch gekennzeichnet, dass
es eine Identitäts-Kennung (IDO) existiert, welche anze dass ein damit ausgezeichneter Serveraufruf nicht Teil
Serveraufruf-Menge ist.
5. Verfahren gemäß Patentanspruch 3 oder 4,
dadurch gekennzeichnet, dass
es eine Identitäts-Kennung (ID_T) existiert, welche den Servern anzeigt, dass zuvor übermittelte Serveraufrufe einer Serveraufruf-Menge (ID) nun auszuführen sind.
6. Verfahren gemäß einem der Patentansprüche 3 bis 5, dadurch gekennzeichnet, dass
es eine Identitäts-Kennung existiert, welche den Servern an- zeigt, dass zuvor übermittelte Serveraufrufe einer Serverauf- ruf-Menge (ID) nun nicht auszuführen sondern zu verwerfen sind .
7. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
die in einer Serveraufruf-Menge zusammen gefassten OPC-UA Serveraufrufe durch den Server konsistent ausgeführt werden.
8. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
nach erfolgter Durchführung aller in einer Serveraufruf-Menge zusammengefassten OPC-UA Serveraufrufe überprüft wird, ob die Ausführung aller OPC-UA Serveraufrufe korrekt erfolgt ist, anderenfalls eine Fehlermeldung ausgegeben wird.
9. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
vor der Durchführung jeder Operation mit einer Serveraufruf- Mengen-Identität diese formal geprüft und danach simuliert wird, und das simulierte Ergebnis an den Client geschickt wird .
10. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
in einer Antwort nach Ausführung aller Operationen der Serveraufruf-Menge der OPC-UA Client die Information über das Gesamtergebnis der Operationen an den OPC-UA Server übermittelt, insbesondere werden die tatsächlichen Detailergebnisse der ausgeführten Operationen über den OPC-UA Event- Mechanismus gesendet.
11. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
nach erfolgter Durchführung aller in einer Serveraufruf-Menge zusammengefassten OPC-UA Serveraufrufe überprüft wird, ob die Ausführung aller OPC-UA Serveraufrufe korrekt erfolgt ist, anderenfalls eine Fehlerbehandlungsroutine ausgeführt wird.
12. Verfahren gemäß einem der vorherigen Patentansprüche, dadurch gekennzeichnet, dass
die Identitäts-Kennung als erste Objekt-ID im RequestHeader des OPC-UA Datenpakets übertragen wird, insbesondere als Re- quest-ID oder zusätzlicher Header.
13. Vorrichtung (UA-C) zur Kommunikation mit einem Server
(UA-Sl, UA-S2, US-S3 ) 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 12,
wobei zur Interaktion der Vorrichtung (UA-C) mit dem Server
OPC-UA Serveraufrufe (OPEN_, CLOSE_) verwendet werden, in dem zumindest zwei im Sinne einer Operation logisch zusammengehörige OPC-UA Serveraufrufe (OPEN_Vl, OPEN _V2 ) durch die Vorrichtung (UA-C) zu einer Serveraufruf-Menge (ID, ID1) zusam- mengefasst werden, wobei die einzelnen OPC-UA Serverauf ufe der Serveraufruf-Menge unabhängig voneinander an den oder die empfangenden Server (UA-Sl, UA-S2, US-S3) übertragen werden.
14. 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 12,
wobei zur Interaktion der Vorrichtung (UA-Sl, UA-S2, US-S3) mit dem Client OPC-UA Serveraufrufe (OPEN_, CLOSE_) verwendet werden, in dem
zumindest zwei im Sinne einer Operation logisch zusammengehörige OPC-UA Serveraufrufe (0PEN_V1, OPEN _V2 ) durch die Vorrichtung (UA-Sl, UA-S2, US-S3) zu einer Serveraufruf-Menge (ID, IDl) zusammengefasst werden, wobei die einzelnen OPC-UA Serveraufrufe der Serveraufruf-Menge unabhängig voneinander an den oder die empfangenden Server (UA-Sl, UA-S2, US-S3) übertragen werden.
PCT/EP2014/059359 2014-05-07 2014-05-07 Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe WO2015169355A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2014/059359 WO2015169355A1 (de) 2014-05-07 2014-05-07 Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2014/059359 WO2015169355A1 (de) 2014-05-07 2014-05-07 Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe

Publications (1)

Publication Number Publication Date
WO2015169355A1 true WO2015169355A1 (de) 2015-11-12

Family

ID=50842234

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/059359 WO2015169355A1 (de) 2014-05-07 2014-05-07 Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe

Country Status (1)

Country Link
WO (1) WO2015169355A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109145000A (zh) * 2018-08-13 2019-01-04 上海电气集团股份有限公司 一种工业实时数据库opc ua数据接口实现方法
EP3528064A1 (de) * 2018-02-15 2019-08-21 Siemens Aktiengesellschaft Steuerungssystem und zugehöriges verfahren zur inbetriebnahme, steuerung und überwachung für stromversorgungskomponenten

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), XP055160156, Retrieved from the Internet <URL:web24267.5udns.cn/attachment.aspx?attachmentid=658> [retrieved on 20150106] *
"OPC Unified Architecture", 19 March 2009, ISBN: 978-3-54-068898-3, article WOLFGANG MAHNKE: "OPC Unified Architecture", pages: 1 - 339, XP055160132 *
OPC FOUNDATION: "OPC Unified Architecture Specification Part 2: Security Model (Release 1.01)", 6 February 2009 (2009-02-06), pages 35 pp., XP055123126, Retrieved from the Internet <URL:http://opcf.org/Downloads.aspx?CM=1&CN=KEY&CI=283&EBP=0&SRT=ModificationTime&DES=Y&SE1=Title&FV1=Custom&FT1=opc+ua+part+2+%&SE2=ReleaseStatus&FV2=All&FT2=&CU=4> [retrieved on 20140612] *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3528064A1 (de) * 2018-02-15 2019-08-21 Siemens Aktiengesellschaft Steuerungssystem und zugehöriges verfahren zur inbetriebnahme, steuerung und überwachung für stromversorgungskomponenten
CN110161896A (zh) * 2018-02-15 2019-08-23 西门子股份公司 用于供电组件的控制系统和用于针对供电组件进行起动、控制和监控的所属的方法
CN110161896B (zh) * 2018-02-15 2023-01-03 西门子股份公司 用于供电组件的控制系统和用于针对供电组件进行起动、控制和监控的所属的方法
CN109145000A (zh) * 2018-08-13 2019-01-04 上海电气集团股份有限公司 一种工业实时数据库opc ua数据接口实现方法
CN109145000B (zh) * 2018-08-13 2022-03-18 上海电气集团股份有限公司 一种工业实时数据库opc ua数据接口实现方法

Similar Documents

Publication Publication Date Title
EP1738236B1 (de) Automatisierungsnetzwerk mit zustandsmeldenden netzwerkkomponenten
DE10316217A1 (de) Individuelle Funktionsblöcke zur Verwendung in einem Prozesssteuerungssystem
EP3137999B1 (de) Verfahren und vorrichtung zur transaktionserweiterung bei opc ua
WO2009083133A1 (de) Verfahren und einrichtung zur client-server-kommunikation gemäss dem standardprotokoll opc ua
DE19837871A1 (de) Verfahren zum automatischen Erzeugen eines Programms
DE102020116200A1 (de) Verbessertes arbeitsauftrags-generierungs- und -verfolgungssystem
EP2197160A1 (de) Azyklischer Datentransfer über einen Feldbuskoppler
WO2015169355A1 (de) Verfahren und vorrichtung für konsistente mengenoperationen datenverändernder opc ua aufrufe
DE102019111790A1 (de) Computerimplementiertes Verfahren zur Umstrukturierung eines vorgegebenen verteilten Echtzeit-Simulationsnetzwerks
WO2015197115A1 (de) Verfahren und vorrichtung zur umsetzung eines transaktionskonzepts bei opc ua mittels time-out mechanismus
EP3200034A1 (de) Verfahren und vorrichtung zum zugriff auf daten oder funktionen einer speicherprogrammierbaren steuerung mittels eines webdientes
EP2557464B1 (de) Verfahren zum Betrieb eines Automatisierungssystems
DE602005000715T2 (de) System und Verfahren zur Auswahl einer aktiven Verbindung
EP1233318A1 (de) Softwarekomponente für ein verteiltes Kontrollsystem
EP3430771B1 (de) Maskierung des einflusses nichtunterstützter feldbuskommandos
LU101975B1 (de) Netzwerk zur Datenübertragung
EP3575976A1 (de) Verfahren zum bestimmen einer physikalischen verbindungstopologie eines für die steuergerätentwicklung eingerichteten, echtzeitfähigen testgeräts
WO2004034639A2 (de) Verfahren zur änderung eines parameters für den betrieb eines netzwerks sowie teilnehmer zur durchführung des verfahrens
DE19818041A9 (de) Verfahren zur Erzeugung einer Oberfläche zum Bedienen und Beobachten von Leitsystemen
EP1703667A1 (de) Netzwerkmanagement unter Verwendung eines Master-Replica-Verfahrens
EP1814281B1 (de) Webserver mit integrierter Automatisierungsfunktionalität und zusätzlichem direktem Zugriff auf die Echtzeit-Kommunikationsebene des Realtime-Ethernets
EP1609272B1 (de) Kommunikationsverfahren und system hierfür
DE102010010035A1 (de) Verfahren zum Erstellen von Objekten einer objektorientierten Datenbank
DE102022125330A1 (de) System zum Bilden eines Feldgerätekomplexes und Feldgerät
DE102009056803A1 (de) Kommunikation zwischen Elementen eines Systems

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: 14727168

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14727168

Country of ref document: EP

Kind code of ref document: A1