在正式采用新的DO-178C / ED-12C標準及其補充（包括關于形式方法的DO-333 / ED-216補充）五年后，尚未有航空電子認證項目承認使用這一新補充。然而，確實存在形式化的方法技術，可以簡化航空電子軟件的開發。

阻礙采用正式程序驗證進行航空電子認證的主要障礙是，盡管開發DO-333 / ED-216的委員會進行了大量的傳播工作，但缺乏關于如何應用DO-333 / ED-216的普遍共識。現在有一個詳細的過程，用于使用 SPARK 來滿足 DO-333/ED-216 的目標，作為某些形式的測試的替代品，重點是檢查源代碼是否一致、準確并符合低級要求。

該過程解決了使用正式方法時的替代覆蓋目標以及源代碼和可執行目標代碼之間的財產保護目標。當某些測試被使用正式方法所取代時，前者是必需的。后者是必需的，以便從可執行目標代碼的源代碼驗證中受益。已與美國聯邦航空管理局（FAA）和歐洲航空安全局（EASA）討論了此過程，以便將來在DO-178C / ED-12C中使用SPARK的申請人。

航空電子學中的形式化方法

盡管在DO-178的C版中添加正式方法補充是2012年，但使用正式方法開發航空電子軟件至少可以追溯到1990年代，當時John Rushby寫了一份關于它們用于FAA的全面指導文件。［“形式方法和關鍵系統的認證”，拉什比，FAA，1993年。雖然Rushby專注于演繹方法，但從那時起自動化和計算機能力的提高使得另外兩種形式化方法對開發航空電子軟件具有吸引力：模型檢查和抽象解釋。DO-333專門針對使用這三類形式化方法來開發航空電子軟件。美國宇航局2014年的一份報告中介紹了所有三個類別的使用示例［“DO-333認證案例研究”，Cofer和Miller，Rockwell Collins，2014年。

圖1：DO-333 驗證活動。圖形由IEEE提供。

雖然抽象解釋和模型檢查非常適合以最少的人為干預檢查代碼庫中的簡單程序屬性，但它們會遇到所謂的狀態爆炸問題，當分析的模型的大小（無論是在模型檢查中顯式提供還是由工具從抽象解釋構建）太大而無法完成分析時。演繹方法沒有這些缺點，但它們有要求用戶編寫函數合約的成本。這些協定是函數行為的（部分）規范，既定義了驗證目標，也定義了用于分析對該函數的調用的函數行為的適當摘要。這允許演繹方法應用強大的驗證技術，這些技術可以證明軟件的非平凡屬性，因為函數合約使焦點能夠專注于對單個函數的驗證，一次一個。

兩個工具集為C和Ada的工業用戶提供基于演繹方法的形式程序驗證：用于C程序的Frama-C工具集和用于Ada程序的SPARK工具集。兩者都被用于DO-178航空電子設備認證。例如，洛克希德馬丁公司最初在1997年將SPARK用于C-130J美國軍方和英國皇家空軍飛機的控制軟件。此后，BAE系統公司使用SPARK在維護期間證明了C-130J控制軟件的關鍵特性。另一個例子，在DO-333中記錄，空中客車公司在2002年使用Caveat（Frama-C的前身）來證明對空中客車A380民用飛機的低級要求，作為單元測試的替代品。

B. 所處理的核查目標

SPARK 可用作 DO-333 中許多驗證目標的主要證據來源，從低級要求 （LLR） 到源代碼和可執行目標代碼 （EOC）。形式驗證是分析的一個特殊情況，因此將形式分析應用于LLR和源代碼所需的指導只是使用形式分析的標準和條件。［“在認證環境中使用形式方法的指南”，Brown 等人，SC-205/WG-71，ERTS 2010。在EOC中使用需要更多的理由，特別是在替換單元測試時。

當 LLR 在 SPARK 中表示為合約時，正式符號保證 LLR 是精確和明確的，因此準確性是有保證的。一致性也得到了保證，因為不同功能的合同不會沖突。合約也是可驗證的，并且通過設計符合（編程語言）標準。這些包括表FM的目標2、4和5。來自DO-4的A-333。（同前科弗和米勒。

SPARK 的主要資源之一是它自動顯示源代碼符合以函數契約表示的 LLR。函數協定還可以表達數據依賴關系，SPARK 工具集可以自動顯示源代碼符合軟件體系結構的這一部分。SPARK代碼是可驗證的，并且符合（編程語言）標準的設計。函數的源代碼隱式追溯到函數協定中表示的 LLR。最后，SPARK 代碼是明確的，因此可以自動分析源代碼的一致性，以表明它沒有未初始化數據的讀取、算術溢出、其他運行時錯誤和未使用的計算（變量、語句等）。這些指標包括表FM的目標1至6。來自DO-5的A-333。

平機會在LLR方面的合規性和穩健性的目標（表FM的目標3和4。DO-333的A-6）可以通過依賴源代碼的相應目標來解決，前提是同時提供源代碼和EOC之間的財產保護演示。顯示財產保全的一種方法是合理地證明，在所有可能的情況下，編譯器都保留了從源代碼到EOC的程序語義。不幸的是，似乎沒有任何合理的辦法能夠提供這種信心。通過在SPARK中執行合約的模式下運行集成測試，用戶可以確信編譯器在EOC中正確保留了源代碼的語義;否則，在單個函數中證明的合同將在集成測試中（很有可能）失敗。通過在執行和不執行合約的情況下運行集成測試并檢查輸出是否相同，用戶可以確信合約的編譯不會影響代碼的編譯，因為否則在某些測試中輸出很可能會有所不同。

當然，使用 SPARK 的一個主要好處是能夠通過 SPARK 分析替換單元測試。在這種情況下，DO-333還定義了表FM的附加目標5至8。A-7.正式驗證和審查的結合可以實現這些目標，正如空中客車和達索航空過去的經驗所證明的那樣。［“測試或形式驗證：DO-178C 替代方案和工業”，Moy 等人，IEEE Software 2013。這里使用了 SPARK 的幾個功能，例如在函數契約中聲明數據依賴關系的能力，以及通過不相交的情況表達函數契約的可能性。

即將上來

自 1990 年代以來，一些先驅者一直在使用正式的程序驗證工具集。航空電子軟件認證中正式程序驗證自動化的進展現在使更多公司可以使用這些技術。SPARK使用戶能夠解決DO-178C的形式方法補充DO-333中定義的許多驗證目標。美國和歐洲的認證機構現在正在看好在航空電子認證中使用這種方法的申請人。

審核編輯：郭婷