一、方案概述
裁断机、针车缝纫机、定型机、压底机、注塑机、验布机——离散制造企业的核心产能都沉淀在这些设备上,但设备本身大多是"数据哑端":机器在转,米数在走,温度压力在变,报警灯在闪,而管理系统里只有人工事后补录的结果数据。客户的数字化调研给出过一句很直接的描述:设备运行参数无法自动上传系统,只能靠人工抄录成台账。这句话背后是一整条断裂的数据链,而且是普遍现象——不是某一类设备的问题,而是整个车间的共性问题。
本方案要解决的正是这一环。它以 MQTT 为统一数据主干,在设备侧做最小化改造,把各类生产设备与计量器具接入 AIoT 边缘工控盒,由边缘网关统一做协议转换与数据清洗,再以 MQTT 主题化上行,进入数据平台层的 Broker 与业务系统。同一套架构、同一套网关、同一套主题规划,可以复制到制鞋的裁断与成型工序、制衣的缝制与整烫工序、纺织面料的验布工序——设备类型不同,接入的数据通路是同一条。
一句话概括:一套 MQTT 数采底座,让全车间的生产设备数据自动上云。

二、总体架构:四层通用体系
整体架构分为四层:设备层、边缘数采层、数据平台层与 AI 应用层。四层的职责边界清晰,每一层只向上提供标准化的数据,不越层耦合。这样做的直接好处是:新接入一类设备,只需在设备层与边缘数采层补充对应的协议解析,数据平台层与应用层完全复用;任何一层扩容或替换不会牵动其他层。
表 2 四层体系与各层职责
层级 | 组成 | 职责 |
AI 应用层 | AI 视觉质检、智能排产、预测性维护、质量根因分析、预警推送(企业微信) | 把数据变成判定与动作:质量评分、异常预警、维保工单、优化建议,结果回写业务系统 |
数据平台层 | MQTT Broker、MES / ERP / IQC / 结算接口、数据中台与统一编码 | 汇聚全部机台数据、维护统一编码与业务规则,向上支撑应用层,向外对接 ERP 等业务系统 |
边缘数采层 | AIoT 工控盒(边缘网关)、Modbus/RS485/OPC-UA 等协议转换、工业相机与光源控制、传感器接入 | 把现场多形态协议转换成统一数据模型,本地缓存、清洗打标,断网时保证数据不丢 |
设备层 | 裁断机、针车缝纫机、定型机、压底机、注塑机、验布机、计长器、电子秤、打印机、工业相机等 | 产生原始计量、工艺、状态、质量信号,是全部数据的起点 |
自下而上看,设备层提供原始信号;边缘数采层负责"翻译"和"暂存";数据平台层负责"汇聚"和"分发";AI 应用层负责"判断"和"推送"。自上而下看,AI 应用与 MES、ERP 等业务系统共用同一条数据主干——这是本方案与"逐设备各自建一套系统"的做法最大的区别:计量数据、设备状态、质量结果走同一条链路、用同一套编码,不需要再做系统之间的对账。
在访问方式上,车间操作终端以 WiFi 或有线访问平台,既可走 HTTP 也可走 MQTT 双通道;车间大屏看板订阅 Broker 的实时主题;ERP 通过 IoT 模块对接;预警消息通过企业微信推送。多种终端共用同一个数据源,避免了同一份数据在多个系统里各存一份、各算一遍。

三、核心技术:为什么选择 MQTT
工业现场可选的通讯协议不少,选择 MQTT 的理由不是它"先进",而是它恰好匹配离散制造车间的三个现实约束:机台数量会持续增长、车间网络不一定稳定、现有业务系统不能被推翻重做。
(一)轻量发布订阅,天然支持多机台扩容
MQTT 采用发布/订阅模型,设备发布消息到主题,订阅方按主题接收,双方不需要知道彼此的存在。一台 Broker 可以汇聚全车间乃至全厂机台,新增一台设备或一个工段只需增加一个发布端,不需要改动订阅端。对于多产线并行作业、后续还要继续扩容的车间,这个特性直接决定了系统能不能平滑长大。
(二)QoS 分级与会话保持
MQTT 提供分级服务质量。方案对计量与工艺数据采用 QoS1,确保产量、尺寸、温度压力这类不可重算的数据至少送达一次,不因瞬时网络抖动丢失。配合会话保持,客户端重连后仍能接续原有订阅关系,不需要业务系统重新登记。
(三)断网续传
边缘网关在本地做缓存。当上行链路中断时,数据先落在本地,链路恢复后按原有时序续传。这一能力对计量数据尤为关键:一次计量的原始读数只有一次采集机会,丢了就补不回来。

(四)主题规划:从厂区到机台再到数据项
方案按三级主题组织数据,形如"业务域/厂区车间/机台/数据项"(例如 fabric/一车间/验布机03/米数,stitching/制鞋一部/针车12/转速)。第一级区分业务域或工序,第二级区分厂区与车间,第三级定位到具体机台,末级标识数据项。这样的结构既是寻址方式,也是权限与订阅边界:车间看板只订阅本车间的主题,集团看板订阅全部,AI 质检模块只订阅与图像、评分相关的分支。不同工序、不同设备类型的差异全部消化在主题命名规范里,平台侧逻辑保持统一。
(五)遗嘱消息报设备离线
客户端与 Broker 建立连接时可以登记遗嘱消息。一旦该客户端异常断开,Broker 立即代其发布遗嘱,业务系统据此判定设备离线并触发预警。这比"长时间没有数据就认为离线"的超时判断更及时,也避免了网络瞬时抖动造成误报。
(六)与现有系统兼容:HTTP/MQTT 双通道
车间操作终端访问平台时同时支持 HTTP 与 MQTT 两种通道:需要请求—响应语义的业务操作走 HTTP,需要实时推送的数据走 MQTT。现有基于 HTTP 的 MES、ERP 业务逻辑不需要推翻,可以在原基础上逐步切换到实时通道,属于平滑升级而不是推倒重来。
表 3 四步数据链路
环节 | 角色 | 做什么 | 关键点 |
第一步 | 现场设备 | 生产设备、仪表、传感器以 RS232 / RS485 / Modbus / 以太网接入,具备条件的直接读取设备自带接口 | 设备侧连接全部有线直连,不用无线 |
第二步 | AIoT 边缘网关 | 协议转换、数据清洗与打标(补机台号、时间戳、班次)、本地缓存、断网续传 | Ubuntu 24.04 / i5 十一代 / 8G 内存 / 6 串口,可按机台密度扩展 |
第三步 | MQTT Broker | 按三级主题分发;QoS1 保计量数据;遗嘱消息报离线 | 一台 Broker 汇聚全部机台,主题规范跨工序通用 |
第四步 | 业务应用 | 操作终端 WiFi/HTTP 访问、MES/ERP-IoT 模块、大屏看板、企业微信推送 | 多终端共用同一数据源 |
这条链路上每一环都可以独立观察:网关有连接与缓存状态,Broker 有主题与客户端状态,应用侧有数据入库时间。一旦某台设备的数据缺失,可以从网关一路查到业务系统,定位到具体环节,而不是笼统地说"系统没数据"。
