作者 |蔡喁上海控安可信軟件創新研究院副院長

版塊 |鑒源論壇 · 觀擎

社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區”

01

源頭和現狀

在越來越多的國產機載系統研制中，操作系統軟件的選擇對后續開展研制以及適航舉證活動帶來很大的影響。與其他行業不同的是，民用飛機的適航對飛機上所有安裝的功能及其組成部分都有著具體的適航符合性要求。這就使得研制單位因為采用第三方開發的操作系統從而無法免除適航符合性責任。另一方面，前期的文章中我們也已經介紹過，民用飛機保證安全的核心手段，是詳盡的安全性分析【詳見：淺談民用飛機機載系統的安全性】。對每種可能的功能根據其失效后果精確地分析可能的產生原因，針對每種可能的失效源頭，分別適用不同的適航要求。操作系統作為機載軟件的底層，其功能異常往往會引起上層應用軟件異常，進而引發飛機功能異常，因此，研制單位在系統中使用的操作系統不但應該具體分析其潛在的安全影響，而且還是機載軟件適航標準DO-178B/C所適用的對象。

實際上，DO-178B/C標準并沒有將應用程序和包括操作系統在內的底層軟件模塊區分對待，也就是說，所有裝載在飛機上可能引起功能異常的代碼，均需滿足相應的適航符合性要求。除操作系統外，函數庫、以代碼形式呈現的BSP組件等模塊實際上也是需要滿足適航要求的，也就是在采用DO-178B/C標準表明符合性的機載項目中，嵌入式操作系統也需要滿足標準對于軟件計劃過程、軟件開發過程、軟件綜合過程（驗證、構型、質量、審定）的目標【詳見：民用飛機機載軟件是如何表明適航符合性的】。

由于民機軟件適航標準較高的要求，實際上使得大部分嵌入式操作系統沒有或者無法應用于民用飛機中。目前國內外民用飛機中常見的操作系統研發模式有兩種，按照航空標準專門研制或由第三方專業操作系統開發單位對實時操作系統進行適航改造。在上世紀90年代到本世紀初，部分研制單位通過自己開發操作系統的方式來確保底層軟件完全可適航。典型的代表有霍尼韋爾公司的DEOS、HeartOS系統等。其中DEOS系統在上世紀90年代取得了DO-178B A級軟件的適航認可。在那個航空機載軟件有自己的編程語言（Ada）的年代，采用自研滿足適航標準的操作系統似乎也是一種高效的解決方案。實際上，在那個時期，機載系統廠商不僅自研操作系統，很多研制單位甚至會自己定制處理器。本世紀初，隨著美軍表對強制使用Ada語言要求的廢除，越來越多的研制單位選擇采用C語言開發，這也就減少了對Ada編譯環境以及實時內核等的需求，同時，其他嵌入式領域內基于C語言的工具和庫極大地降低了機載軟件的開發成本，但也推高了航空專用操作系統的開發和維護難度。自此，由機載研制單位開發專用操作系統逐漸減少。

面對航空市場，通用操作系統提供商從另一條路徑實現其操作系統的適航化。那就是將通用操作系統按照DO-178B/C標準進行生命周期改造，并提供相關適航符合性證據。目前，包括WindRiver、GreenHill在內的嵌入式操作系統研發企業，同時也包括中航工業操作系統研發單位均采取這種方法實現對民機機載研制環境的支持。所謂的適航鑒定包指的是操作系統研制單位，在其開發操作系統的過程中嚴格按照DO-178B/C的生命周期過程進行開發，并保留和記錄了所有用于表明DO-178B/C適航標準符合性的生命周期數據證據，從而確保在應用程序開發和適航取證過程中無需反復對操作系統進行驗證和審查。國際上也有將開源或者簡單操作系統逆向工程的方法，補齊對應的需求、設計等生命周期數據并通過基線迭代的方法表明操作系統適航符合性的例子。

實際上，適航鑒定包是操作系統開發方的一種說法，不論是中國、美國還是歐洲的民航局方幾乎沒有給操作系統單獨頒發適航認可的先例。哪怕是相同的操作系統運用在不同的機載系統中，或者運行在不同的硬件環境上，其潛在的失效源頭、影響等并不一定相同，從而造成適航審定無法將操作系統和應用軟件分開。特別是，不同系統中調用和使用操作系統的方式也存在差異，這也造成了操作系統很難單獨地評價其適航符合性。換句話來說，在每一個機載系統審定項目中（包括TC和TSO），操作系統必須和應用軟件一同表明符合性。適航鑒定包的主要意義在于通過實現固化的生命周期證據，在每個取證項目中減少了大量重復舉證的成本。同時，較為成熟的操作系統也有助于提高局方審查信心，減少審查開銷。

02

如何簡單快速預計操作系統適航性

針對國內外大大小小的數百個實時操作系統，研制單位往往難以判斷其滿足適航要求的程度以及后續舉證的復雜度。筆者在適航審查工作中，往往通過以下幾個要素快速判斷操作系統適航風險的大小。這些問題并不足以判斷操作系統的適航符合性，但作為挑選可用的操作系統提供了較為快速的評價判斷參考。

·操作系統是否有完善的需求定義，特別是對其自身性能和使用邊界的精確定義？

·是否能夠按照基于需求的測試原則實現軟件結構覆蓋要求？

·操作系統是否包含其他第三方的庫函數或者必須依賴某些黑盒組件？

·操作系統在當前項目的硬件平臺上是否開展過完整的軟硬件集成驗證？

·操作系統當前構型是否穩定，是否對其使用問題和缺陷開展的長期的跟蹤？

·操作系統研制單位或應用開發單位至少一個是否熟悉DO-178B/C標準的要求？

03

嵌入式操作系統適航的主要難點

滿足適航要求的操作系統之所以開發難度較大與民用飛機保證適航安全的思路是直接相關的。

3.1 需求定義及其追溯

在民機的適航體系中，幾乎所有的設計都是從嚴格的需求定義開始的。操作系統（除非在某個項目中專門開發）一般來說不大可能僅僅通過來自上級的設計輸入進行開發。因此在表明適航符合性過程中，其自身的需求定義往往存在難點。

· 需求定義的精確性和完整性

傳統行業中，需求的定義往往存在一定的不精確性。而民用飛機的設計思路與之不同，要求對需求進行精確完整的定義。對于操作系統來說，高質量的需求定義不僅是確保自身正確實現功能和充分驗證的前提，也是證明應用軟件正確遵循了操作系統的約束進行開發的證據。例如提供某種接口的需求，不僅要定義接口的名稱、參數、類型和使用方式，還需要明確說明這種接口的任何使用限制、性能邊界、禁止行為等。筆者曾經審查過的某一系統，在其需求中詳細定義了其命令所帶的后綴的具體行為，但卻沒有描述這些后綴是否存在使用限制，在后續的分析中發現某些后綴在一起使用或者連續使用實際上會產生非預期的輸出。由于需求中并沒有禁止這種行為，按照民機的需求定義規則，這種功能是被允許的，在對需求的充分驗證中將發現功能與需求的不一致情況。從上面例子可見，民機體系中，一系列適航活動的基礎是對需求的精確完整定義。

· 需求之間的追溯

由于操作系統功能往往不是來自上級系統和應用的功能分解，實際上打破了民機領域自頂向下精確傳遞的研制過程。按照DO-178B/C的要求，研制單位需要證明軟件高層需求與系統需求的一致性、軟件低層需求與高層需求的一致性等等。實際情況下，操作系統提供的功能和接口經常超過上級設計的需要。如果嚴格按照追溯方法定義需求和開展驗證，會造成大量未能覆蓋的代碼和功能，難以通過適航評審。為此，當今的操作系統往往將其適航鑒定數據包作為獨立的滿足DO-178B/C標準的實體，而將操作系統頂層需求以及應用開發的約束限制條件作為與應用軟件的符合性界面。在界面以內通過完整的需求、設計、代碼的追溯表明符合性；在界面以外，通過應用軟件完全遵從設計的假設條件，按照限定的方式開發軟件作為證據，最終實現內外符合性證據的組合整體表明適航符合性。換句話來說，操作系統開發單位為應用開發劃定一個安全區域，并對這個區域內各種可能的情況進行驗證和分析，而應用研制單位只要能能證明不超出這個安全區域就證明了其自身軟件的安全性。這實際上給操作系統開發方提出了很高的要求，特別是要求能夠充分地分析和定義應用的行為。

· 對于應用的假設

上文提到了操作系統設計中安全區域的概念，實際上在鑒定包的開發過程中，這種安全區域的識別和分析極具挑戰。也就是說，在鑒定包開發過程中，除了通常的需求定義、軟件架構、代碼等生命周期數據以外，為確保應用單位能最低成本的快速復用當前鑒定包所固化的適航符合性證據，操作系統開發方需對這些證據的適用條件（場景）進行充分的分析和定義。一個好的鑒定包能夠做到在其所明確定義的使用場景下，操作系統所提供的功能和呈現的性能完全在需求所定義的范圍內。反之，如果假設條件定義的不完整，應用研制單位需要針對自己使用的場景重新開展分析和驗證，從而使得應用研制活動中必須解決操作系統設計中的部分符合性，在降低開發效率的同時也因為不同的開發流程而造成困擾。這就會造成鑒定包的效用難以有效發揮。

3.2 驗證開銷

隨著需求定義的越來越細、假設條件的精確化，對操作系統開展的軟件驗證工作量也隨之增加。通常來說，按照適航要求開發的軟件，其需求規模數倍于傳統方式開發的軟件。對應的功能驗證以及魯棒性測試開銷必然成倍增長。更有甚者，由于DO-178B/C標準中，不僅要求設計精確地滿足需求（且不超過需求），還要求驗證相關算法的精確性。這使得很多操作系統在開展測試的同時必須進行大量的分析工作。特別是在上一節對應用的假設條件范圍內，如何證明操作系統在所有可能的場景和場景組合中均能按照預期的輸出將是驗證工作中的難點。

3.3硬件適配問題

一個成熟的操作系統必然涉及到在不同的應用甚至硬件環境中使用的問題，除了上文提到的應用邊界外，在不同的硬件環境下（哪怕僅是存在微小的硬件構型變化），已經取得的驗證證據將不再有效。通常需要開展差異評估和回歸測試，或者將已經開展過的驗證（測試、評審和分析）整體重新開展一遍。這對操作系統的開發也造成明顯的壓力。某些操作系統其針對不同硬件進行重新驗證的成本數倍于操作系統本身的開發和驗證。

3.4 第三方組件問題

另外，在操作系統研制中，操作系統本身，以及后續開發的應用軟件往往會使用到第三方的組件。按照適航標準，研制單位需要對所有最終加載在機上的代碼證明其適航符合性。相較于傳統系統開發，針對第三方組件研制單位無非又回到自研、逆向以及購買第三方鑒定包的幾種選擇中，這一問題又進一步推高操作系統研制和取證的成本。

在淺談操作系統的適航符合性（下）中，將詳細展開討論降低機載軟硬件適航成本的潛在方法，以及國內首個完全符合適航標準的輕量級嵌入式操作系統——飛蜻FlyLite等內容。

審核編輯 黃宇