Mapping spec

[Kantiran91]

Add the Spec for the umati Dashboard PubSub

[wlkrm]

I think including the TypeDefintion of the Objects and maybe even the nested VariableTypes (e.g. FiniteStateVariableType for CurrentState) the is also needed, as the Frontend has some conditional rendering logic based on TypeDefinitions. I suggest adding Fields with TypeDefintion for the ObjectNode of the DataSet. E.g.:

        "Fields": [
            {
                "Name": "TypeDefinition",
                "Description": {
                    "Locale": "",
                    "Text": ""
                },
                "FieldFlags": 0,
                "BuiltInType": 0,
                "DataType": {
                    "Id": 0
                },
                "ValueRank": 1926237584,
                "ArrayDimensions": [],
                "MaxStringLength": 0,
                "DataSetFieldId": "57B13D4E-3F71-2A07-5AE5-1E9107E09EF9",
                "Properties": []
            },

[Kantiran91]

I´m not sure. The TypeDeifnition is given in the MetaData. If it is part of the DataSet a lot of value which do not change will send in every message.

[wlkrm]

I don't think it matters much, except that using the description may not be semantically straightforward.
Wouldn't we use Delta Frames if we were interested in low bandwidth anyway?

[GoetzGoerisch]

Key and Delta Frames, should be followed.

[Kantiran91]

You're right, both solutions are not elegant as they misuse some concepts of the specification. I understand your point about mapping as a field, keeping the information in the same place, but with Delta Frames, this information is also missing, and a client would need a mapping logic.

The solution with the JSON description has the advantage of being extendable, and we also need to encode references somewhere.

[Kantiran91]

Where do you think using the field is violating the Spec?

We add MetaData (the TypeDefinition) to the DataSet

E.g, how to serialize the TypeDefintion (FiniteStateVariableType) of the CurrentState if it is part of the State's DataSet.

The CurrentState has a own Topic that describes the Type.

[wlkrm]

Yes, but nothing in the spec forbids this, I guess, as arbitrary fields can be added.
Ah ok, then this should be updated:

The image shows a part of an address space. Each object is mapped to a DataSet:

Production
ActiveProgram
State

If CurrentState gets its own message, we break the semantics, that each ObjectNode (object?) gets its own DataSet?
What would be the semantics? There is always an own DataSet for nodes, if they are object nodes or if they are VariableTypes with properties? It they are VariableTypes with properties they get their own Topic, otherwise they are added to the parent?

I find the simpler mapping of ObjectType -> Own topic, VariableType -> no own topic more straightforward.

[Kantiran91]

The semantic idea was that a topic contains the childs. So the value of a Variable is in the DataSet of the Object an the childs are in the new Topic.

The question in a straightforward mapping is, how to handle that variable also can have childs and grandchilds?

[Kantiran91]

Yes, but nothing in the spec forbids this, I guess, as arbitrary fields can be added.

Yes also nothing forbids to use the description. Both solution are ugly in my point of view. The description solution try to map metadata to metadata and data to data.

[Kantiran91]

@wlkrm I try to describe both variants. Can you please check if I describe the Field solution correct?
If it is okay for you I would suggest to send this doc with both variants to the OPC Foundation and get their opinion.

[ccvca]

How to derive the Topic-Path for specifictions like CNC, where Nodes have multiple BrowsePaths?
Whats the topic of Nodes without a BrowsePath (e.g. Events that are not hierarchical connected to the address space)

[GoetzGoerisch]

@Kantiran91 could you please rebase onto of the latest develop?

[Kantiran91]

How to derive the Topic-Path for specifictions like CNC, where Nodes have multiple BrowsePaths? Whats the topic of Nodes without a BrowsePath (e.g. Events that are not hierarchical connected to the address space)

For multiple BrowsePath I add a field in the description. An other solution (also with some problems) to send the same message to different topics.

Topic of Nodes without a BrowsePath are currently not described. For Event a solution to use the BrowsePath of the SourceNode as Topic.

[wlkrm]

Additional Questions from @ccvca and me:

• Use NodeId as topics?
• How to identify machine dataset to find entry point for reconstruction
• How do you handle inheritance, i.e., custom types based on spec types? Publish ObjectTypeDefinition address space part

[Kantiran91]

Additional Questions from @ccvca and me:

• Use NodeId as topics?

Than you have a lots of topic without a semantic and this make debugging an mapping more complex

• How to identify machine dataset to find entry point for reconstruction

With the TypeDefinition

• How do you handle inheritance, i.e., custom types based on spec types? Publish ObjectTypeDefinition address space part

Currently we also have not add this information. We can add a Field for that.

[wlkrm]

Additional Questions from @ccvca and me:

• Use NodeId as topics?

Than you have a lots of topic without a semantic and this make debugging an mapping more complex

Yes, our concern is, that using non-unique BorwsePaths isn't a good semantic as well. Is this problem solved by the current mapping?

• How to identify machine dataset to find entry point for reconstruction

With the TypeDefinition

See below. How to know, which level of inheritance is the one to include in the TypeDefinition?

• How do you handle inheritance, i.e., custom types based on spec types? Publish ObjectTypeDefinition address space part

Currently we also have not add this information. We can add a Field for that.

Not sure if a field is enough, how would one know, which level in the hierarchy is the correct "Spec"-TypeDefinition. We had some issues with that in the past, because essentially you cannot know, which is the correct level in the hierarchy. Ideally we would expose the AddressSpace part of the Types as well to be prepared...

[Kantiran91]

Additional Questions from @ccvca and me:

• Use NodeId as topics?

Than you have a lots of topic without a semantic and this make debugging an mapping more complex

Yes, our concern is, that using non-unique BorwsePaths isn't a good semantic as well. Is this problem solved by the current mapping?

The last solution is that we use the HierachicalReference to create an subtopic (I will change the spec tomorrow) and the BrowseName as TopicName with an Itteration if more as one fit. The unique identification should be done in the MetaData (Including NodeId and BrowsePath).

• How to identify machine dataset to find entry point for reconstruction

With the TypeDefinition

See below. How to know, which level of inheritance is the one to include in the TypeDefinition?

• How do you handle inheritance, i.e., custom types based on spec types? Publish ObjectTypeDefinition address space part

Currently we also have not add this information. We can add a Field for that.

Not sure if a field is enough, how would one know, which level in the hierarchy is the correct "Spec"-TypeDefinition. We had some issues with that in the past, because essentially you cannot know, which is the correct level in the hierarchy. Ideally we would expose the AddressSpace part of the Types as well to be prepared...

Yes I think we should give the complete inheritance tree in this field as Array. And as second field also the Implemented Interfaces.

[ccvca]

The NodeId of the objects and variables is not published anywhere? I was just thinking about variales, which have a NodeId as Value to point to something (because a subscription is easier than a ModelChange event)

[GoetzGoerisch]

@Kantiran91 how are the next steps here?

[Kantiran91]

add some changes

[Kantiran91]

add some changes