OPC UA：如何正确组织文件夹和节点
OPC UA: how to organize folders and nodes properly
我是OPC的新手。有些事情对我来说不是很明显。
我正在使用来自：https://github.com/digitalpetri 的 opcua 堆栈 (uaserver)
作为客户端软件（目前，仅用于测试）我使用的是 United Automation 的 UAExpert。
每个客户都有几个单位。每个单位都可以有一些值。
一切都在 postgres 数据库中。我需要通过 OPC 为客户公开这些值。
现在我觉得我必须实施它：
- 每个客户一个文件夹节点。
- 每个文件夹都有多个节点的引用，这些节点是单元
- 每个单元都有一些值的节点（这里并不重要）
我的顾虑：
- 我不知道这种模型对于 OPC-UA 在思想上是否正确。
- 我似乎不清楚如果添加或删除了一个单元，我该如何通知 OPC 客户端。
- 我似乎还需要为所有客户文件夹、单元等准备所有节点，就在我的 OPC 服务器启动时。甚至为永远不会连接的客户保留它们。有什么正确的方法可以避免这种情况吗？
- UAExpert 客户端在连接到服务器后立即订阅一个服务器对象。是否所有客户都需要它？
抱歉，我真的猜想大部分问题都可以在阅读 OPC UA 规范时得到解答，但也许有人可以在我挖掘大量论文之前回答它）
广告 1。基本上，是的。遵循一些额外的规则——例如，"nodes with values" 应该被建模为变量（它们又是节点，具有一些规定的属性和行为等）
广告 2。在许多情况下，这不是必需的。但如果您需要它，可以使用 ModelChangeEvents 完成（请参阅规范的第 3 部分）
广告 3。这不是针对 OPC UA 规范的问题，而是针对您正在使用的特定 stack/SDK/toolkit。他们中的许多人都有抽象的概念 "node manager" 可以将节点保存在内存中， 或 它可以动态提供它们 - 仅在需要时提供。因此，您需要研究手头的特定工具。除非地址space非常大，或者访问底层信息很慢，否则提前准备所有节点是很常见的。
广告 4. 基本上，是的。所有合理的客户端都需要从服务器对象获得一些东西（例如名称space table），再加上 OPC 合规性测试中的一些要求，要求客户端主动使用该信息。大多数 SDKs/toolkits 无论如何都会自动提供服务器对象，无需您进行额外的编程。
我是OPC的新手。有些事情对我来说不是很明显。
我正在使用来自：https://github.com/digitalpetri 的 opcua 堆栈 (uaserver) 作为客户端软件（目前，仅用于测试）我使用的是 United Automation 的 UAExpert。
每个客户都有几个单位。每个单位都可以有一些值。 一切都在 postgres 数据库中。我需要通过 OPC 为客户公开这些值。
现在我觉得我必须实施它：
- 每个客户一个文件夹节点。
- 每个文件夹都有多个节点的引用，这些节点是单元
- 每个单元都有一些值的节点（这里并不重要）
我的顾虑：
- 我不知道这种模型对于 OPC-UA 在思想上是否正确。
- 我似乎不清楚如果添加或删除了一个单元，我该如何通知 OPC 客户端。
- 我似乎还需要为所有客户文件夹、单元等准备所有节点，就在我的 OPC 服务器启动时。甚至为永远不会连接的客户保留它们。有什么正确的方法可以避免这种情况吗？
- UAExpert 客户端在连接到服务器后立即订阅一个服务器对象。是否所有客户都需要它？
抱歉，我真的猜想大部分问题都可以在阅读 OPC UA 规范时得到解答，但也许有人可以在我挖掘大量论文之前回答它）
广告 1。基本上，是的。遵循一些额外的规则——例如，"nodes with values" 应该被建模为变量（它们又是节点，具有一些规定的属性和行为等）
广告 2。在许多情况下，这不是必需的。但如果您需要它，可以使用 ModelChangeEvents 完成（请参阅规范的第 3 部分）
广告 3。这不是针对 OPC UA 规范的问题，而是针对您正在使用的特定 stack/SDK/toolkit。他们中的许多人都有抽象的概念 "node manager" 可以将节点保存在内存中， 或 它可以动态提供它们 - 仅在需要时提供。因此，您需要研究手头的特定工具。除非地址space非常大，或者访问底层信息很慢，否则提前准备所有节点是很常见的。
广告 4. 基本上，是的。所有合理的客户端都需要从服务器对象获得一些东西（例如名称space table），再加上 OPC 合规性测试中的一些要求，要求客户端主动使用该信息。大多数 SDKs/toolkits 无论如何都会自动提供服务器对象，无需您进行额外的编程。