
模擬畫面完成後,最容易出現的誤解是:「既然虛擬手臂已經會動,接下來只要把程式下載到實機。」
但模擬與實機之間還有控制器版本、I/O、座標、工具負載、速度限制、互鎖、安全功能、現場人員與設備差異。輸出越接近實體控制,錯誤的後果越大,審查就必須越嚴格。
** 模擬輸出應如何依成熟度限制用途與核准責任?**
Physical AI Studio 公開技術頁將成熟度分成六層:
| 成熟度 | 主要輸出 | 合理用途 | 不代表什麼 |
|---|---|---|---|
| L0 | 動畫、影片與假設標示 | 提案、流程溝通、教育 | 不是工程可行性或投產核准 |
| L1 | OpenUSD 場景與基礎檢查 | 場景可行性與工程討論 | 尚未形成完整驗證證據 |
| L2 | 碰撞、節拍、失敗紀錄與報告 | 試辦與內部審查 | 不能直接控制實機 |
| L3 | 指定設備版本的控制器草稿 | 工程整合與原廠檢查 | 不是已核准控制程式 |
| L4 | 虛擬控制器與更嚴格 SIL | 雙人簽核前的控制驗證 | 仍未完成現場試車 |
| L5 | 現場低速試車證據包 | 支援受控試車 | 不可自動投產 |
公開平台目前聚焦 L0–L2;L3 以上只說明責任與流程,不在公開工作室提供一鍵產出。
適合簡報、流程審查與跨角色溝通。它讓人看懂動作,但不能重建場景,也不能證明數值門檻通過。
保存設備、工件、布局與相對位置,可供工程端重建與修改。它仍需要資產版本、單位、座標與授權清單。
保存任務步驟、I/O 意圖、限制、假設與失敗分支。它是需求與模擬之間的追溯層,不是硬體命令。
整理碰撞、可達性、節拍、門檻、失敗案例與限制。報告要能追溯到使用的場景與執行版本。
ROS 2 等中性軌跡仍需轉換成特定設備介面;NC、PLC 或控制器程式草稿則必須綁定指定設備與版本,經原廠虛擬控制器、風險審查、人工簽核與現場低速試車。
同一個專案可能同時有這五種輸出,但它們的使用者與責任不同。
公開網站特別標示平台不會直接連線 OT 或實機下指令,原因不是功能做得不夠自動,而是投產本來就需要責任閘門。
至少要逐項確認:
模擬可以支援這些工作,不能取代負責人的簽核。

每次要把輸出交給下一個角色前,可以問五個問題:
| 問題 | 若答案是否定的處置 |
|---|---|
| 用途是否明確標成 L0–L5? | 停止交付,先定義成熟度 |
| 輸出能否追溯到任務、場景與版本? | 補齊 IR、USD 與版本紀錄 |
| 主要門檻、結果與限制是否存在? | 不得宣稱工程驗證完成 |
| 輸出是否會接近或控制實機? | 增加原廠、風險與人工簽核 |
| 現場與模擬差異是否被列出? | 先做校正、低速試車與差異驗證 |
這五題不是延後創新,而是避免展示、工程與投產使用同一句「已完成」。
Physical AI Studio 案例庫包含手術器械取放與雙臂 PSM/ECM 示意。網站已標示它們是模擬示意,不是完整自動手術任務,也不是臨床或法規證據。
若後續要進入醫療器材開發,還要定義預期用途、使用者、使用環境、風險控制、軟體與硬體驗證、人因工程、資安、臨床評估及法規路徑。L0–L5 的工程成熟度不能直接取代醫療器材生命週期證據。
到這裡,讀者已經理解任務、Physical AI 閉環、執行時安全,以及從腳本到模擬證據的責任分層。新的 Day 8 將進入第一個手術情境案例:先建立可以被後續實驗使用的 OpenUSD 手術室場景基線。