EP2826224B1 - Clients accessing a service provided by a server using opc-ua - Google Patents

Description

The invention relates to a method for access by clients to a server service of a server in a network by means of an OPC UA.

OPC UA (= OPC Unified Architecture) is a communication protocol and information model for communicating different automation components (devices), see http://www.opcfoundation.org.

In OPC UA, all communication relationships take place bilaterally between two endpoints. An OPC UA client establishes a communication channel to an OPC UA server, and all communication between the two takes place in this channel. This applies in particular to all read and write accesses, which thus also includes the so-called subscriptions, in which clients are notified of value changes of variables.

In practice, the case often occurs that several clients are interested in the same information of a server. In OPC-UA, each of the clients then establishes a bilateral communication to the server and polls the same values as the other clients. Examples in which such a case occurs are several Human Machine Interface (HMI) devices, which show the same view of a server state, Historian applications, logging, state monitoring, and a parallel KPI (Key Performance Indicator) creation (KPI). ,
From the WO 2004/003735 A2 Such a procedure is already known for OPC, the predecessor of OPC-UA.

The invention is based on the object of providing an improved method for accessing clients to server-variable values of at least one variable server service of a server in a network by means of a server to provide hardware for performing the improved method.

The object is achieved according to the invention with regard to the method by the features of claim 1 and with respect to the hardware by the features of claims 8 to 10.

Advantageous embodiments of the invention are the subject of the dependent claims.

In the method according to the invention for accessing clients from a server service of a server in a network by means of an OPC UA, which provides variable values to the clients, a client logs on to the server service by sending a subscription for the server service to the server sends. The server creates a subscription structure for the server service with a unique subscription ID, i. a unique identifier, and a TCP / IP multicast group (TCP = IP) associated with this subscription structure with a unique multicast address, and allocates the multicast address and to each client that logs in through a subscription for the server service the subscription ID with. The server sends each value change of the value of each server service variable to the multicast address via the network over a multicast message, so that all clients logged on to the server service receive the same multicast message.

In doing so, the server will request for various requested such server services (subscriptions), i. for server services with different variables, each created a separate subscription structure and a separate TCP / IP multicast group, with the subscription IDs and multicast addresses different server services from each other.

Here and below clients are always OPC-UA clients and servers are always OPC-UA servers.

The method according to the invention extends the conventional OPC-UA specification with respect to the server services designated as subscriptions in OPC-UA, in which clients are informed of value changes of variables which are made available by a server and for which the clients log on to the server. The server, in accordance with the invention, serves various clients that subscribe to the same subscription, i. For the same variables, login, a multicast group and sends value changes of these variables in the form of a multicast message to the multicast group, so that all registered for the respective subscription clients receive the same multicast message.

The server thus notifies a value change of a variable to all registered clients by means of a single multicast message, whereas in the conventional OPC UA it is available to each logged-in client on its request (ie to a so-called polled refresh request, by means of which the client sets the value of a or querying multiple variables at the server) sends a separate message. This advantageously reduces the utilization of the server and the network and increases the efficiency of subscriptions over the conventional OPC UA.

In particular, the polled refresh requests of the clients registered with the server service for the variables of the server service can be omitted, i. these clients no longer need to query the server for the current values of variables because the server automatically communicates changes in the value of the variables of a server service by means of the multicast messages and at the same time to all clients registered for the server service.

Applications of a client that generate polled refresh requests for variables of the server service need not be changed compared to the conventional OPC-UA, since these polled refresh requests can be recognized and intercepted by the OPC-UA communication stack of the client, so that they not be delivered to the server. The OPC-UA communication stacks of the clients are therefore preferably designed to detect and intercept such polled refresh requests generated by applications of the client.

In addition, the invention makes it possible to use OPC-UA in places where this is not possible with conventional OPC subscriptions, e.g. in some cases, which today can only be realized with clocked communication, since the automatic transmission of the multicast messages by the server can be adapted to the corresponding timing.

In a preferred embodiment of the invention, the multicast messages sent by the server are UDP (User Datagram Protocol) messages.

The UDP is a simple and connectionless network protocol and is thus particularly advantageous for the simple and fast transmission of multicast messages.

A further preferred embodiment of the invention provides that for the registration of a client for the server service of the OPC-UA communication stack of the client in the credentials sent to the server inserts a date that identifies the client as a multicast subscriptions supporting client.

The date allows the server to communicate the readiness of a client to join a multicast group. The insertion of the date by the OPC-UA communication stack of the client is advantageous since the subscription method according to the invention can thereby remain transparent to applications of the client, so that these applications need not be changed compared to the conventional OPC-UA. The extension according to the invention of the OPC-UA can thereby be limited on the client side to an expansion of the functionality of its OPC-UA communication stack.

Preferably, the server further generates the subscription structure and the TCP / IP multicast group after first receiving a subscription for the server service.

This creates the subscription structure and the TCP / IP multicast group as needed. This is advantageous since it is generally unpredictable which subscriptions are requested by the clients and in particular no unnecessary subscription structure and the TCP / IP multicast group are created.

Furthermore, after receiving a subscription application from a client for the server service, the server preferably checks whether a subscription structure already exists for the server service, and creates a subscription structure for the server service only in the case that no subscription structure is yet established exists for the server service.

In this way, it is advantageously avoided that subscription structures are created multiple times and the server and the network are unnecessarily burdened.

In a further embodiment of the invention, the multicast message is sent multiple times by the server.

This is particularly advantageous if the multicast messages are transmitted unsecured, with the loss of individual multicast messages is accepted and not checked. The multiple sending of a multicast message can advantageously increase the security of delivery of the multicast message in such cases.

A further embodiment of the invention provides that the set of server service variables is formed by the server as a union of variables contained in subscription applications received from the server from different clients.

As a result, it can be advantageously taken into account that in general different clients do not request exactly the same subscriptions. Subscriptions that differ only slightly (in terms of fewer variables) can be grouped together by forming the union of variables, so that a common subscription structure and multicast group are created for them. In this case, preferably a degree of agreement of different subscriptions is determined, up to which these subscriptions are combined or above which a new subscription structure and a new multicast group are created.

Hardware according to the invention is designed to carry out the method according to the invention with the advantages mentioned above.

A client according to the invention accordingly has an OPC-UA communication stack, which is designed to insert a date into the log-on data sent to the server for logging on the client for the server service, which identifies the client as a client supporting multicast subscriptions.

A server according to the invention has an OPC-UA server stack, which is designed to create a subscription structure for the server service with a unique subscription ID and a TCP / IP multicast group assigned to this subscription structure with a unique multicast address to notify a subscription subscription for the server service client, the multicast address and the subscription ID, and to send each change in value of the value of each server service variable to the multicast address via the network via a multicast message.

Thus, OPC UA clients and servers according to the invention differ from conventional OPC UA clients and servers only by additional functions of their OPC UA communication stacks. This has the advantages of having the extra features for conventional OPC UA clients and servers are fully backwards compatible and transparent and applications from clients and servers need not be changed compared to the conventional OPC UA.

A network according to the invention comprises at least one client according to the invention and at least one server according to the invention.

FIG 1

eine Anmeldung mehrerer Clients zu einem Serverdienst eines Servers in einem Netzwerk mittels einer OPC-UA gemäß dem Stand der Technik,

FIG 2

eine Mitteilung einer Wertänderung einer Variablen an zu einem Serverdienst angemeldete Clients in einem Netzwerk mittels einer OPC-UA gemäß dem Stand der Technik,

FIG 3

eine Anmeldung mehrerer Clients zu einem Serverdienst eines Servers in einem Netzwerk mittels einer OPC-UA gemäß dem erfindungsgemäßen Verfahren, und

FIG 4

eine Mitteilung einer Wertänderung einer Variablen an zu einem Serverdienst angemeldete Clients in einem Netzwerk mittels einer OPC-UA gemäß dem erfindungsgemäßen Verfahren.

The above-described characteristics, features, and advantages of this invention, as well as the manner in which they will be achieved, will become clearer and more clearly understood in connection with the following description of exemplary embodiments which will be described in detail in conjunction with the drawings. Showing:

FIG. 1

a login of several clients to a server service of a server in a network by means of an OPC UA according to the prior art,

FIG. 2

a notification of a value change of a variable to clients logged on to a server service in a network by means of a prior art OPC UA,

FIG. 3

an application of multiple clients to a server service of a server in a network by means of an OPC UA according to the inventive method, and

FIG. 4

a notification of a change in value of a variable to logged on to a server service clients in a network by means of an OPC UA according to the inventive method.

Corresponding parts are provided in all figures with the same reference numerals.

FIG. 1 shows a registration of multiple clients 1, 2, 3 to the same server service of a server 4 in a network by means of an OPC UA according to the prior art. The server service provides clients 1, 2, 3 with variable values of one or more variables. In order to log in to the server service, each client 1, 2, 3 according to the OPC UA as a communication channel 7.1, 7.2, 7.3 to the server 4 and sends via its communication channel 7.1, 7.2, 7.3, a subscription application 5.1, 5.2 , 5.3 (subscriber call) to the server 4. Each communication channel 7.1, 7.2, 7.3 is designed as a TCP connection.

Subscription login 5.1, 5.2, 5.3 defines the requested server service by including the variables whose client client 1, 2, 3 is interested in changing their values, and an update rate indicating a desired time interval between updates of the values of those variables. To do so, subscription subscription 5.1, 5.2, 5.3 calls the CreateSubscription method at server 4 and specifies the variables and the update rate as arguments to the method. For example, for the three variables var1, var2, var3, and an update rate of 250 ms, the subscription login 5.1, 5.2, 5.3 contains the CreateSubscription (var1, var2, var3, 250ms) method call.

In FIG. 1 this is shown in greater detail for a first client 1. An application 1.1 of the first client 1 generates the request for the subscription application 5.1 of the first client 1 and transfers it to an OPC-UA communication stack 1.2 of the first client 1, which then sends the subscription application 5.1 to the server 4. Accordingly, the subscription applications 5.2, 5.3 of the other clients 2, 3 are generated and sent.

The server 4 receives the subscription applications 5.1, 5.2, 5.3 of the clients 1, 2, 3 via a server stack 4.1, defines a separate subscription structure S1, S2 for each client 1, 2, 3 that logs on to the server service , S3 on and manages these. With the subscription structures S1, S2, S3, the server 4 generates a separate subscription ID for the server service for each client 1, 2, 3 that logs in to the server service and sends it via the respective communication channel 7.1, 7.2, 7.3 by means of a separate Subscription notification 6.1, 6.2, 6.3 (Subscriber Response) to the respective client 1, 2, 3.

As in FIG. 1 Once again illustrated by the example of the first client 1, the OPC-UA communication stack 1.2 of the first client 1 receives the subscription notification 6.1 of the server 4 sent to the first client 1 and transfers the application 1.1 of the first client 1, which registers the subscription 5.1, the Subscription ID included in subscription notification 6.1. The same applies to the other clients 2, 3 who log on to the server service.

FIG. 2 shows by way of example a notification of a change in value of a variable var1 of the server service to clients logged on to the server service 1, 2, 3 by means of an OPC-UA according to the prior art. The server 4 determines the subscription structures S1, S2, S3 affected by the change in value and sends each client 1, 2, 3 of a determined subscription structure S1, S2, S3 determined via the respective communication channel 7.1, 7.2, 7.3 a separate TCP gateway. A value change message (Subscriber-Publish), which tells the client 1, 2, 3 the value change of the first variable var1.

FIG. 3 shows a registration of multiple clients 1, 2, 3 to the same server service of a server 4 in a network by means of an OPC UA according to the inventive method. As with the basis of the FIGS. 1 and 2 In accordance with conventional methods described above, the server service provides the clients 1, 2, 3 with variable values of one or more variables. In order to log on to the server service, each client 1, 2, 3 in turn builds a TCP connection according to the OPC UA Communication channel 7.1, 7.2, 7.3 to the server 4 and sends via its communication channel 7.1, 7.2, 7.3, a subscription application 5.1, 5.2, 5.3 (subscriber call) to the server. 4

The subscription application 5.1, 5.2, 5.3 defines, as in the conventional method, the requested server service by being interested in the variables whose value changes the client 1, 2, 3 is interested in, and an update rate representing a desired time interval between updates of the values indicates this variable contains. To do so, subscription subscription 5.1, 5.2, 5.3 calls the CreateSubscription method at server 4 and specifies the variables and the update rate as arguments to the method. For example, for the three variables var1, var2, var3 and an update rate of 250 ms, Subscription Login 5.1, 5.2, 5.3 again contains the CreateSubscription (var1, var2, var3, 250ms) method call.

In FIG. 3 this is shown in greater detail for a first client 1. An application 1.1 of the first client 1 generates a request for the subscription application 5.1 of the first client 1 and transfers it to an OPC-UA communication stack 1.2 of the first client 1. In contrast to the conventional method, the OPC-UA communication stack 1.2 of the first client 1 adds Subscription application 5.1 a date that identifies the first client 1 as a client 1, 2, 3 that supports multicast subscriptions, and then sends this date together with the subscription application 5.1 to the server 4. Accordingly, the subscription Registrations 5.2, 5.3 of the other clients 2, 3 are generated, supplemented by a date that identifies the support of multicast subscriptions of the respective client 2, 3, and sent to the server 4.

The server 4 receives the subscription applications 5.1, 5.2, 5.3 of the clients 1, 2, 3 via a server stack 4.1. After the first receipt of a subscription application 5.1, 5.2, 5.3 for the server service recognizes the server 4 based on the Support of multicast subscriptions expelling date the extended functionality of the Subscribers login 5.1, 5.2, 5.3 sending client 1, 2, 3, then sets a subscription structure S1 with a unique subscription ID for the server service and one of these associated TCP / IP multicast group 9 with a unique multicast address and sends this subscription ID and multicast address by means of a subscription notification 6 (Subscriber Response) to the logging client 1, 2, 3 via the communication channel 7.1, 7.2, 7.3 to the server 4.

When the server 4 receives further subscription applications 5.1, 5.2, 5.3 for the same server service, it does not generate any further subscription structure S1, S2, S3, but shares the subscription ID of the already established subscription structure S1 and the multicast address of the associated multicast group 9 each further logging in for the server service client 1, 2, 3 via the respective communication channel 7.1, 7.2, 7.3 by means of a subscription notification 6 with.

In contrast to the conventional method, the server 4 thus generates only a single subscription structure S1 for the server service in the method according to the invention and creates a multicast group 9 for the clients 1, 2, 3 that register for the server service. The subscription notifications 6 sent to the clients 1, 2, 3 thus all contain the same subscription ID for identifying the server service or the subscription structure S1 and the same multicast address of the assigned multicast group 9.

As in FIG. 3 is shown as an example of the first client 1, the OPC-UA communication stack 1.2 of the first client 1 receives the subscription notification 6 of the server 4 sent to the first client 1 and transfers the application 1.1 of the first client 1, which supports the subscription application 5.1 has requested the Subscription ID contained in Subscription Notification 6. The multicast address On the other hand, the application 1.1 is not notified, ie it remains hidden for the application 1.1 that only a subscription structure S1 is generated. For the application 1.1 there is therefore no difference between the conventional and the subscription method according to the invention, so that it does not have to be changed in any way when using the subscription method according to the invention in comparison to the conventional subscription method. The same applies to the other clients 2, 3 who log on to the server service.

FIG. 4 shows a notification of a change in value of a variable var1 to logged on to a server service clients in a network by means of an OPC UA according to the inventive method.

The server 4 determines the subscription structures S1 affected by the change in value, whereby in this example only one subscription structure S1 is affected. For each determined subscription structure S1 determined, the server 4 generates exactly one multicast message 8 (Subscriber Publish), which contains the change in value of the variable var1 and is designed as a UDP telegram. This multicast message 8 is sent to the multicast address of that multicast group 9 which is assigned to the respective subscription structure S1, so that all of these multicast group 9 belonging clients 1, 2, 3 receive the same multicast message 8.

A value change of variable var1 is thus sent by a single multicast message 8 to all clients 1, 2, 3 logged on to the server service, while in the conventional method the server 4 sends a separate TCP to each client 1, 2, 3 logged on to the server service. Value change message sends.

Although the invention has been illustrated and described in detail by a preferred embodiment, the invention is not limited by the disclosed examples and other variations can be derived therefrom by those skilled in the art without departing from the scope of the invention.

LIST OF REFERENCE NUMBERS

1, 2, 3

client

1.1

application

1.2

OPC-UA communication stack

4

server

4.1

Server stack

5.1, 5.2, 5.3

Subscription Application

6, 6.1, 6.2, 6.3

Subscription notification

7.1, 7.2, 7.3

communication channel

8th

multicast message

9

multicast group

S1 S2, S3

Subscription structure

var1

variable

Claims (9)

1. Method for giving clients (1, 2, 3) access to a server service of a server (4) in a network using an OPC-UA, wherein

   - the server service provides the clients (1, 2, 3) with varying values of at least one variable (var1),

   - a client (1, 2, 3) registers for the server service by transmitting a subscription registration (5.1, 5.2, 5.3) for the server service to the server (4),

   - the server (4) creates, for the server service, a subscription structure (S1, S2, S3) having a unique subscription ID and a TCP/IP multicast group (9) which is associated with this subscription structure (S1, S2, S3) and has a unique multicast address,

   - the server (4) communicates the multicast address and the subscription ID to each client (1, 2, 3) registering for the server service by means of a subscription registration (5.1, 5.2, 5.3), and

   - the server (4) transmits each value change in the value of each variable (var1) of the server service to the multicast address using a multicast message (8) via the network, with the result that all clients (1, 2, 3) registered for the server service receive the same multicast message (8),

   characterized in that, in order to register a client (1, 2, 3) for the server service, the OPC-UA communication stack (1.2) of the client (1, 2, 3) inserts a data item into the registration data transmitted to the server (4), which data item shows the client (1, 2, 3) to be a client (1, 2, 3) supporting multicast subscriptions.
2. Method according to Claim 1,
   characterized in that the multicast messages (8) transmitted by the server (4) are UDP messages.
3. Method according to one of the preceding claims,
   characterized in that the server (4) generates the subscription structure (S1, S2, S3) and the TCP/IP multicast group (9) after receiving a subscription registration (5.1, 5.2, 5.3) for the server service for the first time.
4. Method according to one of the preceding claims,
   characterized in that, after receiving a subscription registration (5.1, 5.2, 5.3) from a client (1, 2, 3) for the server service, the server (4) checks whether a subscription structure (S1, S2, S3) already exists for the server service and creates a subscription structure (S1, S2, S3) for the server service only if a subscription structure (S1, S2, S3) does not yet exist for the server service.
5. Method according to one of the preceding claims,
   characterized in that the multicast message (8) is repeatedly transmitted by the server (4).
6. Method according to one of the preceding claims,
   characterized in that the set of variables (var1) of the server service is formed, by the server (4), as a combination set of variables (var1) which are contained in subscription registrations (5.1, 5.2, 5.3) from different clients (1, 2, 3) which are received by the server (4).
7. Client (1, 2, 3) for carrying out the method according to one of the preceding claims, wherein the client (1, 2, 3) has an OPC-UA communication stack (1.2) which is designed to insert a data item into registration data which are transmitted to the server (4) and are intended to register the client (1, 2, 3) for the server service, which data item shows the client (1, 2, 3) to be a client (1, 2, 3) supporting multicast subscriptions.
8. Server (4) for carrying out the method according to one of Claims 1 to 6, wherein the server (4) has an OPC-UA server stack (4.1) which is designed to create, for the server service, a subscription structure (S1, S2, S3) having a unique subscription ID and a TCP/IP multicast group (9) which is associated with this subscription structure (S1, S2, S3) and has a unique multicast address, to communicate the multicast address and the subscription ID to each client (1, 2, 3) registering for the server service by means of a subscription registration (5.1, 5.2, 5.3), and to transmit each value change in the value of each variable (var1) of the server service to the multicast address using a multicast message (8) via the network.
9. Network for carrying out the method according to one of Claims 1 to 6, comprising at least one client (1, 2, 3) according to Claim 7 and at least one server (4) according to Claim 8.

Images