Fujitsu Kozuchi Physical OS is not a general-purpose operating system installed on one robot. It is a developing Physical AI platform intended to connect robots, sensors, business systems and physical space so several machines can collaborate under one operational objective. Fujitsu describes “brain intelligence” that adapts from human demonstrations and prior experience, plus “spatial intelligence” that represents the working environment. As of August 2026, research, partnerships and staged integration are ahead of a broadly released finished product.
Physical OS does not replace Windows, ROS or a certified robot controller
The name Physical OS refers to a common foundation coordinating robots and spatial information across a facility. Its role differs from motor drivers, real-time controllers and ROS 2 nodes that move joints inside an individual robot. Fujitsu says it aims to connect cloud and edge infrastructure while addressing real-time performance, reliability, safety, data sovereignty and governance.
Deploying Kozuchi Physical OS therefore would not remove FANUC, Yaskawa or Kawasaki control. Vendor safety controllers, motion commands, PLCs and equipment interlocks remain. Physical OS is better understood as a higher coordination layer linking business plans, spatial state, robot assignments and data policy.
| Layer | Responsibility | Relationship to Physical OS |
|---|---|---|
| Business systems | Production plans, inventory, hospital transport requests and priorities | Provide goals and constraints for robot work |
| Physical OS | Spatial state, task allocation, multi-robot coordination and governance | Common coordination across unlike systems |
| Fleet and robot control | Path planning, vendor-specific commands and collision avoidance | Translate higher-level tasks into executable commands |
| Safety control | Emergency stops, speed and zone limits, and equipment interlocks | Deterministic protection must remain separate from AI |
| Physical equipment | Robot arms, AMRs, sensors, doors and elevators | Report state and execute authorized action |
Brain intelligence connects task choice with experience
Fujitsu's official Kozuchi Physical OS announcement describes brain intelligence as improving task adaptation through past experience and imitation of people. It targets an ability to choose alternatives when object position or process state changes, rather than executing only fixed coordinates and sequences.
Even if this layer accepts natural-language objectives, physical actions should remain inside an approved capability list. “Send this medicine to the ward” still requires an eligible robot, authorized route, temperature condition and recipient. Passing a language-model plan directly to joints can bypass work rules and safety. Audit logs should retain plan source, approver, model version and exception handling.
Spatial intelligence represents what is possible now—not only a map
Walls and corridors are not enough. People, carts, doors, elevator state, occupied workstations, hazard zones and carried objects change over time. Spatial intelligence is intended to share that live state so different robots and AI agents interpret the same scene.
This is also different from a static digital twin. A detailed 3D model with stale sensor updates can send a robot into a blocked corridor. An object record needs coordinates, observation time, confidence, owner and expiration. Errors may begin in local perception, as in VIO versus SLAM, but Physical OS can propagate them into shared decisions across robots.
Multi-robot coordination is harder in authority and responsibility than maps
When AMRs, arms and humanoids from different companies share a space, matching message formats is not enough. The system needs rules for priority, door and elevator reservations, and reassignment after a robot stops. Fujitsu announced in July 2026 that it would explore business opportunities with FANUC, Yaskawa Electric and Kawasaki Heavy Industries while pursuing a standardized, open collaborative-control foundation.
Fujitsu's official July 2026 release identifies manufacturing, logistics and retail, and healthcare as initial fields. It describes production-aware factory plans, sales- and inventory-aware logistics, and hospital-directed transport of medicines and specimens. This confirms exploration; it does not report that all participant robots already run on one commercial Physical OS.
For facility integration, see Open-RMF across fleets, doors and elevators and the VDA 5050 version 3 guide. Kozuchi Physical OS appears more likely to connect these interfaces with higher business, spatial and AI layers than replace them.
NVIDIA tools enter as simulation and learning components
Fujitsu says it will use NVIDIA Cosmos for social and physical simulation, and Omniverse, Isaac and the Newton physics engine for Sim-to-Real, robot training, validation and optimization. The official NVIDIA robotics platform likewise separates training, physics simulation and edge inference into distinct computing stages.
A future scene produced by a world model is not a factual field log. If friction, sensor noise or assumptions about people are wrong, a plan that appears safe in simulation can fail in reality. Synthetic data needs provenance and generation settings and should be evaluated separately from real logs. Passing simulation is a lower-cost way to find risk—not field safety approval.
Sovereign data means control of access and updates, not only storage location
Factory processes, hospital routes, inventory and worker behavior are sensitive operating data. Sharing them across vendors increases the blast radius of cyberattack, systemwide outage, malfunction and data leakage. That is the background for Fujitsu's emphasis on a sovereign collaborative-control foundation.
Sovereignty includes the country and cloud holding the data, who may view raw video, whether it can train models, and who owns derived spatial representations. One maintenance account should not reach every robot. Commands and model updates need role separation, signatures and audit. If the central platform fails, robots must stop safely or continue only bounded local work.
| Failure scene | Physical OS response | Evidence to record |
|---|---|---|
| Delayed spatial state | Expire stale object and route records, then replan conservatively | Observation time, confidence and discard reason |
| One robot stops | Reassign work, isolate the aisle and avoid fleetwide waiting | Fault start, handoff and recovery times |
| Vendor API changes | Pin adapter versions and support staged rollback | Compatibility matrix, tests and deployment approver |
| Central network loss | Maintain local safety and bounded missions | Last authorized command and offline behavior |
| Account compromise | Least privilege, signed commands and zone isolation | User and equipment ID, change history and alerts |
| World-model error | Reject action with deterministic safety constraints | Prediction, actual outcome and policy version |
Validate a small heterogeneous workflow before connecting a facility
Connecting an entire factory or hospital at once makes root cause difficult. Start where two robot types, one door or elevator and one business system meet—for example, an AMR carries medicine, a humanoid hands it over at a secure door, and the hospital system changes the destination.
Measure end-to-end completion time, deadlocks, use of stale spatial data, human approvals and total recovery—not only one robot's success. Verify that safety survives with the platform off and that removing one vendor adapter does not stop the rest. Contract for export formats and an API sunset policy to reduce lock-in.
Fujitsu says it plans to integrate research-center technology into Physical OS in stages beginning in fiscal 2026. “In stages” means product versions, features, participants, regions and pricing still need later announcements. Track downloadable software, field trials and paid deployment as different evidence levels.
Openness is proven by the ability to remove one component
Participation by major companies does not automatically create an open platform. Ask whether a new robot can use a published adapter specification, whether spatial and task history can be exported in standard form, and whether local operations continue after one cloud is removed. API documentation alone does not prevent lock-in if identity or the data model remains proprietary.
Replace vendor A's robot with a simulator and check that the task request still flows. Inject adapter errors, run an old API during a transition, and verify advance notice of schema changes. Contract terms should define exportable raw data, post-termination retention, adapter source or escrow, and safety support for end-of-life versions. Platform value includes retaining operational assets and history when one component leaves.
Frequently asked questions
Does Kozuchi Physical OS replace ROS?
Fujitsu does not present it as a ROS replacement. It is closer to a higher coordination platform connecting robots, sensors, business systems and shared space.
Can teams download and install Kozuchi Physical OS today?
Public material describes development, staged integration and corporate collaboration. A generally downloadable package, price and supported environment need a separate product announcement.
Does a spatial world model eliminate robot collisions?
No. Sensor delay, occlusion and model error remain. Deterministic safety control such as emergency stops and speed or zone limits must remain separate from AI predictions.
Official sources checked
- Fujitsu's official announcement of Japan Physical AI cooperation
- Official Fujitsu Kozuchi Physical OS announcement
- Official NVIDIA robotics platform
Last checked: August 23, 2026