郭祺君

【摘 要】機載軟件開發(fā)階段的審查工作是軟件適航審查工作的不可或缺的組成部分，同時，機載軟件適航審查工作也影響著整個飛機的適航取證置信度。本文結(jié)合了國際上通用的審查要求及程序，論述了機載軟件開發(fā)階段適航審查工作的目的原則、內(nèi)容及審查方法，并對過程中突出問題進行了分析。

【關(guān)鍵詞】民用飛機；機載軟件；適航審查

中圖分類號： V247 文獻標識碼： A 文章編號： 2095-2457（2017）32-0084-002

【Abstract】The review of airborne software development phase is an indispensable part of airworthiness review of airworthiness software. At the same time， airworthiness review of airborne software also affects the confidence of airworthiness certification. In this paper， the international common review requirements and procedures are discussed in this paper. The principles， contents and examination methods of airworthiness review during airborne software development are discussed. The outstanding problems in the process are analyzed.

【Key words】Civil aircraft； Airborne software； Airworthiness review

1 軟件適航審查工作概述

隨著電子芯片和編程技術(shù)的高速發(fā)展，應(yīng)用于民用飛機領(lǐng)域的機載軟件不僅數(shù)量越來越多，復(fù)雜程度也日趨增高，而我國民機研制經(jīng)驗和國外相比起步較晚，這對機載軟件的適航審查工作帶來了更大的挑戰(zhàn)。

在當前的機載系統(tǒng)及設(shè)備的合格審定中如何保證這些軟件滿足適航要求，工業(yè)界發(fā)布了RTCA DO-178B[1]，之后又更新了部分細節(jié)發(fā)布了RTCA DO-178C[2]，F(xiàn)AA通過AC 20-115C[3]確認了RTCA DO-178C可以為適航當局所接受的一種機載軟件符合性方法。

在民機的適航審查過程中，機載軟件的審查是對軟件研發(fā)過程的審查，是檢查或調(diào)查軟件的生命周期數(shù)據(jù)、軟件項目進展和記錄以及其他證據(jù)，以確定是否符合DO-178B/C目標的活動。

民用飛機機載軟件階段性介入審查（SOI）由美國FAA提出，具體適航審查程序指南的發(fā)布于FAA8110.49 《軟件批準指南》[4]。SOI一般由四個部分組成，SOI#1（軟件計劃階段評審）、SOI#2（軟件開發(fā)階段評審）、SOI#3（軟件驗證階段評審）和SOI#4（軟件最終審定評審）。在實際項目中，可以根據(jù)項目的復(fù)雜程度、委任代表的審查經(jīng)驗或者軟件研制商的適航開發(fā)經(jīng)驗來確定實際項目的評審次數(shù)，即適航當局介入的程度。

本文主要研究的SOI#2，即軟件開發(fā)階段的介入評審。

2 軟件開發(fā)階段審查（SOI#2）目的和原則

開展SOI#2的目的是：

1）通過檢查軟件生命周期數(shù)據(jù)來評估申請方的計劃和標準是否得到有效地實施；

2）評估計劃的任何變更，并對其認可；

3）評審軟件開發(fā)階段中產(chǎn)生的偏離，并給出是否可接受的結(jié)論；

4）確保軟件生命周期數(shù)據(jù)符合DO-178B/C附表A表A-2、A-3、A-4、A-5、A-8、A-9和A-10的目標；

5）確保軟件開發(fā)符合軟件相關(guān)政策、指南、問題紀要等適航要求。

SOI#2的評審原則是檢查申請人的：

1）軟件研制實際過程是否與已批準的計劃和標準一致；

2）計劃的過程是否能夠產(chǎn)生合適的輸出。

3 開展軟件開發(fā)階段審查的前提

軟件開發(fā)階段審查的前提是軟件開發(fā)過程足夠成熟，這要求申請人及軟件供應(yīng)商已經(jīng)完成的工作包括：

1）高層需求已形成文檔、內(nèi)部評審并可追蹤到系統(tǒng)需求；

2）軟件架構(gòu)已定義，并已完成了評審和分析；

3）低層需求已形成文檔、已內(nèi)部評審并可追蹤到高層需求；

4）源代碼實現(xiàn)了低層需求和可追蹤到底層需求，并且經(jīng)過了內(nèi)部評審。

4 軟件開發(fā)階段審查內(nèi)容

軟件開發(fā)階段審查的具體材料及相對應(yīng)的DO-178B章節(jié)如下表：

當申請人確認當前軟件開發(fā)已開展的活動能夠表現(xiàn)出整個開發(fā)階段生命周期的面貌，后期潛在的更改已經(jīng)能夠?qū)Ξ斍敖Y(jié)果的影響進行充分分析，就可以開展SOI#2的審查活動。從歐美適航當局的審查來說，F(xiàn)AA要求至少50%的軟件開發(fā)階段數(shù)據(jù)，包括軟件需求、設(shè)計、代碼，已經(jīng)完成開發(fā)，那么可以執(zhí)行SOI#2的評審；EASA則要求至少75%的軟件開發(fā)階段數(shù)據(jù)已經(jīng)完成開發(fā)后可執(zhí)行SOI#2的評審。

申請人應(yīng)當將SOI#2階段的審查內(nèi)容在SOI#2評審會前提交局方，如果有相關(guān)內(nèi)容涉及公司機密不可以直接提交，那么應(yīng)當允許或邀請審查代表在審查現(xiàn)場直接接觸這些數(shù)據(jù)，以進行審查工作。

5 軟件開發(fā)階段的審查方法

SOI#2開發(fā)評審的檢查方法包括但不限于：介紹、閱讀、采樣、訪談和目擊。

5.1 介紹

主要由申請方進行軟件開發(fā)階段的介紹，包括當前開發(fā)階段執(zhí)行的開發(fā)活動，生成的數(shù)據(jù)，審查方應(yīng)當對照批準的計劃，檢查是否一致；endprint

申請人也應(yīng)當介紹當前已開展的質(zhì)量保證過程的活動，審查方檢查是否存在缺漏，是否存在嚴重的不符合問題，及采取的措施。

5.2 閱讀

審查方通過閱讀的方式對質(zhì)量保證記錄和報告進行監(jiān)察，檢查質(zhì)量保證活動中的不符合問題，問題分類情況，是否有系統(tǒng)性的問題，如有系統(tǒng)性問題，當前的措施是否得當。

通過閱讀也可以檢查：

1）分配的系統(tǒng)需求是否明確；

2）是否所有分配的系統(tǒng)需求都分解到了高級別需求；

3）是否所有的高級別需求都有上級需求對應(yīng)；

4）高級、低級和代碼是否都對應(yīng)評審記錄；

5）識別出的衍生需求，是否都反饋到系統(tǒng)進行安全性分析。

5.3 采樣

采樣是選擇一組典型的軟件生命周期數(shù)據(jù)用于檢查或分析，是評審中非常重要的一種方式，主要是對開發(fā)過程一致性、開發(fā)過程對標準的符合性以及驗證正確性的檢查。

采樣前應(yīng)準備以下相關(guān)數(shù)據(jù)：高級別需求條目，低級別需求條目，已完成編碼的高/低級別需求，已完成的代碼量，生成的生命周期數(shù)據(jù)構(gòu)型項目，產(chǎn)生的問題報告數(shù)目，產(chǎn)生的變更數(shù)目。

在實際的評審中，通常采用的采樣方法有兩種：

1）以某一層次的生命周期數(shù)據(jù)為采樣的開始，比如軟件低級別需求，根據(jù)軟件功能或其他重要指標選定若干條需求作為采樣對象，然后檢查與這些需求追溯的其他各級生命周期數(shù)據(jù)。同時，在檢查時，應(yīng)該保證向上追溯和向下追溯兩種方向都被遍歷。

2）選取某一代表性的變更請求，按照變更原因、分析影響、更改內(nèi)容、再評審的變更步驟進行逐步檢查。

審查方應(yīng)當確保最終采樣的數(shù)據(jù)包括：

1）系統(tǒng)需求-軟件高級別需求-軟件低級別需求；

2）軟件架構(gòu)-軟件代碼-軟件目標代碼；

3）上述軟件生命周期數(shù)據(jù)的驗證記錄；

4）構(gòu)型管理記錄；

5）質(zhì)量保證記錄

另外，由于一般情況下審查時采樣能抽取的數(shù)據(jù)十分有限，無法覆蓋全部SOI#2數(shù)據(jù)，因此無法保證數(shù)據(jù)的完整性。

5.4 目擊

閱讀和采樣都是對數(shù)據(jù)和記錄的靜態(tài)檢查，而目擊是對過程的動態(tài)檢查。

目擊可以使審查人員實際感受當前的軟件研制過程設(shè)置，了解工具和環(huán)境的使用，體會軟件計劃和標準的執(zhí)行過程，并且了解對方人員操作的嚴格程度。

5.5 訪談

和軟件研發(fā)人員的面對面交談可以使檢查人員掌握以下情況，對所需過程及標準的掌握情況；研發(fā)人員是否滿足當前過程設(shè)置要求這一假設(shè)的正確性。

6 審查結(jié)果的記錄

審查方將所有審查數(shù)據(jù)、審查情況及審查中發(fā)現(xiàn)的問題記錄在評審報告中。在審查中發(fā)現(xiàn)的錯誤或者問題，如果發(fā)現(xiàn)不能符合DO-178B/C的一個或多個目標的事項時，會記為不符合項，要求申請人整改。如果發(fā)現(xiàn)軟件生命周期過程中需要改進的潛在事項，則記為建議修改項，可以要求申請人提供更改措施，在后續(xù)軟件研制過程中改進。同時，對于現(xiàn)階段發(fā)現(xiàn)的可能影響接下來的階段審查目標或特別需要接下來階段審查注意的事項，可以記為后續(xù)關(guān)注項，在后續(xù)的審查過程中予以確認。審查方會根據(jù)具體發(fā)現(xiàn)的問題來確定是否需要再啟動SOI#2，或是后續(xù)桌面評審后即可認可所有的問題解釋和相關(guān)證據(jù)。

如果審查方認為通過審查，申請人軟件開發(fā)階段的工作已經(jīng)足夠充分，能夠滿足適用的DO-178B/C所規(guī)定的所有目標，且申請方所有的問題解釋能夠被審查方認可接受，那么審查方會發(fā)布批準表，通過該軟件的SOI#2。

7 總結(jié)

本文對軟件適航審查過程中的軟件開發(fā)階段的評審的目的、原則、開展的前提、審查內(nèi)容及方法，以及審查結(jié)果的記錄進行了討論分析，適用于軟件開發(fā)階段的適航評審，對我國民機飛機機載軟件開發(fā)階段的適航審查工作有著一定的參考意義。

【參考文獻】

[1]RTCA DO-178B.Software considerations in airborne systems and equipment certification[S].Washington DC，1992，12.

[2]RTCA DO-178C.Software considerations in airborne systems and equipment certification[S].Washington DC，2011，12.

[3]AC 20-115C Airborne Software Assurance[Z].Washington DC，2013.07.

[4]FAA Order 8110.49.Software approval guidelines[S].Washington DC， 2003，06.endprint