Fujitsu Kozuchi Physical OS并不是安装在单台机器人上的通用操作系统，而是Fujitsu正在开发的具身智能（Physical AI）平台：它把机器人、传感器、业务系统和物理空间连接起来，让多类设备在同一运营指令下协作。其构想是把从人类示范与历史经验中获得任务适应能力的“Brain Intelligence”，与描述机器人现实作业环境的“Spatial Intelligence”结合起来。截至2026年8月，该项目仍以研发、企业合作和分阶段集成为主，并非已经公开发行的完整产品。
名字里有OS，但它不取代Windows或ROS
“Physical OS”指的是协调工厂内机器人与空间信息的公共底座，其角色不同于电机驱动、实时控制器或ROS 2节点等负责单机关节动作的软件。Fujitsu称将用从云端到边缘的一体化基础设施，处理实时性、可靠性、安全、数据主权和治理。
因此，引入Kozuchi Physical OS并不会让各厂商控制器消失。现场仍然保留FANUC、Yaskawa、Kawasaki等厂商的安全控制与动作指令，以及PLC和设备互锁；Physical OS更像上层协作层，连接业务计划、空间状态、多机器人任务分配和数据政策。
| 层级 | 主要职责 | 与Physical OS的关系 |
|---|---|---|
| 业务系统 | 生产计划、库存、医院运输请求和优先级 | 下发机器人应完成的目标与约束 |
| Physical OS | 空间状态、任务分配、多机器人协作和治理 | 在异构系统之间提供公共协调层 |
| 车队与机器人控制 | 路径规划、设备命令和避碰 | 把上层指令转成各设备可执行命令 |
| 安全控制 | 急停、速度与区域限制、设备互锁 | 需要独立于AI判断的确定性保护 |
| 物理设备 | 机械臂、AMR、传感器、门与电梯 | 上报状态并执行获批动作 |
Brain Intelligence把“做什么”与任务经验连接起来
Fujitsu的Kozuchi Physical OS官方公告把Brain Intelligence描述为一项基于历史经验和人类模仿、提升机器人任务适应性的能力。目标是超越只执行固定坐标和顺序的自动化，在物体位置或工序状态变化时选择替代方案。
即便这一层接收自然语言业务指令，实际动作也只能从获批能力清单中调用。例如，“把药品送到病区”还要核对可运输的机器人、获准路线、温度要求和接收人。若把语言模型生成的计划直接发送为关节命令，就可能绕过业务规则和安全控制。因此要在审计日志中保留计划来源、批准人、模型版本和异常处理。
Spatial Intelligence表达的是“此刻能做什么”，不只是地图
空间信息不能只是一张固定墙体与通道地图。人员位置、移动推车、门的开闭、电梯状态、工位占用、危险区和机器人携带的物体都会随时间变化。Spatial Intelligence试图共享这些现实状态，让不同机器人和AI智能体理解同一个现场。
它也不同于静态数字孪生。即使设备3D模型很精细，只要传感器更新滞后，机器人仍会把已被封堵的通道用于规划。对象信息除了坐标，还应带有观测时间、置信度、所有者和过期时间。摄像头与激光雷达定位偏差可从VIO与SLAM对比理解；到了Physical OS层，这类局部误差可能扩散到多台机器人的共享判断。
多机器人协作更难的是权限与责任，而不是共用地图
不同厂商的AMR、机械臂和人形机器人同场运行，仅把消息格式对齐还不够。谁拥有通行优先权，门与电梯由谁预约，一台设备停机后任务交给谁，都需要明确。Fujitsu在2026年7月宣布，与FANUC、Yaskawa Electric和Kawasaki Heavy Industries研究业务机会，并推进标准化、开放式协作控制底座。
Fujitsu在2026年7月发布的官方公告把制造、物流零售和医疗列为首批应用方向，举例包括按生产变化与现场状态调整工厂计划、按销售和库存组织物流，以及依据医院系统指令运输药品与标本并提供导引。这是合作研究启动的公告，并不是所有参与方机器人已经接入同一个商用Physical OS的完工报告。
设施联动的实务标准可参考用Open-RMF连接门、电梯和车队，AMR消息标准的边界可参考VDA 5050第3版指南。Kozuchi Physical OS的方向更接近把现有接口接到上层业务、空间和AI，而不是将其全部替换。
NVIDIA技术在其中承担仿真与学习组件
Fujitsu称将用NVIDIA Cosmos增强对社会与物理事件的理解和预测，并用Omniverse、Isaac和Newton物理引擎提高Sim-to-Real、机器人训练、验证与优化效率。NVIDIA机器人平台也把训练、物理仿真和边缘推理放在不同计算阶段。
世界模型生成的未来场景并非现场事实。若物理引擎中的摩擦、传感器噪声或人员行为假设不准，仿真里安全的计划仍会在现实中失败。合成数据必须标注生成设置与来源，并与真实日志分开评测。通过仿真不是现场安全批准，而是用较低成本寻找危险条件的前置步骤。
数据主权不只是决定服务器放在哪个国家
工厂工艺、医院动线、库存和员工行为都属于企业或机构的敏感运营数据。多家公司的机器人共享这些信息后，网络攻击、全系统停机、误动作和机密泄露的影响面也会扩大，这正是Fujitsu强调“主权协作控制底座”的背景。
主权要求除了数据存放国家与云环境，还包括谁能看原始图像、数据是否被再次用于模型训练，以及衍生空间表示归谁所有。维护账号不应默认访问所有机器人；命令批准和模型更新要有签名与审计。中央平台断开时，各机器人也应能安全停车或继续受限运行。
| 失败场景 | Physical OS应准备的响应 | 需要验证的记录 |
|---|---|---|
| 空间状态滞后 | 让过期对象和通道信息失效，并采取保守重规划 | 观测时间、置信度和废弃理由 |
| 单台机器人停机 | 转交任务、隔离通道，避免车队连锁等待 | 故障开始、交接和恢复时间 |
| 厂商API变更 | 锁定适配器版本并支持分阶段回滚 | 兼容表、测试结果和部署批准人 |
| 中央网络中断 | 维持本地安全状态和受限任务 | 最后获批命令与离线动作 |
| 账号被盗 | 最小权限、命令签名和按区域隔离 | 用户与设备ID、变更历史和告警 |
| 世界模型误判 | 由确定性安全约束拒绝动作 | 预测值、实际结果和策略版本 |
部署评估应从一小块异构作业区开始
若为了验证Physical OS而一次连接整座工厂或医院，问题出现后很难定位原因。更适合的做法是选一个小区域，让两类机器人、一扇门或一部电梯和一个业务系统发生交互。例如，AMR运输药品，人形机器人在安全门前完成交接，医院系统还可能临时更改目的地。
评测值不应只是单机成功率，而应包括业务完成时间、死锁次数、使用过期空间信息的比例、人工批准次数和故障后的全局恢复时间。还要关闭平台测试安全是否保持，以及移除一家厂商适配器时其他设备会不会停机。为避免供应商锁定，合同应写入空间与任务数据导出格式和API停止服务政策。
Fujitsu表示，计划从2026财年起把研究中心技术分阶段集成到Physical OS。“分阶段”意味着产品版本、可用功能、参与企业、区域和价格仍需后续公告。采购团队应把路线图与实际可用功能分栏，并按可下载软件、现场试点和付费部署区分证据等级。
开放性要靠能否退出接口验证，而不是参与企业数量
多家大型企业参与，并不会自动让平台成为开放系统。应检查新增机器人能否使用公开适配器规范，空间状态和任务历史能否用标准格式导出，以及停止特定云服务后能否继续本地运行。即使有API文档，只要认证服务器或数据模型绑定单一供应商，替换成本仍会很高。
验证时，可以把厂商A的机器人换成模拟设备，观察相同任务请求能否继续流转；还要测试适配器回报错误时全局规划器是否会停摆，旧版API能否在一段时间内并行，以及数据模式变更是否提前通知。合同应写明可导出的原始数据范围、终止后的保存期、适配器源码或托管条件，以及停止支持版本的安全措施。平台价值不只在连接设备数量，还在移除一个组件后仍能保留运营资产和记录。
常见问题
Kozuchi Physical OS会取代ROS吗？
官方公告没有把它描述成ROS替代品。它更像把机器人、传感器、业务系统和空间连接起来的上层协作平台，而不是单机控制软件。
现在可以直接下载并安装Kozuchi Physical OS吗？
公开资料谈的是开发、分阶段集成和企业合作；通用软件包的公开下载、价格及支持环境仍需独立产品公告。
有了空间世界模型，机器人碰撞就会消失吗？
不会。传感器延迟、遮挡和模型误判仍然存在，急停以及速度、区域限制等确定性安全控制必须与AI预测分离。
已核验的官方资料
最后核对：2026年8月23日