Seperate Data and Metadata endpoints

[jwise-mfg]

Splitting out from #3

I would make the data/metadata queries different endpoints as well. It's not often that you want to mix the fast changing data with the stale metadata, in my experience

[matthewGEA]

Interested to discuss this more.

Should metadata be considered to be data, even if it is slow changing or never changing? If so, metadata values also have elementIDs where there is no differentiation on READ or SUBSCRIBE.

[randy-armstrong]

Metadata is data. The issue is metadata does not need to be sent with every update because it does not change as frequently. Separating data and metadata into separate streams is a useful abstraction.

The most important feature is there needs to be an indication that metadata has changed in the live data stream. OPC UA PubSub does this with the ConfigurationVersion. OPC UA Client-Server does this with the StructureChanged and SemanticsChanged bits on the StatusCode.

[matthewGEA]

There are many directions to go, so I will list one option to consider...

Given a generic sensor with entityID of "sensor", READ sensor would return the following:

• sensor.value
• sensor.TimeStamp
• sensor.DataType
• sensor.EngUnit
• sensor.NamespaceURI
• sensor.ParentId
• sensor.metadataCustomID1.value
• sensor.metadataCustomID1.time
• sensor.childrenId[]

SUBSCRIBE sensor would provide on-change updates for any entity underneath "sensor", including metadata. Optionally, a client could subscribe to sensor.value only and not receive updates when the other attributes change.

Or, are you saying the most important feature is in having a single aggregate checksum/status to know when something has changed, but then let the client determine the metadata they want to follow-up with specific READ commands?

[randy-armstrong]

I understand the appeal of the "subscribe object" helper functions but the devil is always in the implementation details.

In particular, metadata and data subscriptions are different. At a minimum, the update frequency for a metadata subscription would be much slower than a data subscription. The client needs to decide what it wants and how frequently it receives updates. Helper functions like "subscribe sensor" could force a server to design its address space in a way that assumes clients will blindly ask for everything even if they don't really need it. This would likely lead to models where the metadata is not part of an object but in a separate object like metadata.sensor which would not be ideal.

The model I am suggesting is clients could promote any metadata value to data value if they choose but the default behaviour is metadata is kept separate from data (i.e. a separate topic for metadata) with some indicator in the data that a material change to the metadata occurred.

[matthewGEA]

Well, that certainly is another option to setup the interface:

READ sensor by default returns

• sensor.value
• sensor.TimeStamp
• sensor.metaDataTimeStamp

and READ sensor.metadata would return the rest:

• sensor.metadata.DataType
• sensor.metadata.EngUnit
• sensor.metadata.NamespaceURI
• sensor.metadata.ParentId
• sensor.metadata.CustomID1.value
• sensor.metadata.CustomID1.time
• sensor.metadata.childrenId[]

Although, I would think this approach has a higher likelihood of your concern being realized?

"models where the metadata is not part of an object but in a separate object like metadata.sensor which would not be ideal."

[randy-armstrong]

Some postman demos using the OPC UA WebAPI:

Read Value:
https://www.postman.com/randy-armstrong/opc-ua-webapi-demo/request/ko2xvj3/readvalue

Read Properties:
https://www.postman.com/randy-armstrong/opc-ua-webapi-demo/request/qc97pkc/readproperties

The ReadProperties is an extension I added for discussion. It uses the AttributeId: 60 to request that Server return the values of all Properties of the specified Node as a dynamic Structure.

Adding support for virtual Attributes that are only accessible via the JSON WebApi is one tool we have to extend the OPC UA Services to meet the requirements identified here.

The idea that a Server can dynamically create a Structure is already part of the OPC UA specification but it is typically not used.

[jwise-mfg]

WG Discussion on this topic:

• The base set of common metadata is described in the RFC (see also Issue Data Quality is not commonly available Metadata #33)
• For additional metadata, objects could have a "property bag" of settable key-value pairs that can be returned as metadata.
• We discussed the idea of having a query parameter that indicates if this extra metadata should be returned or not, but did not resolve
• If user's need more richness in their metadata, they should be modeling that data using relationships.

I will propose an edit to the doc for discussion at the next meeting.

[jwise-mfg]

Proposed resolution: e98eb01