MES系统的工业物联网数据管道设计：从PLC/SCADA到实时OEE看板的全链路架构

Mon, 27 Jul 2026 20:00:00 +0800

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

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

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

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

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

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

特征	表现	对系统的挑战
高频	PLC 以 100ms~1s 的周期上报数据	写入吞吐量要求高，存储成本需要控制
高噪	传感器漂移、信号抖动、通信中断	需要清洗、去噪、断点续传
高异构	Modbus/Profinet/OPC UA/EtherCAT 混用	协议适配层必须足够灵活
低语义	原始数据是寄存器地址和数值	需要上下文注入（设备、工位、产品）才有业务含义

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

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

二、全链路架构总览

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

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

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

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

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

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

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

品牌	典型系列	原生协议	OPC UA 支持	数据刷新周期
Siemens	S7-1500	Profinet / S7 协议	内置（固件v2.5+）	1~100ms
Allen-Bradley	ControlLogix	EtherNet/IP / CIP	需网关或固件升级	10~100ms
Mitsubishi	iQ-R	MELSEC 协议 / CC-Link	需外部 OPC Server	10~500ms
Omron	NX/NJ	EtherNet/IP / FINS	部分型号内置	1~10ms
汇川/信捷	H5U/XDH	Modbus TCP/RTU	无原生支持	10~100ms

一个经常被低估的问题：同一车间往往混用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 读到云端？

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

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

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

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

维度	OPC UA	MQTT
定位	设备到边缘（南向）	边缘到云端（北向）
通信模型	客户端-服务器 + 发布-订阅	发布-订阅（轻量）
信息模型	强类型、面向对象、自带语义	纯消息体，语义靠约定
安全	证书 + 加密 + 认证，内建	TLS + Token，相对简单
适用场景	车间内部设备互联	跨网络、跨地域数据上报

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

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

中间件	核心优势	适用场景	工业场景局限
Apache Kafka	超高吞吐、持久化、回溯消费	数据湖入口、流处理管道	运维复杂、小消息开销大
EMQX	MQTT 原生、百万连接、规则引擎	设备接入层、轻量级消息路由	不具备 Kafka 的流处理能力
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 主流时序数据库对比

数据库	写入性能	压缩率	SQL 兼容性	集群能力	生态集成	适合场景
TDengine	极高（百万点/秒）	高	兼容 SQL	原生集群	Grafana/DataX/Flink	大规模工业采集
InfluxDB	高	中高	InfluxQL/Flux	企业版集群	Grafana/Telegraf	中小规模通用
TimescaleDB	中高	中	完全 SQL	依赖 PostgreSQL	PG 生态	已有 PG 基础设施
IoTDB	高	高	自有 SQL	原生集群	Flink/Spark	开源+Apache 生态
QuestDB	极高	中	SQL	企业版	Grafana	低延迟分析

国内制造业项目中，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 计算的前提是准确的设备状态。这需要在流处理引擎中维护一个设备状态机：

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

状态机的实现要点：

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

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

方案	优势	劣势	适用规模
Apache Flink	精确一次语义、状态管理强、窗口计算灵活	学习曲线陡峭、运维复杂	大规模（百台设备+）
Kafka Streams	轻量、与 Kafka 天然集成	窗口和状态管理能力弱于 Flink	中等规模
自研微服务	完全可控、业务定制灵活	一致性保障靠自己做、重复造轮子	小规模、快速验证
规则引擎（Drools/EMQX Rule）	配置化、业务人员可维护	复杂计算能力有限	简单规则场景

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

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

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	极高	中（插件生态）	快速搭建、工程团队自用
Superset	高	中高	数据分析导向、多数据源
自研前端（React/Vue + ECharts）	低	极高	面向客户的商业产品
低代码平台（宜搭/明道云）	高	低	简单场景、快速验证

实际项目中的常见组合：工程团队内部用 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 台设备）的离散制造企业：

层级	技术选型	说明
设备接入	Kepware / Ignition Edge	成熟的工业 OPC 网关，支持 150+ 驱动
边缘协议	OPC UA → MQTT (Sparkplug B)	Sparkplug B 定义了标准化的工业 MQTT Payload
MQTT Broker	EMQX Enterprise	百万级连接，内建规则引擎桥接 Kafka
消息总线	Apache Kafka (3 Broker)	持久化、回溯消费、精确一次语义
流处理	Apache Flink	设备状态机、OEE 实时计算、异常检测
时序存储	TDengine	超级表建模，高压缩比，SQL 兼容
关系存储	PostgreSQL	主数据、配置、审计日志
看板前端	React + ECharts / Grafana	大屏自研，工程看板用 Grafana
监控运维	Prometheus + Grafana	管道本身的健康监控

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

十三、写在架构之外

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

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

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

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

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

OPC UA on 文艺技术笔记