采集数据时间戳错乱的处理

现象

设备采集的数据出现以下异常：

• 同一台设备的数据时间跳跃（一会儿是今天，一会儿是上周）
• 数据顺序错乱（后采的数据时间早于先采的）
• 工艺曲线图上出现尖刺或断裂
• OEE 算出来开机时长为负

四种成因

成因一：设备时钟不准

设备本身的时钟没有校时，长期运行后漂移。老设备的时钟误差每天可能累积到几分钟，几个月下来就是几小时。

特征：整台设备的所有数据都偏移一个固定量。

成因二：网关与服务端时间不一致

采集网关自己有时间，数据入库时用服务端时间打标。两者不一致就会乱。

特征：同一时刻的数据，一部分是设备时间，一部分是服务端时间。

成因三：网络延迟与缓冲

数据在网关缓冲后批量上传。如果上传时用"上传时间"打标，而非数据实际产生的时间，就会出现时间错乱。

特征：一批数据的时间戳密集集中在某个时刻。

成因四：时区配置错误

设备用 UTC，系统用本地时间（或反之），相差 8 小时。

特征：偏移量正好是整小时（8 小时、时区差）。

排查步骤

第一步：确定偏移规律

把异常数据和正常数据对比，看时间差是：

第二步：核对设备时钟

现场看设备屏幕上的时间，与标准时间对比。

如果偏差超过 1 分钟，就是设备时钟问题。

第三步：检查网关配置

看网关的日志，确认：

• 数据打标用的是设备时间还是网关时间
• 是否有 NTP 校时配置
• 缓冲策略是什么

第四步：检查服务端入库逻辑

确认数据入库时的时间字段是怎么来的：

• 用设备上报的时间 → 依赖设备时钟准确性
• 用服务端接收时间 → 依赖网络实时性
• 同时存两个 → 这是推荐做法

解决方法

短期：统一时间基准

1. 给网关配 NTP 校时，指向内网时间服务器
2. 能校时的设备开启自动校时（支持 NTP 的设备）
3. 不支持校时的老设备，在网关侧做偏移补偿：记录设备时钟与标准时间的差，上报时统一加上这个偏移

长期：双时间戳

数据入库时同时保存两个时间：

有了这两个字段，即使设备时钟有偏差，也能：

• 通过两者差值监控时钟漂移
• 用 server_time 保证数据不丢、不重
• 用 device_time 做工艺曲线分析（但要先补偿偏移）

数据修复

对已有的错乱数据：

1. 先算出一个设备的平均时钟偏移量（用设备时间与 server_time 的差值的中位数）
2. 按这个偏移量批量修正历史数据
3. 修正后重新计算 OEE 等派生指标
4. 保留原始数据，标注"已修正"，便于追溯

不要直接覆盖原始数据。采集数据是原始凭证，修改要留痕。

预防措施

时区这一条建议明确文档化。很多问题是换了个开发人员、或者对接了外部系统之后才暴露的。

一个实战提醒

在项目初期设计采集方案时，时间同步这一条要写进技术方案，并作为验收项。

验收方法很简单：连续观察 7 天，对比设备时间与标准时间的偏差，要求小于 1 秒。

如果方案里没写、验收时也没测，后期数据治理的成本会非常高——你甚至不知道哪些数据是可信的。

时间同步的具体配置方式，[待补充：百华智造 MES 采集网关 NTP 配置说明]。