OPC UA 轮询时间一直更新就算新值吗：怎样保留源值与状态变化记录

轮询记录中ServerTimestamp持续更新，不代表源值或StatusCode发生变化。应保留每次读取的原始DataValue，再按值与状态建立观察到的变化序列；SourceTimestamp缺失或与变化证据矛盾时，将变化时间留为未知，不能拿服务器时间补成源变化时间。

适用版本与输入范围

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

服务器时间可能只是再次确认准确

官方Part4说明，SourceTimestamp由数据源赋给某个值实例后不再修改，宜表示值或StatusCode最后改变的时间；ServerTimestamp则反映服务器收到值或知道值仍准确的时刻。服务器可在值未改变时更新后者。因此附件前两次读取的值25、状态Good和源时间完全相同，服务器时间相差十秒，程序保留两条reads，却只形成一条初始源观察，不新增一条“值改变事件”。

状态改变即使数值不变也有记录

第三次值从25到26形成value_changed；第四次数值仍26但StatusCode转Uncertain，形成status_changed。只比较数值会丢掉质量变化，只比较服务器时间又会把每次读取都算变化。报告source_changes同时保存value、status、source_time和证据类型，reads保留全部原始字段。初始样本标为initial_observation，它是开始观察的基线，不声称该时刻之前没有变化。

缺失与矛盾字段不强行解释

第五次值27但source=null，程序仍记录观察到值/状态改变，source_time保持null并标source_time_unknown。另一组显式矛盾样本值从1到2，却复用同一源时间；本地审计将变化时间标未知、保留原字段，并提示contradictory_source_time，不替设备更正时间。这是对给定证据的保守检查，不能据此断言所有源实现或采样分辨率必然违规；真实原因可能需要原始来源与时钟精度共同核对。

观察变化不等于完整过程重建

轮询之间可能多次变化又回到原值，当前相邻样本相同不能证明中间绝无变化，脚本统计的是observed_change_count而不是物理事件总数。Bad或Uncertain质量也必须保留，不能将其值直接当可用工程量。附件要求UTC文本以消除格式混淆，但不会跨时钟相减或计算延迟；只给出源变化证据与读取记录两条线。程序没有连接服务器，未评估订阅、轮询周期或设备时钟，适合验证采集程序是否错误地用服务器刷新制造假变化。

下载与复跑

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

本次实际运行通过 3 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。reads保留每次原始证据；source_changes是观察序列，未知时间不由server补齐，统计不代表物理变化总数。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• §7.11.3值实例源时间戳不可改、宜反映值或状态改变；§7.11.4值未变时ServerTimestamp仍可更新

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