1. 课程导入与架构总览
工业物联网（IIoT）数据采集，指的是把分布在车间、产线、设备、仪表和控制系统中的物理量、状态量与事件，通过传感、协议转换、边缘计算和网络传输，最终送达云端或数据中心，供监控、分析、优化和决策使用的一整套技术活动。它并不是“把数据读出来”这么简单，而是一条跨越现场层、边缘层、网络层、平台层和应用层的完整链路。理解这条链路的边界与分层，是后续所有架构设计工作的起点。
一、数据采集的定义与边界
从定义上看，工业物联网数据采集包含四个基本要素：采集对象（设备、传感器、PLC、仪表、机器人等）、采集方式（硬接线、现场总线、工业以太网、无线等）、数据形态（模拟量、数字量、寄存器值、报文、事件记录）以及数据用途（实时监控、历史存储、质量追溯、预测性维护、能耗优化）。
边界同样重要。数据采集的起点是“物理信号或设备内部状态”，终点是“可供上层应用消费的、带时间戳和语义的数据”。它通常不包含业务逻辑决策、工艺配方管理、ERP 订单处理等应用层功能，但必须为这些功能提供可靠、一致、可追溯的数据输入。换句话说，采集系统负责“把现场真实发生的事，准确、及时、不丢失地表达成数据”，而不是替业务系统做判断。
在实际项目中，边界模糊往往带来问题。例如，某条产线需要统计 OEE（设备综合效率），采集系统应提供设备运行/停机状态、产量计数、节拍时间等原始数据，而 OEE 的计算公式、班次划分、停机原因归类则属于应用层职责。若把业务规则下沉到采集层，会导致系统僵化、难以复用。因此，明确“采集层只做数据搬运与轻量预处理”这一原则，是架构设计的第一条纪律。
二、核心挑战
工业现场与 IT 环境差异巨大，数据采集面临几类典型挑战：
- 协议碎片化：Modbus、Profibus、Profinet、EtherNet/IP、OPC UA、CAN、BACnet 等并存，同一工厂内可能有十余种协议，且新旧设备混用。
- 实时性与确定性：部分场景要求毫秒级响应（如运动控制），而云端分析可能容忍秒级甚至分钟级延迟，采集架构必须分层满足不同时延要求。
- 数据质量与完整性：现场电磁干扰、网络抖动、设备重启都会造成丢包、乱序、重复或时间戳漂移，采集系统需要具备缓存、补传、去重和时钟同步能力。
- 安全与隔离：OT 网络与 IT 网络必须隔离，采集设备往往成为攻击入口，需要单向网关、白名单、证书认证等机制。
- 可扩展性与运维成本：产线增减、设备更换、点位调整频繁，采集配置应尽量模板化、可远程下发，避免每次改动都到现场重新接线或改程序。
三、端到端架构分层
为了应对上述挑战，工业物联网数据采集通常采用分层架构。下图展示了一条从现场设备到云端应用的典型端到端链路，包含现场层、边缘层、网络层、平台层和应用层五个层次，以及各层之间的关键接口与数据形态。
各层的职责可以概括为：现场层产生原始信号与设备状态；边缘层完成协议解析、数据清洗、时间戳对齐和本地缓存，是采集架构中最关键的一层；网络层提供可靠、安全、有时延保障的传输通道；平台层负责设备接入、物模型管理、时序存储和流式计算；应用层面向具体业务场景消费数据。数据自下而上流动，而配置、控制指令和模型更新则自上而下下发，形成双向闭环。
四、一个教学示例：三台设备的数据采集链路
假设某车间有三台设备：一台西门子 S7-1200 PLC（Profinet 接口）、一台支持 Modbus RTU 的温控仪表、一台通过 OPC UA 提供数据的数控机床。采集目标是把三台设备的运行状态、温度、主轴转速和报警事件上传到云端，采样周期分别为 100 ms、1 s 和 500 ms。
合理的做法是在车间部署一台边缘网关，运行协议驱动分别连接三台设备：S7-1200 通过 Profinet 读取 DB 块，温控仪表通过 RS-485 转 Modbus TCP 读取保持寄存器，数控机床通过 OPC UA 订阅节点。边缘网关统一为每个点位分配唯一标识（如 LINE1.PLC1.RUN_STATE、LINE1.TEMP01.PV、LINE1.CNC01.SPINDLE_SPEED），打上毫秒级时间戳，并按 1 s 聚合后通过 MQTT 发布到云端。若网络中断，网关本地缓存最多 24 小时数据，恢复后按时间顺序补传。云端平台按物模型解析后写入时序数据库，监控看板订阅实时流，预测性维护模块读取历史数据。
五、架构设计的三条基本原则
- 分层解耦：每一层只依赖下一层提供的标准接口，现场协议变化不影响平台和应用。例如，更换 PLC 品牌时只需替换边缘驱动，云端物模型和看板无需改动。
- 边缘优先：能在边缘完成的清洗、聚合、告警判断，不要全部推到云端。这既降低带宽成本，也提高实时性。例如，温度超过 85 ℃ 的告警应在边缘立即产生，而不是等数据上传后再判断。
- 数据可追溯：每个数据点必须携带设备标识、点位标识、时间戳和质量码（如 Good/Bad/Uncertain）。质量码用于标记因通信失败或传感器故障导致的异常值，避免上层应用把坏数据当成真实值使用。