自动线的节拍与报警数据是车间数字化的基础。本文从信号源、采集方案、数据清洗到MES对接，给出可落地的技术路径与注意事项。
一、为什么节拍与报警数据是自动线的“心跳”
在智能车间中，自动线的节拍（Cycle Time）和报警（Alarm）数据直接反映设备状态、生产效率与潜在故障。节拍数据用于OEE计算、瓶颈分析；报警数据用于故障定位、维护排程。但实际项目中，很多工厂采集到的数据要么不完整，要么延迟严重，根本原因在于从PLC/数控系统到上位机之间的链路存在盲区。
二、数据源：PLC、数控系统与传感器
2.1 节拍信号的来源
- PLC内部计时器：通过读取PLC中每个工位的完成信号（如“加工完成”M点）与时间戳，计算实际节拍。
- 数控系统宏变量：如Fanuc的#3001、#3002等计时变量，或Siemens的GUD变量，可读取程序运行时间。
- 外部传感器：如光电开关、接近开关，用于检测工件进出工位的时间点。
2.2 报警信号的来源
- PLC报警位：PLC程序中定义的报警标志位（如DB块中的Bool变量）。
- 数控系统报警历史：通过OPC UA或FOCAS库读取报警列表。
- 驱动器/变频器报警：通过现场总线（Profinet/EtherCAT）读取。
注意事项：不同品牌PLC的IP地址、端口号、数据块地址需以现场电气图纸和网络规划为准，切勿使用默认配置。
三、采集方案：边缘网关与协议转换
3.1 常用协议与转换
| 设备类型 | 原生协议 | 推荐采集方式 |
|---|---|---|
| 西门子S7-1200/1500 | S7通信、Profinet | Snap7库或S7-Comm |
| 三菱FX/L系列 | MC协议、SLMP | MX Component或第三方网关 |
| Fanuc数控系统 | FOCAS1/2 | FOCAS库（需授权） |
| Modbus TCP设备 | Modbus TCP | 标准Modbus TCP客户端 |
3.2 边缘网关选型要点
- 支持多协议并发采集（如同时采集PLC和数控系统）。
- 具备本地缓存能力，防止网络中断导致数据丢失。
- 支持数据预处理：如节拍计算、报警去重、时间戳标准化。
- 安全方面：禁用Telnet、FTP等不安全服务，使用加密通信。
四、数据清洗与节拍计算
原始采集数据通常包含噪声：如设备急停导致的超长节拍、传感器误触发、报警重复上报。建议在边缘端或服务器端进行以下处理：
- 节拍过滤：设定合理阈值（如3秒~300秒），超出范围的数据标记为异常。
- 报警去重：同一报警在短时间内（如5秒）只记录一次，避免MES数据库膨胀。
- 时间对齐：所有设备统一使用NTP时间同步，确保节拍和报警的时间戳一致。
五、数据上送：对接MES与SCADA
5.1 接口方式
- OPC UA：工业标准，支持信息模型，适合复杂数据结构。
- MQTT：轻量级，适合边缘端到云端，需搭配JSON/Protobuf。
- REST API：MES系统常用，需考虑数据量大的情况下的性能。
5.2 数据模型建议
推荐使用ISA-95标准中的设备状态模型：
- 设备ID、时间戳、当前节拍（秒）、累计产量、报警代码、报警描述、报警级别。
- 报警级别建议分为：信息、警告、故障、紧急。
六、常见问题与排查
- 问题1：采集到的节拍忽大忽小。检查：PLC中是否有多工位交替信号？是否包含了非加工时间（如上下料）？
- 问题2：报警数据缺失。检查：PLC报警位是否保持？采集周期是否小于报警保持时间？
- 问题3：网络延迟导致数据滞后。解决：在边缘端增加缓存队列，使用QoS保证数据传输。
七、总结
自动线节拍与报警采集不是简单的“读寄存器”，而是需要从信号源、协议、边缘计算、数据模型到MES对接的全链路设计。建议项目初期先在一条典型自动线上试点，验证采集稳定性和数据准确性后再推广。Bit Factory 提供从边缘网关到MES对接的完整方案，帮助工程师快速落地。
