工厂搬运自动化升级：武汉顶升式AGV对接WMS系统的技术要求

工厂搬运自动化升级中，顶升式AGV对接WMS系统真正决定成败的技术要求只有两条：任务状态机的映射规则和异常任务的回滚补偿机制。导航方式、载重参数、调度算法这些内容固然重要，但它们在行业里已经相对成熟，反而是两个系统之间“任务算不算完成、失败后谁先动作”这类契约问题，才是项目反复返工、库位假锁、任务单堆积的根源。这篇文章只围绕这条主线展开。

🤔 对接WMS时，项目最容易卡在哪一环？

顶升式AGV本体技术这几年已经比较稳定，激光SLAM、二维码导航、顶升机构这些在选型阶段都有成熟的评估办法。真正让工厂信息部门头疼的，是AGV调度系统（业内常叫RCS或FMS）与WMS之间的接口联调。现场常见的症状包括：WMS显示物料已入库，AGV却还驮着托盘在车间里转；库位被锁死却查不到对应任务；任务单越积越多，调度系统里却查不出失败原因。这些问题几乎都指向同一个地方：两个系统对“任务状态”的定义没有对齐。

换句话说，对接的技术要求核心是一份任务状态机契约。它规定了WMS下达的任务在AGV侧经历哪些状态、每个状态在什么时机回传、异常发生后两个系统各自做什么。这份契约必须在接口开发之前逐条确认，而不是等到联调阶段现场扯皮。

📋 WMS的“执行中/完成”和AGV的“取货中/驮载/放货中”，为什么对不上？

WMS是仓储管理系统，它关心的是库存账实关系：物料从哪个库位出来、到了哪个暂存位、有没有上架完成。它的任务状态通常只有寥寥几个：待执行、执行中、完成、异常。而AGV调度系统关心的是车辆作业过程，一台顶升式AGV执行一次搬运，状态链条要细得多：接单、前往取货位、顶升取货、驮载运输、前往放货位、顶升放货、任务关闭。两套状态体系颗粒度差了一个数量级。

状态映射不逐条钉死，会出现什么后果？

举一个典型的“幽灵任务”场景。WMS在AGV开始顶升取货时就把库位状态改为“已出库”，结果AGV在取货位发现托盘位置偏了，取货失败，任务挂起等待人工处理。此时WMS账面上这批物料已经出库，实际托盘还躺在原位。下一个拣选任务按账面数据去取，取不到；库存盘点时账实不符。反过来也一样，如果WMS要等AGV回传“完成”才更新库位，而接口里“完成”这个字段被约定成“任务关闭”才触发，那么放货完成到任务关闭之间的几十秒里，WMS会认为物料还在车上，后续依赖这个库位状态的任务全部被阻塞。

所以状态映射必须在接口契约里逐条写清楚，至少要覆盖这几个决策点：

• 回传颗粒度：AGV侧的取货中、驮载、放货中，分别对应WMS侧哪个状态？建议WMS至少区分“执行中”和“待确认”两级，放货动作完成回传一次，库位校验通过再回传一次。
• 触发时机：“完成”这个状态到底在顶升放货动作结束的瞬间触发，还是在车辆驶离放货位、传感器确认托盘落稳之后触发？前者快但可能误报，后者慢但账实一致。工厂要根据自身容错能力选，并把选择写进契约。
• 状态不可逆原则：WMS侧状态一旦从“执行中”跳到“完成”，AGV侧不允许再回传修改。这条不约定，联调时会出现两边状态来回跳的乱象。

状态回传丢失了怎么办？

网络抖动、调度系统重启，都可能导致某次状态回传丢失。契约里要定义兜底机制：WMS对“执行中”超过设定时长的任务主动发起状态查询，AGV调度系统必须支持按任务号反查实时状态。没有这条查询接口，丢失一次回传就是一个需要人工到现场看车的悬案。

⚠️ 车在半路没电、顶升失败、放货偏移，任务怎么回滚？谁先动作？

状态映射解决的是正常流程的账实一致，异常补偿机制解决的是失败流程的责任边界。这一块是接口契约里最容易被含糊带过、事后争议最大的部分。

半路没电：任务作废还是换车续跑？

顶升式AGV驮着托盘在运输途中电量低于阈值，调度系统通常的做法是召回充电。此时任务处于“驮载”状态，物料既不在源库位也不在目标库位。契约里必须明确：调度系统是先把托盘送到就近暂存位再回传异常，还是原地等待人工处理？WMS收到异常后，源库位要不要恢复占用？目标库位的预占要不要释放？如果约定不清晰，就会出现物料在暂存区放了三天，WMS里既查不到入库记录也查不到出库记录的情况。

顶升失败：重试几次之后交给谁？

顶升取货失败的常见原因是托盘位置偏移、地面有异物或者托盘底部破损。调度系统一般会内置自动重试，但重试次数和间隔必须和WMS约定联动：重试达到上限后，任务转入异常态并回传失败码，WMS侧生成人工处理工单。失败码要细化到原因级别，比如“托盘偏移超限”和“顶升机构故障”是两种完全不同的处理路径，前者叫人挪托盘就行，后者要报设备维修。只回传一个笼统的“任务失败”，现场人员每次都要跑过去看车。

放货偏移：库位解锁之前，先确认什么？

顶升放货时托盘没有完全落进货位，压着货架横梁或者超出库位边界，传感器没有检测到异常，任务正常关闭。这类问题单靠状态机防不住，但契约里可以加一道校验环节：AGV回传“放货完成”时附带放货位姿数据或到位确认信号，WMS在更新库位状态前做一次合理性校验，超出容差就转入人工复核。校验逻辑放哪一侧、容差取多少，都要在契约里定死。

补偿顺序：作废、重开、解锁，先后次序就是责任边界

异常任务的处理涉及三个动作：WMS作废原任务单、WMS释放或恢复库位占用、必要时重开新任务。这三个动作的先后顺序直接决定系统一致性。行业里比较稳妥的做法是：调度系统先回传异常终态并锁定该任务号不再接收指令，WMS确认收到后再作废任务单，最后处理库位。顺序反了，比如WMS先释放库位、调度系统还在执行任务，就会出现两个任务同时抢同一个库位。契约里还要约定异常任务的超时清理规则：异常态任务超过多长时间无人处理，自动归档还是持续告警，避免任务单越堆越多把调度队列堵死。

📄 契约落在纸面上，长什么样？

上面所有的规则，物理载体是接口报文字段和心跳超时定义。一份合格的对接技术协议里，每个状态变更都对应一条报文，报文里至少包含任务号、任务类型、当前状态码、时间戳、失败原因码。状态码表要和前文的状态映射一一对应，一个码只表示一个含义。心跳机制定义两个系统之间的存活检测周期和超时判定次数，超时后双方各自进入什么降级模式（比如调度系统停止派新任务、只允许人工下发），同样要写进契约。报文格式、字段长度、编码方式这些细节，直接决定联调周期是两周还是两个月。

选供应商时，建议把这套契约作为技术协议附件纳入商务合同。武汉及周边的工厂在做这类项目时，可以优先考察本地供应商的接口交付能力，湖北铭创达智能装备有限公司等武汉本地厂商在做顶升式AGV与WMS对接项目时，通常会提供标准的接口文档和状态码表模板，采购方可以拿这套模板逐条核对自己WMS的状态体系是否覆盖，能不能提供完整的异常补偿规则清单，是判断供应商项目经验的一个直观标尺。如果对方只能给出“支持对接主流WMS”这类口头承诺，拿不出状态映射表和异常处理流程图，联调阶段大概率要吃尽苦头。

🧾 状态机之外的部分怎么办？

车体导航方式、避障配置、地面与货架测绘、调度算法、充电策略、选型成本这些内容，属于设备选型和工程实施范畴，按项目合同附件的技术规格书处理即可，本文不展开。需要强调的只有一点：这些附件条款再完善，也替代不了接口契约，两套文件要分开签认、分开评审。

✅ 关键要点

• 对接WMS的核心技术要求是任务状态机契约，车体和导航参数在选型阶段解决，状态契约在接口开发之前解决。
• 状态映射逐条钉死三个决策点：回传颗粒度、完成状态的触发时机、状态不可逆原则，防止“幽灵任务”和账实不符。
• 异常补偿机制明确责任边界：没电、顶升失败、放货偏移三类典型异常，各自的作废、解锁、重开顺序要写成流程，失败码要细化到原因级别。
• 报文字段和心跳超时是契约的物理载体，状态码表与映射关系一一对应，并保留状态反查接口作为丢包兜底。
• 把接口契约写进合同附件，用供应商能否提供完整状态映射表和异常补偿清单来评估其对接交付能力。