IoT 数据接入后的第一道关：时间戳、乱序、去重与质量标记

楼宇设备连接完成后，最容易被忽略的问题不是图表样式，而是“这条数据究竟代表什么时候、哪台设备、什么状态”。网络重连可能带回旧数据，消息重试可能重复到达，传感器故障也可能留下一个看似正常的数值。若直接把最后收到的消息当成最新状态，运维判断就可能被传输过程误导。

分开保存事件时间与接收时间

事件时间描述现场观测发生的时间；接收时间描述平台收到消息的时间。两者差值可用于观察传输延迟，但前提是源端时间可信。OPC UA 的 DataValue 区分数值、状态码、源时间戳和服务器时间戳。其中 serverTimestamp 表示 OPC UA 服务器收到变量值或确认该值准确的时间，不等同于运维平台收到消息时自行记录的 receivedAt；两者应分别保存。OPC Foundation：DataValue

在接入设计中，建议保留原始时间字段、归一后的时间和时间来源。源端缺少可靠时钟时，应明确标记“接收时间代用”，而不是填入当前时间后宣称数据实时。时区转换也应集中处理，避免不同网关对同一时间字符串作出不同解释。

为每条数据保存足够的上下文

对于单位转换，要同时校验量纲和有效范围。压力数值不能仅因字段名相似就互换，累计电量也不能按瞬时功率的方式计算。错误或缺失单位的数据可以进入隔离队列，等待修正映射后重放，不宜无提示地进入报表。

去重规则不能只依赖“同一秒同一个值”

MQTT 的“至少一次”交付语义允许消息重复到达。选择这种传输方式后，业务层仍需要考虑重复处理的问题。OASIS：MQTT 5.0 正式规范

如果源端提供持久的事件 ID，优先把它与设备及点位范围组合为去重键。若只有序列号，还应考虑设备重启后序列重置，通过会话或启动标识区分。没有稳定事件 ID 时，可根据业务约定采用有限时间窗口的组合判断，但应记录其局限，避免删掉合法的重复采样。

去重应在持久化边界有唯一性约束或等效的原子机制。仅在某个进程内记住“刚收到过”，遇到重启、多实例或并发请求就可能失效。被识别的重复消息可计数用于诊断，不必重复触发下游告警。

乱序数据要区分实时状态与历史曲线

设想网关先补传 10:01 的数据，随后收到 10:03 的实时数据，最后又送来 10:02 的缓存数据。历史曲线可以按事件时间补齐，当前状态却不应倒退到 10:02。接入层应分别维护历史样本与当前状态的更新规则。

对迟到窗口也要有明确约定：窗口内是否重算统计，窗口外是否仅归档，报表修订是否留下版本。需要即时处置的告警则应依据业务时效规则判断旧事件，避免断网恢复后把数小时前的状态当作正在发生的异常。

如果源时间显著超前或回退，应把时钟异常与设备异常分开呈现。简单地把时间改成平台当前时间，会掩盖问题并破坏事后追溯；更合理的做法是保留原值、标记原因，并由接入策略决定是否进入实时链路。

数据质量也是一种运行状态

数值越界、长期不变、通信中断、单位未知、时间异常和人工补录，应使用不同标记。图表上的空白不能自动补成零，因为零可能有真实业务含义。使用最近值填补空缺时，也应标明它的原始时间和已持续的时长。

告警规则需要明确哪些质量状态允许参与计算。例如通信失联应进入独立事件流程，不能直接解释为温度正常。对人工修订的样本，要保留修订理由、操作者和原始记录，防止统计结果失去解释依据。

用回放测试验证接入合同

准备一组固定消息：正常采样、完全重复、重启后序列回零、延迟到达、断网补传、单位变化、质量异常和源时钟漂移。检查落库数量、当前值、曲线排序和告警次数是否符合事先约定。

回放还应包含处理到一半时重启服务的情况，确认恢复后不会丢掉已接收但未提交的数据，也不会把已经完成的下游动作重复执行。将输入消息与预期结果一同保存，可在网关配置或解析程序变更后重复验证。

设备点位如何对应模型，可先阅读BIM 与 IoT 点位映射。映射解决“是谁”，数据质量规则继续解决“是什么时候、是否可信、能否参与判断”。