OPC UA 换一台服务器 ns=2 就变了：怎样用 Namespace URI 保持点位身份

ns=2是某一服务器NamespaceArray中的位置，不是跨服务器固定的业务身份。迁移前应先把索引解析为Namespace URI，再在目标NamespaceArray中查回索引，同时保留Identifier类型和值；不能只复制ns数字。

适用版本与输入范围

依据 OPC Foundation 官方参考，v105 链接在核对时显示 v1.05.07，具体 Part 与章节见文末。示例只处理明确声明的值与结构，不实现网络会话、证书或完整服务端。 本文所有输入均为原创合成数据，未接真实设备。

用两张数组展示相同URI的位置变化

合成源服务器的urn:hall位于索引2，目标服务器则位于索引1，节点字符串AHU1.Temp保持不变。程序输出源ns=2与目标ns=1，并保留URI作为映射依据。若直接复制ns=2，目标会落到urn:other命名空间，即使Identifier文本相同也可能指向另一个节点或根本不存在。数组首项标准UA命名空间仍保留，不能为了让业务索引一样而重新排序服务器提供的数组。

Identifier类型和值不能一起猜改

NodeId可使用数字、字符串、GUID或字节串标识，本附件明确只演示字符串s类型，迁移时不将AHU1.Temp解析成浏览路径，也不按点号拆层。URI映射只改变namespace index，不改变标识内容；如果模型版本还改变了Identifier，应另有明确迁移规则，不能靠名称相似自动替换。日志同时保留source_nodeid和target_nodeid，便于核查每个映射决策，而不是仅写“迁移成功”。

缺失与重复URI都应停止映射

目标没有urn:hall时，不能默认退回索引0或沿用旧2；重复URI也使此示例的查找不唯一，应明确报错。附件分别覆盖这两类负例，源索引还要先检查没有越界。这里的去重检查是离线映射保护，不声称真实合规服务器应该存在重复NamespaceArray项。保存两台服务器实际导出的数组及其采集版本，才能在故障时判断是配置变动还是节点模型已经不同。

URI相同也不是业务一致性认证

映射得到一个NodeId只证明标识结构可重建，尚需核对目标节点存在、DataType、ValueRank、单位和访问权限。服务器身份、端点及证书也不属于Namespace URI能独立保证的内容。本程序没有连接服务器或修改配置，用合成数组演示身份稳定化步骤。工程交接建议把服务器身份、Namespace URI、Identifier类型和值分列存储，运行时再解析索引，避免把暂时的数组位置固化进长期点表。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 3 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。URI是映射依据；示例只支持s类型Identifier，节点存在性与类型兼容尚未验证。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到楼宇与工业数据接入链路核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• NodeId Namespace index；结合Part3 NamespaceArray定义
• NamespaceIndex是NamespaceArray中URI索引，跨服务器可能变化

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。