Fujitsu Kozuchi Physical OS不是安裝在單一機器人裡的通用作業系統。它是Fujitsu正在開發的實體 AI（Physical AI）基礎層，要把機器人、感測器、業務系統與物理空間連起來，讓多種設備接受共同營運指令。整體構想結合從人類示範與過往經驗取得工作調適能力的「brain intelligence」，以及描述真實場域的「spatial intelligence」。截至2026年8月，重點仍是研究、合作與分階段整合，而非已完成的通用套件。
Physical 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設備模型再精細，只要感測更新太慢，規劃仍可能選到已堵塞的通道。除了物件座標，還需要觀測時間、可信度、擁有者與有效期限。攝影機和LiDAR的定位偏差可從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、變更紀錄、告警 |
| 世界模型誤判 | 以確定性安全限制拒絕動作 | 預測值、實際結果、策略版本 |
先在異質設備交會的小區域試辦
一次連接整座工廠或醫院，會讓失敗原因難以追查。先選兩種機器人、一座門或電梯、一套業務系統交會的小區域。例如AMR運送藥品，人形機器人在保全門前交接，醫院系統中途改變目的地。
評估不只看單機成功率，還要記錄業務完成時間、僵局次數、過期空間資訊使用率、人員批准次數與障礙後的整體復原時間。停止基礎平台是否仍安全、拔掉一家廠商轉接器是否影響其他設備，也要實測。要避免廠商綁定，合約應包含空間與工作資料輸出格式及API終止政策。
Fujitsu規劃自2026年度起，逐步把研究中心技術整合進Physical OS。「逐步」表示產品版本、功能、合作企業、地區與價格仍需後續公告。路線圖不能與實際供應混在同一欄，應分別追蹤可下載軟體、現場示範與付費部署的證據。
是否開放，要看能否帶著資料與介面退出
多家大型企業參與，不會自動形成開放平台。應查新機器人能否使用公開轉接器規格、空間狀態與工作歷程能否按標準格式輸出，以及停用特定雲端後能否維持本機運作。即使有API文件，認證伺服器或資料模型若由單一企業控制，轉換成本仍高。
驗證時可把A廠牌機器人換成模擬器，檢查相同工作要求能否流通；也要測轉接器回傳錯誤時，全體規劃器是否繼續運作、舊API能否並行一段時間、綱要變更是否事前通知。合約還要寫明可輸出的原始資料範圍、終止後保存期限、轉接器原始碼或託管條件，以及停止支援版本的安全措施。平台價值不只在連線設備數量，更在拆除任何一項後仍保有營運資產與紀錄。
常見問題
Kozuchi Physical OS 會取代 ROS 與各廠牌控制器嗎？
官方內容並未把它描述成ROS替代品。它較接近連接機器人、感測器、業務系統與空間資訊的上位協作基礎層。
企業現在能下載 Kozuchi Physical OS 通用套件嗎？
公開內容談的是開發、分階段整合與企業合作；通用套件的下載、價格與支援環境，仍需要另外的產品公告。
共享空間世界模型後，異質機器人就不會碰撞嗎？
不會。感測延遲、遮蔽與模型誤判仍存在；緊急停止、速度與區域限制等確定性安全控制，必須與AI預測分離。
已查核的官方資料
最後查核：2026年8月23日