超级管理员
楼主
边缘计算在工业现场落地之后，一个常见的问题是：数据全往上报，云平台账单爆炸，真正有用的信号却被淹没。
先想清楚上报的目的 不同的目的对应完全不同的数据策略：
- 设备健康监控：需要的是趋势和异常，不是全量原始数据。
- 工艺分析：需要的是关键工艺参数的时间序列，采样频率和精度要求高。
- 生产统计：需要的是事件（开工、完工、停机、换型），不是连续数据。
- 质量追溯：需要的是与产品批次绑定的过程参数快照。
先定目的，再定数据。反过来做一定出问题。
该发的三类数据
- 状态变化事件。设备从运行到停机、从自动到手动、报警产生和解除。这类数据量小、价值高，必须发。
- 按批次/工单的汇总。每个产品完成后，把这个过程的关键参数做统计（最大、最小、平均、标准差）发出去。
- 异常片段。触发条件时，把前后一段时间的高频数据打包上传。平时不传高频数据。
不该发的
- 全量高频原始数据。1 秒 100 个点的采集，全量上云没有任何意义，存储和带宽成本都撑不住。
- 未经过滤的报警。抖动产生的瞬时报警要先做防抖处理，否则一天几万条。
- 与业务无关的诊断信息。除非在排查特定问题。
边缘侧该做的处理 边缘网关的价值不只是转发，更重要的是在边缘侧完成处理：
- 数据清洗：剔除超出量程的跳变值，标记而不是删除。
- 边缘聚合：把秒级数据聚合成分钟级、小时级统计值。
- 变化检测：只在数值变化超过阈值时才上报，静态数据不重复发。
- 断网缓存：网络中断时本地存储，恢复后补传。工业现场网络不稳定是常态。
MQTT 的实践要点
- Topic 设计要有层次。建议按 工厂/车间/产线/设备/数据类型 组织，方便订阅和权限控制。
- QoS 级别按需选。状态和报警用 QoS 1，高频数据用 QoS 0。全用 QoS 2 会导致吞吐量严重下降。
- 保留消息和遗嘱消息用好。设备离线时遗嘱消息能立刻通知订阅方。
- 心跳间隔设置合理。太频繁浪费带宽，太长则故障发现慢。
一个判断标准 如果上云的数据里，超过一半从来没有被查询过，说明你的上报策略需要重做。数据不是越多越好，能支撑决策的数据才是资产，其余是成本。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。