OPC UA StatusCode 不等于零就失败吗：怎样拆严重级别与信息位

StatusCode不是“零成功、非零失败”的布尔值。最高两位表示Good、Uncertain、Bad或保留严重级别，低位还可能携带信息；Good带信息位仍不能被简单归为失败，Bad和保留严重级别则不得使用对应值。

适用版本与输入范围

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

按32位无符号字段拆分

附件hex_word是便于人读的十六进制数值文本，不是线上四字节排列；若从二进制读取，需先按UA小端UInt32还原这个数。程序右移30位取严重级别，取16到27位为SubCode，10到11位为InfoType，其余低十位作为信息位保留。字段先分解，再由上层决定展示，不能拿完整整数与某一个错误码做字符串比较后就忽略严重级别。

Good并非只有全零一种形态

00000480的最高两位仍是00，InfoType=1并带信息位128，本程序返回Good并保留信息。这个合成输入用于揭露code!=0即失败的错误逻辑，不把每个信息位都展开为完整业务解释。若项目关心溢出、限值或历史信息，应按具体InfoType继续解释，不能把低位当成任意厂商自定义状态。报告保留原始输入，未来可增加有依据的具体位映射。

保留严重级别也按不可用处理

40000000表示Uncertain，应谨慎使用；80020000为Bad，值不可用；C0000000的严重级别11保留，客户端也应按Bad处理。程序把severity名称与usable_policy分开，避免未知类别走到默认“成功”分支。字段超出32位的负例直接拒绝，不截去高位后生成Good。实际显示可以分质量标识和原始码两列，不能把Bad值用最近一次正常数覆盖后不留断点。

服务结果与单项结果分别检查

OPC UA可能在服务层成功，却有某个DataValue或操作返回Bad。检查ResponseHeader一次不代表所有点都可用；每个值应读取自己的StatusCode。本题只拆一个给定码，不实现服务会话，也不根据SubCode自动归因到网络或权限。实际节点的值、状态和时间证据应一起保存，尤其质量变化而数值不变时仍有意义。附件没有连接服务器、未测试产品支持，仅验证32位质量门控的基础逻辑。

下载与复跑

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

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。hex_word是数值文本；usable_policy仅为严重级别门控，不代替具体SubCode与InfoBits解释。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• StatusCode binary encoding；Part4 StatusCode字段
• StatusCode严重级别、SubCode和InfoBits位分配

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