OPC UA TranslateBrowsePathsToNodeIds：解析 NodeID 的稳定性/易失性

如何解决OPC UA TranslateBrowsePathsToNodeIds：解析 NodeID 的稳定性/易失性

有一个 OPC UA 服务 TranslateBrowsePathsToNodeIds。

服务返回的 NodeIDs 结果有多不稳定或稳定 --- NodeIDs 是否有可能在服务器运行时由服务更改解析？

在我们的案例中，我们在服务器上运行我们的客户端，它在每次服务器重启时以不同的方式枚举 NodeID。因此，我们决定在每次（重新）连接到服务器后通过 BrowsePath 解析 ID。到现在为止还挺好。但是现在当服务器重新启动并且第一个客户端重新连接后没有路径无法解析时出现问题..似乎服务器还没有准备好工作（...）。

我想知道我需要多久更新一次已解析的节点 ID（全部或只是未正确解析的一次？）。

在这种情况下，我们通过轮询读取数据。

解决方法

我不知道您的服务器，但看起来您确实以非常动态的行为处理了 OPC UA 服务器，但我认为，它在 OPC UA 规范内。

这取决于 OPC UA 对象、此服务器提供的内容以及客户端应该或想要对它们做什么。

服务解析的 NodeID 是否有可能在服务器运行时改变？

是的！

许多服务器确实提供了设备配置中的静态节点集。在这种情况下，客户端将始终从 TranslateBrowsePathsToNodeIds 获得相同的节点 id，客户端可以直接使用节点 id 而无需转换（但必须在连接到服务器后始终解析命名空间索引）。但显然这不是你喜欢的那种服务器。

另一个用例是动态对象，具有有限的生命周期，可以随时来来去去。想象一个仓库，在其中接收和交付货物。因此，商品将使用单个 OPC UA 对象实例表示，在接收时创建并在交付时删除。只要商品存在于仓库中，您就可以浏览该对象，将其浏览路径转换为节点 ID 并使用它们（读取、写入、监控）。当然，当货物送达时，UA 对象将不再需要，可以被服务器删除。现在删除的节点 ID 稍后可以在其他上下文中用于另一个对象实例。

或者，服务器可以提供一个接口来与客户端创建或删除对象。

问题是，服务器如何处理它的对象的创建或删除，它如何宣布更改？应该有一种您想用客户端监视的配置更改事件。当您的客户端收到一个事件时，它可能会决定要执行哪些操作，例如重新浏览对象并转换浏览路径。阅读手册！

顺便说一句：TranslateBrowsPathsToNodeIds 广泛用于处理具有已知对象类型的对象实例的子节点。一旦您知道整个对象的节点 ID，您就可以轻松获得子节点的节点 ID 及其浏览路径。