Topic RSS17:21, EEST
April 3, 2012
OfflineHi,
Seems you edited the question while I was writing a complicated answer. Thus an edited shorter version of that below.
You will need to represent data as ‘UaNodes’. Due to history of the SDK, it is kinda hard to do “data only” representation of the server (or alternative UaNode implementations). You might try just UaServer.init without starting, or just bind to 127.0.0.1 only and use normal UaNodes. Then you can use NodeManagerUaNode.toNodeSet() + UaNodeSet.toXml(). It is not recommended to write the core namespace (index 0). Also the index 1 should typically be ignored, as often it contains diagnotics nodes only. In case you read stuff back to our SDK server, it should be noted that UaServer.init does create the namespaces in index 0 and 1 by itself, that should not be modified.
There is not a public way yet to export more than one namespace per UaNodeSet. However, we do have these “public internal” ones:
– https://documentation.prosysop…..arser.html
– https://documentation.prosysop…..arser.html
They have a bit more stuff that was not public-ready, but needed for Browser(nodeset export in pro) and SimulationServer. The classes are public, though they should be considered as internal, i.e. we could remove/modify these at will (though most likely we will need something similar anyway in some form ourselves). I can try to explain in more detail later if needed, but short versions: The InternalUaNodeSetNodeManagerUaNodeParser mostly is NodeManagerUaNode.toNodeSet() with few additional options. InternalUaNodeSetAddressSpaceParser (NodeManagerTable does implement UaAddressSpace) can write any Set of UaNodes (of that UaAddressSpace), not limited to ones of the same namespace. Though note that the constructor parameter “primaryNamespace” will become the index 1 for model purposes (since typically a model has just one “provided namespace” and it typically is index 1, rest of NamespaceUri list is typically dependencies). The rest will depend on iteration orders. Also, I heavily recommend exporting complete namespaces (one or more), or you might end up with an invalid model.
P.S.
I can explain later, if needed, but there is sort of an issue regarding cyclic dependencies, which might occur for weirder models. The internal ones have a parameter to break these if it can be done from the outside, but we have not found a proper “UA way” for this. SDK does apply some heuristics in order to determine which namespaces are dependencies and which are not regarding references.
16:31, EEST
February 21, 2014
OfflineThank you very much for the swift reply.
I think that either of the 3 options will work for producing a nodeset. The only open subject would be the addition of NodeSet Extensions elements. We would want to add non-OPC UA configuration information like PLC data tag mappings etc into the nodeset as well as a single-source-of-truth.
10:21, EEST
April 3, 2012
OfflineWe have added at some point limited support for the Extensions. Since they are not in the UA’s node-model they are only in the server-side implementation UaNodes:
ServerNode.setNodeSetExtensions(UaNodeSetExtensions)
ServerNode.getNodeSetExtensions()
All server-side UaNodes are (and must be) ServerNode-based, so they can be casted to it (or if creating instances, the XXXTypeNode.class can be used instead of XXXType.class, if known and using class-based createInstance methods).
For now the UaNodeSetExtensions is still quite … crude. It is just a wrapper for the raw whole Extensions XML element, including the Extensions element definition. It be created with UaNodeSetExtensions.parse(String) (doesn’t validate anything yet) and the UaNodeSetExtensions.getRawXml() gives the raw xml back. Note that it might not be 1:1 for exporting/loadingh the model e.g. some whitespaces might change and the xml namespaces might need some experimenting, we have not explored this that much. The following should work, let us know if there are issues:
"<Extensions xmlns=\"http://opcfoundation.org/UA/20…..odeSet.xsd\">"
+ " <Extension>"
+ " <prosys:ProsysExtension xmlns:prosys=\"http://www.prosysopc.com/OPCUA…..nsions.xsd\">"
+ " <prosys:Name>ExtensionName1</prosys:Name>"
+ " </prosys:ProsysExtension>"
+ " </Extension>"
+ " <Extension>"
+ " <prosys:ProsysExtension xmlns:prosys=\"http://www.prosysopc.com/OPCUA…..nsions.xsd\">"
+ " <prosys:Name>ExtensionName2</prosys:Name>"
+ " </prosys:ProsysExtension>"
+ " </Extension>"
+ "</Extensions>";
node.setNodeSetExtensions(UaNodeSetExtensions.parse(extensionsXml));
(… some day we will have better code-block for the forum, anyway think there is a newline character at the end of each line’s String data)
The xmlns needs to be defined for the Extensions element. And since it and Extension element are in the UANodeSet.xsd, I think using any own namespaces must be defined within each element that is inside the Extension like above. The resulted total XML for the model isn’t as pretty as I would like it to be, as the xmlns:prosys part wont get “elevated” yet to the whole document root element XML namespaces definition.
1 Guest(s)

Log In
Register