两份契约，一条走廊

这个问题会在第三次会议上出现，问的人是凌晨三点要负责处理事故的那一位。你们的演示有 Wi-Fi。那么在电梯里、在地下室里、在某个接入点重启之后的那几秒钟，机器人会做什么？

我们找到的两份文件，为一台失去机群管理系统的移动机器人白纸黑字地回答了这个问题，而两份的答案相反。

VDA 5050 3.0.0 版是德国汽车工业界制定的机群控制系统与移动机器人之间的接口。按它的规定，一台机器人若在断链期间占用某一空间的许可到期，就停车，并上报一条级别为 CRITICAL 的 RELEASE_LOST 错误。按 MiR 的《Fleet Enterprise Documentation》，一台机群已经联系不上的机器人保留手里已有的资源，做完已经派给它的任务，而在五分钟没有通信之后，被允许 "continue the mission without waiting to be assigned resources"，即不等资源分配就继续任务——也就是说，去占它从未被分配到的地方。

两者都已公布，两者都站得住，本文不说哪一个是对的。本文要说的是：一家医院若运行两家厂商的配送机器人，就可能在同一条走廊里同时得到这两种行为，而把两者调和起来的文件，一份也没有。

两份都没有公布检测时间——机器人要多久才察觉链路断了。这不是遗漏。2026 年 9 月 11 日，这两份文件连同另外三份规范都被从头读到尾，而原因是结构性的：机器人接下来做什么，走的是它手里已经有的一个时钟，不是靠察觉。

第一份契约

VDA 5050 v3.0.0 读的是 VDA 自己仓库里的 3.0.0 标签，不是 main，也不是摘要。标签发布于 2026 年 3 月 18 日；规范是一个 208,085 字节的文件 [已通读]。

它的基线行为是宽松的。§4.1："If the mobile robot disconnects from the broker, it keeps all the order information and fulfills the order up to the last released node."，即移动机器人若与代理（broker）断开，保留全部订单信息，并把订单执行到最后一个已释放节点。

§7.7 定义了四种连接状态，而其中的区分正是这次的发现："'OFFLINE': connection between mobile robot and broker has gone offline in a coordinated way"，即机器人与代理之间的连接以协调方式下线；对应的是 "'CONNECTION_BROKEN': the connection between mobile robot and broker has unexpectedly ended"，即连接意外终止。两个事件，两个名字——§6.5 还给了它们两套流程：协调下线由机器人执行，意外中断由代理发布机器人的遗嘱消息（last will）。第四种状态 HIBERNATING 覆盖低功耗保持：机器人停止发送状态消息，与代理的连接却保持着。

唯一一条说明"机器人不在了"的通道，自己声明不是健康信号：§4.3 的主题表把 connection 描述为 "Not to be used by fleet control for checking the mobile robot health, added for an MQTT protocol level check of connection"，即不供机群控制系统检查机器人健康之用，加入它只是为了 MQTT 协议层面的连接检查。

真正让机器人停下的是许可。区域（zone）带一个 releaseLossBehavior——§6.4.1.1，枚举值为 STOP、CONTINUE 与 EVACUATE——并且 "If not defined, the mobile robot is expected to STOP and report an error. 'STOP': Mobile robot stops and sends a 'RELEASE_LOST' error with level 'CRITICAL'."，即未定义时机器人应停车并报错；STOP 是机器人停车，并发送一条级别为 CRITICAL 的 RELEASE_LOST 错误。通道（corridor）带一个更窄的——§7.3，枚举值为 STOP 与 RETURN，其中 "'STOP': Mobile robot shall stop and await manual intervention"，即机器人应停车并等待人工干预，并且 "Default: 'STOP'."。两个枚举，同一个默认值。

这份文件把一家医院会以为它涵盖的东西明确排除在外。§2 适用范围："This document does not define functional, operational, or system safety requirements and shall not be regarded or applied as a safety standard."，即本文件不定义功能、运行或系统安全要求，不得被视为或用作安全标准。同一条还写明，它 "does not allocate responsibilities among operators, system integrators, vehicle manufacturers, or fleet control providers"，即不在运营方、系统集成商、车辆制造商与机群控制系统供应商之间分配责任，而对它的使用 "is optional and non-binding"，即是可选的、不具约束力的。本文引用的任何一条要求都不是安全要求；文件自己这样说。

第二份契约，以及我们一直没搜对的那个词

我们此前根据一次检索得出结论：没有哪家机群厂商公布过这样的东西。那是错的，而且值得记下来：我们搜的短语是 "degraded mode"，降级模式。MiR 用的词是 Unavailable（不可用），写在一份没有哪个搜索引擎会为我们那个短语翻出来的产品手册里。一次检索一无所获，我们就把它读成了这个领域一片沉默。这个领域并没有沉默。

《MiR Fleet Enterprise Documentation》（英文版），01/2025，v.1.2，©Copyright 2024–2025: Mobile Industrial Robots A/S，§2.17.5 "Unavailable robots" [已通读]。我们读的这一份由一家德国经销商镜像，不是从 MiR 自己的门户取得。文件的身份没有疑问——每一页都有 MiR 的版权页脚、标题与版本号——但托管方不是 MiR。

这一条开头写道："When MiR Fleet cannot communicate with a connected robot, the robot is considered Unavailable."，即 MiR Fleet 无法与一台已连接的机器人通信时，该机器人被视为 Unavailable。随后是六项后果。机器人保留进入该状态时手里的资源；不能再被分配新的资源、任务、充电器或待命位；不能交换避碰数据。还有："Continue executing missions they were assigned before losing connection."，即继续执行断开连接之前分配给它们的任务。

然后是让 MiR 与 VDA 5050 相左的那条规则：

"If the robot needs a resource that it was not assigned before losing connection, it waits until it either reconnects to MiR Fleet and is assigned the resource, or until five minutes without any communication with MiR Fleet passes and the robot is permitted to continue the mission without waiting to be assigned resources. If the communication is ever re-established, the robot will revert to waiting for fleet resources like all other active fleet robots."

大意是：机器人若需要一项断开连接前未分配给它的资源，它会等待，直到重新连上 MiR Fleet 并获得分配，或者直到与 MiR Fleet 没有任何通信满五分钟，此时机器人被允许不等资源分配就继续任务。一旦通信恢复，机器人会像其他所有活跃的机群机器人一样，回到等待机群资源的状态。

这是一个从失去通信起计的资源等待超时，不是检测时延，也无法与检测时延相比。能否配置，文件没有说，我们也不知道。

MiR 公布了两件 VDA 5050 没有公布的事。调度端的情形，§2.17.2："When MiR Fleet starts up again, all robots are re-evaluated and resynchronized before being considered as active robots."，即 MiR Fleet 重新启动时，所有机器人先经重新评估与重新同步，才被视为活跃机器人。以及一种有名字的协调断开，§2.9.4 "Standalone robot"（独立机器人）：其中 "the robot creates a local MiR Fleet that runs on the robot itself"，即机器人在自身上创建并运行一个本地的 MiR Fleet，而 "Occupied resources are handled in the same way as if a physical obstacle is blocking the position"，即被占用的资源按有物理障碍物挡住该位置的方式处理。

两者相左，走廊就在这里

带着 CRITICAL 错误停车，或者在五分钟之后去占新的地方。两份文件都是现行版本，描述的都是同一类机器，而一支混合机群两种都在跑。

1 · 已连接

• VDA 5050 v3.0.0§6.6——状态消息在相关事件发生时发布，或至少每 30 秒一次。§4.3——connection 主题“Not to be used by fleet control for checking the mobile robot health”，不供机群控制系统检查机器人健康之用。
• MiR Fleet Enterprise Documentation v1.2§2.17.5——已连接的机器人“like all other active fleet robots”，像其他所有活跃机群机器人一样，等待资源分配。§2.22——“The synchronization is only from MiR Fleet to the robots.”，同步只从 MiR Fleet 到机器人。
• Tidewell——设计目标Crew：现场网络内每台机器人共享一份受治理的记忆。已公布的设计，不是测量。

2 · 断链

• VDA 5050 v3.0.0§7.7——四种连接状态，两个不同的事件、两个不同的名字：“‘OFFLINE’: connection between mobile robot and broker has gone offline in a coordinated way”（以协调方式下线）对应“‘CONNECTION_BROKEN’: the connection between mobile robot and broker has unexpectedly ended”（连接意外终止）。§6.5 给了它们两套流程。
• MiR Fleet Enterprise Documentation v1.2§2.17.5——“When MiR Fleet cannot communicate with a connected robot, the robot is considered Unavailable.”，MiR Fleet 无法与已连接的机器人通信时，该机器人被视为 Unavailable。§2.9.4 给协调的情形起了自己的名字 Standalone robot：“the robot creates a local MiR Fleet that runs on the robot itself”，机器人在自身上创建并运行一个本地的 MiR Fleet。
• Tidewell——设计目标只公布了一个转换：断链 → Solo。我们不区分协调下线与意外断开，而上面两份文件都区分。这是我们自己契约里的缺口。

3 · 检测

• VDA 5050 v3.0.0——无数值§6.5 点了机制的名——“The disconnection is detected via a heartbeat that is exchanged between the broker and the client”，断开由代理与客户端之间交换的心跳来检测——却没有规定间隔与容差。§7.10 的 factsheet 留了四个时间参数槽位，一个也没填。§6.9：“The handling of timeouts and retries shall be defined during integration.”，超时与重试的处理应在集成阶段定义。
• MiR Fleet Enterprise Documentation v1.2——无数值通读整份文件，找不到进入 Unavailable 的时延。§2.17.5 的五分钟属于下面那个条带：它是从失去通信起计的资源等待超时，不是检测时间。
• Tidewell——2 秒以内，设计目标我们自己已公布页面上的设计目标，不是测量。机器上什么都还没测，首台 W1 原型机正在制造，所以这个条带里没有一格是实测数字——我们的那格也不是。

4 · 降级运行

• VDA 5050 v3.0.0——停车，级别 CRITICAL§4.1——“If the mobile robot disconnects from the broker, it keeps all the order information and fulfills the order up to the last released node.”，断开后保留全部订单信息，执行到最后一个已释放节点。§6.9——未获回应的许可请求按未获批准处理；leaseExpiry 到时，releaseLossBehavior 生效：区域按 §6.4.1.1（STOP、CONTINUE、EVACUATE），通道按 §7.3（STOP、RETURN），两者默认都是 STOP。STOP 意味着机器人停车，并发送级别为 CRITICAL 的 RELEASE_LOST 错误。
• MiR Fleet Enterprise Documentation v1.2——继续，五分钟后去占新的地方§2.17.5——六项后果。机器人保留手里的每一项资源，不能再被分配新的资源、任务、充电器或待命位，不能交换避碰数据，并继续“executing missions they were assigned before losing connection”，执行断开前分配的任务。若需要一项未分配的资源，它等到重连，“or until five minutes without any communication with MiR Fleet passes and the robot is permitted to continue the mission without waiting to be assigned resources”，或者等到与 MiR Fleet 无通信满五分钟，即被允许不等分配继续任务。五分钟是从失去通信起计的资源等待超时，不是检测时延。
• Tidewell——设计目标无需人工即自动降级为 Solo；机器人以较小的规划器和保守的交通规则继续工作；没有策略与安全功能在机器人之外运行；不在任务中途推送检查点。这里每一行都是设计目标。

5 · 重连

• VDA 5050 v3.0.0——未作规定文件中没有出现机器人侧的重连行为。
• MiR Fleet Enterprise Documentation v1.2§2.17.5——“If the communication is ever re-established, the robot will revert to waiting for fleet resources like all other active fleet robots.”，通信一旦恢复，机器人回到像其他所有活跃机群机器人一样等待机群资源的状态。§2.22.2——“Once reconnected, its site data is updated to the latest version on MiR Fleet.”，重连后其现场数据更新到 MiR Fleet 上的最新版本。
• Tidewell——设计目标重连即开始重新同步，机器人从不阻塞于上传。

6 · 重新同步

• VDA 5050 v3.0.0——无流程文件中哪里都没有调和流程，而 §6.1.2 给了理由：“the base cannot be changed. The fleet control shall therefore assume that the base has already been executed by the mobile robot.”，已释放部分（base）不可更改，机群控制系统应假定机器人已经执行了它。一条不可变的已释放路线，没有留下需要调和的东西。
• MiR Fleet Enterprise Documentation v1.2——仅单向§2.17.2，调度端的情形：“When MiR Fleet starts up again, all robots are re-evaluated and resynchronized before being considered as active robots.”，MiR Fleet 重启时，所有机器人先经重新评估与重新同步，才被视为活跃机器人。§2.22：“The synchronization is only from MiR Fleet to the robots. Changes on robots are not synchronized back to MiR Fleet.”，同步只从 MiR Fleet 到机器人，机器人上的更改不会同步回 MiR Fleet。
• Tidewell——设计目标重连后仅追加同步。设计目标；没有测过。

• 该文件在此处公布了一种行为，引用原文或标明条款号
• 该文件在此处没有规定
• 我们的——本图中每一格 Tidewell 都是设计目标，没有在机器上测过

第三份接口规范走得很近，又在门前停住。T/SSITS 204-2023《工业应用移动机器人与其调度系统的数据接口规范》，由深圳市机器人标准检测技术学会与移动机器人（AGV/AMR）产业联盟于 2023 年 4 月 4 日发布，全文在全国团体标准信息平台上免费公开，我们从头读到尾 [已通读]。它定义了两种离线状态。§3.6 物理离线："工业应用移动机器人停止向调度系统发送状态消息，并不再占据地图资源，完全脱离调度系统管控。" §3.7 逻辑离线："工业应用移动机器人不再接收调度系统任务指令消息，依然占据地图资源，没有完全脱离调度系统管控。" 它为网络通讯中断定义了一个异常代码 0x1005。而且它干脆把状态帧当作心跳帧：§7.3.1，"此帧消息作为心跳帧用于判断通讯超时……默认上报周期为 1 秒"——默认一秒一报。这是一个默认值，对照的是一个上限：VDA 5050 的 §6.6 允许状态消息之间最长相隔 30 秒，所以两个数字相差三十倍，却不是同一类数字。

两种离线状态都由人来进入。§7.3.9："IMR 车辆自动模式共有三种基本状态：空闲，运行，暂停。人工干预共有两种基本状态：逻辑离线和物理离线。" 自动模式有三种状态，离线这一对归人工干预。没有与 CONNECTION_BROKEN 对应的状态，对意外断链也没有规定任何行为。心跳更紧，用途有名，超时值仍然没有。

还有两份文件补齐了我们读到的这一组。MassRobotics 的 AMR Interoperability Standard——文件封面印的是 Version 1.0，二手来源对这个版本号说法不一——有一个运行状态 "5.1.3.4 - Offline - no current messages"，即离线、无当前消息，没有附带任何行为；它的 §1 适用范围写着 "Industrial mobile robots specifically excludes mobile robots used in education, entertainment, consumer, military, medical, surgical, and robots engaged in transport on the public highways."，即工业移动机器人明确排除用于教育、娱乐、消费、军事、医疗、外科的移动机器人，以及在公共道路上从事运输的机器人。这份美国的互操作标准，在自己的适用范围条款里把医院写了出去。Open-RMF 的 RobotMode.msg 定义了十二种模式，没有一种是离线或断开；它公布的唯一一个数字方向相反：mutex_group_supervisor/main.cpp 里硬编码的 10 秒超时，过时之后由调度方撤销机器人的占用声明，旁边的注释是 // TODO(MXG): Make this timeout configurable。OTTO Motors 无法评估：其机群文档不对外公开。在 2026 年 9 月 11 日检索过的服务机器人与医院机器人厂商中，我们没有定位到这一类的公开契约——读过上一段之后就知道，这是关于我们检索的陈述，不是关于这个领域的 [已检索，未找到]。

三份接口规范里，两份用自己的话把安全排除在外，第三份只是没有写下安全要求。VDA 5050 的排除条款已引在上文；MassRobotics 写明 "is not to be relied upon for any purposes related to safety"，即不得为任何与安全有关的目的依赖它；T/SSITS 204-2023 带有附录 E.0.3 的安全类型异常参数表和一个车体安全轮廓字段，却没有一条条款约束机器可以做什么。三份文件，三个大洲，押的是同一个架构判断：安全功能在车上，所以失去调度系统不是安全事件 [推断]。这个读法是我们的。移动机器人安全标准的条款正文我们仍未读过，不把任何东西归到它们名下；那些标准之间的适用范围缺口是另一篇文章的论点。

为什么它们都没有数字，又为什么都不需要

一台 VDA 5050 机器人要进入一段已释放的区域，先向机群控制系统请求许可。§6.9："If no response is received within the time frame required by the application, the mobile robot shall behave as if the request had not been granted and shall not perform the operation that requires explicit permission."，即若在应用所要求的时限内没有收到回应，机器人应视为请求未获批准，不得执行需要明确许可的操作。断链的机器人发出的请求得不到回应，于是它按未获批准处理。

断链之前已经拿到的许可，带着到期时间。同一条："If a request is answered with 'REVOKED', or if the leaseExpiry is reached, the mobile robot shall act according to the releaseLossBehavior defined for the requested resource."，即若请求被答复为 REVOKED，或 leaseExpiry 已到，机器人应按该资源所定义的 releaseLossBehavior 行事。而它的默认值是 STOP，附带级别为 CRITICAL 的 RELEASE_LOST。

所以，让一台失去调度系统的 VDA 5050 机器人停下来的，是租约到期，不是断链检测。这份规范从来不需要检测时间，因为它的设计不用这个量。

这条链，从头到尾——VDA 5050 v3.0.0

1. 1. 请求§6.9——机器人向机群控制系统请求占用一段已释放空间的许可。“If no response is received within the time frame required by the application, the mobile robot shall behave as if the request had not been granted.”，在应用所要求的时限内没有收到回应，机器人应视为请求未获批准。
2. 2. 批准，附带 leaseExpiry§6.9——机器人拿到的许可带着一个预先给定的到期时间。
3. 3. 链路断开§7.7——CONNECTION_BROKEN：“the connection between mobile robot and broker has unexpectedly ended”，机器人与代理之间的连接意外终止。
4. 4. 租约到期，在机器人手里已有的时钟上§6.9——“If a request is answered with ‘REVOKED’, or if the leaseExpiry is reached, the mobile robot shall act according to the releaseLossBehavior defined for the requested resource.”，请求被答复为 REVOKED 或 leaseExpiry 已到，机器人按该资源所定义的 releaseLossBehavior 行事。这一步的触发不需要任何消息。
5. 5. releaseLossBehavior 生效区域按 §6.4.1.1——STOP、CONTINUE、EVACUATE——通道按 §7.3——STOP、RETURN。两者默认都是 STOP，并且“If not defined, the mobile robot is expected to STOP and report an error.”，未定义时机器人应停车并报错。
6. 6. STOP，并发出级别为 CRITICAL 的 RELEASE_LOST 错误§6.6.5.4——错误及其级别。通道的情形见 §7.3：“Mobile robot shall stop and await manual intervention.”，机器人应停车并等待人工干预。

纵向读。每一环都是引用的条款，没有一环提到察觉。

检测——不在链上没有箭头指向它，这就是为什么没有为它公布数字。§6.5 点了机制的名——“The disconnection is detected via a heartbeat that is exchanged between the broker and the client”，断开由代理与客户端之间交换的心跳来检测——却不给它间隔与容差。§7.10 的 factsheet 给车辆留了四个可申报的时间参数槽位，一个也没填，回退路径循环指回主文件。§6.9 把剩下的交了出去：“The handling of timeouts and retries shall be defined during integration.”，超时与重试的处理应在集成阶段定义。对整份 208,085 字节的规范做一次数字时间值的正则扫描，返回一行：§6.6 的 30 秒状态上报间隔。

• 链上的一环，每一环都是 VDA 5050 v3.0.0 的一条引用条款
• 链外：没有东西指向它，规范也没有为它公布数值

规范点了检测机制的名，然后把它留空。§6.5："The disconnection is detected via a heartbeat that is exchanged between the broker and the client."，即断开由代理与客户端之间交换的心跳来检测。间隔与容差在文件里哪里都没有出现。§7.10 的 factsheet（车辆信息表）给车辆留了四个可申报的时间参数槽位，一个也没填，回退路径循环指回主文件。§6.9 把剩下的交了出去："The handling of timeouts and retries shall be defined during integration."，即超时与重试的处理应在集成阶段定义。

这个否定的最强形式，一条命令就能核对。对 3.0.0 标签下 208,085 字节的 VDA5050_EN.md 跑一个匹配数字时间值的正则表达式，返回的只有一行：§6.6，"The mobile robot state message shall be published when relevant events occur or at least every 30 seconds."，即状态消息应在相关事件发生时发布，或至少每 30 秒发布一次。整份规范只有一个数字时间值，而它是状态上报间隔，不是检测预算。文件里另一处时长是用文字写的，而且它是一个动作的例子，不是时间要求：§6.2 的 "audio signal that lasts for five seconds"，持续五秒的声音信号。

同一轮阅读在 VDA 5050 里没有找到调和流程——读过的各节里都没有重新同步。MiR 是这一组里的例外，公布了一个，单向的：§2.17.2 让调度端在重启时重新评估并重新同步每一台机器人，§2.22 写明了限制，"The synchronization is only from MiR Fleet to the robots."，即同步只从 MiR Fleet 到机器人。VDA 5050 没有的理由写在 §6.1.2："Since MQTT is an asynchronous protocol and transmission via wireless networks is not reliable, the base cannot be changed. The fleet control shall therefore assume that the base has already been executed by the mobile robot."，即由于 MQTT 是异步协议、无线传输不可靠，已释放部分（base）不可更改，机群控制系统应假定机器人已经执行了它。已释放的路线不可变且被视为已执行，于是分区之后按构造就没有东西需要调和——与仅追加设计走的是同一步棋，只是从相反方向到达 [推断]。

我们自己的契约，以及尚未写下的那一部分

一份公布出来的降级契约，是姊妹篇所说的、一份现场记忆必须保证的几件事之一。我们的写在 Crew 与大脑页上，每一行都是设计目标：断链在 2 秒内被检测到，无需人工即自动降级为 Solo（单机模式），重连后仅追加同步，没有策略与安全功能在机器人之外运行，不在任务中途推送检查点。这份清单上没有一项在机器上测过。每一项都要等到旁边写上测试日期，才成为实测值。

于是，诚实的说法比这些证据所引诱的要窄。我们不公布检测时间。我们公布的是一个检测时间的设计目标，而在我们找到的范围内，没有人公布检测时间，我们自己也在内。我们产品页上那句话——据我们所查，没有哪家厂商、哪份标准公布过可供对照的断链检测时间——经这一轮之后原样保留。MiR 公布的是资源等待超时，那是另一个量。

本文背后的研究修好了我们自己的一个页面。大脑页上的架构图，把"断链 2 秒内 → Solo"和"重连 → 仅追加同步"作为边的标签，图内没有设计目标标记，两个语言版本都是如此。限定句在下面八行的正文里，截图截不到。四个字符串，于 2026 年 9 月 11 日更正：这些标签现在在图内就写着"（设计目标）"。

然后是缺口。VDA 5050 区分协调下线与意外断开，再在其上加了 HIBERNATING。T/SSITS 204-2023 有两种协调的离线状态。MiR 有 Standalone 模式。我们只公布了一个转换：断链 → Solo。一台被告知要下线的机器人——进电梯、进入排定的无线静默时段——与一台链路断掉的机器人不是同一个事件，而医院两个都会问。我们没有公布这个区分，而我们应该公布。

有一份标准针对的是建筑而不是机器人。新加坡标准 eShop 上 SS 713:2025 的条目把它的范围描述为规定 "the requirements for integrating robots with lifts and robots with automated doorways"，即机器人与电梯、机器人与自动门集成的要求，覆盖 "abnormal conditions such as power outage or disruption"，即停电或中断等异常状况。它售价 36.10 新元，不含消费税，没有人买过，这里也没有把任何东西归到它的某一条款——我们读到的只有条目上的摘要。

所以，第三次会议上的那个问题，不再是链路断了会发生什么。一个标准组织和一家厂商都已经把它写了下来。问题是：这两种行为里你的机器人做的是哪一种，同一条走廊里另一家厂商的机器人是不是做另一种，以及——既然没有哪份文件规定机器人何时察觉——两家厂商各自愿意在合同里写下什么数字，如果有的话。要的是条款，不是宣称。两份文件能给你一份条款。关于那条走廊的答案，目前还没有人能给你。