OPC UA的规范（第3部分：地址空间模型）
5.2.2 NodeId
......服务器应该保留Node的NodeId，也就是说，它不会 重新启动时生成新的NodeIds。
但这怎么可能？
NodeId是NamespceIndex和Identifier的组合。服务器重新启动时，可以更改NamespceIndex。见：
http://documentation.unified-automation.com/uasdkhp/1.0.0/html/_l2_ua_node_ids.html
出于这个原因，客户端不应该在不存储名称空间URI的情况下保留名称空间索引，因为在一个会话期间由索引“2”表示的名称空间URI可以在下一个会话期间由索引“5”表示
还使用FolderType和例如“文件”作为项目再说一遍，或者服务器是否应该存储它用于File-X的NodeId，以便在重新启动后再次分配它？
如果无法创建NodeId，那么“GenericModelChangeEventType”是什么？
客户端我认为使用BrowsePath-Path（例如“Objects.Server.ServerStatus.CurrentTime”（*））来寻址NodeId，然后使用NodeId来访问节点时clinet会话是一个好方法。另外因为Companion规范定义了browsename所以我可能会保存。这是一个好主意吗？ （*需要注意由不同命名空间引起的冲突）
服务器：服务器在需要生成/创建新的NodeId时应该如何表现。需要NodeIds始终是明确的，或者只是服务器运行时。我知道有些服务器正在使用带有字符串类型标识符的NodeIds，而这个字符串标识符来自BrowsePath，例如： “NS = 1; S = Server.ServerStatus.CurrentTime”。但我不喜欢这个...
答案 0 :(得分：2)
OPC UA规范的含义是“服务器应该保留节点的NodeId，也就是说，重启时不会生成新的NodeId”。如下所示：NodeIds在被视为名称空间URI 和标识符的组合时，不得更改。重新启动后，服务器可能会也可能不会重新分配命名空间索引 - 但生成的namespaceURI / Identifier不得更改。因此，如果在第一次运行时我有一个带有标识符1234和命名空间索引7的节点，并且该命名空间索引在命名空间表中对应于“http://mynamespace.mycompany.com”，则在第二次运行时，同一节点可能具有标识符1234，但是命名空间索引8，只要在新的NamespaceTable索引8中现在对应“http://mynamespace.mycompany.com”。
答案 1 :(得分：1)
我认为统一自动化SDK在技术上违反了这方面的规范。它建议的建议是客户端实现的良好实践，但正如您所指出的那样，不应该严格必要。
还使用FolderType和例如“文件”作为项目再次说明，或者服务器是否应该存储它用于File-X的NodeId，以便在重新启动后再次正确分配它？
我不确定你在这里问的是什么。
如果无法创建NodeId，那么“GenericModelChangeEventType”是什么？
这不是这里所说的。可以创建和删除节点，并且可以更改对象和变量的结构。所有规范都说，如果节点“Foo”与NodeId“ns = 1; s = Foo”，如果服务器重新启动它应该具有相同的NodeId。
我认为使用BrowsePath-Path（例如“Objects.Server.ServerStatus.CurrentTime”（*））来寻址NodeId然后使用NodeId，而clinet会话访问节点是一个很好的方法。
浏览路径用于针对类型进行编程。统一自动化SDK文档建议的方法是在客户端中持久保存NodeIds的安全方法。
当服务器需要生成/创建新的NodeId时，应该如何表现。需要NodeIds始终是明确的，或者只是服务器运行时。我知道有些服务器正在使用带有字符串类型标识符的NodeIds，而这个字符串标识符来自BrowsePath，例如： “NS = 1; S = Server.ServerStatus.CurrentTime”。但我不喜欢这个...
在您控制的命名空间中创建它们，但这取决于您。使用基于字符串的NodeIds允许您轻松地从某些其他来源“派生”NodeId，例如，从PLC中的变量地址或类似的东西。