本文重點
- 先凍結目標模組、載板 BSP、JetPack／Jetson Linux、周邊韌體、容器與模型；只寫『Jetson Orin』或『JetPack 7』不足以重現。
- NVIDIA 的 image-based OTA 產生更新 payload，但產品團隊仍要完成驗證、簽署／加密、託管、下載、觸發、回報和發布權限。
- Rootfs redundancy、更新路徑與限制會依平台和 L4T 版本不同；不要把 Orin 文件中的 A／B 行為直接推定到 Thor 或自訂載板。
- Secure Boot、磁碟加密、rollback protection 和安全儲存是不同控制；必須在量產金鑰生命週期與復原流程中逐項驗證。
- 至少測更新中斷電、payload 損毀、空間不足、服務啟動失敗、看門狗重啟、感測器斷線和回復上一版。
- 全數 PASS 只代表技術證據已備妥，仍不代替場域、安全、資安與發布負責人的簽核。
直接答案：量產驗收要證明「可重現、可更新、可失敗、可回復」
Jetson 開發套件能開機、相機有畫面、模型 Demo 能跑，都不能單獨證明產品可量產。量產前至少要回答四件事：
- 可重現：能否用相同模組、載板、BSP、JetPack／Jetson Linux、容器、模型和周邊版本重建同一套系統？
- 可更新：更新檔由誰產生、驗證、簽署、託管、批准與分批發布？設備如何回報結果？
- 可失敗：下載中斷、斷電、空間不足、payload 損毀或新服務啟動失敗時，設備會停在哪個狀態？
- 可回復：可以回到哪一個已知正常版本？由誰觸發？若遠端連線失效，現場如何救援？
NVIDIA 的 Jetson Linux 文件提供映像更新、安全、Rootfs redundancy 與驗證機制，但它不是一個代管好的整機發布平台。官方機制和產品責任要分開看。
先下載可追溯清單
本站整理兩個空白模板，所有結果預設為 NOT_TESTED，沒有替任何 Jetson、載板或產品填入虛構測試結果：
- 下載 Jetson 量產驗收 CSV：適合逐次測試、簽核與交付。
- 下載 JSON 驗收結構：保留狀態規則、版本快照與 12 個檢查層，方便接內部流程。
判讀規則很簡單：
- 有
FAIL或BLOCKED：不應發布。 - 還有
NOT_TESTED：驗收未完成。 - 全數
PASS：技術證據已備妥，仍待場域、安全、資安與發布負責人依風險簽核。 - 沒量到的欄位保持空白，不用
0偽裝成正常。
第 1 關：先凍結目標，不要只寫「Jetson Orin」
截至 2026 年 8 月 25 日，NVIDIA 的官方封存頁同時存在不同產品與維護軌，例如 JetPack 7.2.1／Jetson Linux r39.2.1，以及 Orin 的 JetPack 6.2.3／Jetson Linux r36.5.2。這不是要求所有產品立刻升級，而是提醒：平台名稱不能代替版本基線。
一個可重現的發布目標至少要保存：
- Jetson 模組、SKU、載板與載板 BSP／device tree commit。
- JetPack、Jetson Linux／L4T、bootloader 與韌體版本。
- Rootfs 映像雜湊、分割區配置、儲存型態與容量。
- CUDA、TensorRT、ROS 2、容器 digest、模型與應用 build ID。
- 相機、SerDes、CAN、Ethernet、SSD 等周邊和驅動版本。
- 功耗模式、時脈、散熱、開機服務與校正資料。
若這些欄位無法對上，同一個「版本」就可能在不同設備有不同結果，也很難證明回滾真的回到哪裡。
第 2 關：把 image OTA 和完整發布服務分開
Jetson Linux r39.2.1 的更新文件說明 image-based OTA 可以產生涵蓋系統與相關元件的 payload，也能處理 bootloader 與 rootfs 更新。但官方文件同時說明，產品團隊要實作自己的 OTA 用戶端，並依自身安全政策驗證 payload。
也就是說，量產還少不了：
| 環節 | 產品團隊要回答 | 必要證據 |
|---|---|---|
| 產生與識別 | 哪個來源版本可升到哪個目標版本？哪些模組、載板和分割區相容？ | 版本矩陣、payload 雜湊、建置紀錄 |
| 簽署與驗證 | 誰能簽署？設備信任哪些金鑰？金鑰輪替或撤銷怎麼做？ | 簽署政策、驗證 log、拒絕錯誤簽章測試 |
| 傳送與觸發 | 如何驗證下載完整、限制頻寬、安排維護窗並防止未授權觸發？ | 下載中斷續傳、權限、重試和稽核紀錄 |
| 安裝與回報 | 空間不足、斷電或安裝失敗時停在哪裡？設備如何回報？ | 故障注入、錯誤碼、設備狀態與保留 log |
| 發布治理 | 誰批准先導、擴大或停止？什麼訊號會自動暫停 rollout？ | 分批名單、門檻、批准人與停止紀錄 |
不要只測「正常網路下一次更新成功」。至少還要測 payload 被改動、下載被中斷、設備在安裝階段斷電、剩餘空間不足、服務健康檢查失敗和回報端暫時離線。
第 3 關：A／B 與回滾不是一句設定值
Jetson Linux 的 Root File System 文件對 Orin 說明了 Rootfs redundancy、slot 切換、boot retry 與 bootloader／rootfs slot 關聯，也列出部分更新方式的限制。這些功能可以成為復原設計的一部分，但量產前必須在目標平台與目標 L4T 版本確認：
- 你的 Jetson 型號、載板 BSP、分割區與儲存配置是否支援預定路徑。
- 更新的是 bootloader、rootfs、韌體、容器還是應用；失敗時每一層要回哪一版。
- A／B slot 是否真的包含新版本造成故障的元件。
- 系統如何判定新 slot 健康，而不是只要 kernel 開機就算成功。
- 啟動重試耗盡、slot 損毀、兩邊都不可用時，是否有 recovery 或現場救援。
- 成功與失敗 log 如何跨重啟保留，避免設備恢復後失去事故證據。
尤其不要把 Orin 文件中的 Rootfs redundancy 行為直接推定到 Thor、自訂載板或另一條 Jetson Linux 版本。正確做法是把「目標平台／版本已確認」列為測試前置條件。
第 4 關：安全開機、磁碟加密與金鑰生命週期要分開驗
Jetson Linux 安全文檔列出 Secure Boot、disk encryption、secure storage、fTPM 與 rollback protection 等機制。它們處理的是不同風險：
| 控制 | 主要目的 | 量產常漏掉的驗證 |
|---|---|---|
| Secure Boot | 讓開機鏈只接受被信任的元件。 | 錯誤簽章是否被拒絕、換板／維修怎麼做、量產燒錄是否可稽核。 |
| 磁碟加密 | 降低儲存裝置或設備遺失時的資料外洩。 | 金鑰來源、離線復原、效能／開機影響、設備報廢與金鑰銷毀。 |
| Rollback protection | 阻止降回不被允許的舊版本。 | 緊急回復需求是否和防降版政策衝突，哪些版本仍被允許。 |
| 安全儲存／fTPM | 保存裝置身分、機密或量測狀態。 | 憑證註冊、輪替、撤銷、備援與主機板更換流程。 |
「已啟用 Secure Boot」不能代替威脅模型，也不能證明磁碟、OTA 通道、管理權限或應用供應鏈安全。要把每個控制的金鑰擁有者、輪替方式、失敗處置與證據位置寫清楚。
第 5 關：先用官方測試當底線，再補你的整機風險
Jetson Linux r39.2.1 的 Test Plan and Validation 文件涵蓋燒錄與開機、頻率／功耗、看門狗、相機和效能等測試。它適合用來建立平台層基線，但產品仍要補上自己的載板、感測器、模型、容器、場域與故障後果。
建議至少包含下面 12 層：
- 版本與硬體基線可重建。
- Rootfs 映像與建置產物可驗證。
- OTA payload 簽署、授權和相容性拒絕。
- 正常更新與服務健康檢查。
- 下載、安裝與首次開機階段的斷電測試。
- slot／recovery／現場救援路徑。
- Secure Boot、磁碟加密與金鑰輪替。
- 相機、CAN、Ethernet、儲存與時間同步。
- 熱穩態、功耗、降頻與看門狗。
- 模型、容器與完整任務的端到端行為。
- telemetry、log、資產清冊與版本稽核。
- 分批發布、停止條件、人工接管與責任人。
短時間 benchmark、開發套件 Demo 或「更新指令成功」都不能涵蓋這些失敗模式。
第 6 關：用分批發布保護場域
在實驗室通過後，也不要一次推到全部設備。比較可回復的做法是：
- 先選可接近、可人工救援的測試設備。
- 更新後觀察開機、應用健康、感測器、溫度、記憶體、磁碟、網路和任務結果。
- 確認錯誤率與回滾門檻沒有越界，再擴大一小批。
- 每一批都保留設備清單、版本、批准人、開始／停止時間與異常證據。
- 若核心訊號異常，停止擴大；先回復，不以重跑更新掩蓋失敗。
場域設備還要有「遠端完全失效時怎麼辦」的答案：誰能到場、需要什麼 recovery media、如何驗證設備身分、會不會影響安全控制，以及多久內能恢復到可接受狀態。
一張表分清官方機制與量產事實
| 看到的訊號 | 最多能證明 | 還不能證明 |
|---|---|---|
| 官方 archive 有支援版本 | 該平台有官方發布軌可查。 | 你的載板、驅動、容器與模型已相容。 |
| image OTA 範例成功 | 指定設備的一條正常更新路徑可運作。 | 安全發布、斷電、批次擴大與回滾已完成。 |
| Rootfs redundancy 已設定 | 目標配置可能具備另一個 rootfs slot。 | 應用故障會被偵測，所有失敗都能自動回復。 |
| Secure Boot 已啟用 | 開機鏈可依設定驗證簽章。 | 磁碟、OTA、帳號、憑證和供應鏈風險都已處理。 |
| 官方測試通過 | 指定平台層項目符合該測試方法。 | 你的整機任務、場域、安全和維運已驗收。 |
最後的發布閘門
在按下量產或場域發布前，應能用一份紀錄回答：
哪個模組、載板、BSP、Jetson Linux、Rootfs、容器和模型，從哪一版更新到哪一版；由誰建置、簽署與批准；在哪些設備測過正常、斷電、損毀、回滾、熱穩態和感測器故障；失敗時設備停在哪裡、誰負責、證據在哪裡？
如果只能回答「最新 JetPack 已經支援」或「測試機更新成功」，證據還停在功能展示。能回答版本、失敗、回復與責任，才接近可持續維運的 Jetson 量產系統。
常見問題
Jetson 有官方 OTA，就代表可以直接做遠端更新嗎？
不代表。Jetson Linux 提供 image-based OTA payload 與更新流程，但官方文件也把 OTA 用戶端與伺服器的實作、payload 驗證、託管、下載、觸發及回報留給產品團隊。還要自行定義金鑰、權限、分批發布、失敗停止和回滾政策。
Jetson Rootfs A／B 可以保證更新失敗一定回復嗎？
不能先這樣保證。Rootfs redundancy 需要依目標 Jetson 平台、L4T 版本、分割區、載板 BSP 與更新方式確認支援和限制，再實測啟動重試、slot 切換、損毀、斷電與應用服務失敗。文件列出機制不等於整機情境都已驗證。
Secure Boot 和磁碟加密是同一件事嗎？
不是。Secure Boot 用來驗證開機鏈中的元件；磁碟加密保護儲存資料，rollback protection、防竄改、安全儲存與金鑰撤銷又是不同控制。產品要依威脅模型決定組合，並驗證量產燒錄、換板、維修和金鑰遺失的處置。
Jetson 開發套件測過，可以直接換成量產模組嗎？
不可以直接推論。量產模組搭配的載板、BSP、供電、散熱、相機、CAN／Ethernet、儲存、開機設定和機構都可能不同；應在目標整機上重新做映像、I/O、熱穩態、更新、斷電與復原測試。
JetPack 要永遠追最新版嗎？
量產通常需要被管理的版本基線，而不是所有設備立即追新。先確認目標模組的官方支援軌、相依套件與安全修補需求，在測試設備完成升級、相容性與回滾證據後，再分批發布。最新版也不能跳過你的整機驗收。
所有檢查都 PASS 就能宣告量產嗎？
本站清單只能整理技術證據。全數 PASS 仍不代替功能安全、資安、法規、場域營運、供應與產品負責人的正式簽核；任何 NOT_TESTED、FAIL 或 BLOCKED 則代表這份技術驗收尚未完成或不應推進。