3. 实时数据采集与接入

生产异常实时预警的第一道关口不是算法，而是数据能不能稳定、及时、准确地进入分析链路。一条产线上，温度可能来自传感器变送器，节拍来自PLC，设备状态来自SCADA，工单与批次来自MES，而跨厂区的汇总又依赖IoT平台。这些数据源处在不同的层级，采集方式、通信协议、上报频率和数据质量约束各不相同。理解它们的差异，才能设计出既满足预警时效、又不会压垮网络的接入方案。

一、从现场到平台的四层数据来源

按距离物理过程的远近，可以把数据源分为四层。最底层是传感器与仪表，直接感知温度、压力、流量、振动、电流等物理量，输出4-20mA、0-10V模拟信号，或通过RS-485输出Modbus RTU数字信号。往上一层是PLC，它扫描输入模块、执行逻辑、驱动输出，内部维护着I/O映像区和数据块（如西门子的DB块、三菱的D寄存器），是设备动作与状态最权威的来源。再往上是SCADA，它通过驱动连接一台或多台PLC，完成集中监视、报警与历史存储，通常以OPC UA或厂商私有协议对外提供数据。最上层是MES与IoT平台，MES掌握工单、批次、物料、人员等业务上下文，IoT平台则负责海量设备的统一接入、边缘预处理与云端汇聚。

这四层不是替代关系，而是互补关系。预警系统往往需要把PLC的高频设备信号与MES的批次信息在时间轴上对齐，才能判断“这次温度超限发生在哪个工单的哪一批产品上”。

二、采集方式与协议选择

采集方式决定了数据进入系统的路径。常见做法有三类：轮询采集由采集程序按固定周期向设备读取寄存器，实现简单、兼容性好，但周期越短对设备通信负担越大；订阅/发布由设备或网关在数据变化时主动推送，如OPC UA Subscription、MQTT Publish，实时性好且节省带宽；事件触发只在报警、状态跳变或批次切换时上报，适合低频但关键的事件。

协议选择要匹配层级。现场仪表多用Modbus RTU（RS-485总线，9600~115200bps）；PLC与上位机之间常用Modbus TCP、西门子S7协议或EtherNet/IP；SCADA对外推荐OPC UA，它自带信息模型、支持订阅和安全通道；IoT平台侧普遍采用MQTT，轻量、支持断线重连和QoS等级。若现场已有老旧设备只支持OPC DA（基于DCOM），通常需要加一层OPC UA网关做协议转换，避免DCOM在跨网段时的配置难题。

三、采集频率的确定

频率不是越高越好，而应由“异常需要多快被发现”倒推。以温度预警为例：若工艺温度从正常到超限大约需要30秒，那么1秒采集一次已足够，5秒也能接受，但500毫秒并不会带来实质收益，反而增加存储和网络压力。经验上可参考下表：

对高频振动信号，推荐在边缘侧先做特征提取（均方根、峰值、峭度），只把特征值和原始片段按需上传，这样既保留诊断能力，又把上行带宽降低一到两个数量级。

四、数据质量要求

预警系统最怕的不是没有数据，而是“看起来正常但实际错误”的数据。接入时必须明确几项质量约束：

• 时间戳一致性：所有数据必须带采集时刻，且各层时钟通过NTP同步，偏差控制在100ms以内。否则PLC报警与MES批次无法对齐。
• 量程与单位：4-20mA对应0~150℃还是-50~200℃，必须在接入时登记，避免量程错配导致误报。
• 坏值标记：传感器断线、PLC通信超时、数值超物理极限时，应标记为Bad而非填0，防止0值被当成真实低温。
• 完整性：关键点位丢包率应低于0.1%，MQTT使用QoS 1，OPC UA使用可靠订阅。
• 重复与抖动：对状态量做去抖（如连续3次采样一致才确认跳变），避免报警风暴。

五、一个可执行的接入检查示例

假设某注塑机需要接入温度、压力、锁模状态和当前工单四个数据。可按如下方式落地：温度与压力通过Modbus TCP从PLC读取，周期1s；锁模状态用OPC UA订阅，变化时推送；工单号由MES通过REST接口在换单时写入IoT平台。接入后做一次验证：手动加热使温度超过设定上限，观察预警是否在3秒内产生，并检查该报警记录中是否携带了正确的工单号与时间戳。若报警延迟超过5秒，优先检查采集周期与MQTT链路，而不是调整预警阈值。

数据采集与接入的质量，直接决定了后续钻取分析能走多深。把协议、频率、时间戳和质量标记在接入阶段就定义清楚，异常预警才不会沦为“事后统计”。