AGV跨层搬运的工业IoT架构：信号盲区治理与任务自愈设计

1. 项目背景：跨层搬运为什么成了IoT架构的试金石

1.1 业务场景速写：三层立体库的AGV跨层调度

这个项目是从一个三层立体仓库的搬运智能化改造开始的。仓库单层面积接近8000平方米，一层是原料收发区，二层是半成品缓存区，三层是成品入库区，楼层之间靠两台液压提升机和一部货梯完成物理转运。原本的搬运方式是人工开电动地牛，从一层拉到提升机口，再上楼接驳，两班倒共需要6个搬运工，高峰期还是经常堵在提升机门口。

改造目标很直接：用AGV替代人工，实现跨层搬运任务的全自动流转。听起来好像就是把单层AGV调度搬到多层里，实际上做起来完全不是一回事。单层搬运只需要管平面路径和避障，跨层搬运多了一个物理换层动作——AGV要自己开进提升机、在提升机里停稳、确认楼层到位后再开出来——这中间任何一个环节的网络抖动、信号丢失、状态不同步，都可能让整车卡死在半空或者门区。

整个系统上线后，我们复盘时把核心难点归成两个词：信号盲区和任务自愈逻辑。这两个问题不解决，跨层搬运就是纸面方案，现场跑一周就会被故障逼回人工模式。

1.2 痛点拆解：信号盲区与任务中断的真实代价

先量化一下信号盲区的严重程度。我们用的是Wi-Fi 6工业级AP，仓库内做了覆盖，理论上RSSI不低于-65dBm。但现场实测发现，提升机井道内部、金属卷帘门关闭后的门区、以及货梯轿厢内，这三处位置的无线信号衰减极其严重。提升机是金属结构，轿厢和井道本身就是一个法拉第笼，Wi-Fi信号进去以后RSSI直接从-55dBm掉到-92dBm，丢包率超过60%。

这种环境下AGV会发生什么？车载PLC和调度系统之间的心跳包丢失，调度系统以为AGV离线，实际上车还停在提升机里；或者更麻烦的——任务指令已经发出去了，但AGV只收到一半，导致它停在提升机门口既不前进也不后退，堵住后面所有车。单次故障的处理时间平均在10到15分钟，如果赶上两辆车在同一楼层互锁，恢复时间直接翻倍。

为什么传统单层AGV方案没这个毛病？因为单层AGV整个运行路径都在AP覆盖良好的区域，中断概率低，偶尔断一次人工遥控一下就行。跨层搬运把AGV的物理活动范围从“平面”扩展到了“立体”，等于强制把设备往信号最差的地方送。所以这个项目的核心矛盾变成了：无线环境不可控是常态，任务执行必须在这种常态下保持正确。

1.3 架构选型的底层逻辑：为什么不能用单机思路硬扛

最开始有过一个简化思路：给每台AGV装4G/5G工业模组，用公网回传指令，绕开厂区Wi-Fi。听上去能回避盲区问题，但实际落地有两个硬伤。第一，厂区在地下室和提升机井道内，公网信号一样覆盖不到，运营商的5G在金属井道里照样没辙。第二，即使信号能通，公网链路的时延抖动比局域网大得多，AGV在提升机内停靠的精度要求是±10mm，靠公网做实时控制风险太高。

所以架构选型上必须接受一个前提：跨层搬运场景里，无线链路必然存在不可用时段，系统设计要按“弱网甚至断网可运行”来要求，而不是按“网络永远稳定”来假设。这个前提直接决定了后续所有的技术决策——从AP部署密度、漫游策略，到任务状态机、超时重试机制，全部围绕“链路会断”这个假设展开。

2. 工业IoT整体架构：从感知到决策的分层设计

2.1 四层架构模型：各自干什么、边界在哪

项目最终采用的是工业IoT标准的四层架构，但在每一层都做了针对跨层搬运场景的强化。最底下是感知执行层，包括AGV车载PLC、提升机控制系统、门禁传感器、楼层到位检测光电开关，这一层负责物理动作的执行，也是信号盲区最直接的受害者。

第二层是网络传输层，由工业Wi-Fi 6 AP、工业交换机、AGV车载无线终端、提升机内的有线备份网口组成。这一层的设计重点是冗余和漫游优化，后面第3节会详细展开。

第三层是平台服务层，跑的是RESTful API和MQTT消息总线，负责设备注册、任务队列管理、状态聚合、告警计算。这层不关心具体搬运动作，只维护逻辑状态，所以它对网络的要求相对宽松，断网一段时间后能自动恢复同步。

最上层是应用决策层，即智能调度引擎，负责跨层任务的拆分、排序、分配和异常重调度。所有“任务自愈”的核心逻辑都集中在这一层。四层的边界划分有个潜在原则：越靠近物理动作的层，越要求实时性和确定性；越靠近决策的层，越强调容错和恢复能力。这个原则听起来抽象，但实际排查问题时非常有用——一旦AGV卡住，你可以快速定位是感知层没到位，还是网络层丢了包，还是决策层逻辑判断错了，不至于一层一层去猜。

2.2 分布式架构在工厂里的落地姿势

很多工厂项目的通病是把调度系统做成一个单体服务，所有模块在一个进程里跑。这次我们没有这么做，原因是跨层搬运有个特殊点：提升机是稀缺资源，两台提升机要服务5台AGV和几十个搬运任务，一旦调度服务宕机，所有跨层任务全部会卡在等待分配状态。单机部署等于把整个仓库的命脉押在一个进程上，扛不住。

因此我们把系统拆成了4个核心服务：设备接入网关、任务调度服务、状态监控服务和告警通知服务。设备接入网关负责跟AGV和提升机通信，做协议转换、心跳保活；任务调度服务负责任务拆解、分配和重调度；状态监控服务持续轮询各设备状态，发现异常就写告警事件；告警通知服务再负责把事件推给现场大屏和运维手机端。这四个服务之间通过消息队列解耦，任何一个服务重启都不会让整个系统瘫痪。

服务拆分的代价是增加了部署和联调成本，但收益也很明显。有一次任务调度服务的JVM内存泄漏导致频繁重启，如果是单体架构，整条搬运线就停了。拆分之后设备接入网关和状态监控还在正常运行，AGV至少能保持原地待命而不是乱跑，调度服务恢复后任务自动继续流转，损失控制在5分钟内。

2.3 通讯链路与数据回传设计

链路层我们选了两条路并行。AGV车载终端优先走Wi-Fi，通过MQTT上报状态，通过REST接口接收任务指令；但每台AGV在提升机上还接了一根有线网口做备份——AGV开进提升机后，车体底部的探针会和提升机地坑里的工业网口对接，形成一条有线链路。

当时有人质疑这个设计是多此一举，认为既然装了无线终端，何必再搞有线对接。但实际运行中这条有线链路救了无数次场。提升机内Wi-Fi信号弱是一回事，更麻烦的是AGV在提升机里停放的位置会遮挡天线方向，哪怕补了AP，信号强度也只是从“完全不可用”变成“基本可用”，时延依然不稳定。有线对接虽然只覆盖“AGV在提升机内”这个短暂阶段，但恰恰是最需要确定性通信的阶段——因为要执行精准停靠和楼层确认。

数据回传的细节上，我们规定所有AGV状态上报的MQTT QoS级别为1，确保消息至少送达一次。同时设备接入网关维护了一个本地的状态快照缓存，即使断网30秒，网关也能基于最后一次已知状态做初步判断，等链路恢复后再补报增量事件。

3. 信号盲区治理：用实测数据说话

3.1 盲区是怎么被发现的：现场勘测与RSSI数据记录

信号盲区不能靠感觉判断，必须用数据说话。我们带着手持频谱仪和连上测试终端的笔记本电脑，沿着AGV的完整运行路径走了一遍，每隔2米记录一次RSSI和丢包率。这个工作看起来笨，但价值极高——很多“看着信号很好”的位置，实测丢包率已经高得离谱了。

测试结果整理出来后，三个盲区点非常清晰：提升机井道内部，平均RSSI -88dBm，丢包率55%；提升机门区（卷帘门关闭状态），平均RSSI -72dBm，丢包率18%；二楼货梯口缓冲区，因为两层楼板间的钢筋网屏蔽，平均RSSI -70dBm，丢包率15%。

这几个数据直接决定了后续动作：井道内必须补AP或使用有线备份；门区可以通过调整天线角度和增加漫游阈值优化；二楼缓冲区则需要增加一台AP来消除楼板屏蔽带来的信号凹陷。没有这些实测数据，补点工作就会变成“哪里卡了补哪里”，既没有优先级也没有验证基线。

3.2 漫游与频段规划的优化细节

信号盲区不是只靠加AP就能解决的，漫游策略不优化，AGV会在两个AP之间反复横跳，产生频繁的断线重连。我们做了三个具体调整。

第一，把AGV车载无线终端的漫游阈值从默认的-70dBm调到-75dBm，避免AGV在AP边缘区域过早触发漫游。默认阈值对手机来说是合适的，但AGV在运动中切换漫游意味着短暂丢包，而丢包就会影响指令接收，所以宁可让它在弱信号区多坚持一会儿，也不要频繁切换。

第二，手动规划信道，把相邻AP分配到互不干扰的信道。现场因为周围还有办公Wi-Fi和蓝牙设备，2.4GHz频段非常拥挤，我们把AGV业务全部锁定在5GHz频段，2.4GHz留给非实时设备。5GHz穿墙能力差，但带宽高、干扰少，适合AGV这种需要低时延但移动范围固定的设备。

第三，给AGV的无线终端关闭了802.11r快速漫游协议。原以为这个协议能加快漫游速度，结果实测发现它和厂区现有的认证服务器存在兼容问题，反而导致漫游时认证超时。关闭后漫游切换时间从800ms降到200ms，体感明显变好。

3.3 补点方案与终端容错：双保险思路

补点方案我们采用了分布式AP接入方式，在提升机井道顶部和底部各加装一台工业级AP，天线方向对准井道内部，并用定向天线减少信号外泄。这里有个经验：提升机井道内补AP，一定不要用全向天线，因为全向天线会把信号打在金属壁上反射，形成多径干扰，效果反而更差。定向天线把波束对准AGV停靠位置，信号更集中。

补点之后我们又做了3天的连续性测试，把AGV来回跑跨层任务100多次，持续记录RSSI和任务成功率。最终的优化结果：井道内RSSI从-88dBm提升到-65dBm，丢包率从55%降到2%以下；门区丢包率从18%降到5%；整个跨层搬运任务的一次成功率从82%提升到96%。

但即便做了这些优化，我们依然保留了“终端容错”的设计。AGV车载端增加了一个数据缓存队列，时间窗口为10秒，网络断连期间AGV可以继续执行当前指令并缓存状态变更，链路恢复后一次性补报。这样做的逻辑是：网络不可能做到100%，但任务执行不能因为网络抖动而中断，终端必须有“断网继续干活”的能力。

4. 任务自愈逻辑的设计与实现

4.1 任务状态机的核心设计

任务自愈的前提是状态清晰可追溯。我们给跨层搬运任务设计了6个状态：PENDING（等待执行）、DISPATCHED（已下发）、ARRIVED（已到达提升机口）、TRANSFERRING（跨层转运中）、COMPLETED（已完成）、FAILED（失败）。

每个状态都有明确的超时时间，超过就触发自愈动作。比如DISPATCHED状态下，AGV超过60秒没有上报位置更新，调度服务就认为下发可能丢失，重新下发一次指令；TRANSFERRING状态下，AGV超过90秒没有上报楼层到位确认，系统就进入提升机异常处理流程。

状态机最大的价值是把“异常”从隐性问题变成显性问题。以前没有状态机的时候，AGV卡住了，系统里只有“最后一次心跳时间”和“当前任务ID”，根本不知道它卡在哪个环节。有了状态机，一看状态就知道卡在哪，下一步该做什么也就清楚了。

4.2 心跳与租约机制：分布式场景的“保命”策略

AGV和设备接入网关之间的心跳是基础保障，心跳周期设为500ms，连续6次心跳丢失（即3秒无心跳）判定设备离线。但这个机制有个问题：心跳丢失不等于任务失败，可能是网络瞬断，也可能是AGV正好在提升机井道内信号弱。如果一丢心跳就立刻判定失败并重调度，反而会造成任务重复执行。

所以我们引入了任务租约机制：设备接入网关维护一个租约表，每台AGV有一个租约ID和租约截止时间。调度服务在分配任务时，会先检查AGV的租约状态——租约有效，任务才能分配；租约过期，就先把AGV标记为“待恢复”，等心跳恢复并确认位置后再重新分配任务。

租约机制的实现不复杂，但逻辑上很关键。它把“设备在线”和“设备可执行任务”分成两个判断维度：设备在线但任务租约过期，说明链路曾经中断过，需要重新确认；设备在线且租约有效，才能安全下发新任务。这个设计避免了最让人头疼的问题——重调度后AGV旧任务还在执行，新旧指令叠加导致它跑错楼层。

4.3 超时熔断与任务重调度

跨层任务执行过程中，最怕的是同一个环节反复失败。所以我们在自愈逻辑里加了一个熔断器模式：每个任务最多重试3次，超过3次就进入FAILED状态，不再自动重试，等待人工介入。

这个熔断设计是因为我们踩过一次坑。系统刚上线时，任务调度逻辑是“只要失败就重新下发”，结果发生过一件事：提升机二层的到位传感器因为灰尘遮挡触点，光电信号偶尔丢失，AGV每次都走到位了但系统判定不到位，任务被反复重试了8次。重试过程中一层有3台AGV陆续到达提升机口排队，后面的任务越积越多，整个仓库的搬运效率暴跌。

后来加了熔断器并辅以失败原因分类：对于可以明确排除的偶发故障（如网络超时），允许重试；对于现场物理设备故障（如传感器信号丢失），直接判定FAILED并通知人工处理，不让系统在同一个坑里反复跌倒。这个区别非常重要——自愈逻辑不是让系统无限重试，而是让系统知道哪些错可以自己纠正，哪些错必须交给人。

4.4 幂等恢复：断电恢复后不乱跑

AGV在跨层过程中还有一个很隐蔽的场景——意外断电。尤其是AGV在提升机内断电的情况，既不能前进也不能后退，恢复供电后调度系统必须知道它到底在哪里、执行到哪一步了。

幂等恢复的核心理念是：恢复后的动作不能依赖不确定的中间状态，而必须以持久化的最后确认状态为准。我们在设备接入网关里增加了一个断电恢复记录表，AGV每次进入一个确定状态（比如“到达提升机口”、“进入提升机”、“楼层到位”）都会同步写一条确认记录到本地和网关。断电恢复后，网关从数据库读取最后一条确认记录，把AGV恢复到该状态对应的安全动作——比如恢复到“进入提升机”状态，就重新执行楼层确认流程；恢复到“到达提升机口”状态，就重新呼叫提升机。

这个设计最大的好处是让恢复过程可预测、可审计。每次断电恢复后，运维人员能清楚看到AGV恢复到了哪个逻辑位置，而不是靠猜。实际运行中，这个机制也帮助我们排查过两次AGV位置传感器偶发故障，因为恢复记录里的位置和传感器实际读数不一致，一下子就暴露了传感器异常。

5. 常见问题排查实录与避坑经验

5.1 三个典型故障案例

第一个案例是AGV在提升机内“假死”。表现为AGV心跳正常、任务状态正常，但车就是不动。排查过程发现是提升机到位传感器把“未到位”信号误报为“已到位”，AGV收到确认后准备开出，实际上提升机还没升到目标楼层，安全逻辑自动停机。这个问题靠任务状态机看不出来，因为状态机里“楼层到位”的判断来自传感器，传感器本身错了我这边很难察觉。解决方案是在AGV开出提升机前增加了一个“驶出前二次确认”逻辑——AGV必须同时收到传感器到位信号和调度服务下发的“楼层确认指令”才能开出，两者缺一不可。

第二个案例是二楼货梯口AP频繁掉线。现象是每天早班时报“AGV离线”的次数特别多，中午以后就恢复正常。最后查到原因是二楼窗口外的厂区照明灯太阳下山后自动开启，照明灯的电源线路和AP供电线路共用了一个配电箱，灯开启瞬间产生电压跌落，AP供电不稳直接重启。把AP供电改成独立UPS回路后问题彻底消失。这个案例教训很深：排查无线问题不能只看无线本身，供电、接地、干扰源都要查。

第三个案例是任务重调度后AGV重复执行。一次任务下发后网络瞬断，调度服务没收到ACK，按超时重发，结果AGV其实已经收到了第一次指令并开始执行。第二次指令到达后，AGV无法对账，导致同一趟搬运执行了两次。解决方法是引入了指令幂等ID——每一条任务下发指令都带唯一ID，AGV收到重复ID的指令直接丢弃，不会重复执行。

5.2 排查工具与排查思路

跨层搬运系统的故障排查比单层系统复杂得多，因为涉及的设备层级多、链路多。我们搭建了一套三层排查工具链。

第一层是实时监控大屏，展示所有AGV的当前位置、任务状态、心跳延迟、提升机状态。这一层解决的是“哪里有问题”的问题——运维人员一眼看出哪台车卡了、哪台提升机没响应。

第二层是设备接入网关的日志查询接口，按设备ID、时间范围、事件类型检索。这一层解决的是“为什么有问题”的问题——通过查看设备上报的心跳记录和指令下发记录，初步判断是网络问题、设备问题还是逻辑问题。

第三层是抓包分析，在问题设备附近的交换机上做端口镜像，抓取AGV与调度服务之间的原始通信报文。这一层解决的是“问题到底出在哪条链路”的问题——通过分析报文确认是Wi-Fi丢包、TCP重传还是MQTT消息堆积。

这三层工具缺了任何一层，排查效率都会大打折扣。最典型的例子是：如果没有抓包分析，MQTT消息堆积导致的消息延迟和网络延迟在表面上看起来一模一样，但处理方法完全相反。

5.3 架构层面值得提前埋好的“安全垫”

这个项目跑下来，有几条经验我觉得值得提前规划，而不是等问题出现了再补。

第一，所有关键指令必须设计幂等ID。不管是任务下发、提升机呼叫还是楼层确认，每条指令都要带唯一ID，消费者端要去重。这件事在架构设计阶段做成本很低，后面再加就很麻烦——因为去重逻辑要嵌入到所有业务流程里，改一处漏一处。

第二，状态监控一定要独立于业务服务。我们把状态监控服务单独部署，即使任务调度服务宕机，监控服务依然能持续接收设备心跳并记录状态变化。这让我们在故障期间能保留完整的现场数据，恢复后可以分析出故障原因，而不是一团黑。

第三，所有任务执行记录必须持久化到数据库。中间状态的记录宁可多写、不要少写。排查问题时最怕的就是“知道有故障，但没有现场数据”，所以AGV每到一个关键位置，哪怕只是路过，都写一条位置点记录。日志存储成本很低，排查问题的效率提升是成倍的。

第四，预留人工干预接口。再好的自愈逻辑也不可能覆盖所有场景，所以系统里一定要有“人工接管”的入口——运维人员可以手动把某台AGV置为FAILED状态、手动指定某台提升机关闭检修、手动把一个卡住的任务作废重来。这些操作在系统稳定的时候用不上，但故障来临时能救命。

说实话，跨层搬运的IoT架构做下来，我的感触是：方案设计阶段80%的精力应该花在“链路断了怎么办”这个假设上，而不是花在“如何让链路更稳定”上。链路优化当然要做，但你永远做不到100%稳定，所以系统必须学会在“不完美的网络”下优雅运行。信号盲区和任务自愈，本质上是一枚硬币的两面——盲区提醒你不要把网络当成可靠资源，自愈逻辑告诉你如何在不完美中保持正确。

如果你也在做类似的跨层搬运或者立体仓库项目，我建议你在开工前先回答清楚三个问题：设备在盲区里能不能安全停下？任务在断网后能不能准确恢复？系统在反复重试时会不会自己“卡死”？这三个问题想清楚了，项目就成功了一大半。