在制造业数字化转型的深水区，真正的瓶颈往往不是「有没有系统」，而是「数据能不能流起来」。

一个典型的离散制造车间里，PLC 控制器每秒产生上千个数据点，SCADA 系统管理着数百条报警规则，而管理层渴望看到的是——一块实时跳动的 OEE（设备综合效率）看板，告诉他们哪条产线在浪费产能、哪台设备正在拖后腿。

问题在于，从 PLC 寄存器里的一个布尔量，到看板上那个百分比数字，中间隔着协议转换、边缘聚合、消息队列、流式计算、时序存储等至少六七层技术栈。每一层的设计选择都会影响数据的实时性、可靠性和系统的可维护性。

本文尝试把这条数据管道从头到尾拆开，讲清楚每一层为什么这样设计、有哪些工程上的取舍。

一、问题的本质：车间数据的「三高一低」

制造车间的数据特征可以概括为「三高一低」：

有句话说得好：制造业的数据工程师，一半时间在跟协议打交道，另一半时间在跟脏数据打交道。

理解了这四个特征，后面的架构选型就不再是纸上谈兵——每一个技术决策都有它对应的现实约束。

二、全链路架构总览

在展开每一层之前，先看全貌。一条完整的数据管道大致分为六层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

┌─────────────────────────────────────────────────┐
│  第六层：可视化与决策（OEE看板 / 报警 / 报表）      │
├─────────────────────────────────────────────────┤
│  第五层：实时计算引擎（OEE计算 / 异常检测 / SPC）    │
├─────────────────────────────────────────────────┤
│  第四层：时序数据存储（TDengine / InfluxDB / TSDB）  │
├─────────────────────────────────────────────────┤
│  第三层：消息中间件（Kafka / EMQX / RabbitMQ）       │
├─────────────────────────────────────────────────┤
│  第二层：边缘计算网关（协议转换 / 数据清洗 / 聚合）   │
├─────────────────────────────────────────────────┤
│  第一层：设备层（PLC / SCADA / 传感器 / 仪表）       │
└─────────────────────────────────────────────────┘

每一层都不是"有了就行"，而是需要回答三个问题：为什么需要它？它解决什么问题？它的边界在哪里？

三、第一层：设备层——数据的源头

3.1 PLC：车间的「神经末梢」

PLC（Programmable Logic Controller）是车间里最忠实的数据生产者。它不管你想不想听，都在忠实地按照扫描周期刷新自己的输入/输出映像区。

主流 PLC 品牌的数据接口能力差异很大：

一个经常被低估的问题：同一车间往往混用3~5个品牌的PLC。新建产线可能统一用 Siemens，但老产线上可能还跑着 Mitsubishi FX 系列甚至更老的型号。数据管道的第一道难题就是异构适配。

3.2 SCADA：不只是「上位机」

很多人把 SCADA（Supervisory Control and Data Acquisition）简单理解为"上位机监控软件"。实际上，在现代工厂里，SCADA 扮演的角色远比这复杂：

• 实时数据库角色：SCADA 内部的 Tag 数据库本身就是一个轻量级的时序数据缓存，WinCC、iFix、InTouch 的实时库可以支撑数万点位的秒级刷新
• 报警管理角色：设备故障、工艺越限等事件，通常由 SCADA 的报警引擎产生和确认
• HMI 交互角色：操作工在触摸屏上的操作（换型、确认、报工）也是重要的业务事件

在数据管道设计中，SCADA 既可以是数据的「中转站」（从 SCADA 的 OPC Server 取数），也可以被绕过（直接从 PLC 取数），这取决于项目的具体情况。

从 SCADA 取数的优势：协议统一（OPC DA/UA），开发量小，报警事件现成可用。

绕过 SCADA 直接取数的场景：SCADA 授权费用过高、SCADA 系统老旧不支持 OPC UA、需要更高采集频率（超过 SCADA 的扫描周期）。

3.3 传感器与仪表：被忽视的数据源

除了 PLC 控制的设备，车间里还有大量独立传感器和仪表：

• 温湿度传感器（Modbus RTU）
• 电表/气表（Modbus/DL/T645）
• 振动传感器（4-20mA 经采集模块转 Modbus）
• RFID 读写器（TCP/IP 或串口）

这些设备通常不具备 OPC UA 能力，需要通过 Modbus 网关或专用采集模块接入。它们的数据频率低（秒级甚至分钟级），但对能耗管理、环境监控、物料追溯等场景至关重要。

四、第二层：边缘计算网关——协议统一与数据预处理

这是整条管道里「脏活累活最多」的一层。

4.1 为什么不能直接从 PLC 读到云端？

理论上可以，但工程上不建议，原因有四个：

1. 网络隔离：车间 OT 网络通常与 IT 网络物理隔离或设置 DMZ，直接穿透违反安全策略
2. 协议适配：PLC 说 Modbus、Profinet、EtherNet/IP，云平台说 MQTT、HTTP——需要翻译
3. 带宽控制：如果每台 PLC 每秒上报 100 个点位、每个点位 4 字节，100 台 PLC 就是 40KB/s、约 3.3GB/天的纯数据量，还不算协议开销
4. 断网容错：工厂网络不可靠，需要边缘侧缓存和断点续传

4.2 协议转换：OPC UA 与 MQTT 的分工

在工业物联网领域，OPC UA 和 MQTT 不是竞争关系，而是互补关系。一个常见的误解是"用了 MQTT 就不需要 OPC UA"。

OPC UA 解决的是"设备说的话能不能被标准化理解"的问题，MQTT 解决的是"数据能不能低成本、低带宽地传到云端"的问题。两者在架构中各守一段。

推荐的协议流：

1

PLC --[Modbus/Profinet]--> 边缘网关 --[OPC UA Client]--> 协议解析 --[MQTT Publish]--> 消息队列

4.3 边缘网关的选型考量

市面上边缘网关的形态很多，按定位可以分为三类：

工业级硬件网关（如 IOT2050、Neousys、研华 ICR 系列）：适合恶劣环境，宽温宽压，但算力有限，主要做协议转换和简单过滤。

边缘服务器方案（如 Dell Edge Gateway、联想边缘计算盒子）：算力更强，可以跑轻量级流处理、本地 AI 推理，适合需要边缘计算的场景。

软件定义网关（在工控机/IPC 上部署 Node-RED、Kepware、Ignition Edge 等软件）：灵活度最高，但运维复杂度也最高。

选型时的核心判断标准：

• 点位数量：1000 点以下用硬件网关，1 万点以上考虑边缘服务器
• 计算需求：只做协议转换还是需要在边缘跑规则引擎、异常检测
• 运维能力：工厂 IT 团队能否管理 Linux 服务器和容器

4.4 边缘侧的数据预处理

好的边缘网关不只是"传声筒"，它应该在数据上传前完成初步处理：

死区过滤（Deadband Filtering）：只上报变化超过阈值的点位，大幅减少无效传输。一个温度传感器在 25.0°C 和 25.1°C 之间跳动时，没有必要每秒都上报。

时间戳对齐：不同 PLC 的系统时钟可能有秒级偏差，边缘网关需要统一打上 NTP 同步后的时间戳。

质量标记：通信中断时，网关上报的数据应该携带质量标记（Good/Bad/Uncertain），而不是默默填充上一个值。

本地缓存与断点续传：网络中断期间，数据缓存在边缘（SQLite/RocksDB/文件），恢复后按时间顺序补传，确保时序连续性。

五、第三层：消息中间件——数据的「高速公路」

5.1 为什么需要消息中间件？

边缘网关可以直接写入数据库，但当系统规模扩大后，直连模式会暴露三个致命问题：

• 耦合：网关直接依赖数据库的可用性，数据库维护时整个采集中断
• 削峰：设备重启、产线换型瞬间会产生数据洪峰，直接写入可能压垮数据库
• 多消费者：OEE 计算、报警引擎、历史查询、AI 模型都需要消费同一份数据，直连模式下每个消费者都要独立接入

消息中间件解决的就是解耦、削峰和扇出。

5.2 Kafka vs EMQX vs RabbitMQ

在工业物联网场景下，三个常见选项的定位不同：

实战中常见的组合模式：

1

边缘网关 --[MQTT]--> EMQX --[Rule Engine Bridge]--> Kafka --[消费]--> 各下游系统

EMQX 负责 MQTT 协议接入和设备管理（连接/断线感知、ACL 鉴权），然后通过其内置的 Bridge 或 Rule Engine 将消息转发到 Kafka。Kafka 作为统一的数据总线，对接流处理引擎、时序数据库、数据湖等下游。

5.3 Topic 设计：工业数据的命名规范

MQTT/Kafka 的 Topic 设计直接影响系统的可扩展性。推荐采用 ISA-95 层级模型 来组织 Topic 命名空间：

1

{企业}/{工厂}/{车间}/{产线}/{设备}/{数据类型}/{具体点位}

示例：

1
2
3

acme/shanghai-stamp/body-shop/line-01/robot-07/status/joint_torque_j3
acme/shanghai-stamp/body-shop/line-01/robot-07/event/alarm
acme/shanghai-stamp/body-shop/line-01/robot-07/metric/cycle_time

这种命名的好处：

• 按层级订阅：想看整条线的状态，订阅 acme/shanghai-stamp/body-shop/line-01/#
• 权限隔离：不同工厂只能发布自己工厂 Topic 前缀下的消息
• 数据路由：Kafka Consumer Group 可以按 Topic 前缀分配不同消费逻辑

5.4 消息体格式：Avro vs JSON vs Protobuf

工业数据的消息体格式选型需要平衡可读性、紧凑性和 Schema 演进能力：

• JSON：人可读，调试方便，但体积大（约为二进制格式的 3~5 倍），无 Schema 约束
• Protobuf：紧凑高效，有 Schema，但调试时需要反序列化工具
• Avro：Schema 内建演进能力（前向/后向兼容），适合 Kafka + Schema Registry 的组合

实践建议：开发调试阶段用 JSON，生产环境切换到 Protobuf 或 Avro。边缘网关的计算资源有限时，JSON 的序列化开销可能成为瓶颈。

六、第四层：时序数据存储——为工业数据量身定制

6.1 为什么不用 MySQL/PostgreSQL？

这是很多项目初期最容易犯的错误。关系型数据库不是不能存时序数据，而是存不好：

• 写入瓶颈：时序数据是 append-only 的追加快节奏写入，MySQL 的 B+ 树索引在高并发写入下性能急剧下降
• 压缩率低：工业传感器数据（温度、压力、电流）相邻值高度相似，专用时序数据库的 Gorilla/Delta-of-Delta 编码可以将存储空间压缩到 MySQL 的 1/10~1/50
• 查询模式不匹配：时序查询的核心是"某设备某段时间内的某指标"，这是按时间范围扫描，不是按条件过滤——LSM-Tree 比 B+ 树更适合

6.2 主流时序数据库对比

国内制造业项目中，TDengine 和 IoTDB 的采用率在快速上升。TDengine 的超级表（Super Table）概念天然契合"同一型号设备共享 Schema、不同设备实例各有数据"的工业数据模型。

6.3 数据分层存储策略

工业时序数据有一个显著特征：查询频率随时间急剧衰减。最近 7 天的数据可能被频繁查询，30 天前的数据偶尔用于报表，一年前的数据几乎只用于审计。

分层存储策略：

1
2
3

热数据（0~7天）   →  SSD + 内存缓存    →  支持毫秒级查询
温数据（7~90天）  →  HDD              →  支持秒级查询
冷数据（90天+）   →  对象存储/压缩归档  →  按需加载

TDengine 和 InfluxDB 都支持数据保留策略（Retention Policy），可以自动执行数据过期删除。但归档到对象存储这一步通常需要自己写 ETL 任务。

七、第五层：实时计算引擎——OEE 的计算心脏

7.1 OEE 的三个因子

OEE = 可用率 × 性能率 × 良品率

看起来公式简单，但要实时计算这三个因子，需要解决的问题比想象中多得多：

可用率 = 实际运行时间 / 计划运行时间

• 计划运行时间来自排产系统（MES/APS），需要与班次日历、换型计划联动
• 实际运行时间的判定依赖设备状态机的实时切换（运行/待机/故障/换型/停机）
• 短暂停机（<5分钟）的捕捉是个难题——如果 PLC 没有主动上报短暂停机事件，需要从"零产量持续 N 秒"来推断

性能率 = (实际产量 × 理想节拍时间) / 实际运行时间

• 理想节拍时间（Ideal Cycle Time）是工艺参数，来自工艺数据库或 MES 的工艺路线配置
• 实时产量需要基于计数传感器或工位通过信号来计算
• 小停机（Minor Stop）和速度损失（Reduced Speed）需要区分

良品率 = 合格品数量 / 总产量

• 质检结果往往有延迟——生产是实时的，但质检可能在数小时后才完成
• 在线检测（视觉检测、称重分选）可以实时提供良品信号，离线检测只能事后修正

7.2 设备状态机：OEE 计算的基石

所有 OEE 计算的前提是准确的设备状态。这需要在流处理引擎中维护一个设备状态机：

1
2
3
4
5
6
7
8
9

                    ┌─── 计划停机（保养/换班）
                    │
运行中 ──停机信号──→ 故障停机
  │                  │
  │                  ├─── 短暂停机（<5min）
  │                  │
  ├──换型信号──→ 换型/调试
  │
  └──无订单──→ 待机/空闲

状态机的实现要点：

• 互斥性：任何时刻设备只能处于一个状态，状态切换必须有明确的事件触发
• 优先级：同时收到多个信号时（故障 + 换型），故障优先级最高
• 超时保护：如果进入某状态后长时间没有收到状态切换信号，应有超时兜底逻辑
• 手动覆盖：允许操作员通过 HMI 或 MES 手动修正设备状态（传感器无法区分的场景）

7.3 流处理引擎选型：Flink vs 自研 vs 规则引擎

对于中大型制造业项目，Flink 是最稳妥的选择。它的 Event Time 语义和 Watermark 机制，天然适合处理工业场景中"数据迟到"和"乱序到达"的问题——边缘网关断网重连后补传的数据，Flink 可以正确归入历史时间窗口重新计算。

7.4 OEE 计算的 Flink 作业设计要点

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

MQTT/Kafka Source
       │
       ▼
[设备状态事件流] ──→ [状态机 Processor] ──→ [状态时长聚合窗口] ──→ 可用率
       │
       ▼
[产量计数事件流] ──→ [节拍匹配 Join] ──→ [产量效率窗口] ──→ 性能率
       │
       ▼
[质检结果事件流] ──→ [延迟关联] ──→ [良品统计窗口] ──→ 良品率
       │
       ▼
[OEE 合成算子] ──→ 写入时序库 / 推送看板

几个工程细节值得注意：

状态持久化：Flink 的 State Backend 选择 RocksDB（持久化到磁盘），防止 JobManager 故障重启后丢失设备当前状态。

迟到数据处理：质检结果可能延迟数小时，Flink 的 Allowed Lateness + Side Output 机制可以将迟到数据单独处理，不影响实时计算的主流程，但可以在事后修正 OEE 数值。

多粒度聚合：OEE 需要按设备、产线、车间、班次等多个维度同时计算。Flink 的 Keyed Window 可以按设备聚合，但跨设备汇总到产线级别需要额外的 Reduce 算子。

八、第六层：可视化与决策——让数据被看见

8.1 OEE 看板的设计原则

看板不是"把所有数据堆上去"。好的 OEE 看板遵循三层递进原则：

第一层：态势感知（3 秒内获取全局信息）

• 所有设备/产线的 OEE 数值和状态灯（绿/黄/红）
• 当前班次目标 vs 实际产量的进度条
• 最严重的 Top 3 异常

第二层：定位问题（30 秒内找到根因方向）

• 选定设备的 OEE 三因子拆解（可用率/性能率/良品率哪个在拖后腿）
• 设备状态甘特图（过去 8 小时的状态分布）
• 故障/停机事件时间线

第三层：追溯细节（深入分析）

• 具体时段的过程参数趋势曲线
• 关联的工艺参数和质检结果
• 历史对比（同设备上周同期、同产品其他产线）

8.2 看板技术栈选型

实际项目中的常见组合：工程团队内部用 Grafana 快速验证数据管道是否正常，面向管理层和操作工的大屏则用自研前端——因为管理层需要的不只是图表，还有排产信息、绩效指标、行动建议等业务上下文。

8.3 实时性要求与推送机制

OEE 看板的刷新频率取决于谁在看：

• 车间大屏：5~15 秒刷新一次（WebSocket 推送），展示整线状态
• 管理者手机/PC：1~5 分钟轮询或推送即可，重点是趋势和异常通知
• 工程师调试界面：实时（100ms~1s），用于排查设备问题

推送机制推荐 WebSocket + SSE（Server-Sent Events） 的组合。WebSocket 用于双向交互（工程师主动查询设备详情），SSE 用于单向推送（看板被动接收更新）。

九、数据治理：管道里最容易欠的债

技术架构搭好后，真正决定系统能不能长期健康运行的，是数据治理——而这是大多数项目最容易忽略的部分。

9.1 点位管理（Tag Management）

一个中等规模的工厂可能有 5~10 万个数据点位。没有统一的点位管理规范，半年后就会陷入混乱：

• 同一个 PLC 地址在不同系统里叫不同的名字
• 点位含义只有最初配置的工程师知道，人员变动后变成「孤儿点位」
• 新增点位没有审批流程，随意添加导致命名冲突

建议建立点位注册表（Tag Registry）：每个点位有唯一的 ID、标准化的命名、清晰的描述、所属设备/系统的映射关系、数据类型和单位、采集频率和质量要求。这个注册表应该版本化管理，与 MES 的设备主数据联动。

9.2 数据质量监控

数据管道里最常见的问题不是"系统挂了"，而是数据悄悄变脏了：

• 传感器老化导致读数漂移（温度持续偏高 2°C）
• PLC 程序更新后地址映射变了（原来读电流值的地址变成了读速度值）
• 边缘网关重启后时间戳跳变（NTP 未同步）

需要建立数据质量的自动化巡检：

• 新鲜度检查：某点位超过预期频率未更新，触发告警
• 范围检查：数值超出物理合理范围（温度 < -40°C 或 > 500°C）
• 一致性检查：设备状态为"运行中"但功率读数为零，明显矛盾
• 完整性检查：预期有 N 个点位在上报，实际只收到 M 个（M < N）

9.3 主数据同步

OEE 计算依赖的主数据包括：

• 设备主数据：设备编号、型号、所属产线/工位、额定参数
• 产品主数据：产品编号、理想节拍时间、质量标准
• 排产主数据：班次日历、生产计划、换型计划

这些主数据通常散落在 ERP、MES、APS、PLM 等多个系统中。数据管道需要一个主数据同步层，确保 OEE 计算引擎在计算时引用的是最新、一致的主数据。

十、安全与合规：工业数据管道的底线

10.1 OT/IT 网络隔离

IEC 62443 标准定义了工业网络安全的层级模型。数据管道跨越 OT 和 IT 网络时，必须遵守以下原则：

• DMZ 架构：在 OT 和 IT 网络之间设置 DMZ，边缘网关部署在 DMZ 中
• 单向数据流：OT→IT 方向的数据流通过单向网关或严格白名单控制，IT→OT 方向的命令下发需要二次认证
• 最小权限：边缘网关对 PLC 只读（读寄存器），不写（不改参数），除非有明确的远程控制需求

10.2 数据加密与传输安全

• OT 内部：OPC UA 自带证书加密，Modbus 无加密（需要 VPN 或 VLAN 隔离补偿）
• OT→IT 跨越：MQTT over TLS 1.2+，设备证书 + 用户名密码双重认证
• IT 内部：Kafka 集群间通信启用 SSL，Schema Registry 启用 HTTPS

10.3 审计与追溯

所有设备状态变更、手动覆盖操作、系统配置变更都应该记录审计日志。在医疗器械、汽车、航空航天等受监管行业，这些审计日志是合规审查的硬性要求。

十一、工程落地的典型陷阱

陷阱一：过度采集

“先把所有能采的数据都采上来，以后再说用不用”——这是最常见的错误。结果就是存储成本飙升、数据管道拥堵、真正需要的数据反而被淹没在噪声里。

正确做法：从业务场景倒推采集需求。OEE 需要哪些数据？能耗分析需要哪些？质量追溯需要哪些？每个场景明确后，再汇总去重，形成最终的采集点位清单。

陷阱二：忽视边缘侧的运维

边缘网关分布在车间各个角落，不像服务器可以集中管理。如果运维工具不到位，一个网关故障可能需要工程师跑到现场插 U 盘重启。

正确做法：选型时优先考虑支持远程 OTA 升级、远程日志采集、远程配置下发的网关方案。K3s（轻量 K8s）+ GitOps 是目前比较成熟的边缘运维模式。

陷阱三：实时性期望不切实际

“我要毫秒级实时”——先问清楚：谁需要毫秒级？操作工在 HMI 上需要毫秒级响应，这个应该由 PLC + SCADA 本地闭环解决。OEE 看板需要毫秒级吗？15 秒刷新和 1 秒刷新对管理决策的影响微乎其微，但系统成本可能差 3 倍。

正确做法：按消费者分层定义实时性 SLA，而不是全链路统一追求最高实时性。

陷阱四：OEE 指标政治化

OEE 是一个诊断工具，不是绩效考核工具。一旦 OEE 数字与员工绩效挂钩，就会出现数据造假——手动修改设备状态、隐瞒短暂停机、虚报产量。

正确做法：OEE 看板定位给工程团队和管理层用于发现改进机会，而非惩罚操作工。自动采集的数据尽量不经人工干预，需要干预的地方留下审计痕迹。

十二、一条参考的技术栈组合

最后给一个经过多个项目验证的参考技术栈，适合中等规模（50~200 台设备）的离散制造企业：

没有银弹。每个工厂的 PLC 品牌组合、网络拓扑、团队能力都不一样。上面这张表是起点，不是终点。

十三、写在架构之外

技术架构解决的是"数据怎么流"的问题，但决定一个工业物联网项目成败的，往往是架构之外的因素：

业务目标的清晰度：是追求"看见"（数据采集 + 可视化），还是追求"优化"（数据驱动决策 + 闭环控制）？两者的投入和复杂度差一个数量级。

组织的配合度：IT 部门懂系统但不懂工艺，OT 部门懂设备但不懂软件。项目需要真正理解两端语言的"翻译者"——这个角色在国内制造业中极度稀缺。

渐进式推进：不要试图一步到位搭建完整的六层架构。从一条产线、几台关键设备开始，验证数据流通、OEE 计算、看板展示的最小闭环，再逐步扩展。先让数据流起来，再让数据产生价值。

制造业的数字化不是一场技术秀，而是一场持久战。数据管道是这场战役的后勤线——它不需要最炫的技术，但需要最扎实的工程质量。当所有数据都能准确、及时、可靠地从车间流到决策者面前时，改善才有据可依，优化才有迹可循。