Log In
Home
09/09/2015
Offline
Hello,
I wondered about the correct namespace using in OPC UA Servers. Well I know that ns 0 and ns 1 are reserved specifically for the standard OPC UA Specifications. When I now want to use the OPC UA for Devices Specification it hat its own namespace-uri, but the xml-schema says it is ns 1. Should I now integrate the Companion Spec into ns 1 and change the uri or should I change it to a new namespace? But also the spec says that the ns index is dependend on the position of the ns in the ns-table. That’s ok and the way I implemented it till now. But regarding the newest AutoID-Spec, at p. 51 it says “namespaces used in this specification” and suddenly the Devices-Spec is at ns 1.
Another question goes to the generated nodes out of an spec. Which ns should they have? It tells in the AutoID-Spec that they should not have the same ns used in the specification (but no word about it in the devices spec). I am using a server without ModellingRules so I need to implement the nodes by hand. And when I looked how ModellingRules and InstanceDeclarations are working, I couldn’t see how they will handle the ns. I’m sure that an instance of a node created by a vendor should have the vendor-ns but I can’t find anything about that in the spec.
so for my example here there are in the NamespaceArray:
ns0: https://opcfoundation.org/UA/
ns1: urn:unconfigured:application
ns2: https://opcfoundation.org/UA/DI/
ns3: vendor specific
is this correct or what do I need to change?
best regards
Felix
Moderators-Specifications
Moderators-Companion
Moderators-Implementation
Moderators-Certification
Moderators-COM
02/24/2014
Offline
Felix,
Specification define an NamespaceURI. This NamespaceURI defines who is responsible for the namespace. It is always unique for each namespace. If you are defining you own instance of a type that was defined by another organization you always want to define the instance in your own namespace (i.e. you are the person that is responsible for that namespace, even if they are instance of a node from a namespace defined by someone else).
The namespace index is just an index into the server’s namespace table (or the namespace table associated with a file). So every node uses this table instead of storing the long namespace uri. The purpose of a Namespace-URI is ensure that there is no naming conflicts – I can use the same browse name or nodeid as one that is issued by another group, but since I defined the namespace- it has my namespace URI associated with it and it will not conflict.
Depending on what toolkit or how the server is implemented, the functionality on how to load an address space changes, but many times a file is used. Pretty much all of the files will contain some part of an address space (i.e. not an entire address space). The file includes a table with the NamespaceURIs that are included in the file (numbered in order). If there is only 1 namespace in a file it will be index 1 in the table in the file. When the file is loaded by the server – it will add the specified namespace from the file to the namespace table in the server – tracking what index it was loaded into (i.e. index 3 for DI in your sample) and it will translate all of the indexes in the file (1) to be the index that was actually used in the servers table (3).
By definition every time a server loads, the order of the namespace in the namespace table might change, i.e. the index might change. In reality, since a server typically load the same namespaces in the same order each time it does not change – at least not often, but the server still have to be able to handle a different order for loading.
In some embedded servers the namespace table is hard coded, which means the namespace index will always be the same and the indeex in a node can be hard coded, but even in these system the namespace index is controlled by some tool that is used to generate the configuration/firmware.
Paul
Paul Hunkar - DSInteroperability
1 Guest(s)
Usage Policy