车间里十二台AGV同时进入充电区紧接着一辆接一辆地往货梯口靠群里调度屏幕上的未处理呼叫瞬间堆到十几条电梯那边却只回了一句“busy”。这是我在工厂现场做过的高并发IoT项目里最典型的场景AGV要坐电梯跨楼层节点虽然不算多但呼叫是短时突发式的一旦处理不好整条产线的物流节奏全部卡死。今天想把这个基于MQTT与边缘计算的AGV梯控集成方案完整拆开讲一遍覆盖消息链路、主题设计、并发控制、边缘部署和现场排查给正在做同类项目的同学一个可以直接参考的落地版本。1. 先从现场约束说起AGV梯控为什么不能只靠云端1.1 梯控的真实并发模型不是百万级而是突发式耦合很多人一听“高并发IoT”第一反应就是百万设备同时上报数据。但工厂AGV梯控场景完全不是这个模型。我经手的项目里AGV数量在十几台到几十台之间电梯通常只有几部真正的压力来自“任务耦合”——十几台AGV几乎同时到达电梯口各自发出呼叫指令而电梯只有一个轿厢。这种并发特点是流量峰值持续时间短但消息之间强关联。如果处理不及时电梯响应慢了十秒AGV就可能在门口空等后面的AGV又会堵上来形成连锁拥堵。所以系统设计的关键不是每秒百万条消息的吞吐能力而是“短时间内的调度正确性和响应确定性”。还有一个隐藏约束AGV和电梯控制器都是存量工业设备。AGV自带调度系统电梯那边往往是老式的PLC控制柜配485总线或者简单继电器输出。想让电梯听懂MQTT要么改造电梯控制系统要么加一个边缘协议转换层。对大多数工厂来说改造电梯代价太高所以边缘计算节点的角色就变得不可替代。1.2 云平台方案在梯控场景中的三大硬伤先说明一下这里说的“云平台方案”是指AGV通过公网云服务直接呼叫电梯的方式比如把指令先发到阿里云或华为云的IoT平台再由云平台下发到电梯网关。理论上是通的但落到梯控现场有三个硬伤。第一是链路不确定。AGV在厂区里移动经过货架、设备、钢结构WiFi信号波动非常明显。呼叫指令走云端多一跳在信号差的角落可能从200ms变成2sAGV已经停在电梯口了云平台还在那儿处理。电梯对这种不确定延迟的容忍度极低因为电梯门开了要等你等不到就会超时关门AGV就进不去。第二是电梯控制协议碎片化。电梯品牌不同控制接口不同有走Modbus RTU的有走无源干接点的还有走私有TCP报文协议的。云平台没办法为每个电梯型号定制一套驱动就算能远程更新驱动的过程中一旦断连电梯控制逻辑可能停在中间态这是工厂安全绝对不允许的。第三是现场网络口径。不少工厂的办公网和生产网是物理隔离的AGV无线网络属于生产网生产网不允许任意设备访问公网。你让AGV直接上云先要过网络安全评审。大部分客户一听这个直接摇头宁可本地化。所以现阶段真正能交付落地的梯控方案普遍是“边缘闭环为主、云端同步为辅”要和我下面讲的MQTT加边缘计算架构结合起来看。1.3 边缘计算介入后的职责划分边缘计算在这个项目里负责三件具体的事接收AGV通过MQTT发布的电梯呼叫请求做本地排队和互斥判断把调度指令转换为电梯控制器认识的协议报文Modbus、485或干接点信号把电梯状态采集回来再通过MQTT反馈给AGV和云端。这就形成了一个本地闭环AGV发布消息到Broker边缘节点从Broker订阅到消息经过调度逻辑控制电梯动作电梯回到位后再上报状态。整个过程不依赖公网延迟稳定在几十毫秒级别。云端在我的设计里退居二线只做三件事数据汇总、异常报警、长周期调度优化。AGV梯控这种对实时性敏感的业务让边缘节点做决策主战场云端做观察者这个分工比全都丢给云端合理得多。2. 系统骨架MQTT主题树、边缘网关与消息流转设计2.1 MQTT Broker选型与部署位置Broker是整个系统的消息中枢。项目规模不大时我自己用Mosquitto就能扛住单机几万连接没压力AGV几十台的场景完全是杀鸡用牛刀。但如果工厂未来要扩展AGV数量到一两百台或者有多车间统一调度需求建议直接上EMQX集群分片部署在产线边缘机房。部署位置必须和生产网在同一网段。我踩过一个坑最开始把Broker放在办公室网络AGV无线网络和生产网之间有防火墙规则虽然能通信但延迟抖动很厉害高峰期丢包率飙到5%。后来把Broker挪到生产网的核心交换机旁边延迟从平均80ms降到了10ms以内。梯控指令这种消息Broker离现场越近系统越稳。边缘节点也主要部署在电梯控制柜附近的边缘盒子或者和电梯网关同机房部署它同时扮演MQTT客户端和协议转换端两个角色和Broker之间保持长连接。2.2 主题树的命名与访问控制设计MQTT主题树设计直接影响系统的可维护性和安全边界。我给出一个经过现场验证的示例结构factory/{plant_id}/agv/{agv_id}/call factory/{plant_id}/agv/{agv_id}/ack factory/{plant_id}/agv/{agv_id}/status factory/{plant_id}/elevator/{elevator_id}/dispatch factory/{plant_id}/elevator/{elevator_id}/status factory/{plant_id}/edge/{edge_node_id}/event每个主题层级都携带语义factory后面的plant_id用于多车间隔离agv_id定位到具体车辆elevator_id定位到具体电梯。这样后续做权限控制既方便又清晰。主题访问控制是所有现场项目都不能跳过的步骤。AGV客户端只允许发布“call”主题和订阅自己的“ack”主题边缘节点才有权限发布“dispatch”。否则一旦某台AGV的发布逻辑写错把消息发到了电梯的dispatch主题就可能出现共享单车锁被随意打开的问题。实际做法上EMQX可以启用ACL规则Mosquitto也可以配置password_file和acl_file不要嫌麻烦。2.3 消息格式定义与版本管理梯控消息的payload格式我统一使用JSON虽然比二进制协议多几十个字节但现场调试方便云端解析也容易。AGV呼叫电梯的消息体大致是这样{ command_id: a3f2c1e8-6b4d-4f2e-9f35-9c8e7d6a2b1f, agv_id: AGV-07, timestamp: 1735689600000, target_floor: 3, call_type: standard, priority: 5, sequence: 42 }这里有个关键字段command_id。它是一次呼叫请求的全局唯一标识AGV因为网络原因重发消息时会复用同一个command_id边缘节点靠它做去重避免重复分配电梯。sequence字段是同一AGV的递增序号用来辅助校验消息顺序防止旧消息晚到覆盖新状态。所有主题的payload接口建议定义好版本字段即使现在不用也可以先保留。梯控系统往往要运行很多年后期增加“VIP优先通道”或“跨楼层连续搬运”功能时没有版本控制就只能在原来的JSON上加字段加到最后新旧客户端互相看不懂那个痛我体会过。2.4 QoS、保留消息与遗嘱消息的分工MQTT的QoS级别按消息类型分开设置不要一套用到底。呼叫指令QoS 1。至少送达一次避免AGV发出呼叫Broker却没收到。状态反馈QoS 0。电梯状态是周期性上报的丢一帧下一帧马上就来不必多耗资源。调度指令QoS 1。边缘节点发给电梯控制器的指令不能丢。遗嘱消息QoS 1且消息内容要能被边缘节点理解并触发清理动作。电梯的状态通道要打开保留消息比如边缘节点启动后新接入的AGV订阅电梯状态主题时能立刻收到电梯当前位置、门状态、是否空闲而不必等下一个上报周期。这个细节在现场非常实用。AGV的在线状态用遗嘱消息实现。AGV异常断电时MQTT连接断开Broker自动发布遗嘱消息到状态主题边缘节点订阅后就能立刻知道某台车掉线了然后把它在等待队列里的任务清理掉同时释放它占用的电梯。如果没有这层机制死掉的AGV会一直占着电梯队列系统会慢慢堵死。3. 从呼叫到动作AGV呼叫电梯的完整业务链路3.1 呼叫发起与确认用发布-订阅模式搭命令管道AGV靠近电梯口后通过中控系统或车载PLC调用MQTT客户端携带完整的command_id发布到该车的“call”主题。边缘节点订阅了所有AGV的“call”主题收到消息后立刻在本地生成一条排队记录然后回一条“ack”给AGV告诉它“呼叫已收到请保持当前位置”。这个ack动作很多人会忽略直接在电梯到了才回消息。实际上AGV的等待策略是基于确认的如果几秒内没收到ackAGV就会重发呼叫甚至报错停车。所以边缘节点处理呼叫的第一动作一定是确认再进调度逻辑能减少很多现场误报。我还会在ack消息里带上排队序号和预计等待时间。这样AGV本地可以有更好的显示逻辑调度中心也能知道哪台车排在哪个位置。预计等待时间的算法可以很简单当前队列里前面的任务数乘以单次平均电梯使用时长。3.2 边缘节点上的排队与互斥调度边缘节点是整个调度系统的“大脑”。它维护两部电梯、一条调度状态表核心数据结构可以理解为每个电梯对应一个任务队列每个任务绑定一个AGV。调度器按规则从队列头部取任务然后向对应的电梯控制器发送动作指令。这里的互斥逻辑很关键同一时刻一台电梯只能分配给一个任务。多台AGV同时喊同一部电梯时调度器必须做仲裁不能因为MQTT消息是并发的就把电梯拆成两半。我的实现是边缘节点内的调度服务加一个全局锁所有分派操作串行化处理。并发量少时这种简单方法最可靠。队列规则我会用“优先级优先同级别先进先出”。生产系统里有些AGV运的是急料有些是返空托盘急料任务priority字段给到高值调度器优先分派。后续如果需要更复杂的路径优化可以引入权重队列但第一版不建议做太复杂先把互斥和确认闭环做好。3.3 电梯侧协议转换从MQTT到Modbus再到动作电梯控制器大概率不认识JSON。边缘节点调度器确定任务后通过协议适配器把指令转成电梯侧能执行的信号。最常见的是Modbus RTU走485总线协议适配器向PLC写入寄存器比如目标楼层寄存器、呼叫登记寄存器、电梯运行方向寄存器。写寄存器后边缘节点还要持续读取电梯状态寄存器确认电梯开始关门、开始动、到达楼层、开门到位。这中间每一步都有明确的状态码。电梯是特种设备不能直接把“到达”这个状态交给AGV必须等待“门开到位”再通知AGV进入。实际项目里门到位信号是硬接线光电开关或PLC输入点位提供的可靠性远高于纯软件判断。这部分还有一个容易出错的点电梯本身就自带调度系统比如电梯按键呼叫的楼层停靠逻辑。如果外部接入指令和电梯内召信号冲突会出现电梯被内部乘客按走的场景。所以边缘适配器在发指令的同时还要根据电梯实时状态判断“当前能否接受外部呼梯”比如检测到轿厢内有内召信号或满载信号时暂时挂起外部调度。这是对接电梯厂家时最需要拉通的一个点。3.4 状态回传与任务闭环电梯按指令动作完成、门开到位后边缘节点更新电梯状态并发布状态消息到“status”主题同时向对应AGV发布“ack”主题的下一条消息内容为“预约完成请进电梯”。注意这里用的是“预约”而不是“强制命令”。AGV收到消息后自行判断是否满足进入电梯的条件比如车宽和门宽、载重安全。确认进入电梯后AGV可以再发一条“confirm_in”消息边缘节点收到后调度器才认为这个任务真正进入执行状态电梯才能按AGV选择的楼层启动。任务闭环一定要清楚呼叫→排队→分派→电梯动作→AGV进入→电梯到达→AGV驶出→释放电梯。每个环节都有消息事件每个事件都带同一个command_id后续出问题排查时可以按command_id串起整条链路非常高效。4. 高并发防冲撞队列优先级、去重与故障恢复4.1 并发模型为什么纯FIFO不够用纯FIFO看起来公平但在AGV梯控场景容易出问题。假设A车呼叫3层B车呼叫5层两部电梯都不是空闲状态纯FIFO先把A排到1号电梯B排到2号电梯结果A车的位置实际上离2号电梯更近B车离1号电梯更近两车都绕了远路。所以我在调度模型里加入了“就近分配”逻辑。边缘节点维护每部电梯的当前位置和每台AGV的等待位置分派时优先选择“电梯到AGV距离AGV到目标楼层时间”综合代价最小的电梯。这个计算不复杂但比纯FIFO合理很多。当然优先级还是要保留。现场总有“这个物料必须马上送”的插队需求。实现方式是在任务结构体里加priority字段调度器每次从非空队列中挑priority最大的任务同priority时再按时间戳排序。注意插队要保护不能让高优先级任务无限推迟低优先级任务可以设置最大等待阈值超过阈值的任务自动提升优先级。这个机制在长尾拥堵时特别有用。4.2 防止“一呼多应”与重复分派MQTT的QoS1协议天然有重复消息的可能一个呼叫被重复执行就可能导致两辆AGV争抢一部电梯。防重复分派有两道防线。第一道防线是command_id去重。边缘节点保存最近N条已处理command_id的LRU缓存。每次收到呼叫消息先查缓存存在就直接回ack并提示“重复呼叫”不重复排队不存在才进入队列。这能拦截QoS1重发和AGV业务层重试导致的重复请求。第二道防线是边缘节点内的分配操作原子化。分配电梯的动作必须和更新电梯状态在同一个事务里完成要么成功要么回滚。用C或Go实现时直接使用互斥锁包住整个分配逻辑用Java可以走同步块或分布式锁。关键是不能让两个并发任务同时读到电梯空闲状态。我之前遇到过一起严重事故调试阶段因为QoS1重复消息没去重一台电梯同时分配给了两台AGV两台车同时朝电梯门开过去幸亏现场有安全雷达自动刹停。后来我把去重逻辑加到了边缘节点第一层类似的重复分配再没出现过。4.3 超时与重试状态机必须带看门狗梯控链路涉及多个网络跳段任何一段超时都必须有兜底。我的实现里每个任务有三个超时定时器超时阶段默认值超时后的处理呼叫确认超时3秒AGV重发相同command_id等待电梯超时30秒边缘节点检查电梯状态若电梯离线则重新排队或改派电梯动作超时60秒边缘节点向告警主题发异常事件人工介入检查特别要说一下等待电梯超时。AGV排到队首后电梯可能因为内召先去了其他楼层如果没有超时机制任务就永远卡在队首。我的做法是调度器发布dispatch消息后会启动一个定时检查任务定时轮询电梯状态是否和期望状态一致连续两次轮询不一致就触发重派逻辑把任务放回队列重新分配。重试必须配合幂等。AGV重发呼叫时复用了command_id边缘节点去重逻辑已经处理过不会产生新任务但如果AGV逻辑写错每次重发都生成不同command_id边缘节点会收到无数个新任务。所以AGV侧的重试策略要严格限定为“同一个command_id”这一点需要在接口文档里写死并在联调时检查。4.4 故障恢复断线、离线与重启的状态一致性AGV断线时Broker会发布遗嘱消息。边缘节点收到后先把该AGV的所有排队任务标记为取消再查它当前是否占用电梯。如果占用立即释放电梯并把电梯状态置为空闲。这个处理必须在几十毫秒内完成否则其他AGV会被死人堵住。电梯离线更麻烦。电梯控制器断电或者485通信断开时边缘节点无法实时感知需要一轮轮询失败后才能确定。我的做法是对每部电梯维护一个lease每次成功轮询后续期轮询失败超过阈值就标记电梯离线。电梯离线期间调度器会把该电梯的任务转移到可用电梯同时把离线状态发布到告警主题让中控屏弹窗。边缘节点自身重启是所有故障里最危险的。重启后内存里的任务队列、去重缓存、电梯状态全部丢失。我用两个手段解决一是Broker侧的保留消息保存电梯最新状态边缘节点启动拉取后重建电梯模型二是边缘节点本地落盘一份任务日志每次任务状态变更写一行记录重启后扫描日志恢复未完成任务。整个过程不需要引入复杂的分布式协调组件单边缘节点场景下这种“保留消息本地日志”的恢复方式最简单可靠。如果未来要搞多边缘节点集群再上Raft选主或者用Redis持久化现阶段没必要把架构做重。5. 边缘计算节点的部署细节与高可用设计5.1 硬件选型与资源规划边缘节点的硬件要按“工业环境7×24小时”去选。别拿普通办公电脑往控制柜里塞高温、振动、电压波动都扛不住。我在现场用的是一款无风扇嵌入式工控机配置x86低功耗处理器四核主频2.0GHz左右16GB DDR4内存因为要跑MQTT客户端、调度逻辑、协议转换和本地数据库16G比较稳妥双千兆网口一个接生产网连AGV和Broker一个接电梯控制网连PLC物理隔离比单网口强太多工业级固态硬盘至少保留60%剩余空间因为要落盘任务日志和缓存数据宽温设计和支持导轨安装方便直接固定在电控柜里。之前为了省钱试过用ARM开发板跑梯控这种对线程调度和磁盘IO有要求的场景ARM板在压力测试时任务日志写入出现明显延迟果断换回x86。5.2 容器化部署与升级策略整个边缘节点我以Docker Compose管理三个容器services: mqtt-broker: image: eclipse-mosquitto:2.0 ports: - 1883:1883 volumes: - ./mosquitto/config:/mosquitto/config restart: always edge-scheduler: build: ./scheduler depends_on: - mqtt-broker network_mode: host restart: always protocol-adapter: build: ./adapter depends_on: - mqtt-broker network_mode: host restart: always这三个服务分开的好处是协议适配器如果升级电梯侧驱动只重启adapter容器不影响调度器状态调度器升级也只影响调度逻辑电梯状态采集还在继续。现场升级有一条铁律不要直接在正在运行的边缘节点上docker pull最新镜像然后强制重启。梯控不是互联网应用停机窗口要提前申请先备份配置和任务日志再分批重启。我有一次图省事直接重建容器结果MQTT的clean session配置没保留导致恢复后AGV的在线状态全丢边缘节点以为AGV离线把正在执行的任务全部取消了产线停了一个多小时。5.3 本地数据缓存与断网续跑边缘节点除了转发指令还要落地一份本地缓存。电梯状态、任务状态、AGV状态都定期写进本地SQLite。断网时呼叫闭环还能在本机完成网络恢复后边缘节点把断网期间的任务结果补发到Broker让云端数据对齐。这个补发机制涉及的细节不少补发的消息必须携带原始时间戳不能使用补发时的当前时间否则云端统计延迟指标会全部失真。我的做法是每条消息从一开始就带event_time字段后续所有补发都沿用原值保证数据时间线正确。本地缓存还能帮上另一个忙Broker短暂宕机时边缘节点的调度逻辑不中断。AGV呼叫消息先缓存在本地Broker恢复后集中补发。这里有个小坑集中补发时消息量会在短时间内拉高需要在补发线程里加个节流器比如每50ms批量发十条避免把刚恢复的Broker又压垮。6. 现场实测中的坑与排查思路6.1 连接风暴AGV大面积重连打爆Broker系统上线初期遇到过一次全厂AGV在充电桩区集体掉线重连。原因是集中充电时电压波动导致部分AGV的车载无线模块重启几十台车几乎同时重新连接Broker。Mosquitto在默认配置下瞬间连接数暴涨大量会话建立又断开Broker文件描述符耗尽直接拒绝新连接连带正常运行的电梯状态订阅也被踢掉。排查时先看Broker日志发现大量“Socket error on client, disconnecting”和连接建立消息。后来做了三个调整AGV端MQTT客户端开启指数退避重连初始1秒最大30秒避免集中式轰炸Broker端把max_connections调高并启用persistent_session让断线重连更快恢复订阅状态在AGV充电策略上加了一个小延迟不允许多台AGV同时触发无线模块重启。这三招之后连接风暴基本消失。虽然AGV不是互联网App但大量工业设备集中重连的现象非常真实不要觉得MQTT broker默认配置就够了。6.2 QoS1重复消息引发的重复分配这个坑我在前面已经提到过这里再说一下完整的排查思路。现场现象是两台AGV同时收到进电梯指令事发时边缘节点日志里能看到两条不同的command_id对应同一部电梯。沿着日志往回查发现AGV端因为网络中断把呼叫消息重发了一次但重发时业务代码没有复用原command_id而是生成了新ID。边缘节点按新任务处理于是同一部电梯被分配两次。修复方案有两层一是AGV侧严格约束重发必须复用原ID二是边缘节点在分配动作前增加电梯状态二次校验分配时再次确认电梯仍为空闲若已经被占用则拒绝新分配。这里想强调一句MQTT的QoS1只保证至少一次送达不保证不重复所有对重复敏感的业务最终兜底都要落在业务层的幂等设计上协议层解决不了这个问题。6.3 时钟偏差导致调度记录错乱边缘节点、AGV中控、云端数据库三方的时间基准不一致曾经导致过一起调度记录乱序事故。AGV发出呼叫的真实时间是14:32:05但它的系统时钟慢了半分钟边缘节点收到消息时按自己时间戳记录为14:31:35导致调度顺序排序时把这条消息排到了其他车前面。从数据上看起来可能只是顺序不对但落在实际调度里可能出现“后呼叫的AGV先上电梯”的不公平现象。解决办法是全链路统一使用NTP同步时钟Broker、边缘节点、AGV中控、数据库服务器全部指向工厂内部NTP服务器并且事件排序严格以event_time字段为准不以接收时间为准。6.4 实战排障工具清单最后列一下我现场排查问题时的常用工具组合。这些不是商业软件都是开源或自带工具但对梯控系统调试非常够用MQTT Explorer图形化订阅所有主题实时看消息流排查主题写错、payload格式问题最直观mosquitto_sub配合通配符快速验证某个主题的消息是否能正常到达比如订阅“factory/#”看全量消息tcpdump抓包电梯侧485转TCP时出问题先抓网络包确认报文是否到达再排查适配器SQLite浏览器看边缘节点的本地任务日志按command_id查任务流转轨迹边缘节点自带的/metrics接口暴露当前队列长度、电梯状态、各AGV在线情况配合Grafana做趋势监控。排查这类系统的通用思路就是先看链路是否通再看数据是否符合预期最后才怀疑业务逻辑。大多数梯控问题不是逻辑多复杂而是消息链路里某个环节把数据改坏了或者丢了。从Broker日志和边缘节点日志按command_id追踪一遍问题一般都能定位到具体环节。我个人现在做任何梯控项目都会在部署时就把日志链路建好消息从AGV发出到边缘节点处理每一步都记录同一个command_id的轨迹。这样上线初期就算出了问题也能在几分钟内定位到是哪台AGV、哪部电梯、哪个环节出的事比翻遍全厂日志再猜要高效得多。这套方案的核心不在于用了多高深的技术而是把MQTT的可靠传输、主题设计和边缘计算的低延迟处理正确组合在一起用最简单的机制保证电梯调度这个对安全和时序极度敏感的业务能稳定跑下去。 
长河君 · 2026/10/5 13:50:25 · 阅读 1.2k 基于MQTT与边缘计算的AGV梯控高并发集成方案解析
车间里十二台AGV同时进入充电区紧接着一辆接一辆地往货梯口靠群里调度屏幕上的未处理呼叫瞬间堆到十几条电梯那边却只回了一句“busy”。这是我在工厂现场做过的高并发IoT项目里最典型的场景AGV要坐电梯跨楼层节点虽然不算多但呼叫是短时突发式的一旦处理不好整条产线的物流节奏全部卡死。今天想把这个基于MQTT与边缘计算的AGV梯控集成方案完整拆开讲一遍覆盖消息链路、主题设计、并发控制、边缘部署和现场排查给正在做同类项目的同学一个可以直接参考的落地版本。1. 先从现场约束说起AGV梯控为什么不能只靠云端1.1 梯控的真实并发模型不是百万级而是突发式耦合很多人一听“高并发IoT”第一反应就是百万设备同时上报数据。但工厂AGV梯控场景完全不是这个模型。我经手的项目里AGV数量在十几台到几十台之间电梯通常只有几部真正的压力来自“任务耦合”——十几台AGV几乎同时到达电梯口各自发出呼叫指令而电梯只有一个轿厢。这种并发特点是流量峰值持续时间短但消息之间强关联。如果处理不及时电梯响应慢了十秒AGV就可能在门口空等后面的AGV又会堵上来形成连锁拥堵。所以系统设计的关键不是每秒百万条消息的吞吐能力而是“短时间内的调度正确性和响应确定性”。还有一个隐藏约束AGV和电梯控制器都是存量工业设备。AGV自带调度系统电梯那边往往是老式的PLC控制柜配485总线或者简单继电器输出。想让电梯听懂MQTT要么改造电梯控制系统要么加一个边缘协议转换层。对大多数工厂来说改造电梯代价太高所以边缘计算节点的角色就变得不可替代。1.2 云平台方案在梯控场景中的三大硬伤先说明一下这里说的“云平台方案”是指AGV通过公网云服务直接呼叫电梯的方式比如把指令先发到阿里云或华为云的IoT平台再由云平台下发到电梯网关。理论上是通的但落到梯控现场有三个硬伤。第一是链路不确定。AGV在厂区里移动经过货架、设备、钢结构WiFi信号波动非常明显。呼叫指令走云端多一跳在信号差的角落可能从200ms变成2sAGV已经停在电梯口了云平台还在那儿处理。电梯对这种不确定延迟的容忍度极低因为电梯门开了要等你等不到就会超时关门AGV就进不去。第二是电梯控制协议碎片化。电梯品牌不同控制接口不同有走Modbus RTU的有走无源干接点的还有走私有TCP报文协议的。云平台没办法为每个电梯型号定制一套驱动就算能远程更新驱动的过程中一旦断连电梯控制逻辑可能停在中间态这是工厂安全绝对不允许的。第三是现场网络口径。不少工厂的办公网和生产网是物理隔离的AGV无线网络属于生产网生产网不允许任意设备访问公网。你让AGV直接上云先要过网络安全评审。大部分客户一听这个直接摇头宁可本地化。所以现阶段真正能交付落地的梯控方案普遍是“边缘闭环为主、云端同步为辅”要和我下面讲的MQTT加边缘计算架构结合起来看。1.3 边缘计算介入后的职责划分边缘计算在这个项目里负责三件具体的事接收AGV通过MQTT发布的电梯呼叫请求做本地排队和互斥判断把调度指令转换为电梯控制器认识的协议报文Modbus、485或干接点信号把电梯状态采集回来再通过MQTT反馈给AGV和云端。这就形成了一个本地闭环AGV发布消息到Broker边缘节点从Broker订阅到消息经过调度逻辑控制电梯动作电梯回到位后再上报状态。整个过程不依赖公网延迟稳定在几十毫秒级别。云端在我的设计里退居二线只做三件事数据汇总、异常报警、长周期调度优化。AGV梯控这种对实时性敏感的业务让边缘节点做决策主战场云端做观察者这个分工比全都丢给云端合理得多。2. 系统骨架MQTT主题树、边缘网关与消息流转设计2.1 MQTT Broker选型与部署位置Broker是整个系统的消息中枢。项目规模不大时我自己用Mosquitto就能扛住单机几万连接没压力AGV几十台的场景完全是杀鸡用牛刀。但如果工厂未来要扩展AGV数量到一两百台或者有多车间统一调度需求建议直接上EMQX集群分片部署在产线边缘机房。部署位置必须和生产网在同一网段。我踩过一个坑最开始把Broker放在办公室网络AGV无线网络和生产网之间有防火墙规则虽然能通信但延迟抖动很厉害高峰期丢包率飙到5%。后来把Broker挪到生产网的核心交换机旁边延迟从平均80ms降到了10ms以内。梯控指令这种消息Broker离现场越近系统越稳。边缘节点也主要部署在电梯控制柜附近的边缘盒子或者和电梯网关同机房部署它同时扮演MQTT客户端和协议转换端两个角色和Broker之间保持长连接。2.2 主题树的命名与访问控制设计MQTT主题树设计直接影响系统的可维护性和安全边界。我给出一个经过现场验证的示例结构factory/{plant_id}/agv/{agv_id}/call factory/{plant_id}/agv/{agv_id}/ack factory/{plant_id}/agv/{agv_id}/status factory/{plant_id}/elevator/{elevator_id}/dispatch factory/{plant_id}/elevator/{elevator_id}/status factory/{plant_id}/edge/{edge_node_id}/event每个主题层级都携带语义factory后面的plant_id用于多车间隔离agv_id定位到具体车辆elevator_id定位到具体电梯。这样后续做权限控制既方便又清晰。主题访问控制是所有现场项目都不能跳过的步骤。AGV客户端只允许发布“call”主题和订阅自己的“ack”主题边缘节点才有权限发布“dispatch”。否则一旦某台AGV的发布逻辑写错把消息发到了电梯的dispatch主题就可能出现共享单车锁被随意打开的问题。实际做法上EMQX可以启用ACL规则Mosquitto也可以配置password_file和acl_file不要嫌麻烦。2.3 消息格式定义与版本管理梯控消息的payload格式我统一使用JSON虽然比二进制协议多几十个字节但现场调试方便云端解析也容易。AGV呼叫电梯的消息体大致是这样{ command_id: a3f2c1e8-6b4d-4f2e-9f35-9c8e7d6a2b1f, agv_id: AGV-07, timestamp: 1735689600000, target_floor: 3, call_type: standard, priority: 5, sequence: 42 }这里有个关键字段command_id。它是一次呼叫请求的全局唯一标识AGV因为网络原因重发消息时会复用同一个command_id边缘节点靠它做去重避免重复分配电梯。sequence字段是同一AGV的递增序号用来辅助校验消息顺序防止旧消息晚到覆盖新状态。所有主题的payload接口建议定义好版本字段即使现在不用也可以先保留。梯控系统往往要运行很多年后期增加“VIP优先通道”或“跨楼层连续搬运”功能时没有版本控制就只能在原来的JSON上加字段加到最后新旧客户端互相看不懂那个痛我体会过。2.4 QoS、保留消息与遗嘱消息的分工MQTT的QoS级别按消息类型分开设置不要一套用到底。呼叫指令QoS 1。至少送达一次避免AGV发出呼叫Broker却没收到。状态反馈QoS 0。电梯状态是周期性上报的丢一帧下一帧马上就来不必多耗资源。调度指令QoS 1。边缘节点发给电梯控制器的指令不能丢。遗嘱消息QoS 1且消息内容要能被边缘节点理解并触发清理动作。电梯的状态通道要打开保留消息比如边缘节点启动后新接入的AGV订阅电梯状态主题时能立刻收到电梯当前位置、门状态、是否空闲而不必等下一个上报周期。这个细节在现场非常实用。AGV的在线状态用遗嘱消息实现。AGV异常断电时MQTT连接断开Broker自动发布遗嘱消息到状态主题边缘节点订阅后就能立刻知道某台车掉线了然后把它在等待队列里的任务清理掉同时释放它占用的电梯。如果没有这层机制死掉的AGV会一直占着电梯队列系统会慢慢堵死。3. 从呼叫到动作AGV呼叫电梯的完整业务链路3.1 呼叫发起与确认用发布-订阅模式搭命令管道AGV靠近电梯口后通过中控系统或车载PLC调用MQTT客户端携带完整的command_id发布到该车的“call”主题。边缘节点订阅了所有AGV的“call”主题收到消息后立刻在本地生成一条排队记录然后回一条“ack”给AGV告诉它“呼叫已收到请保持当前位置”。这个ack动作很多人会忽略直接在电梯到了才回消息。实际上AGV的等待策略是基于确认的如果几秒内没收到ackAGV就会重发呼叫甚至报错停车。所以边缘节点处理呼叫的第一动作一定是确认再进调度逻辑能减少很多现场误报。我还会在ack消息里带上排队序号和预计等待时间。这样AGV本地可以有更好的显示逻辑调度中心也能知道哪台车排在哪个位置。预计等待时间的算法可以很简单当前队列里前面的任务数乘以单次平均电梯使用时长。3.2 边缘节点上的排队与互斥调度边缘节点是整个调度系统的“大脑”。它维护两部电梯、一条调度状态表核心数据结构可以理解为每个电梯对应一个任务队列每个任务绑定一个AGV。调度器按规则从队列头部取任务然后向对应的电梯控制器发送动作指令。这里的互斥逻辑很关键同一时刻一台电梯只能分配给一个任务。多台AGV同时喊同一部电梯时调度器必须做仲裁不能因为MQTT消息是并发的就把电梯拆成两半。我的实现是边缘节点内的调度服务加一个全局锁所有分派操作串行化处理。并发量少时这种简单方法最可靠。队列规则我会用“优先级优先同级别先进先出”。生产系统里有些AGV运的是急料有些是返空托盘急料任务priority字段给到高值调度器优先分派。后续如果需要更复杂的路径优化可以引入权重队列但第一版不建议做太复杂先把互斥和确认闭环做好。3.3 电梯侧协议转换从MQTT到Modbus再到动作电梯控制器大概率不认识JSON。边缘节点调度器确定任务后通过协议适配器把指令转成电梯侧能执行的信号。最常见的是Modbus RTU走485总线协议适配器向PLC写入寄存器比如目标楼层寄存器、呼叫登记寄存器、电梯运行方向寄存器。写寄存器后边缘节点还要持续读取电梯状态寄存器确认电梯开始关门、开始动、到达楼层、开门到位。这中间每一步都有明确的状态码。电梯是特种设备不能直接把“到达”这个状态交给AGV必须等待“门开到位”再通知AGV进入。实际项目里门到位信号是硬接线光电开关或PLC输入点位提供的可靠性远高于纯软件判断。这部分还有一个容易出错的点电梯本身就自带调度系统比如电梯按键呼叫的楼层停靠逻辑。如果外部接入指令和电梯内召信号冲突会出现电梯被内部乘客按走的场景。所以边缘适配器在发指令的同时还要根据电梯实时状态判断“当前能否接受外部呼梯”比如检测到轿厢内有内召信号或满载信号时暂时挂起外部调度。这是对接电梯厂家时最需要拉通的一个点。3.4 状态回传与任务闭环电梯按指令动作完成、门开到位后边缘节点更新电梯状态并发布状态消息到“status”主题同时向对应AGV发布“ack”主题的下一条消息内容为“预约完成请进电梯”。注意这里用的是“预约”而不是“强制命令”。AGV收到消息后自行判断是否满足进入电梯的条件比如车宽和门宽、载重安全。确认进入电梯后AGV可以再发一条“confirm_in”消息边缘节点收到后调度器才认为这个任务真正进入执行状态电梯才能按AGV选择的楼层启动。任务闭环一定要清楚呼叫→排队→分派→电梯动作→AGV进入→电梯到达→AGV驶出→释放电梯。每个环节都有消息事件每个事件都带同一个command_id后续出问题排查时可以按command_id串起整条链路非常高效。4. 高并发防冲撞队列优先级、去重与故障恢复4.1 并发模型为什么纯FIFO不够用纯FIFO看起来公平但在AGV梯控场景容易出问题。假设A车呼叫3层B车呼叫5层两部电梯都不是空闲状态纯FIFO先把A排到1号电梯B排到2号电梯结果A车的位置实际上离2号电梯更近B车离1号电梯更近两车都绕了远路。所以我在调度模型里加入了“就近分配”逻辑。边缘节点维护每部电梯的当前位置和每台AGV的等待位置分派时优先选择“电梯到AGV距离AGV到目标楼层时间”综合代价最小的电梯。这个计算不复杂但比纯FIFO合理很多。当然优先级还是要保留。现场总有“这个物料必须马上送”的插队需求。实现方式是在任务结构体里加priority字段调度器每次从非空队列中挑priority最大的任务同priority时再按时间戳排序。注意插队要保护不能让高优先级任务无限推迟低优先级任务可以设置最大等待阈值超过阈值的任务自动提升优先级。这个机制在长尾拥堵时特别有用。4.2 防止“一呼多应”与重复分派MQTT的QoS1协议天然有重复消息的可能一个呼叫被重复执行就可能导致两辆AGV争抢一部电梯。防重复分派有两道防线。第一道防线是command_id去重。边缘节点保存最近N条已处理command_id的LRU缓存。每次收到呼叫消息先查缓存存在就直接回ack并提示“重复呼叫”不重复排队不存在才进入队列。这能拦截QoS1重发和AGV业务层重试导致的重复请求。第二道防线是边缘节点内的分配操作原子化。分配电梯的动作必须和更新电梯状态在同一个事务里完成要么成功要么回滚。用C或Go实现时直接使用互斥锁包住整个分配逻辑用Java可以走同步块或分布式锁。关键是不能让两个并发任务同时读到电梯空闲状态。我之前遇到过一起严重事故调试阶段因为QoS1重复消息没去重一台电梯同时分配给了两台AGV两台车同时朝电梯门开过去幸亏现场有安全雷达自动刹停。后来我把去重逻辑加到了边缘节点第一层类似的重复分配再没出现过。4.3 超时与重试状态机必须带看门狗梯控链路涉及多个网络跳段任何一段超时都必须有兜底。我的实现里每个任务有三个超时定时器超时阶段默认值超时后的处理呼叫确认超时3秒AGV重发相同command_id等待电梯超时30秒边缘节点检查电梯状态若电梯离线则重新排队或改派电梯动作超时60秒边缘节点向告警主题发异常事件人工介入检查特别要说一下等待电梯超时。AGV排到队首后电梯可能因为内召先去了其他楼层如果没有超时机制任务就永远卡在队首。我的做法是调度器发布dispatch消息后会启动一个定时检查任务定时轮询电梯状态是否和期望状态一致连续两次轮询不一致就触发重派逻辑把任务放回队列重新分配。重试必须配合幂等。AGV重发呼叫时复用了command_id边缘节点去重逻辑已经处理过不会产生新任务但如果AGV逻辑写错每次重发都生成不同command_id边缘节点会收到无数个新任务。所以AGV侧的重试策略要严格限定为“同一个command_id”这一点需要在接口文档里写死并在联调时检查。4.4 故障恢复断线、离线与重启的状态一致性AGV断线时Broker会发布遗嘱消息。边缘节点收到后先把该AGV的所有排队任务标记为取消再查它当前是否占用电梯。如果占用立即释放电梯并把电梯状态置为空闲。这个处理必须在几十毫秒内完成否则其他AGV会被死人堵住。电梯离线更麻烦。电梯控制器断电或者485通信断开时边缘节点无法实时感知需要一轮轮询失败后才能确定。我的做法是对每部电梯维护一个lease每次成功轮询后续期轮询失败超过阈值就标记电梯离线。电梯离线期间调度器会把该电梯的任务转移到可用电梯同时把离线状态发布到告警主题让中控屏弹窗。边缘节点自身重启是所有故障里最危险的。重启后内存里的任务队列、去重缓存、电梯状态全部丢失。我用两个手段解决一是Broker侧的保留消息保存电梯最新状态边缘节点启动拉取后重建电梯模型二是边缘节点本地落盘一份任务日志每次任务状态变更写一行记录重启后扫描日志恢复未完成任务。整个过程不需要引入复杂的分布式协调组件单边缘节点场景下这种“保留消息本地日志”的恢复方式最简单可靠。如果未来要搞多边缘节点集群再上Raft选主或者用Redis持久化现阶段没必要把架构做重。5. 边缘计算节点的部署细节与高可用设计5.1 硬件选型与资源规划边缘节点的硬件要按“工业环境7×24小时”去选。别拿普通办公电脑往控制柜里塞高温、振动、电压波动都扛不住。我在现场用的是一款无风扇嵌入式工控机配置x86低功耗处理器四核主频2.0GHz左右16GB DDR4内存因为要跑MQTT客户端、调度逻辑、协议转换和本地数据库16G比较稳妥双千兆网口一个接生产网连AGV和Broker一个接电梯控制网连PLC物理隔离比单网口强太多工业级固态硬盘至少保留60%剩余空间因为要落盘任务日志和缓存数据宽温设计和支持导轨安装方便直接固定在电控柜里。之前为了省钱试过用ARM开发板跑梯控这种对线程调度和磁盘IO有要求的场景ARM板在压力测试时任务日志写入出现明显延迟果断换回x86。5.2 容器化部署与升级策略整个边缘节点我以Docker Compose管理三个容器services: mqtt-broker: image: eclipse-mosquitto:2.0 ports: - 1883:1883 volumes: - ./mosquitto/config:/mosquitto/config restart: always edge-scheduler: build: ./scheduler depends_on: - mqtt-broker network_mode: host restart: always protocol-adapter: build: ./adapter depends_on: - mqtt-broker network_mode: host restart: always这三个服务分开的好处是协议适配器如果升级电梯侧驱动只重启adapter容器不影响调度器状态调度器升级也只影响调度逻辑电梯状态采集还在继续。现场升级有一条铁律不要直接在正在运行的边缘节点上docker pull最新镜像然后强制重启。梯控不是互联网应用停机窗口要提前申请先备份配置和任务日志再分批重启。我有一次图省事直接重建容器结果MQTT的clean session配置没保留导致恢复后AGV的在线状态全丢边缘节点以为AGV离线把正在执行的任务全部取消了产线停了一个多小时。5.3 本地数据缓存与断网续跑边缘节点除了转发指令还要落地一份本地缓存。电梯状态、任务状态、AGV状态都定期写进本地SQLite。断网时呼叫闭环还能在本机完成网络恢复后边缘节点把断网期间的任务结果补发到Broker让云端数据对齐。这个补发机制涉及的细节不少补发的消息必须携带原始时间戳不能使用补发时的当前时间否则云端统计延迟指标会全部失真。我的做法是每条消息从一开始就带event_time字段后续所有补发都沿用原值保证数据时间线正确。本地缓存还能帮上另一个忙Broker短暂宕机时边缘节点的调度逻辑不中断。AGV呼叫消息先缓存在本地Broker恢复后集中补发。这里有个小坑集中补发时消息量会在短时间内拉高需要在补发线程里加个节流器比如每50ms批量发十条避免把刚恢复的Broker又压垮。6. 现场实测中的坑与排查思路6.1 连接风暴AGV大面积重连打爆Broker系统上线初期遇到过一次全厂AGV在充电桩区集体掉线重连。原因是集中充电时电压波动导致部分AGV的车载无线模块重启几十台车几乎同时重新连接Broker。Mosquitto在默认配置下瞬间连接数暴涨大量会话建立又断开Broker文件描述符耗尽直接拒绝新连接连带正常运行的电梯状态订阅也被踢掉。排查时先看Broker日志发现大量“Socket error on client, disconnecting”和连接建立消息。后来做了三个调整AGV端MQTT客户端开启指数退避重连初始1秒最大30秒避免集中式轰炸Broker端把max_connections调高并启用persistent_session让断线重连更快恢复订阅状态在AGV充电策略上加了一个小延迟不允许多台AGV同时触发无线模块重启。这三招之后连接风暴基本消失。虽然AGV不是互联网App但大量工业设备集中重连的现象非常真实不要觉得MQTT broker默认配置就够了。6.2 QoS1重复消息引发的重复分配这个坑我在前面已经提到过这里再说一下完整的排查思路。现场现象是两台AGV同时收到进电梯指令事发时边缘节点日志里能看到两条不同的command_id对应同一部电梯。沿着日志往回查发现AGV端因为网络中断把呼叫消息重发了一次但重发时业务代码没有复用原command_id而是生成了新ID。边缘节点按新任务处理于是同一部电梯被分配两次。修复方案有两层一是AGV侧严格约束重发必须复用原ID二是边缘节点在分配动作前增加电梯状态二次校验分配时再次确认电梯仍为空闲若已经被占用则拒绝新分配。这里想强调一句MQTT的QoS1只保证至少一次送达不保证不重复所有对重复敏感的业务最终兜底都要落在业务层的幂等设计上协议层解决不了这个问题。6.3 时钟偏差导致调度记录错乱边缘节点、AGV中控、云端数据库三方的时间基准不一致曾经导致过一起调度记录乱序事故。AGV发出呼叫的真实时间是14:32:05但它的系统时钟慢了半分钟边缘节点收到消息时按自己时间戳记录为14:31:35导致调度顺序排序时把这条消息排到了其他车前面。从数据上看起来可能只是顺序不对但落在实际调度里可能出现“后呼叫的AGV先上电梯”的不公平现象。解决办法是全链路统一使用NTP同步时钟Broker、边缘节点、AGV中控、数据库服务器全部指向工厂内部NTP服务器并且事件排序严格以event_time字段为准不以接收时间为准。6.4 实战排障工具清单最后列一下我现场排查问题时的常用工具组合。这些不是商业软件都是开源或自带工具但对梯控系统调试非常够用MQTT Explorer图形化订阅所有主题实时看消息流排查主题写错、payload格式问题最直观mosquitto_sub配合通配符快速验证某个主题的消息是否能正常到达比如订阅“factory/#”看全量消息tcpdump抓包电梯侧485转TCP时出问题先抓网络包确认报文是否到达再排查适配器SQLite浏览器看边缘节点的本地任务日志按command_id查任务流转轨迹边缘节点自带的/metrics接口暴露当前队列长度、电梯状态、各AGV在线情况配合Grafana做趋势监控。排查这类系统的通用思路就是先看链路是否通再看数据是否符合预期最后才怀疑业务逻辑。大多数梯控问题不是逻辑多复杂而是消息链路里某个环节把数据改坏了或者丢了。从Broker日志和边缘节点日志按command_id追踪一遍问题一般都能定位到具体环节。我个人现在做任何梯控项目都会在部署时就把日志链路建好消息从AGV发出到边缘节点处理每一步都记录同一个command_id的轨迹。这样上线初期就算出了问题也能在几分钟内定位到是哪台AGV、哪部电梯、哪个环节出的事比翻遍全厂日志再猜要高效得多。这套方案的核心不在于用了多高深的技术而是把MQTT的可靠传输、主题设计和边缘计算的低延迟处理正确组合在一起用最简单的机制保证电梯调度这个对安全和时序极度敏感的业务能稳定跑下去。