2

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?

  1. 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

  2. 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?

  3. 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...

4

2 回答 2

2

当 OPC UA 规范说“服务器应保留节点的 NodeId，即重启时不应生成新的 NodeId”时，它的含义是什么。如下： NodeIds，当被视为命名空间 URI和标识符的组合时，不得更改。服务器可能会或可能不会在重新启动后重新分配命名空间索引 - 但生成的命名空间URI/标识符不得更改。因此，如果在第一次运行时我有一个标识符为 1234 和命名空间索引为 7 的节点，并且该命名空间索引对应于命名空间表中的“ http://mynamespace.mycompany.com ”，那么在第二次运行时，同一节点可能有标识符 1234，但命名空间索引为 8，只要在新的 NamespaceTable 索引 8 现在对应于“ http://mynamespace.mycompany.com ”。

于 2018-06-15T16:54:17.533 回答
2

  1. 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.

  2. 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.

  1. 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.

于 2018-06-15T11:52:07.833 回答