航電軟體的入場券叫 DO-178C，而它的第一個問題永遠是：你的軟體是什麼 DAL（Design Assurance Level）？ 這個字母（A 到 E）決定接下來的一切——目標數量、覆蓋率要求、獨立性要求、文件深度。eVTOL 把一批新團隊帶進了這個世界，這套分級邏輯值得在寫第一行程式碼之前弄懂。
DAL 從哪裡來：失效條件的嚴重度
DAL 不是軟體團隊自選的，它繼承自系統安全評估：這個軟體參與的功能如果失效，對航空器會發生什麼？
| 失效條件 | 白話 | DAL |
|---|---|---|
| 災難性（Catastrophic） | 通常導致墜毀、多人死亡 | A |
| 危險（Hazardous） | 嚴重傷害、機組能力大幅下降 | B |
| 重大（Major） | 明顯增加工作負荷與不適 | C |
| 輕微（Minor） | 些微不便 | D |
| 無安全影響 | — | E |
與車用 ASIL 的邏輯同源（比較可見 ASIL 那篇），但有個氣質差異：DO-178C 是目標導向——它列出各等級要滿足的目標（Objectives），等級越高目標越多、其中要求「獨立達成」的比例也越高。
覆蓋率階梯：DAL 的最直觀差異
結構覆蓋率是 DAL 差異最具體的展現：
- DAL C：敘述覆蓋（每一行都執行過）
- DAL B：加上判定覆蓋（每個分支真假都走過）
- DAL A：加上 MC/DC——每個條件都要被證明能獨立影響判定結果
還有一項 DAL A 的獨門要求：原始碼到目的碼的追溯——編譯器生成的目的碼若包含無法直接對回原始碼的結構，要額外驗證。這是其他產業幾乎不會遇到的深度。
覆蓋率在 DO-178C 裡的角色也值得說清楚：它不是測試目標，是完備性的量尺——測試必須從需求推導；跑完需求測試後，覆蓋率缺口代表「有程式碼沒有需求對應（死碼？）或需求測試不完備」，兩者都要處置，而不是補一條「為了覆蓋而覆蓋」的測試把數字填滿。
「獨立性」獨立的是什麼
DO-178C 的獨立性不是「另找一家公司」，而是活動層級的角色分離：某些目標（等級越高越多）要求驗證者不能是被驗證產物的作者。實務含意：
- 需求審查、測試案例開發與程式實作之間的人力配置要規劃——小團隊尤其要提早設計，不然到了審查階段才發現「全部是同一個人做的」
- 自動化幫得上忙：工具執行測試、量測覆蓋率本身沒有「作者偏見」——但前提是工具本身可信，這就到了下一題
DO-330：工具也要有身分
用工具取代人工活動（自動生成測試、自動量覆蓋率、自動檢查標準），DO-178C 要求工具鑑定（Tool Qualification，DO-330）——依工具產出「會不會直接進入機載軟體」與「取代了哪類活動」定出鑑定等級。所以選工具時，「有沒有現成的鑑定套件（Qualification Kit）」是實質採購條件：像 VectorCAST 這類在航電領域長期使用的工具會提供對應的鑑定支援，把這條路的成本從「自己證明工具可信」壓到「執行既有鑑定流程」。
eVTOL 團隊最常見的三個誤判
- 把 DO-178C 當事後文件工程——它是全生命週期過程：計畫（PSAC 等五份計畫）先行，審查與紀錄同步發生；事後補的痕跡，審查員一眼看穿
- 低估組態管理——每一份產物（需求、程式碼、測試、結果）的版本與基線都在受控範圍，問題報告與變更影響要能追溯
- 覆蓋率當 KPI 衝——見上：缺口是訊號，不是待填的空格
下一步
從 DAL 對應的驗證策略、MC/DC 自動化到工具鑑定，歐特莫夫（Vector Informatik 合作夥伴）協助 eVTOL 與航電團隊把證據鏈建到審查等級。
- 📄 解決方案：eVTOL 與航電系統測試解決方案（DO-178C）
- 📬 預約一次現況盤點