终端还在发送心跳，测量值却很久没有更新。只用在线图标描述系统状态，会让使用者误以为采集功能也正常。
心跳证明某条通信路径有活动，数据时间证明观测是否新鲜，功能探针证明目标业务是否可用。它们的周期、超时和恢复条件应独立定义。
一、问题的范围与前提
设备接入需要贯通物理连接、通信帧、数据解释与业务语义。一个端口可打开，只证明访问条件的一部分；收到变化数值也不证明单位正确。测点身份、量程、时间和质量信息都应保存，才能区分真实零值、无效输入和过期观测。
二、技术分析与方案取舍
可以在界面分别显示通信在线、数据有效和功能可用。设备按期发心跳却没有新测量时，前者仍在线，后者应过期；平台存储故障时，通信和测量都可能正常，业务仍不可用。超时规则按不同周期设置，恢复以新观测或探针结果确认。离线补传进入历史，不应把一小时前的值标成现在刚采到。
从厂家手册确定允许的读取和输入条件，先用单设备、单主站、已知测点建立基线，再扩展采集规模。协议地址、字节序和缩放在入口转换，业务层使用统一含义。生产控制与示例采集分开，不把未经确认的现场接线、寄存器或阈值公开。
三、实现与排查的顺序
- 区分通信与采集状态。
- 记录最后成功观测时间。
- 设置符合采样频率的失效规则。
- 恢复时核对序号和实际新数据。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
通信：最后心跳 / 连接状态
数据：最后有效观测 / 质量 / 序号
业务：目标功能探针 / 最近完成结果
三个维度可以同时存在不同状态。心跳周期、数据有效期和业务超时按各自节奏设置，不能因为某一层在线就把另外两层标成正常。
四、验证和结果解释
原始回包与解析值可以同时记录，排查需要保持二者关联。将采样、轮询、平台接收和告警时间分开，有助于解释等待和补传。持续采集时统计成功、超时、无效值与重连，而不是只保留最近一次成功读数。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 设备进程存活但采集失败能被发现 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 离线补传不改写当前状态 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 短暂丢包不会反复切换在线图标 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
验收既覆盖连续正常读取，也覆盖断开、设备重启、错误地址与异常数据。恢复后检查新鲜度和序号，防止旧值继续驱动业务。稳定命名、防抖与重试分别解决不同问题，不能代替链路与协议条件检查。
五、适用边界与结论
超时值应由链路和业务节奏确定，不能照搬其它设备。时钟漂移时需同时参考平台接收时间，不把未来设备时间认作永久新鲜。
这条路径把“区分通信与采集状态”与“恢复时核对序号和实际新数据”连在一起，中间保留可复查的条件。实施时优先确认“设备进程存活但采集失败能被发现”，再检查“短暂丢包不会反复切换在线图标”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
