Log In
Home
01/03/2020
Offline
This is my personal view and I just want to throw out there so we can have some meaningful discussion regard where it should go.
- Data point status cannot have industry (like oil and gas)custom alarm status. OPC UA status code is pretty generic but industry need to have its own status on top of OPC UA status. For example, level alarm and watchdog alarm status. This kind of status should travel with data value and its timestamp
- Client has to subscribe alarm/data separately and will have difficulty to nail them back together (data with proper alarm status). This is an issue derived from above mentioned issue. We really do not need different subscriptions for live/real-time data and its alarms. For simple alarms (which is only related to single tag. Composite alarms are different matter), they should reside with data. Without it it's hard to implement one simple task - display live data on chart with proper color coding for its alarm status.
- Yes OPC UA has specs for real-time write and historical write for persistence. But why bother? The server implementation for persistence should know whether it's forward or backward data and should persist accordingly. Client should have no knowledge of which API to choose, because server has the knowledge. This is a fundamental mistake for OPC UA spec.
Without these issues addressed, OPC UA will never be prevailing in real-time world.
05/30/2017
Offline
It can sometimes be challenging to make the jump from the frame of reference that someone is used to the frame of reference that OPC UA built on. Making the frame of reference switch requires that one understand what needs to be accomplished with a feature.
For example, you indicate a desire for a vendor specific status that travels with the DataValue. This can be achieved in OPC UA by creating a structure that contains the value and the vendor specific status. Complex variables can also be created that allow clients to subscribe to raw value if that is all they need while providing the value-status structure.
It is also not clear what you think the alternative to the UA approach would be be? custom JSON objects? why is that different from a UA structure designed to meet your requirements?
You also indicate that you need to connect the alarm to the current value an associated process variable. This should be easy to do with the 'SourceNode' field of the alarm. It is not clear why this field does not let you do what you want.
Your comment about forward or backward data is puzzling. The HA APIs allow the client to chose how it wants to get the data no matter how the server persists. So hiding how the server persists the data is a feature rather than a limitation. I really do not see the problem that you want to solve.
Lastly, what are you calling the 'real time world'? Deterministic networks? If you simply mean SCADA/HMI collecting live process data then your statement does not make much sense since OPC is widely used today in that domain. OPC UA builds on that large installed base.
01/03/2020
Offline
Hi Randy,
Thank you for the reply.
I worked with you before and I know that you were having issues on my first point. You were using the reserved bits for status code.
The data structure if I may suggest would be data instance with alarm instance attached (referenced), and for alarms they will have acknowledgements attached (referenced). But for serving data purpose, client should have the parameter to tell server if all the attachments should be instantiated so all the information will served through one package.
On my second point, when a client is subscribing data to get live data, I meant it should get data with its alarm at same time. Not a second read or subscription. Yes I know there are ways to do it but it is awkward.
On my last data point, by real-time world I mean live data feed 24/7 with potential out of order data. All I'm asking is that client should not care whether it's out of order or not. Server should care and that's internal implementation from client. I should have just one API function to call for persistence, without knowing whether it's backward data or not. In simple words, it should be transparent.
Regards,
Brian
05/30/2017
Offline
The trouble with using the StatusCode bits is interoperability requires metadata to describe vendor specific extensions. The structure approach provides the same information but makes use of mechanisms that are already in UA to document the extensions. The important point is OPC UA allows you to represent what you need so it is not clear why you see an issue.
Alarms are different from data even if they are related. Many applications are dedicated alarm clients and they want the alarms and not the data. Other clients only care about the data. Furthermore, alarms are are complex when data can be simple. This means the subscription/monitoring parameters are usually different so it makes no sense for both sets of information the same subscription. What does make sense is metadata that makes it easy to correlate an alarm with a data point when there is a relationship (not all alarms are tied to a single data point). The SourceNode/SourceName should do this.
HA allows clients to request data ordered in the way they want. This is especially important when clients want processed data. Clients do not care how it is persisted but it does mean the server has to be able to sort the data. This is not an issue for the majority of HA server implementations which uses a DB for persistence but I can see it could be a challenge for a server with a simple file based log of data acquired from another system. However, I don't see the value of an API optimized for a subset of possible server implementations especially if this API would then require clients to do more work sorting data that could be easily sorted by most servers.
1 Guest(s)
Usage Policy