注塑车间设备报警数字化：从人工记录到云端闭环的落地思路

一、问题从哪来

注塑车间的设备报警长期依赖"人盯机"：机台报警灯亮，操作工按经验判断是缺料、模温异常还是液压超压，处理完在纸质点检表上记一笔。这种模式有三个直接损失：响应靠人是否在场、经验只存在老员工脑子里、报警数据无法回溯。一批不良品做完才发现工艺漂移，是注塑厂最常见的隐性成本。

二、采集层怎么落地

主流注塑机（海天、震雄、住友等）都提供通讯接口，按机龄分三种情况：

• 新机（近五年）：原生支持 OPC UA 或 MQTT，可直接对接，报警码、温度、压力、射胶时间都能读到。
• 中等年份：提供 Modbus TCP，需要按厂商寄存器表做点位映射，工作量集中在确认每个寄存器的缩放系数和字节序。
• 老机（无通讯口）：用电流互感器 + 三色灯采集器做"有无报警"的粗粒度判断，成本低但拿不到具体报警码。

采集端不建议直接上服务器，先在车间放一台边缘网关做三件事：协议转换（Modbus/OPC UA 转 MQTT）、断网缓存（本地存 24 小时以上）、报警码标准化（不同品牌统一成一套内部编码）。

三、上云用华为云 IoTDA 的几点实操

边缘网关通过 MQTT 接入华为云 IoTDA，设备侧重点是三个设计：

• 物模型先行：把"机台"定义为设备，"模温/料温/注射压力/报警码/循环时间"做成属性；报警做成事件，不要塞进属性，否则历史追溯会很难查。
• 报警分级：按可自恢复、需调机、需停机维修三档打标，规则引擎据此决定是推送班组群还是直接通知机修。
• 属性上报频率：工艺参数按 30 秒或按模次上报，报警按事件实时上报。全部高频上报会白白消耗消息量。

数据落到 IoTDA 之后，用规则引擎转发到 DWS 或直接进 OBS 做冷存，分析侧只关心三张表：机台运行状态、报警明细、工艺参数时序。

四、闭环怎么形成

数字化最容易死在"只采不用"。建议第一个月只做一件事：把报警响应时长可视化。谁处理、多久处理、同一报警在 7 天内是否重复出现，这三个指标一上墙，班组的处理习惯就会变。第二个月再做报警与不良率的关联分析，找出哪些报警会真正导致废品——大部分车间的结论是少数几类报警贡献了绝大多数损失。

五、总结

注塑车间的设备联网不追求一步到位。先把报警这件事做成"采集-分级-推送-闭环"的最小链路，验证三个指标，再往上叠工艺优化和预测性维护。链路没跑通就上算法，只会得到一堆没人看的看板。