iT邦幫忙

2026 iThome 鐵人賽

DAY 7
1

用 L0–L5 成熟度分開展示、工程證據與投產責任

image

模擬畫面完成後,最容易出現的誤解是:「既然虛擬手臂已經會動,接下來只要把程式下載到實機。」

但模擬與實機之間還有控制器版本、I/O、座標、工具負載、速度限制、互鎖、安全功能、現場人員與設備差異。輸出越接近實體控制,錯誤的後果越大,審查就必須越嚴格。

** 模擬輸出應如何依成熟度限制用途與核准責任?**

L0–L5 不是能力排名,而是用途邊界

Physical AI Studio 公開技術頁將成熟度分成六層:
image

成熟度 主要輸出 合理用途 不代表什麼
L0 動畫、影片與假設標示 提案、流程溝通、教育 不是工程可行性或投產核准
L1 OpenUSD 場景與基礎檢查 場景可行性與工程討論 尚未形成完整驗證證據
L2 碰撞、節拍、失敗紀錄與報告 試辦與內部審查 不能直接控制實機
L3 指定設備版本的控制器草稿 工程整合與原廠檢查 不是已核准控制程式
L4 虛擬控制器與更嚴格 SIL 雙人簽核前的控制驗證 仍未完成現場試車
L5 現場低速試車證據包 支援受控試車 不可自動投產

公開平台目前聚焦 L0–L2;L3 以上只說明責任與流程,不在公開工作室提供一鍵產出。

五種輸出,不能混成一個「交付完成」

MP4 模擬影片

適合簡報、流程審查與跨角色溝通。它讓人看懂動作,但不能重建場景,也不能證明數值門檻通過。

USD 場景

保存設備、工件、布局與相對位置,可供工程端重建與修改。它仍需要資產版本、單位、座標與授權清單。

任務 IR

保存任務步驟、I/O 意圖、限制、假設與失敗分支。它是需求與模擬之間的追溯層,不是硬體命令。

驗證報告

整理碰撞、可達性、節拍、門檻、失敗案例與限制。報告要能追溯到使用的場景與執行版本。

中性軌跡或控制器草稿

ROS 2 等中性軌跡仍需轉換成特定設備介面;NC、PLC 或控制器程式草稿則必須綁定指定設備與版本,經原廠虛擬控制器、風險審查、人工簽核與現場低速試車。

同一個專案可能同時有這五種輸出,但它們的使用者與責任不同。

為什麼不能一鍵投產?

公開網站特別標示平台不會直接連線 OT 或實機下指令,原因不是功能做得不夠自動,而是投產本來就需要責任閘門。

至少要逐項確認:

  • 實體設備型號、韌體與控制器版本。
  • 工具中心點、負載、座標與校正資料。
  • 安全 PLC、護欄、光柵、急停與互鎖。
  • 速度、加速度、力量與工作區限制。
  • 通訊逾時、斷線與故障退回。
  • 原廠程序、風險審查與現場驗收。

模擬可以支援這些工作,不能取代負責人的簽核。

用一道交付閘門結束 Day 7

image
每次要把輸出交給下一個角色前,可以問五個問題:

問題 若答案是否定的處置
用途是否明確標成 L0–L5? 停止交付,先定義成熟度
輸出能否追溯到任務、場景與版本? 補齊 IR、USD 與版本紀錄
主要門檻、結果與限制是否存在? 不得宣稱工程驗證完成
輸出是否會接近或控制實機? 增加原廠、風險與人工簽核
現場與模擬差異是否被列出? 先做校正、低速試車與差異驗證

這五題不是延後創新,而是避免展示、工程與投產使用同一句「已完成」。

醫療情境要再多一層界線

Physical AI Studio 案例庫包含手術器械取放與雙臂 PSM/ECM 示意。網站已標示它們是模擬示意,不是完整自動手術任務,也不是臨床或法規證據。

若後續要進入醫療器材開發,還要定義預期用途、使用者、使用環境、風險控制、軟體與硬體驗證、人因工程、資安、臨床評估及法規路徑。L0–L5 的工程成熟度不能直接取代醫療器材生命週期證據。

今天帶走三件事

  1. 模擬輸出越接近實機,設備綁定、驗證與人工核准必須越嚴格。
  2. 影片、USD、任務 IR、報告與控制草稿是不同交付物,不能用同一個「完成」概括。
  3. 模擬成功不等於安全核准、投產核准或臨床可用。

到這裡,讀者已經理解任務、Physical AI 閉環、執行時安全,以及從腳本到模擬證據的責任分層。新的 Day 8 將進入第一個手術情境案例:先建立可以被後續實驗使用的 OpenUSD 手術室場景基線。


上一篇
Day 6|動畫順利播放,為什麼還不能說產線可行?
下一篇
Day 8|手術機器人情境設計:先別急著讓機械臂動,3D 手術室如何通過基線檢查?
系列文
Physical AI 驗證工程:30 天把機器人模擬變成可檢查的證據17
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言