醫療器材軟體的世界裡，一個字母決定你接下來一年的工作量：IEC 62304 的軟體安全分類——Class A、B、C。分錯級，要嘛白做一堆文件，要嘛在審查時被打回重來。這套分級的邏輯值得每個進入醫材領域的軟體團隊先搞懂。
分級的依據：軟體失效會傷人到什麼程度
分類問的是一條因果鏈：軟體失效 → 危險狀況 → 傷害，傷害的嚴重度決定等級：
- Class A：不會造成傷害
- Class B：可能造成非嚴重傷害
- Class C：可能造成嚴重傷害或死亡
兩個實務要點藏在細節裡：
- 評估時要先假設失效會發生（發生機率不能拿來降級）——能往下降級的路徑是外部風險控制：如果軟體之外有獨立的硬體保護（機械聯鎖、獨立監控電路）能把傷害擋住，等級才可以往下修。這也是為什麼分級是系統層風險管理（ISO 14971）與軟體開發的交會點，不是軟體團隊自己填的表
- 分級可以分段：系統拆成多個軟體項目（Item）後，各項目可以有各自的等級——前提是隔離成立（見下）
等級怎麼放大工作量
62304 的過程要求隨等級疊加，粗略地說：
| 活動 | A | B | C |
|---|---|---|---|
| 軟體開發計畫、需求分析 | ✓ | ✓ | ✓ |
| 架構設計 | — | ✓ | ✓ |
| 細部設計（單元層級） | — | — | ✓ |
| 單元實作 | ✓ | ✓ | ✓ |
| 單元查證 | — | ✓ | ✓（更嚴） |
| 整合與整合測試 | — | ✓ | ✓ |
| 系統測試 | ✓ | ✓ | ✓ |
方向很清楚：等級越高，越往「單元層級」的嚴謹度下探。Class C 要求把設計與查證做到單元粒度——這正是自動化單元測試與覆蓋率工具（VectorCAST 這類）在醫材專案裡的位置：手工做 Class C 的單元查證與紀錄，成本會失控。
隔離設計：把 C 關進小房間
整包軟體都按 Class C 開發是最貴的選項。更聰明的架構是隔離（Segregation）：把安全關鍵功能收攏成小而清晰的元件（維持 C 級），其餘部分在證明「其失效不影響安全功能」後取得較低等級。但隔離必須是可論證的技術事實——記憶體保護、執行時間隔離、介面受控——而不是方塊圖上的一條虛線。審查員的標準問題就是：「B 級那塊當掉、寫壞記憶體、吃光 CPU 的時候，C 級那塊為什麼沒事？」
SOUP：來路不明軟體的管理義務
62304 給第三方／既有軟體一個專有名詞：SOUP（Software of Unknown Provenance）——RTOS、協定堆疊、開源函式庫都算。用 SOUP 不被禁止，但要盡義務：明確列管每一項 SOUP 與版本、定義你依賴它的功能與效能需求、評估它的已知異常清單（釋出說明裡那些 bug 對你的裝置有沒有影響）、在風險管理裡處理它的失效模式。版本升級是 SOUP 管理最常破功的地方——升了版沒有重走評估，稽核一翻紀錄就現形。
與車用世界的互相借鏡
做過 ISO 26262 的團隊會發現骨架似曾相識：風險驅動分級（ASIL ↔ Class）、等級放大方法嚴謹度、單元覆蓋率證據（分級邏輯比較見 ASIL 那篇）。差異在生態：62304 與 ISO 14971（風險管理）、IEC 62366（可用性）緊密掛鉤，而「軟體變更後的重新驗證範圍」在醫材監管下（上市後變更管理）更為敏感——追溯與自動化回歸的價值，兩個產業完全相通。
下一步
從分級論證、隔離架構到 Class C 的單元查證自動化，歐特莫夫（Vector Informatik 合作夥伴）把跨產業的證據鏈方法帶進醫材軟體專案。
- 📄 解決方案：醫療器材軟體測試解決方案（IEC 62304）
- 📬 預約一次現況盤點