采集到原始数据，只完成了数采项目的第一步。真正让数据可以被业务使用的，是后面的清洗、转换、计算、缓存、存储和告警。

一、原始数据不是业务数据

设备上报的数据通常带着明显的现场特征：寄存器地址、原始整数、设备状态码、不同单位、不同时间格式，甚至还会夹杂超时、断线和异常值。

业务系统想要的则是另一种数据：

• 这条数据属于哪台设备
• 它代表哪个业务点位
• 当前值是多少
• 单位是什么
• 数据是否可信
• 什么时候采集的
• 是否触发了报警

因此，边缘侧要做的事情可以概括为：把现场原始值转换成业务可用数据。

二、六步边缘数据处理流水线

一个完整的边缘数据服务，可以拆成六个步骤：

告警规则引擎可以横向贯穿这条流水线，在实时数据处理之后生成告警事件。

三、第一步：原始数据采集

采集层负责从现场设备获得最原始的数据，同时保留必要的上下文：

• 设备编号
• 协议类型
• 采集时间
• 点位编码
• 原始地址
• 原始值
• 通信状态
• 采集耗时
• 错误信息

采集层不要急着把所有逻辑揉进代码。设备模型、点位配置、采集频率和协议参数应该尽量配置化。

配置化的好处是：增加设备或调整点位时，不需要频繁修改程序；发生现场变化时，工程人员也能通过配置完成调整。

四、第二步：数值转换

很多设备读出来的并不是最终业务值，需要经过转换。

缩放

设备可能用整数表示小数，例如寄存器值为 2309，实际温度是 23.09℃。这时可以采用：

单位转换

不同设备可能使用 Pa、kPa、MPa，或者使用摄氏度、华氏度。业务系统最好统一单位，避免在每个页面里重复转换。

枚举映射

设备状态码 0、1、2 对现场工程师有意义，但业务用户更容易理解“停止、运行、故障”。边缘侧可以完成状态码到中文状态的映射。

类型转换

原始值可能是 uint16、int16、float32，也可能是多个寄存器组合的数据。类型转换应放在统一处理层，避免不同模块各自解释。

五、第三步：物理量计算

有些业务数据并不是设备直接上报的点位，而是由多个点位计算得到的派生值。

例如：

• 根据电压和电流计算功率
• 根据瞬时流量累计能耗
• 根据温度和压力计算工艺指标
• 根据计划产量和实际产量计算 OEE
• 根据多个传感器计算设备综合状态

计算公式应该进入配置或规则库，而不是硬编码在页面中。这样既方便调整，也有利于审计和追溯。

六、第四步：实时数据处理

实时处理重点不是“把每个数据都原样保存”，而是提高数据质量和使用效率。

常见处理包括：

去噪

过滤明显不合理的跳变值，或者采用滑动平均、中值滤波等方法降低噪声。

聚合

对高频数据进行秒级、分钟级或小时级聚合，减少存储和传输压力。

质量标记

每条数据除了 value，还应该带有质量信息，例如：

• good：采集正常
• timeout：通信超时
• stale：数据过期
• invalid：数据无效
• substituted：使用补偿值

如果没有质量标记，业务人员看到一个“正常数字”时，很难判断它是真实采集值还是断线前的旧值。

七、第五步：队列与缓冲

工业现场不可能永远稳定。边缘服务需要考虑：

• 云端暂时不可用
• 时序数据库写入变慢
• MQTT 连接断开
• 突发告警大量产生
• 网络恢复后需要补传历史数据

这时就需要队列和缓冲机制：

1. 数据先进入本地队列。
2. 下游可用时正常写入。
3. 下游不可用时暂存在本地。
4. 根据重试策略逐步补传。
5. 补传成功后清理已确认的数据。

队列的作用不仅是防丢，还能削峰解耦。采集层和存储层不必严格同步完成，短时压力也不会直接传导到设备侧。

八、第六步：时序存储与数据同步

边缘侧通常需要保留一定时间的本地时序数据，满足：

• 本地趋势查询
• 断网期间的数据查看
• 网络恢复后的历史补传
• 现场故障追溯
• 边缘告警规则计算

云端则可以保存跨工厂的长期数据，用于设备对比、能耗分析和集团级运营。

边缘和云端不一定要实时同步所有原始数据。可以根据数据类型分层：实时值走实时通道，告警走高可靠通道，历史数据采用批量归档。

九、告警规则引擎：从“超过阈值”到“形成事件”

简单报警是：当前值大于上限就报警。但生产场景通常还需要：

• 持续超过阈值一段时间才报警
• 多个点位组合满足条件才报警
• 同一个问题不能重复生成大量事件
• 人员确认后仍需等待恢复
• 某些时间段抑制报警
• 不同等级发送给不同人员

因此，告警可以拆成两层：

规则判断

根据阈值、组合条件和持续时间判断是否满足报警条件。

事件管理

对报警事件进行创建、确认、抑制和恢复管理。

这两层分离后，规则变化不会影响事件历史，事件生命周期也不会被简单的 if 判断绑死。

十、计划任务和服务端命令如何协作

规律性的采集任务，可以由计划任务负责定时调度；复杂的转换、计算和业务逻辑，则适合封装成服务端命令。

计划任务适合：

• 按周期轮询设备
• 定时触发同步
• 固定频率执行采集
• 采集完成后触发后续任务

服务端命令适合：

• 循环和判断
• 对象操作
• SQL 查询和事务
• 复杂数据转换
• 可复用业务逻辑
• 可视化调试和集中执行

这种拆分能让“调度”和“业务逻辑”各自保持清晰。

十一、一个可落地的数据结构

建议从一开始就输出统一数据结构：

后续不管数据来自 Modbus、OPC UA 还是 MQTT，进入业务层后都可以使用同一套查询、报警和展示逻辑。

十二、总结

工业数据处理不是把原始 JSON 转成另一个 JSON，而是建立一条可解释、可恢复、可追溯的数据链路：

• 采集保留现场事实
• 转换统一数据含义
• 计算生成业务指标
• 处理提高数据质量
• 缓冲应对网络波动
• 存储支撑实时和历史分析
• 告警把数据变成业务事件

系统真正稳定的标志，不是平时能显示数字，而是设备异常、网络中断、数据库短暂不可用时，数据链路仍然知道应该怎么做。