Add information coming from other OPC nodes in the message sent to Edge

[Gimly]

We would like to use one OPC publisher for multiple OPC servers. This means that we need a way to know from which OPC server (running on a physical machine) the message was coming from.

We would like to use a node that is published by the OPC server that contains a "serial number" unique to the machine. This means that, instead of just sending the value in the message like the publisher is doing now, we'd like to send another information, coming from another OPC node.

Is this possible in the current version of the publisher? Is it something that would be interesting to be added as a parameter?

[mpostol]

Consider using Semantic Data concept described here:

section SemanticData

In this concept, the data has been assigned Uniform Resource Identifier (URI). To protect the performance against degradation URI should be replaced on the wire by a serial number - kind of identifier - unique in a selected context. Anyway, there must be a data discovery services, see for example: OPC UA OOI Global Data Discovery

to solve the problem of using redundant servers exposing the exact same data in two different contexts.

Let me know how it works for you.

[Gimly]

Thanks a lot for the links @mpostol, it's a very interesting read. If I understand correctly, you suggest to use the serial number directly in the namespace URI of our OPC server, is that correct?

It does make sense, even if it will make the URI pretty complicated since those serial numbers are quite long.

Would you have a "real-life" example of a namespace used this way?

[mpostol]

It is hard to provide the real life example because it is just research, but there is a description of a real scenario:

Domain Model of the Global Data Discovery

It is real because many years ago I did deploy a solution like this but using "manual approach" - no UA, no modeling, communication by post (even forgot about email :disappointed: ). But the computer system was responsible for all measurements and final calculations.

Other examples (scenarios) called challenge 1,2,3 you have in the article:

OOI SemanticData Processing Architecture

Next one is a software prototype implementing a set of boilers (factory) simulator:

Simulator.Boiler.

The data from the simulator is to be (in testing) published by the ReferenceApplication and Walk-through

In the independent project, we (me and my student; engineering dissertation) are working on mobile HMI subscribing for the data and offering localization (GPS) sensitive GUI - the screen displays the device (e.g. boiler) you are walking nearby or which are passing by (e.g train). The prototype is related to Part 14 OPC UA pub/sub, but as long as you are using Information Modeling approach the idea is always the same. Unfortunately, the OPC UA Client creates a subscription on random variables selection basis.

Note the prototype code is on the branch 400.

Because I am talking about Object Oriented Internet in all cases I am thinking about globally scoped scenarios.

@Gimly answering your question: The URI owner is responsible to define it according to the general rules (see RFC) and make it globally unique. My recommendation is to define the URI for the data in the context of its semantics - to get more visit the article:

Data is Data: It Doesn’t Matter Where It Comes From!

Sorry for a very long answer, but you have the weekend ahead :smile:. Enjoy reading.

[hansgschossmann]

We send back the ApplicationURI as part of the message. This should uniquely identify the OPC Application the telemetry is coming from. Makes sense?

[mpostol]

@hansgschossmann We must distinguish between the following terms:

• Application - an instance of a program (this case it is OPC UA Server)
• UA Address Space (AS) - an instance of the UA Information Model (IM) exposed by the server
• Subscription - a set of variables to be handled together as one whole
• Data - as a set of values describing the current process state or behavior

If we are talking about the application instead of URI the URL is usually used. This information normally describes access point - where the UA services are exposed - but not the data the server publishes. In other words, we can change the server URL and get the same data. So if we are going to have data identifier it doesn't solve the problem.

Talkin about AS the URI is applicable - in this case, we must consult redundancy stuff. I am not sure about the release stage of this particular UA part.

Anyway, the subscription is always a carrier of the data, but it could change at any time according to the OPC UA Client request. In this case, unique identification of the AS doesn't help - it is possible to send temperature instead of pressure (both are float) to the cloud as the result of configuration mistake and there is no rescue.

[Gimly]

@hansgschossmann Good point, I had the wrong impression that the ApplicationURI was not modifiable and was always the computer's name. Now that I can see that it can be edited, it makes sense to use it for this purpose. Only thing that confuses me a bit is that I can't seem to be able to get that ApplicationURI from the OPC client directly.

@mpostol I'm not completely sure I'm following you. If the ApplicationURI uniquely identifies the machine, independently from the OPC UA's server IP address, then the message can always be linked back to this machine. If we construct the ApplicationURI with the machine's serial number for example.

Now, for the data that is sent, to identify it we have the NodeIDs, this should make clear about what kind of data we are talking about. If the NodeIDs identify that we are taling about a temperature and not a pressure for example.

[mpostol]

@Gimly you said "If the ApplicationURI uniquely identifies the machine" so what in a case you will need to replace the machine? NodeId:

• Namespace - is an index of URI in the server table (dynamic relationship :exclamation: )
• identier of the syntax
• Value - identifier of the node in the Address Space ( not in the machine :exclamation: )

Anyway, it is valid in the context of the selected machine(even in the context of the session) - see question above.

It seems we are talking about two different scenarios

• identification of the machine and assuming that the expected data is always exposed by the machine.
• identification of the data and assuming that the data always represents expected information.

Let me give you an example: sometimes it makes sense to use a car plate number to find information about the driver :smile:, doesn't it?

[Gimly]

@mpostol Yes, I definitely see what you mean, in my current case "the machine" is something unique and its data it produces is only valid in the relationship with that specific machine.

If we have to replace the machine, the data of the "old" machine would not be relevant anymore. We are in a scenario similar to the car example you give, telemetry data of a car would not have much value if we change that car, so having the VIN of the car attached to the car's telemetry data would be sufficient.

I understand that if we're talking about a device that is part of a bigger system, and that this device can be replaced without altering the system, we would probably want to structure your data identifiers so that you can figure out where from the data is coming, even after we have replaced part of the system.

[mpostol]

@giladmit if we are on the same page now it is time to answer @hansgschossmann if the proposed solution is general enough, in other words, if it is portable from the scenario:

where we are going to measure the car engine temperature - using VIN stamp

to another:

where we are going to measure the car driver temperature - using driving license stamp

I opt to develop against a general solution, but I know that sometimes it is costly or even impossible.

@giladmit in the discussion I have completely forgotten that there are embedded and closely couple solutions but you are right they are - thanks for recalling me.

[hansgschossmann]

@mpostol you posted above: If we are talking about the application instead of URI the URL is usually used. This information normally describes access point - where the UA services are exposed - but not the data the server publishes. In other words, we can change the server URL and get the same data. So if we are going to have data identifier it doesn't solve the problem.

If you look at a OPC UA server, which runs UA Application, this UA Application is identified globally unique by an Application URI (BTW: this does not to be an URL, think about having the same application deployed on multiple physical machines reachable via different URLs).

The UA Application can be reached by endpoints with different security. So by publishing the ApplicationURI and the NodeId, you should be able to identify globally uniquely where the data is coming from.

PS: i am OOF next 3 weeks

[mpostol]

@hansgschossmann it is exactly what I said. My concern is that you are talking about Application URI. An application is the instance of a software program, so this URI usually is used to identify the software vendor. To identify the Node you need URI for UA Address Space, which is an instance of a UA Information Model exposed by selected software instance.

So you could have many applications with the same URI, hosted on different computers (boxes) identified by different URL ( you are right each computer could have many URL addresses) and exposing depending on needs the same or different Address Space. If we have many instances of the same Information Model we redundancy. There are many kinds of redundancy, to name only the most important ones: transparent and not transparent. I think it is only terminology stuff. My concern is what is the main purpose of the Node identification? In a case where we have tightly coupled case where everything has one to one relationship it really doesn't matter what we are using to identification. On the other hand, where a dynamic loosely coupled scenario is the case we could need identification provided directly by a selected node that is part of an object representing part of the process, e.g. a rolling balls, passing by trains, etc.

Have a nice vacation :smile:

[markusstuhler]

This will be updated in the upcoming version of the publisher. We won't change anything on the current version. So I will close this issue for now.

Thanks! Markus