Message or Subscription?

[CaRu2024]

Hello Everybody,
My name is Carsten and I am from an engineering company with no experience with the use of OPC UA so far. I am just trying to understand the basics. To be honest I am a little bit confused by the terminology of "services", "subscription", "message" and "event" and please excuse me if refer to these expressions in an irritating way.

Considering a possible applications of OPC UA for our purposes the following basic question comes into my mind:
What is the best way to obtain data from a sensor integrated to production line, e.g. a laser based measurment of the distance between the sensor and a sheet of metal?

In order to explain this question let me describe more what I mean:
We have a production line with a control system and we have the single sensor. I do understand that, on the one side the sensor needs to be connected to an OPC-server or even has to contain a feature acting as an OPC-server already. On the other side the contol system needs to have an OPC client application. The question is, how is the communication working between both, the server and the client ?
A) Shall the server provide a service which presents the sensors data continuously or periodically and the client will then just subscribe to this service?
B) Or shall the client send a message to the server and request the data? And the server then will respond to this request with a message, too, that contains the requested data?

Is is one of the two options or are there even more options and is one of the options reccommend, eg. for reasons of perfomance, safety or reliability?

Thanks for your time and patience,
Carsten

[Support Team]

Hi,

the OPC UA technology offers different mechanizm which all have their pros and cons and final selection depends on the use case.

1) UA Client/Server (the sensor being the "Server" itself, or attached to a "Server" e.g. PLC) providing the Data "individually" to the client (maybe multiple clients) in a peer-to-peer connection. The security (authentication and encryption) is, in a peer-to-peer relation individual for each connection/session.
-> with this approach the Client could a) adhock-read (on desire), b) could also cyclic read (polling), c) or even better "monitor" (on change) the data
-> and each client can decide what is best approach for the use case: a control system probably needs constant flow of data, wheras an HMI/Scada only needs "on change".
-> Depending on the "intelligence" of the sensor, OPC UA could even "deadband" the monitored data and transfer data only if changed more than 5%, and by such pre-operation the measured value will be transmitted only if "important" enough (extremley reduce bandwith).

2) UA Client/Server (the sensor being a "Client" itself, connected to one or more servers) and "write" the value, a) cyclic or b) when changed, depending on its internal configuration, and depending on the server's individual desire. Each server being a pre-configured target, where the client writes to individually.

3) UA PubSub (the sensor being a "publisher" itself, constantly steam, or publish on change, the data to a Broker (pre-configured target), or even broadcast/multicast the data without a specific target, and any subscriber listening on the cable can grab the information (or subscribe to the Broker respectively).

These are basically the options you have with OPC UA, including the sub-options. The beauty in OPC UA is that you could even have a combination of those, depending on which/how many different use cases you want to fullfill. And even better the standardized information modeled data is same for al these communication options.
E.g. on IO level between the Sensor and the PLC you probably want a constant (cyclic) stream, last value is most important. Between PLC and HMI/Scada you you probably want monitoring on-change (with deadband), but all values are of relevance, not only the last (tracking&tracing). Between Scada and MES/ERP you probably want publish to a Broker (on-prem, edge) which decouples data provision from the consumer(s) data sink, which might be data-lake, or analytics (no control-loop, but long term time series for statistics type of applications)

Hoping I could shed some light on all the terminology, which i totally agree, seems to be mixed up. You as an engineer having your application specific use case in mind, looking for an optimal solution. The vendor of the sensor on manufacturer of the PLC, offering the sensore for different use cases, may decide for the "full package" of options, and let you pick/configure the one you desire.