3. 数据采集系统架构
数据采集系统是工业互联网与智能制造的基础神经末梢，其架构设计直接决定了数据质量、实时性、可靠性以及后续分析与决策的深度。一个完整的采集链路通常由传感器、PLC/DCS、SCADA、边缘网关与云平台构成，各层职责不同、协议各异。理解这一分层架构，是进行协议解析与实战调试的前提。本章将逐层拆解各组件在数据链路中的角色、关键协议特征、数据流向及工程部署要点，并给出一个从传感器到云端的完整案例闭环。
上图展示了从物理世界到数字世界的完整数据通道。传感器负责感知物理量，PLC/DCS 负责设备级控制与数据汇聚，SCADA 承担厂级监控，边缘网关在靠近数据源的位置完成协议转换与预处理，云平台则进行全局存储与分析。值得注意的是，边缘网关与 SCADA 之间、SCADA 与云平台之间往往存在多条冗余链路，实际部署时需根据实时性、安全性和成本进行权衡。
3.1 核心原理：各层组件的职责与协议特征
数据采集系统的每一层都有明确的职责边界，同时通过标准或私有协议进行衔接。理解各层的核心原理，是进行协议解析的基础。
- 传感器层：负责将物理量（温度、压力、振动、流量、位移等）转换为电信号。常见输出形式包括 4-20mA 电流环、0-10V 电压、热电偶/RTD 电阻信号、以及数字接口（如 I2C、SPI、RS-485 输出的智能传感器）。该层协议简单，但信号易受干扰，需关注屏蔽、接地和量程校准。
- PLC/DCS 控制层：PLC 以高速逻辑控制为主，DCS 以过程控制为主。它们通过 I/O 模块采集传感器信号，并向上提供通信接口。主流协议包括 Modbus RTU/TCP、Profinet、EtherNet/IP、IEC 61850（电力）、OPC UA（跨平台互操作）。该层是数据采集的“第一跳”，数据质量直接影响上层应用。
- SCADA 监控层：SCADA 系统（如 WinCC、iFIX、Ignition）通过 OPC DA/UA 或厂商驱动从 PLC/DCS 读取数据，提供人机界面、报警、趋势记录。SCADA 通常具备历史数据库，但实时性要求高，数据刷新周期一般在 100ms~1s 之间。
- 边缘网关层：边缘网关是近年架构演进的产物，它部署在靠近 PLC 或 SCADA 的现场侧，支持多协议接入（Modbus、OPC UA、BACnet、MQTT），进行数据清洗、缓存、边缘计算（如阈值判断、简单滤波），并以 MQTT/HTTPS 方式上云。该层解决了“最后一公里”的协议碎片化问题。
- 云平台层：云平台（如 AWS IoT Core、Azure IoT Hub、阿里云 IoT）提供设备管理、消息路由、时序数据库（如 InfluxDB、TDengine）、流计算和机器学习服务。数据在云端进行长期存储、跨厂区分析、预测性维护等高级应用。
| 层级 | 典型设备 | 核心协议 | 数据粒度 | 实时性要求 |
|---|---|---|---|---|
| 传感器 | 变送器、编码器 | 4-20mA、HART、IO-Link | 原始物理量 | 毫秒级（取决于采样） |
| PLC/DCS | 西门子 S7-1500、罗克韦尔 ControlLogix | Modbus TCP、Profinet、OPC UA | 寄存器/变量 | 10-100ms |
| SCADA | WinCC、Ignition | OPC DA/UA、厂商驱动 | 过程值/报警 | 100ms-1s |
| 边缘网关 | 工业网关、边缘服务器 | MQTT、OPC UA、Modbus | 清洗后数据包 | 秒级（可缓存） |
| 云平台 | IoT Hub、时序数据库 | HTTPS、MQTT、WebSocket | 聚合/分析结果 | 分钟级（非实时） |
3.2 判断方法与操作流程：如何选择采集路径与协议
在实际项目中，工程师常面临“从哪一层取数”和“用什么协议”的决策。以下流程可帮助快速判断：
- 明确数据用途：若用于实时控制，必须从 PLC/DCS 直接读取（延迟 <50ms）；若用于生产报表，可从 SCADA 历史库取数；若用于远程监控或 AI 分析，则优先走边缘网关。
- 盘点现有设备接口：检查 PLC 是否支持以太网口、是否开放 Modbus TCP 或 OPC UA 服务。老旧设备可能只有串口（RS-485/Modbus RTU），需配置串口服务器或协议转换器。
- 评估网络环境：若现场网络不稳定，边缘网关需具备本地缓存和断点续传功能；若涉及跨区域组网，需考虑 VPN 或专线。
- 确定协议转换点：通常建议在边缘网关完成协议转换（如 Modbus TCP → MQTT），避免 SCADA 承担过多协议负担。若已有 SCADA 且数据质量良好，可直接从 SCADA 的 OPC UA 接口取数。
- 测试与验证：使用 Modbus Poll、UaExpert 等工具测试连通性，抓包分析报文（如 Wireshark 解析 Modbus TCP），确认字节序、寄存器映射和数据类型。
3.3 案例拆解：某汽车零部件工厂的数据采集改造
某汽车零部件工厂有 12 条装配线，每条线由 1 台西门子 S7-1200 PLC 控制，现场有约 300 个传感器（压力、位移、扭矩）。工厂原有 SCADA（WinCC 7.4）仅用于本地监控，管理层希望将设备 OEE 数据、工艺参数实时上传至集团云平台，进行跨厂区对比分析。
初始现象与约束：PLC 支持 Profinet 和 Modbus TCP，但 WinCC 的 OPC DA 接口无法跨网段访问；集团要求数据上传延迟不超过 5 秒，且需支持断网缓存；现场无专业 IT 人员，需简化运维。
关键输入数据：PLC 内 DB 块存储了 50 个关键变量（如循环时间、扭矩实际值、温度），每个变量为 32 位浮点数或整数；WinCC 已采集部分数据，但历史库仅保留 30 天。
分析判断过程：若从 WinCC 取数，需解决 DCOM 跨域问题，且历史数据粒度不够（WinCC 归档最小周期 1s）；若直接从 PLC 取数，需编写 Modbus 映射表，但 PLC 的 Modbus 地址与 DB 块映射需逐一核对，工作量较大。最终决定采用边缘网关方案：网关同时连接 PLC 的 Modbus TCP 端口和 WinCC 的 OPC UA 服务器（WinCC 7.4 支持 OPC UA 补丁），实现双通道冗余。
实际操作步骤：
- 在 PLC 中启用 Modbus TCP 服务，并创建地址映射表（将 DB100.DBD0 映射到 Modbus 40001 等）。
- 配置边缘网关（如 ThingsBoard Gateway 或工业网关），添加 Modbus TCP 从站和 OPC UA 客户端连接。
- 设置采集周期为 500ms，并配置本地 SQLite 缓存，当云平台不可达时自动存储数据。
- 在云平台创建 IoT Hub，使用 MQTT 协议接入，主题按“工厂/产线/设备/参数”分层设计。
- 部署后对比网关采集值与 WinCC 显示值，误差小于 0.1%，且上传延迟平均 1.2 秒。
结果与复盘：改造后，集团可实时查看 12 条线的 OEE 和工艺参数，并利用云端时序数据库训练预测性维护模型。但项目中也发现两个问题：一是 PLC 的 Modbus 映射表在 PLC 程序更新后需手动同步，容易遗漏；二是边缘网关的 4G 模块在工厂屏蔽区信号弱，导致断网缓存频繁触发。后续优化为：使用脚本自动生成映射表，并增加外置天线。
3.4 常见误区与总结复盘
在数据采集系统架构设计中，工程师常陷入以下误区：
- 误区一：所有数据都从 PLC 取。实际上，SCADA 已经做了报警处理和量程转换，直接取 SCADA 数据可减少重复计算，但需注意 SCADA 的刷新周期可能成为瓶颈。
- 误区二：忽略时间同步。各层设备时钟不一致会导致数据时间戳错乱，尤其在分析故障时序时无法还原真实顺序。建议部署 NTP 服务器，确保 PLC、网关、服务器时间同步。
- 误区三：协议网关“万能论”。边缘网关虽然能转换协议，但无法解决设备本身的数据质量问题（如传感器漂移、PLC 扫描周期抖动）。网关只能做格式转换，不能做物理量补偿。
- 误区四：忽视网络安全。直接暴露 Modbus TCP 到公网风险极高，应通过 VPN 或边缘网关的防火墙功能隔离。
总结复盘：一个健壮的数据采集架构应遵循“分层解耦、冗余互备、协议标准化”原则。传感器层关注信号完整性，控制层关注实时性，SCADA 层关注可视化，边缘层关注协议转换与缓存，云平台关注数据价值挖掘。在实际项目中，建议先绘制数据流图，明确每个节点的协议、数据项、刷新周期和故障处理策略，再进行设备选型和调试。协议解析的功夫不仅在报文本身，更在于对整个链路时序和语义的深刻理解。