I am novice to OPC Unified Architecture world and I'm studying it from basics. What exactly are namespaces and why it is always appended with NodeID?
A namespace in OPC UA is like a container for node ids.
There is the predefined namespace with index 0 from the OPC foundation.
And there are many more namespaces, e.g. DI, PLCopen. Each namespace belongs to a specific OPC UA specification, and every OPC UA specification can define its own node ids.
To make sure a specific ID uniquely identifies a specific node within a namespace you need to indicate the namespace ID.
More information can be found in the official OPC UA specification:
https://reference.opcfoundation.org/v104/Core/docs/Part3/8.2.2/
Related
I'm very new to the OPC UA and would appreciate your help with stuff that seems to be basic but I can't grasp it in full.
I'm exploring a publicly available OPC UA server at opc.tcp://opcuaserver.com:48010.
Here's the tree of nodes it exposes:
I'm trying to figure out what's the logic behind assigning namespaces here.
Path
Node Id
Comment
Objects
i=85
(I understand ns=0 is the default one and is omitted)
Objects/Demo
ns=2;s=Demo
Objects/BuildingAutomation
ns=3;s=BuildingAutomation
Why is it in a different namespace while it's under same parent?
Objects/BuildingAutomation/ControllerConfigurations
ns=3;s=ControllerConfigurations
BuildingAutomation is not part of the prefix?
Objects/BuildingAutomation/AirConditioner_1
ns=3;s=AirConditioner_1
Why doesn't it have BuildingAutomation in the prefix?
Objects/BuildingAutomation/AirConditioner_1/Temperature
ns=3;s=AirConditioner_1.Temperature
Why does it have AirConditioner_1 in the prefix?
Is it that we see multiple trees (each having its own namespace) merged here? Where do these trees come from? How namespace is assigned?
What's the logic behind node IDs without prefixes (ex. ControllerConfigurations ) vs with prefixes (ex. AirConditioner_1.Temperature) (as both seem to be attributes?)
Here is a great explanation.
Each namespace is a different model (tree of data):
Namespace 0 is defined by the OPC Foundation and contains OPC Core nodes that you cannot modify.
Namespace 1 is specific to your server can contains server info like certificates and open connections.
Namespace 2 ... n is where your business objects are.
I have created a channel and device on KepserverEx with a couple of tags.
In the configuration, I have set the address of a node as:
ns=3;s=Channel1.Device1.Start
And if I browse for the same node using UeExpert I find the NodeId as
nsu=KEPServerEX;ns=2;s=Channel1.Device1.Start
Which is what I need to use in my C# Client.
Why the value of ns(namespace index) is not the same as I have defined in the Server?
I don't know about KepserverEx, but in general the namespace index of a node is not static, but is (re-)defined dynamically in a server when a model is loaded/instantiated.
The only static namespace index is 0 for the default opc ua nodeset.
So, if you have only two namespaces (+ the default nodeset) defined in your server, the namespaces will have the indicies 1 and 2.
If the client doesn't know the index of a namespace in a specific server, it can request the list of namespaces and can so resolve the right index for a specific namespace name.
From looking at the node ids file , you'll notice that node ids skip the range 951 - 1999 i.e. there are no OPC UA nodes with nodeids within that range.
Is the range reserved for application use ? Is it safe for my server implementation to use nodeids in the range 950 - 1999 ?
I'm also seeking a part of the specification that mentions about the nodeid range.
What you are referring to are node IDs in the namespace 0 (with URI being http://opcfoundation.org/UA/ ). The whole namespace is reserved for use by OPC Foundation. You are not allowed to define any new NodeIDs in this namespace - no matter what their numeric or other identifier.
For nodes specific to your server, you should define your own namespace - and then it's all yours. You can then use any node identifiers inside this namespace - even numeric ones "colliding" with namespace 0 (which, in fact, is no collision at all, as the namespaces are there for the purpose of preventing the collisions).
The Specification (Part 3: Address Space Model) of OPC UA says
5.2.2 NodeId
... A Server shall persist the NodeId of a Node, that is, it shall not
generate new NodeIds when rebooting.
but how can this be?
NodeId is a combination from a NamespceIndex and Identifier. NamespceIndex can be changed when the Server is restarting. see:
http://documentation.unified-automation.com/uasdkhp/1.0.0/html/_l2_ua_node_ids.html
For this reason, a Client should not persist the namespace index without storing the namespace URI as well, because a namespace URI represented by index “2” during one session could be represented by index “5” during the next session
Also the use of FolderType with e.g. "Files" as Items speak again this, or should the server store the NodeId it uses for File-X to assign it right again after restart?
What for is "GenericModelChangeEventType" if no NodeId can be created?
Client: I thought useing BrowsePath-Path (e.g. "Objects.Server.ServerStatus.CurrentTime" (* ) ) for addressing NodeIds and then using the NodeId while the clinet session to access the nodes is a good approach. Also because Companion Specifications defines the browsename so I might by save. Is this a good idea? ( *need attention on collisions caused by different namespaces)
Server: How should the Server behave when it needs to generate/create new NodeIds. Need the NodeIds to be unambiguous all the time or just for the Server runtime. I know some Servers are using NodeIds with String-Typed Identifiers and this String-Identifiers are made from the BrowsePath e.g. "ns=1;s=Server.ServerStatus.CurrentTime". But I don't like this...
What the OPC UA spec means when it says " A Server shall persist the NodeId of a Node, that is, it shall not generate new NodeIds when rebooting." is as follows: The NodeIds, when seen as a combination of namespace URI and identifier, must not change. The server may or may not reassign namespace indices after reboot - but the resulting namespaceURI/Identifier must not change. So, if on the first run I had a node with Identifier 1234 and namespace index 7, and that namespace index corresponded to "http://mynamespace.mycompany.com" in the namespace table, on the second run the same node may have Identifier 1234, but the namespace index 8, as long as in the new NamespaceTable index 8 now corresponds to "http://mynamespace.mycompany.com".
I think the Unified Automation SDK technically violates the spec in this regard. The recommendation it suggests is good practice for client implementations either way, but as you pointed out, shouldn't strictly be necessary.
Also the use of FolderType with e.g. "Files" as Items speak again this, or should the server store the NodeId it uses for File-X to assign it right again after restart?
I'm not sure what you're asking here.
What for is "GenericModelChangeEventType" if no NodeId can be created?
That's not what is being said here. Nodes can be created and deleted and the structure of objects and variables can change. All the spec is saying is that given Node "Foo" with NodeId "ns=1;s=Foo" it should have the same NodeId if the server reboots.
I thought useing BrowsePath-Path (e.g. "Objects.Server.ServerStatus.CurrentTime" (* ) ) for addressing NodeIds and then using the NodeId while the clinet session to access the nodes is a good approach.
Browse paths are for programming against types. The approach suggested by the Unified Automation SDK docs is the safe one for persisting NodeIds in your client.
How should the Server behave when it needs to generate/create new NodeIds. Need the NodeIds to be unambiguous all the time or just for the Server runtime. I know some Servers are using NodeIds with String-Typed Identifiers and this String-Identifiers are made from the BrowsePath e.g. "ns=1;s=Server.ServerStatus.CurrentTime". But I don't like this...
Create them however you like in the Namespaces you control, it's up to you. Using string-based NodeIds allows you to easily "derive" the NodeId from certain other sources, though, e.g. from the address of a variable in a PLC or something similar.
I'm trying to build a OPC UA client application.
I'd like to be able to identify a UA node uniquely in the OPC tree.
I know that in OPC DA, a standard node id is a string with a '.' as a delimeter that I can use in order to identify a node.
In OPC UA, the node ID doesn't have to be a string, but I'd still like to be able to build a unique string that maps to a particular node.
I'm thinking about basing it on the the nodes names. e.g.: Demo.MyNode.MyValue.
but I'm afraid that the node name can contain characters such as "." and this will make my IDs not unique.
Is there a character I can use as a delimeter?
Is there a better way to represent the node ID as a string (including its path)?
OPC-UA offers the concept of a unique "BrowsePath" for each and every node, and a client could opt to store BrowsePaths instead of NodeIds, and then upon startup call the TranslateBrowsePathsToNodeIds service.
In fact, I believe this may be the intended behavior, as there's no requirement that a server use the same NodeId for any given Node after restarting, even if in practice that's how it's done.
I was wrong about NodeId being allowed to change. The spec says: "A Server shall persist the NodeId of a Node, that is, it shall not generate new NodeIds when rebooting."
I now believe its best to store NodeIds and only use BrowsePaths to aid in programming against type definitions.
One of the features of OPC UA is that the server can offer different menu trees to different users. It may not matter for your client, since any given user will only see the one tree, and the BrowsePath will be unique for that user.
In v1.03 of Part 3 of the OPC UA spec, "OPC UA Part 3 - Address Space Model 1.03 Specification.pdf", section 5.2.2 says a server should not change a node's NodeId when it reboots. (The spec is available from the OPC Foundation at https://opcfoundation.org. You can register and download it for free.)
Of course, some UA servers might not maintain their NodeIDs across a reboot. Which is another reason to use Kevin's suggestion to use the BrowsePath to make a unique string for each node. The string can make it clearer to the user which node they're accessing. Good idea!
The OPC Foundation announced their “OPC UA Open Shared Source” Strategy (04/14/2015).
The stack for .NET including lots of samples for DA, Historie... clients and servers can freely be downloaded here OPCFoundation/UA-.NET on GitHub.
Also Build OPC UA .NET applications using C#, VB.NET
You can take a look at the samples in the "SampleApplications" directory and see how they do things...