OPC-UA device protocol - cyclic read vs. subscription

, ,
1

The OPC-UA device protocols allow to choose between 2 mechanisms for data reporting:
https://cumulocity.com/guides/protocol-integration/opcua/#data-reporting

Cyclic read vs. subscription.

What are the pros & cons for each mechanism?
When should subscription be used and when not?

From the first glance cyclic read works fine and is easier to setup.

Thanks for any advice!

Edit:
Regarding the deadband percentage, please be aware of this answer as well:

1 Like
2

Hi Kai,

Cyclic Read is just polling the value every x seconds. This leads to a lot of data event when the value in the OPC-UA Server does not change.

As subscription can be configured to give only updates of the value if something changes. E.g. value, status or timestamp. Even more sophisticated is the deadband value where you can define over which threshold from the last value you would like to get a reading (e.g. 10% more).

I always prefere subscription over cyclic read.

Regards,

Marco

4 Likes
3

Hi Kai,

Marco did already summarize it very well. I would like to add something. If your OPC UA Server supports subscription you should use subscription, that is the standard way to go. However, there are OPC UA Server out there which don’t support subscription. For that reason, cyclic read is available as workaround. The OPC UA gateway is frequently doing a read, nothing else…

Best regards,
Alex

PS:
Have a look at unified-automation (a good source about OPC UA) High Performance OPC UA Server SDK: OPC UA Subscription Concept

5 Likes
4

Hi there,
I would like to add some information about this topic.

I am not sure if it is a good way to reply to this topic. Any suggestions are welcome.

First: a correction.
As defined here, the deadband in Percent is not a corresponding change of %-Value of the current value but rather depending on the EU-Range.

e.g. 
EU-Range High = 100.0
EU-Range Low  = 50.0

Deadband Percent = 10%  --> **deadband value = 5.0**   // ( hi - low ) * deadband / 100.0

Calculation is done based on the last transmitted value

Examples:
The information in the original post suggests that it would need to change from 
50.0 to 55.0 
or
90.0 to 99.0  (10% of last transmitted value)

**Correct**
50.0 to 55.0
or
90.0 to 95.0

Second:
There is a problem in the Current UI of the device-management (as of UI: 1011.0.12)
In the section of the device-protocol where one could configure the deadband of the protocol, it does not work (there exists a workaround for e.g. Postman)
It is supposed to be solved in
UI: 1011.0.15 upwards

–
BR Manfred

2 Likes
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.