——边缘数据处理流水线)
采集到原始数据只完成了数采项目的第一步。真正让数据可以被业务使用的是后面的清洗、转换、计算、缓存、存储和告警。一、原始数据不是业务数据设备上报的数据通常带着明显的现场特征寄存器地址、原始整数、设备状态码、不同单位、不同时间格式甚至还会夹杂超时、断线和异常值。业务系统想要的则是另一种数据这条数据属于哪台设备它代表哪个业务点位当前值是多少单位是什么数据是否可信什么时候采集的是否触发了报警因此边缘侧要做的事情可以概括为把现场原始值转换成业务可用数据。二、六步边缘数据处理流水线一个完整的边缘数据服务可以拆成六个步骤告警规则引擎可以横向贯穿这条流水线在实时数据处理之后生成告警事件。三、第一步原始数据采集采集层负责从现场设备获得最原始的数据同时保留必要的上下文设备编号协议类型采集时间点位编码原始地址原始值通信状态采集耗时错误信息采集层不要急着把所有逻辑揉进代码。设备模型、点位配置、采集频率和协议参数应该尽量配置化。配置化的好处是增加设备或调整点位时不需要频繁修改程序发生现场变化时工程人员也能通过配置完成调整。四、第二步数值转换很多设备读出来的并不是最终业务值需要经过转换。缩放设备可能用整数表示小数例如寄存器值为 2309实际温度是 23.09℃。这时可以采用单位转换不同设备可能使用 Pa、kPa、MPa或者使用摄氏度、华氏度。业务系统最好统一单位避免在每个页面里重复转换。枚举映射设备状态码 0、1、2 对现场工程师有意义但业务用户更容易理解“停止、运行、故障”。边缘侧可以完成状态码到中文状态的映射。类型转换原始值可能是 uint16、int16、float32也可能是多个寄存器组合的数据。类型转换应放在统一处理层避免不同模块各自解释。五、第三步物理量计算有些业务数据并不是设备直接上报的点位而是由多个点位计算得到的派生值。例如根据电压和电流计算功率根据瞬时流量累计能耗根据温度和压力计算工艺指标根据计划产量和实际产量计算 OEE根据多个传感器计算设备综合状态计算公式应该进入配置或规则库而不是硬编码在页面中。这样既方便调整也有利于审计和追溯。六、第四步实时数据处理实时处理重点不是“把每个数据都原样保存”而是提高数据质量和使用效率。常见处理包括去噪过滤明显不合理的跳变值或者采用滑动平均、中值滤波等方法降低噪声。聚合对高频数据进行秒级、分钟级或小时级聚合减少存储和传输压力。质量标记每条数据除了 value还应该带有质量信息例如good采集正常timeout通信超时stale数据过期invalid数据无效substituted使用补偿值如果没有质量标记业务人员看到一个“正常数字”时很难判断它是真实采集值还是断线前的旧值。七、第五步队列与缓冲工业现场不可能永远稳定。边缘服务需要考虑云端暂时不可用时序数据库写入变慢MQTT 连接断开突发告警大量产生网络恢复后需要补传历史数据这时就需要队列和缓冲机制数据先进入本地队列。下游可用时正常写入。下游不可用时暂存在本地。根据重试策略逐步补传。补传成功后清理已确认的数据。队列的作用不仅是防丢还能削峰解耦。采集层和存储层不必严格同步完成短时压力也不会直接传导到设备侧。八、第六步时序存储与数据同步边缘侧通常需要保留一定时间的本地时序数据满足本地趋势查询断网期间的数据查看网络恢复后的历史补传现场故障追溯边缘告警规则计算云端则可以保存跨工厂的长期数据用于设备对比、能耗分析和集团级运营。边缘和云端不一定要实时同步所有原始数据。可以根据数据类型分层实时值走实时通道告警走高可靠通道历史数据采用批量归档。九、告警规则引擎从“超过阈值”到“形成事件”简单报警是当前值大于上限就报警。但生产场景通常还需要持续超过阈值一段时间才报警多个点位组合满足条件才报警同一个问题不能重复生成大量事件人员确认后仍需等待恢复某些时间段抑制报警不同等级发送给不同人员因此告警可以拆成两层规则判断根据阈值、组合条件和持续时间判断是否满足报警条件。事件管理对报警事件进行创建、确认、抑制和恢复管理。这两层分离后规则变化不会影响事件历史事件生命周期也不会被简单的 if 判断绑死。十、计划任务和服务端命令如何协作规律性的采集任务可以由计划任务负责定时调度复杂的转换、计算和业务逻辑则适合封装成服务端命令。计划任务适合按周期轮询设备定时触发同步固定频率执行采集采集完成后触发后续任务服务端命令适合循环和判断对象操作SQL 查询和事务复杂数据转换可复用业务逻辑可视化调试和集中执行这种拆分能让“调度”和“业务逻辑”各自保持清晰。十一、一个可落地的数据结构建议从一开始就输出统一数据结构后续不管数据来自 Modbus、OPC UA 还是 MQTT进入业务层后都可以使用同一套查询、报警和展示逻辑。十二、总结工业数据处理不是把原始 JSON 转成另一个 JSON而是建立一条可解释、可恢复、可追溯的数据链路采集保留现场事实转换统一数据含义计算生成业务指标处理提高数据质量缓冲应对网络波动存储支撑实时和历史分析告警把数据变成业务事件系统真正稳定的标志不是平时能显示数字而是设备异常、网络中断、数据库短暂不可用时数据链路仍然知道应该怎么做。 端到端数采链路(三)——边缘数据处理流水线
采集到原始数据只完成了数采项目的第一步。真正让数据可以被业务使用的是后面的清洗、转换、计算、缓存、存储和告警。一、原始数据不是业务数据设备上报的数据通常带着明显的现场特征寄存器地址、原始整数、设备状态码、不同单位、不同时间格式甚至还会夹杂超时、断线和异常值。业务系统想要的则是另一种数据这条数据属于哪台设备它代表哪个业务点位当前值是多少单位是什么数据是否可信什么时候采集的是否触发了报警因此边缘侧要做的事情可以概括为把现场原始值转换成业务可用数据。二、六步边缘数据处理流水线一个完整的边缘数据服务可以拆成六个步骤告警规则引擎可以横向贯穿这条流水线在实时数据处理之后生成告警事件。三、第一步原始数据采集采集层负责从现场设备获得最原始的数据同时保留必要的上下文设备编号协议类型采集时间点位编码原始地址原始值通信状态采集耗时错误信息采集层不要急着把所有逻辑揉进代码。设备模型、点位配置、采集频率和协议参数应该尽量配置化。配置化的好处是增加设备或调整点位时不需要频繁修改程序发生现场变化时工程人员也能通过配置完成调整。四、第二步数值转换很多设备读出来的并不是最终业务值需要经过转换。缩放设备可能用整数表示小数例如寄存器值为 2309实际温度是 23.09℃。这时可以采用单位转换不同设备可能使用 Pa、kPa、MPa或者使用摄氏度、华氏度。业务系统最好统一单位避免在每个页面里重复转换。枚举映射设备状态码 0、1、2 对现场工程师有意义但业务用户更容易理解“停止、运行、故障”。边缘侧可以完成状态码到中文状态的映射。类型转换原始值可能是 uint16、int16、float32也可能是多个寄存器组合的数据。类型转换应放在统一处理层避免不同模块各自解释。五、第三步物理量计算有些业务数据并不是设备直接上报的点位而是由多个点位计算得到的派生值。例如根据电压和电流计算功率根据瞬时流量累计能耗根据温度和压力计算工艺指标根据计划产量和实际产量计算 OEE根据多个传感器计算设备综合状态计算公式应该进入配置或规则库而不是硬编码在页面中。这样既方便调整也有利于审计和追溯。六、第四步实时数据处理实时处理重点不是“把每个数据都原样保存”而是提高数据质量和使用效率。常见处理包括去噪过滤明显不合理的跳变值或者采用滑动平均、中值滤波等方法降低噪声。聚合对高频数据进行秒级、分钟级或小时级聚合减少存储和传输压力。质量标记每条数据除了 value还应该带有质量信息例如good采集正常timeout通信超时stale数据过期invalid数据无效substituted使用补偿值如果没有质量标记业务人员看到一个“正常数字”时很难判断它是真实采集值还是断线前的旧值。七、第五步队列与缓冲工业现场不可能永远稳定。边缘服务需要考虑云端暂时不可用时序数据库写入变慢MQTT 连接断开突发告警大量产生网络恢复后需要补传历史数据这时就需要队列和缓冲机制数据先进入本地队列。下游可用时正常写入。下游不可用时暂存在本地。根据重试策略逐步补传。补传成功后清理已确认的数据。队列的作用不仅是防丢还能削峰解耦。采集层和存储层不必严格同步完成短时压力也不会直接传导到设备侧。八、第六步时序存储与数据同步边缘侧通常需要保留一定时间的本地时序数据满足本地趋势查询断网期间的数据查看网络恢复后的历史补传现场故障追溯边缘告警规则计算云端则可以保存跨工厂的长期数据用于设备对比、能耗分析和集团级运营。边缘和云端不一定要实时同步所有原始数据。可以根据数据类型分层实时值走实时通道告警走高可靠通道历史数据采用批量归档。九、告警规则引擎从“超过阈值”到“形成事件”简单报警是当前值大于上限就报警。但生产场景通常还需要持续超过阈值一段时间才报警多个点位组合满足条件才报警同一个问题不能重复生成大量事件人员确认后仍需等待恢复某些时间段抑制报警不同等级发送给不同人员因此告警可以拆成两层规则判断根据阈值、组合条件和持续时间判断是否满足报警条件。事件管理对报警事件进行创建、确认、抑制和恢复管理。这两层分离后规则变化不会影响事件历史事件生命周期也不会被简单的 if 判断绑死。十、计划任务和服务端命令如何协作规律性的采集任务可以由计划任务负责定时调度复杂的转换、计算和业务逻辑则适合封装成服务端命令。计划任务适合按周期轮询设备定时触发同步固定频率执行采集采集完成后触发后续任务服务端命令适合循环和判断对象操作SQL 查询和事务复杂数据转换可复用业务逻辑可视化调试和集中执行这种拆分能让“调度”和“业务逻辑”各自保持清晰。十一、一个可落地的数据结构建议从一开始就输出统一数据结构后续不管数据来自 Modbus、OPC UA 还是 MQTT进入业务层后都可以使用同一套查询、报警和展示逻辑。十二、总结工业数据处理不是把原始 JSON 转成另一个 JSON而是建立一条可解释、可恢复、可追溯的数据链路采集保留现场事实转换统一数据含义计算生成业务指标处理提高数据质量缓冲应对网络波动存储支撑实时和历史分析告警把数据变成业务事件系统真正稳定的标志不是平时能显示数字而是设备异常、网络中断、数据库短暂不可用时数据链路仍然知道应该怎么做。