一、引子：一个差点出事的场景

我在做一个智能生产线MES项目时，遇到一个让我重新思考「安全设计」边界的问题。

场景是这样的：门扇组对点焊工序的码垛机器人，动作区域正好在WMS立库的某个库口位置。当机器人运行时，MES必须停止调度出料筐，防止料筐运行到库口与机器人发生碰撞。

客户的第一反应是：「让MES在机器人运行时锁定库口，不调度出料筐不就行了？」

听起来很合理，对不对？MES控制业务流转，检测到机器人正在运行，就发个指令让WMS停止出库。

但仔细一想，这个方案存在一个根本性的问题——它把安全联锁交给了业务系统。

二、为什么安全点位不适合走MES/上位机？

1. 延时不可控

拿我们这套系统举例，一个信号从发出到执行，要经过的链路是：

产线PLC → KingIOServer → KingFusion（MES系统） → WMS → WCS→立库PLC → 执行机构

中间多少个环节？六个。每个环节都有处理延迟、网络延迟、队列等待。

在工业控制中，安全联锁的响应时间要求是毫秒级的。而经过MES这一套链路，延迟轻松到几百毫秒甚至秒级。对码垛机器人来说，几百毫秒已经足够完成一次碰撞了。

2. MES不是实时系统

这一点很多人容易忽略：MES是业务管理平台，不是实时控制系统。

MES的定位是生产执行管理——工单流转、质量追溯、数据统计。它的架构设计就不是为实时控制而生的。把安全联锁交给MES，等于让一个搞行政的去管工厂安保——不是不能管，但真出事了反应不过来。

3. 断连风险是致命缺陷

MES系统可能因为以下原因断连：

• 服务器重启/维护

• 网络中断

• 数据库连接池满

• 上位机蓝屏

一旦MES或上位机断连，安全联锁就失效了——机器人该停的时候没停，料筐照常出库，结果就是撞车。

安全联锁必须无条件执行，不能依赖某个系统是否在线。

三、正确的做法：底层PLC直连

最终我们给出的方案是：安全点位走底层PLC直连。

具体来说，组对点焊工序的PLC直接与WMS立库的PLC进行通讯，通过硬接线或现场总线（Profinet/Profibus）交换安全信号。

正确方案（安全联锁）	错误方案（业务管控）
组对PLC  →Profinet → 立库PLC → 执行机构	产线PLC → KingIOServer → KingFusion（MES系统） → WMS → WCS→立库PLC → 执行机构
毫秒级响应	秒级响应，有断连风险

这样设计的优势：

对比维度	底层PLC直连	MES上位机管控
响应速度	毫秒级	百毫秒~秒级
可靠性	不依赖上位机/网络	依赖中间环节正常
安全性	硬接线/现场总线，物理隔离	软逻辑，有断连风险
维护成本	低（固化在PLC程序）	高（多个系统协作）

四、这个原则能推广到什么场景？

这个原则其实适用于所有工控项目的安全设计：

安全相关的信号，层级越低越好，越直接越好。

这和SCADA项目中的老规矩一脉相承——急停信号必须硬接线，不能走通讯。为什么？因为通讯协议可能丢包、可能延迟、可能断连。硬接线是物理层，不依赖任何软件栈。

类似的操作还有：

• 安全光栅 → 直接接入PLC的急停输入模块，不走上位机

• 限位开关 → 硬接线到PLC输入，不走任何中间协议

• 安全门锁 → 串联到安全回路，独立于控制系统

五、给MES工程师的几点建议

1. 明确职责边界

MES工程师容易犯的一个错误是：什么功能都往MES上堆。

MES负责业务流转（工单、质量、追溯、报表），PLC负责实时控制（运动控制、逻辑联锁、安全保护），各司其职。在接需求时，先判断这个功能属于哪个层级——如果是安全联锁类的，坚决推到底层去做。

2. 在需求阶段就划清界限

当客户说「让MES在机器人运行时锁住库口」时，要能解释清楚为什么不建议这么干，并给出替代方案（PLC直连）。不要等到实施阶段才发现安全联锁走MES太慢，那时候改方案成本就高了。

3. 安全设计不能凑合

工控项目的安全设计，没有「差不多就行」这一说。一次撞车事故的损失，可能远超整个MES系统的造价。在安全设计上，用最笨、最可靠、最底层的方式，往往就是最好的方式。

六、总结

• MES不要做安全联锁——响应速度不够、可靠性不足、有断连风险

• 安全信号走底层PLC直连——毫秒级响应、不依赖上位机、物理隔离

• 安全设计原则：层级越低越可靠——硬接线 > 现场总线 > 上位机通讯 > MES管控

• MES的职责边界要清晰——管业务，不管安全联锁

不是所有功能都适合往MES上堆。MES负责业务流转，PLC负责实时控制——知道什么时候该放手，比知道什么时候该接手更重要。