同时使用不同厂商的机器人，并不需要让一个中央AI直接操纵每台设备。更现实的具身智能（Physical AI）架构是：上层系统协调任务、路线以及门禁、电梯、充电桩等共享资源，各厂商控制器继续负责行驶、避障和急停。接上通用API还远远不够，坐标、状态与错误的含义、最小权限安全、数据使用规则和故障隔离，都必须统一。
同屏显示只是监控，任务能够交接才算协同
控制台同时显示A厂AMR与B厂服务机器人的图标，如果它们不能互相交接任务，也无法安全预约同一部电梯，这仍然只是监控层整合。多厂商运营必须走到以下环节：机器人声明自己能做什么，上层协调器分配任务，并用统一含义回传执行状态与失败原因。
Open-RMF官网把Open Robotics Middleware Framework描述为免费的开源模块化系统，用于帮助多支机器人车队与门、电梯和楼宇管理系统共享资源、实现互操作。它最初面向医院，也可用于办公室、机场、港口、商场、工厂和物流中心。框架提供连接点，并不等于保证任何具体现场都能即插即用。
| 控制层 | 必须统一的内容 | 应留给厂商或现场的内容 |
|---|---|---|
| 业务 | 任务类型、优先级、完成与取消语义 | 各机器人可执行任务及限制 |
| 移动与资源 | 地图基准、路径冲突、门、电梯与充电预约 | 本地避障和实时安全控制 |
| 状态与故障 | 等待、执行、中止、恢复状态和故障等级 | 厂商专有诊断与维护流程 |
| 治理 | 身份认证、权限、审计和数据政策 | 设备密钥、安全认证和现场急停 |
上层系统分配任务，实时安全留在机器人本体
中央协调器可以把“从3层药品库送到检验室”这样的任务分给合适车队，并安排路线及共享资源的使用顺序；车轮应以多少rpm转动、发现人员后应在多少ms内停车，则由机器人本地控制器和独立安全装置负责。
保持这条边界后，即使网络短暂中断，机器人仍能避开人员并安全停车。反之，若中央服务器实时直接操纵关节或车轮，网络时延和服务器故障会立刻传导到现场风险。上层软件不应拥有绕过厂商安全功能的权限。
上层指令还需要有效期。如果通信恢复后照常执行10秒前收到的“进入通道”指令，通道里可能已有其他设备。机器人应先重新上报状态，获得新授权后再移动。
适配器必须翻译坐标、状态转移与恢复含义
两台机器人即使使用同一张地图，原点、楼层高度和可通行门宽也可能不同。A厂可能把距目标20cm判为“到达”，B厂则用1m；若不把坐标转换、允许误差、机器人外廓和限速统一进公共模式，控制台显示已到达，机械臂却可能够不到工作台。
状态名称同样需要语义转换。paused可能表示安全停车，也可能只是等待运营员；failed可能是可自动重试的错误，也可能需要现场回收。车队适配器不能只改消息格式，还要把状态转移与可恢复性映射成公共语义；未知的新错误码不能当作“正常”，而应进入隔离状态。
版本管理也是适配器的一部分。机器人固件或API更新后，原有状态码与路径响应可能变化。每种机器人都应保存支持版本、兼容性测试和可回滚的适配器包，避免夜间升级后整支车队停摆。
下发任务前还要协商能力。同为“搬运”机器人，最大载荷、通过宽度、可到楼层、对接装置和冷藏箱支持各不相同。上层系统应依据机器人当前上报的能力与状态分配任务，而不是固定型号名称；信息过期或缺少必要能力时，不得下发。能力描述发生变化后，应把适配器和调度规则放在一起测试。
电梯、门和充电桩的死锁比机器人对话更难
多厂商现场最棘手的往往不是机器人互相通信，而是共享唯一设施。两支车队从不同楼层预约同一部电梯，或多台低电量机器人同时涌向充电桩，都会引发资源死锁和长时间等待。通道、门、电梯和工位必须建模成可预约资源。
每次预约要有开始与到期时间、所有者和失败释放规则。机器人在电梯内失联后，如果预约永久保留，其他车队也会停下；到期时间过短，又可能让设备在移动途中失去权限。应依据真实行程耗时分布与最坏条件设置。
优先级政策也要对应现场业务。医院的紧急样本运输和废弃物搬运不能按相同顺序排队；但若高优先任务不断进入，普通任务也不能永远被饿死，因此要设置最长等待时间和人工调整程序。
死锁测试可以从两台机器人在狭窄通道两端互相等待开始。如果双方都不能决定谁后退，中央协调器应指定安全等待点和重新规划路线。机器人同时持有电梯与充电预约时，还要固定多资源获取顺序，或允许释放其中一项。相比一时吞吐量下降，避免整个现场停摆更重要。
开放API必须与最小权限、签名和供应链审计绑定
开放并不意味着任何系统都能发送任何命令。订单系统只应拥有创建任务的权限，楼宇系统只管理门和电梯状态，维护账户只诊断指定机器人；运动指令和解除急停需要更强的认证与审批。
每台设备和每项服务都要有独立身份，并使用双向认证通信。命令应带上发送者、目标、时间、到期和签名，以识别重放与篡改；密钥泄露或供应商账户被入侵时，应只封禁相关车队，其他机器人继续运行。
适配器和插件本身也可能成为供应链攻击路径。应验证发布包来源与签名，把所需网络和文件权限列入清单，并先在隔离测试车队运行新版本。维护软件资产与发布谱系后，漏洞出现时才能马上定位安装了该版本的机器人与服务器。
Fujitsu在日本推进Physical AI合作的官方公告称，Fujitsu于2026年7月16日开始与FANUC、Yaskawa Electric、Kawasaki Heavy Industries探讨融合NVIDIA技术的协同控制平台商机。公告明确指出，应用范围扩大也会加剧网络攻击、系统整体中断与误动作、机密信息泄露风险。这是研发和标准化方向，不是已经完成的通用平台商业性能发布。
数据主权不仅是服务器放在哪个国家
数据主权的范围远大于选择存储国家。还要控制谁能查看传感器原始数据，供应商能否把它用于故障分析或模型训练，派生特征与模型能否传出境外，以及合同结束后怎样删除。
Fujitsu表示，要把连接数字世界与物理世界、同时保障主权的协同控制基础发展成开放平台。制造、物流和医疗现场分别包含工艺机密、销售库存与患者移动等敏感信息；即使只分享机器人坐标，也可能推断产量和设施布局，所以仅保护视频文件并不足够。
| 数据类别 | 合同与技术控制应约定 | 需要查验的证据 |
|---|---|---|
| 实时位置与状态 | 访问者、保留期和外部传输范围 | 权限表与访问审计日志 |
| 视频与传感器原始数据 | 最小化采集、脱敏和训练使用同意 | 数据谱系与删除测试 |
| 故障与维护日志 | 各供应商查看范围和事故共享方式 | 按事件留存的查阅与导出记录 |
| 派生数据与模型 | 所有权、再利用、跨境传输和合同终止 | 版本来源与销毁证明 |
SEER Robotics在WRC 2026发布的战略也提出连接机器人模型、控制与车队层以及数据网络。供应商的整合愿景可以作为参考，但数据权利和可导出性仍要在客户合同与实际API中单独核验。
把故障域切开，避免一台设备拖停所有车队
整合故障可能表现为所有机器人同时停摆。应提前规定：中央调度器宕机时，在途任务是安全完成还是停车；门服务器故障后封锁哪些区域；某一供应商API变慢时，是否会堵住整个任务队列。
熔断与超时应按车队设置。无响应机器人进入隔离，其他车队仍可接收任务；中央系统恢复后，要重新查询机器人的真实位置和任务状态，不能用服务器里的旧状态覆盖现场，现场观测应优先于最后一条正常数据。
离线运行范围也必须有限。机器人可以在失联时本地避开普通障碍，但没有上层预约就不能进入电梯和狭窄通道。急停应不依赖网络，解除则只能由核实现场的人员执行。
用两台机器人验证语义与恢复，再扩展到整座设施
首个试点只放入不同厂商各一台机器人和一项共享设施。重复相同取货与放货任务至少50次，记录坐标误差、状态转换、资源等待与远程介入；成功运行后，再主动注入通信中断、门无响应、低电量和未知错误码，验证隔离与恢复。
可结合Open-RMF多机器人联动、VDA 5050 3.0标准解读和VIO与SLAM对比，具体检查设施对接、消息标准与定位方法的差别。
扩展前要把接入一种新机器人所需的适配器开发时间、兼容性测试、安全审查和故障恢复演练计入成本。与其看“支持标准”的复选框，不如核对真实消息版本、可选功能和厂商错误映射；还要检查各供应商的价格、支持与数据条款是否在合同中互相冲突。
扩展后要同时观察吞吐量与隔离能力。总吞吐量提高，可能掩盖某种机器人长时间等待或优先级饥饿；应把各厂商任务成功率、等待、适配器错误、设施预约冲突和人工恢复与总指标并列，并在升级后逐车队检查回归。
安全指标应包括被阻断命令、过期证书、过度授权和异常数据导出。数据主权政策必须通过真实执行删除与导出阻断来验证；故障演练则依次断开中央服务器、某供应商云端和楼宇系统，测量安全状态及剩余服务范围。
多厂商运营的成熟度，不取决于一个屏幕上放了多少品牌标志，而在于新增供应商后能否保留统一语义、隔离单点失败，并让现场所有者持续掌握命令与数据控制权。
常见问题
不同厂商的机器人出现在同一控制台，就算完成整合了吗？
通常只能说明监控已汇总。还要验证任务分配、状态与故障语义、门、电梯和充电预约，以及失败后的隔离与恢复，才能称为运营整合。
支持Open-RMF或VDA 5050后，机器人可以直接互通吗？
不能直接假设。必须用真实消息测试标准版本、可选功能、坐标系、状态转移、厂商错误码与安全责任；相同标准名称下的实现范围也可能不同。
给多机器人平台开放API，会不会必然降低安全性？
开放本身不决定安全强弱。为设备分配独立身份与最小权限，对命令加入签名和到期时间，保留审计日志并支持按车队封禁，才是可控连接的基础。
已核验的官方资料
最后核对：2026年8月23日