Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Fetching Metadata
January 12, 2022
15:08, EET
Avatar
pradeep_patel
Member
Members
Forum Posts: 13
Member Since:
July 13, 2021
sp_UserOfflineSmall Offline

Hi Team,

I am using prosys-opc-ua-sdk-for-java-4.6.2-1636-evaluation. I want to know regarding one of the use case related to metadata.
The usecase is to fetch the metadata from Publisher Server using tcp connection and set to Reader set using PubSubDataSetMetaDataConf object.
In `Prosys_OPC_UA_SDK_for_Java_PubSub_Tutorial` It is written that Subscribers can also request DataSetMetaData on demand from the Publisher but it is not clear how to do that, Can you please guide me on this.

Also when we start SampleSubscriberClient we need to set the server adress as `client.setAddress(serverAddress);` in initialize() method. Is this server used to pull the metadata information ?

January 13, 2022
11:10, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

I guess no way to avoid my typical long answers, sorry.

First a note that things with PubSub are noway near on the level I would like them to be, i.e. there is still a lot to be done, also OPC UA 1.05 will probably bring some improvements as well once it properly arrives (since people are pretty much only now starting to use PubSub, the spec typically evolves once someone actually uses something specified as typically it usually is not that great to start as use-cases are not that well known). Also, this answer is mostly related to UDP-UADP PubSub, as in MQTT-UADP + MQTT-JSON the publisher would publish the metadata to the Broker.

IF the Publisher supports metadata discovery requests (https://reference.opcfoundation.org/v104/Core/docs/Part14/7.2.2/#7.2.2.4.1), that will happen automatically. SDK makes a metadata request if the Reader didn’t have metadata. This is done on the PubSubUdpUadpConnectionConf.getDiscoveryNetworkAddress(), if specified (or tried on the normal getNetworkAddress() if not). Our Publishers do support this and this is basically the configuration we test with for the time being. Yes, this also requires a Publisher to listen to incoming messages which might sound odd.

There are at least 2 alternatives to the discovery request. One is to “just magically know it” (e.g. some external information or a “well known” DataSet). Another would be to check the server via Client-Server connection and Browse/Read the “PubSub configuration address space”.

We do not yet support the “PubSub configuration address space”, so for our Publishers the metadata discovery requests (or “just magically know it”) are the current options. However, note that the configuration types are part of the standard namespace i.e. you can Read/Browse them IF the Publisher you are connecting to does support them (per our IOP workshop partisipation it would seem some do and some do not yet and some have had some custom solutions as the address space model is … complicated). So you could observe that and then have the info that way (you just cannot yet directly push that to PubSubSystem without doing conversions yourself).

As for the SampleSubscriberClient. Long story, but in short our DataSetMetadata is not exactly correct yet. It has a flaw that the NamespaceArray and custom structures definitions are not sent within it. Only the DataSet’s fields and their types are. So we use the client-server connection to obtain NamespaceTable+definitions for the custom structures. Yes, this does mean that it must be _that server_ that is doing the Publishing. Or well, standard namespace data would work from any Publisher, as that is inherently known.

Also, basically the samples are split in 4 (server/client + publisher/subscriber), but nothing prevents having both publisher and subscriber in the same PubSubSystem.

Also, while not very useful yet, the SampleSubscriberClient is sort of the convert PubSub -> Client-Server while SamplePublisherClient is Client-Server -> PubSub. The SampleSubscriberClient doesn’t define TargetVariables (at least not yet), but that concept should work. If it would, it would Write the data received from Publishers to the server it is connected to. Probably at some point in the future we should make a “standalone PubSubSystem”.

January 14, 2022
17:36, EET
Avatar
pradeep_patel
Member
Members
Forum Posts: 13
Member Since:
July 13, 2021
sp_UserOfflineSmall Offline

Thanks Bjarne Boström for an elaborated explanation, … Just one question regarding sdk as we are willing to take it ahead for one of our product requirement.

So if we correctly configure our Subscriber client or Subscriber Server with below variables
1. WRITER_GROUP_NAME,
2. WRITER_GROUP_ID,
3. READER_GROUP_NAME
4. READER_NAME
3. PUBLISHER_ID,
4. QUEUE_NAME topic and
5. METADATA_QUEUE_NAME topic

would that be sufficient to decode the subscribed dataset messages published by any OPC (part14) compliant Publisher or do you see any risk of it getting breaking against few Publishers while still working for few others? What code changes or configuration we should do to make it generic Subscriber client that can decode any dataset message published by any Publisher available in the market.

Also I have couple of questions here as you mention that DataSetMetadata is not exactly correct yet and the NamespaceArray and custom structures definitions are not sent within it and for this client-server connection is required to obtain NamespaceTable+definitions for the custom structures.
1. By when can we expect a fix on this issue ?
2. If there exists a reference Publisher (other than sample publisher) which can publish complete detail (NamespaceTable+definitions for the custom structures) to metadata topic then can we expect the current subscriber client/server to pic this up and decode the dataset message? or would you like to suggest any workaround here?

January 17, 2022
13:32, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Note that we too sort of have these questions, as we for the most parts are just implementing the spec, not specifying it.

Not all of those variables would be in the “filter” of the DataSetReader, the DataSetWriterId would be most important (with the PublisherId).

You are looking for a “get all data from a publisher” solution here. As far as I’m aware, there is no good way to do that (if at all; we too would like to do this as well for our Browser application soon). It would pretty much seem the intended way is to look the address space configuration (or some external thing) and construct DataSetReaders “one by one”.

Yes, the DataSetReader “filter” parameters can take in 0 as a wildcard. But per the address space configuration model, each DataSetReader could only hold a single metadata (https://reference.opcfoundation.org/v104/Core/docs/Part14/6.2.8/#6.2.8.11.1 + https://reference.opcfoundation.org/Core/docs/Part14/9.1.8/#9.1.8.2). So.. I’m not 100% sure yet of their usefullness. Maybe in the future we can offer some “none Readers matched this message” event or something that could be used to drive some automatic generation of the configuration.

While we sort of intentionally went with our own configuration format (different story for a different post), we do also support (only) a single metadata per reader.

Also I should note that for the time being, we pretty much have tested just those samples that come with the SDK. We have done some interop tests in the IOP Workshops the OPC Foundation hosts (though they have been quite basic at this point).

For your questions:

1.
No idea. But like sooner or later we must do that, as I would assume the need for custom structures will be there (i.e. “maybe this year”. I believe you are the first to sort of ask for this. Typically we try to do things that our customers have demand for (or if we need things in our apps).

What would be the “target” of the subscriber? Just visualizing it or actually doing something with it or pushing it to somewhere? Because, this is sort of unexplored territory, but IF the “push target” is an OPC UA Application, it sort of would also need to “know” the custom types. That is to say, the namespaceindex of namespaceuris of custom types can be different, but you could not have a TargetVariable of a Server that would not be of correct type (or assuming it was BaseDataType so anything goes, the OPC UA Client reading it from that server would not have the metadata then in turn, unless the server has it).

2.
I’m not aware of such. Those samples are basically the best we have to offer right now. The OPC Foundation’s .NET (https://github.com/OPCFoundation/UA-.NETStandard) might have some samples that have it.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
10 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 113

pramanj: 86

ibrahim: 74

kapsl: 57

rocket science: 52

gjevremovic: 49

Xavier: 42

fred: 41

TimK: 41

Fransua33: 39

Member Stats:

Guest Posters: 0

Members: 1743

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1206

Posts: 5137

Newest Members:

LimaomoT, eulaallcot, brain7955241817, barbaravillalobo, widallet, erminovski, etsuko73u61420, donnyblaxland, DonaldHAp, kelvin6887

Moderators: Jouni Aro: 918, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 726, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 24, Teppo Uimonen: 21, Markus Johansson: 36, Niklas Nurminen: 0, Matti Siponen: 163, Lusetti: 0

Administrators: admin: 1