Topic RSS21:19, EEST
February 21, 2014
OfflineI’d like to add meta-data to variable based datasets / PublishedDataSets, such as the engineeringUnits for individual variables or EURanges.. In the SDK samples I only saw meta data for broker based communication.
Could you please provide a short example of adding meta-data on the publisher side and retrieving it on the subscriber side? Both sides would be servers as well.
Many thanks
PS: I tried using PubSubPublishedVariableConf.putMetaDataPropertyMap` and `PubSubSystemConf.addDataSetMetaData’. But neither seems to serialize the meta data on the wire
11:27, EEST
April 3, 2012
OfflineHi,
Basically there is almost no information modelling in the PubSub side.
The metadata SamplePubSubConfiguration is related to which MQTT Broker topic the DataSetMetaData is published. You might be referring to the FieldMetaData https://reference.opcfoundatio…../6.2.3.2.4 that is contained in the DataSetMetaData. Currently there is no way in the SDK to cause anything be sent in the ‘Properties’ field related to it.
In UDP the Subscriber must ask for the metadata via the multicast network, the Publisher would then send a message that contains the DataSetMetaData. It would seem the spec also nowadays allows cyclic publishing (we could implement this in the future).
The only info our SDK Subscriber side would currently look from the DataSetMetaData are the field names. Custom types are not supported (but will probably work, if the Subscriber side already knows them) nor is the RAWDATA mode. Our Subscriber side will invent Field#### style names for fields of datasets for which it doesn’t know the metadata. It will also send the “discovery request” messages for which our Publisher side will respond with the DataSetMetaData messages.
The received metadatas will cause SDK to update the PubSubSystemConf of the PubSubSystem. They can also be manually set via PubSubSystemConf.Builder.addDataSetMetaDatas(PubSubDataSetMetaDataConf). This only works for the Subscriber side, not for the Publisher side. The idea at least was that the SDK calculates the metadata from the nodes, as they already contain the information.
The com.prosysopc.ua.samples.pubsub.SampleUtils.addPubSubSystemListeners(PubSubSystem) shows how to listen for DataSet and DataSetMetaData messages. The metadata can be obtained also from PubSubDataSetMessage.getDataSetMetaData(), assuming it is known.
P.S.
The PubSubSystemConf PubSubDataSetMetaDataConf is only used in the Subscriber side.
PubSubPublishedVariableConf.getMetaDataPropertyMap() I believe at the moment does nothing. Probably should be categorized as a missing feature or bug, some of the thing were originally added 1:1 mirroring the spec configuration. It probably should go to com.prosysopc.ua.pubsub.PubSubFieldMetaDataConf.getProperties(), then I think it might get sent.
P.S.2
Vacation season starts soon, thus it might take after summer to do much
P.S.3
If a Subscriber would need instead a .uabinaryfile for the publisher configuration (this used to be common), there is a prototype implementation via PubSubSystem.commands().execute(PubSubSystemCommands.INTERNAL_PUB_SUB_SYSTEM_CONF_TO_UABINARYFILE, command) and give PubSubSystemConfToUaBinaryFileCommand as the command. Then com.prosysopc.ua.UaBinaryFile.toBinary() and write the ByteString.getValue byte[] to a file.
12:53, EEST
April 3, 2012
OfflineIf you want to try, we now have a beta build that fixes the PubSubPublishedVariableConf metadata issue, ask via jsdk-support@prosysopc.com
Now in the Publisher in com.prosysopc.ua.samples.pubsub.SamplePubSubConfiguration.addPublishedVariableDataSet(Builder, UaNodeId) you can add e.g.
variableConfBuilder.putMetaDataPropertyMap(UaQualifiedName.standard(“Test”), “TestValue”);
Tested via in Subscriber side in com.prosysopc.ua.pubsub.PubSubSystem.addEventListener if you print the event/metadata.
Note that the SDK doesn’t support ‘metadata versioning’ and it is only created when the PubSubSystem starts. Thus only constant values work. Depending how things go, maybe at some point there could be some “selector” configuration similar to how EventFilter works in opc.tcp events that would select sub-node values from a node being published (and maybe even monitor those ..), but that is possible future exploration.
Also, use namespaces for the UaQualifiedName(s) that are known for both sides. We sort of did a bit of a mistake in the design that both sides are assumed to know the types, but for a generic Subscriber it would instead need a separate “type realm” for each PublisherId+WriterId combination. The DataSetMetaData inherits from DataTypeSchemaHeader (from which also UABinaryFileDataType inherits) that is intended to list types used by the Publisher (though, in a case where the data would get pushed to a node on the server, then it must also follow that the server must know the type, or there wouldn’t be much sense as far as I can think of use-cases).
1 Guest(s)

Log In
Register