Log In
Home
01/15/2025
Offline
Hello,
I’m currently working on resolving an issue with an OPC Client application which is using the .net client components and I’m having an issue with understanding notification order.
So in my client I am creating a subscription for a number of customer-configured tags (e.g. A, B, and C). In this case, the customer has configured their ladder logic to write to A, B and then C, with the expectation that the C tag notification is a trigger to tell the client that it can now carry out some operation on the client-cached values of A and B.
So what they expect to happen, in the order they expect it to happen, is:
- Add items A, B and C to subscription for tags A, B and C respectively.
- Write fresh value to tag A from PLC.
- Write fresh value to tag B from PLC.
- Write fresh value to tag C from PLC.
- The client gets a notification for A, B and C in that order. When we get the notification for C we are assuming that we have already received notifications for A and B and the client can use the fresh cached values for A and B.
What’s actually happening:
- Add items A, B and C to subscription for tags A, B and C respectively.
- Write fresh value to tag A from PLC.
- Write fresh value to tag B from PLC.
- Write fresh value to tag C from PLC.
- The client gets a notification for A, C and B in that order. When we get the notification for C we are assuming that we have already received notifications for A and B and the client can use the cached values for A and B. The problem is obviously that the cached value for B is stale.
One thing to mention is that the server shows the tags being updated at the same timestamp (not sure if that matters)
So my question is:
How do we track the order that these operations are happening on the server/PLC? Is this something that the UA stack even handles or does the server just throw the notifications at the client in any arbitrary order at the end of the publishing interval? Is there some configuration that I’m missing to define some sort of dependency between these items, or maybe a common design pattern that people use to achieve this that isn’t necessarily part of the UA stack itself?
Any advice would be greatly appreciated,
Thanks very much.
05/30/2017
Offline
You cannot make any assumption about the order that updates are received.
This is true even if it is seems to work under some conditions with some s/w. There is nothing in the specification that guarantees that updates will be delivered in the same order (all of the logic for queuing, bundling updates into messages can re-order updates – on top of that the client side library may change the order due to threading).
The timestamps need to be used to determine relationship between updates.
Moderators-Specifications
Moderators-Companion
Moderators-Implementation
Moderators-Certification
Moderators-COM
02/24/2014
Offline
If you want to ensure the data is all received at the same time , then you should update the server to generate a structure with the three values and make sure the Server perform an atomic update on the structure – then when the structure is received it contain the three value as a set.
Paul Hunkar - DSInteroperability
10/18/2019
Offline
Yes, I also agree with the usage of Structure Data Type for use cases where we have transactional context and need to make decisions based on the received data.
It is used in multiple Companion Specifications for modelling and should be encouraged to be used to group data based on the use case.
Part 3 Annex also gives an overview of the usage of structure or simple data variables: https://reference.opcfoundatio…..cs/A.4.3
Many times, OPC UA is considered for simple types for reading a sensor value etc. but OPC UA has a lot of useful mechanisms to solve different use cases.
The only problem you might face with Structures is some OPC UA SDKs may or may NOT support it but then it is a matter of time and we need to start using available features and get these things addressed over a period of time.
01/15/2025
Offline
Than you very much for the replies. The data structure approach would be ideal but unfortunately isn’t practical for us as our customers have ownership over these OPC servers and we wont be able to convince them to make these changes their end. We also need our solution to work with any OPC UA server out of the box, and the fact that not all vendors support data structures (yet) has me very nervous, although I am definitely going to push for adaption our OPC client when it is more widely supported.
I found a (not perfect, but one we are happy with for now) solution for this issue. I originally had the data change notification handler subscribed to each monitored item in the subscription. I’ve changed this to now subscribe to the subscription instead and the notification which comes in contains the new values for A,B and C regardless of the order that they are configured against the subscription or the order that their values are set (as long as they are all set in the same publishing interval)
Thanks again for the advice, I will definitely push for the structured data model approach in the future.
1 Guest(s)
Usage Policy