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.
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.
there is a OPC UA service TranslateBrowsePathsToNodeIds.
How volatile or stable are the NodeIDs results returned by the service ---
Is it possible that NodeIDs resolved by the service alter while server runtime?
In our Case we are running our client against a server, which enumerates NodeIDs differently on every server restart. So we decide to resolve IDs by BrowsePath once after each (re)connect to the server. So far so good. But now there is a Problem when the server is restartet and after the first client reconnect no paths can't resolved.. it seems the server is not ready for the job (...).
I am wondering how often I have to update the resolved Node IDs (all or just the onces which was not resolved correctly?).
We are reading data by polling in this case.
I don't know your server, but it seems, you do address an OPC UA Server with a very dynamic behaviour, But I think, it's within the OPC UA spec.
It depends on the OPC UA objects, this server offers and what a client should or wants do with them.
Is it possible that NodeIDs resolved by the service alter while server runtime?
Yes!
Many servers do offer a static node set from the device configuration. In this case, the client will always get the same node ids from TranslateBrowsePathsToNodeIds, the client may use the node ids directly without translation (but has always to resolve the namespace index after connecting to the server). But obviously it's not your kind of server.
Another use case are dynamic objects, with a restricted lifetime, coming and going on any time they want to come an go. Imagine a warehouse in which goods are received and delivered. So a good will be representent with an individual OPC UA object instance, created on receive and removed on delivery. As long the good exists in the warehouse, you may browse to the object, translate its browse pathes to node ids and use them (reading, writing, monitoring). Of course, when the good delivers, the UA object will no longer be needed and could be removed by the server. The node ids removed now could be used later in an other context for another object instance.
Alternatively, the server could offer an interface to create or remove objects with a client.
The question is, how the server deals with the creation or removal of it's objects, how does it announce the changes? There should be a kind of configuration change event you want to monitor with your client. When your client receives an event, it may decide which actions to do, e.g. rebrowse the object and translate the browse pathes. Read the manual!
By the way: TranslateBrowsPathsToNodeIds is widly used to adress subnodes of object instances with a known object type. Once you know the node id for the entire object, you easily get the node ids for the subnodes with their browse pathes.
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 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/
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...