專家意見驅動的民用機載系統需求確認方法

吳健

摘 要：專家意見是檢查民用機載系統需求正確性和完整性的重要依據，因而系統工程師掌握有效應對各類專家問題的方法是十分必要的。通過分析專家意見處理中存在的各種問題，提出了新的以專家意見為主線的系統需求確認方法：搜集專家意見以確定系統范圍，用系統規范中的術語系統結合多種手段來解答專家問題。搜集的過程要盡量避免專家對系統規范文本的逐字理解，而應該讓專家根據自己專業的需要提出意見。解答的過程要直接證明專家意見能被系統規范定義的術語表示并能進行有效的推理，讓專家肯定外部結論。該方法中角色職責清晰，能適應實際開發中團隊合作和系統規范內容不穩定的特點，比現有方法更有效率。

關鍵詞：系統工程 民用飛機 需求確認 專家意見

中圖分類號：V37 文獻標識碼：A 文章編號：1674-098X（2014）08（b）-0066-03

在民用航空研制領域廣泛使用的ARP4754A，民用飛機系統開發指南，推薦將系統與外界的接口需求以協議的方式形成機載系統規范。系統規范的具體形式包括工作說明、計劃、手冊、需求文檔、接口文檔或合同[1]，是完整和詳細的系統接口描述。從本體論的角度來看，系統規范就是機載系統的知識本體，是該系統“共享概念模型的明確的形式化規范說明”[2-3]。除了該系統內部的系統工程師，共享這些知識概念的專家還包括適航代表，飛行員代表，軟硬件工程師，系統驗證工程師和其他相關系統的系統工程師等外部人員。以上所有專家會在飛機研制的不同階段分別參與到該系統的確認過程。ARP4754A建議使用模板/檢查單、用戶操作場景描述和原型建模等確認方法來保障系統規范的正確性和完整性[1]。這些方法在實際操作過程中普遍存在著以下問題：

（1）模板訂制（裁剪、擴展和修改）缺乏依據。

（2）檢查單項目含義模糊，難以判斷。

（3）用戶操作場景描述不準確或相關條件尚未確定。

（4）原型建模受問題特點的制約，使用范圍有限。

因此，作為上述方法的重要補充，各類專家會根據各自的工作職責針對性地提出問題作為專家意見，參與到系統需求的確認過程中。匯總的專家意見是系統利益相關人對該系統的客觀要求，是飛機設計評審中的重要參照，是飛機研制過程向前邁進和適航取證的必要條件，是決定民機項目成功的關鍵因素。所有系統工程師都很重視這些意見。不過，由于專家知識背景不同，描述問題的角度和層次不同，系統工程師如果直接納入這些意見和反饋進行系統規范開發就會產生知識沖突。綜合分析以上情況，本人提出以專家意見為主線的機載系統需求的確認方法，在一個新的系統工程框架下實現理論與實踐的結合。

1 專家意見驅動的需求確認方法

系統規范的開發是一個迭代的過程，一開始就需要確定知識領域和系統范圍。這將會涉及到以下基本問題：

（1）該系統規范覆蓋什么領域？

（2）該系統規范用來干什么？

（3）該系統規范能回答哪些類型的問題？

（4）誰使用和維護該系統規范？

從本體論的角度看，專家意見就是一系列基于系統規范代表的領域知識模型應該能夠回答的問題，即“資質性問題（Competency Questions）”[4]。它能夠有效確定系統知識的廣度和深度，可以用來評價和比較現有的不同系統規范，也可以作為以后需求確認的有效參照。

系統規范草案出爐之后，部門會先組織內部評審。一般情況下，系統規范都會參照以往機型相似系統的設計文件和航空業適用于該系統的指導規范。一個容易出現的錯誤做法就是把系統規范與行業指導規范做比較，找出兩者的差異，然后研究出現差異的原因和減少差異的措施。這種做法沒有抓住問題的關鍵。行業指導規范大多不是強制標準，不針對任一機型，允許不同機型參考并根據需要進行裁剪，擴充和修改。這種適應性修改的依據，不是看與行業指導參考規范的差異，而應該是看能否滿足飛機設計和適航的各種需求。

系統規范草案通過了內部評審就會進行外部評審。一般的做法就是把系統規范的草案分發到相關專業和適航機構，要求同行評審。這種做法也有問題。首先每個飛機系統都有一套獨立的術語系統來保證描述的一致性和準確性。要讓其他專業背景的系統工程師在短時間內理解和掌握這套新建的術語系統是有難度的。另外，由于飛機系統間的有機聯系，從系統開始研制的相當長的時間內，系統規范的輸入都沒有辦法完全確定，送審的系統草案本身也是不穩定的。草案不成熟蘊含的術語不一致性，會導致外專業評審人員從字面無法理解概念，提出的問題包含大量要求澄清概念的情形。當本系統工程師不得不花費時間和精力向外專業工程師講解系統規范這個版本中的術語概念時，也注意到這些外部專家對概念的初步掌握對系統規范本身的質量提升一般不會起到很大作用。而實際上，外部專家并不真正關心這些概念。他們的最終目的在于確認能用系統規范中的概念表達他們感興趣的問題并能推導出合理的外部結論。

通過對以上兩種做法的分析，可以得出以下結論：系統需求的確認必須以專家意見為依據，以及確認的本質在于讓專家明白系統規范能夠表達他們關心的問題并能進行有效推理。因此，一種更好的確認方法是，系統工程師通過搜集專家意見來確定系統范圍，并利用系統規范建立的領域知識模型來直接表示和解答專家意見，從而避免外部專家對系統規范的字面理解。以下分三個步驟來介紹這種需求確認方法的具體操作過程。

2 搜集專家意見

從系統研制啟動就可以準備搜集專家意見。搜集問題可以從最簡單的問題開始，然后逐步變得復雜。問題必須是具體的，要能夠直接標識到飛機系統，設備，軟件加載項或者硬件接口。問題需要有代表性，不必窮盡。

按問題來源，專家意見可以分為內部意見和外部意見。內部意見來自軟硬件工程師，具體可以參考ARP4754A，4.6.1節“系統過程與配置項過程的信息流”。[1]來自諸如適航代表，飛行員代表，系統驗證工程師和其他相關系統的系統工程師等系統外部人員的意見稱為外部意見。需要特別注意的是系統驗證工程師的盡早介入。系統需求的驗證工作是在系統設備試驗件提交之后，系統驗證工程師按照既定的試驗大綱進行試驗并逐個確認是否滿足預期結果。不過，為了盡早暴露問題，提高系統需求的可驗證性，避免驗證工程師誤解系統概念導致的試驗問題和不必要的進度延誤，試驗大綱也將作為專家問題的重要來源。endprint

根據表述類型，專家問題又可以分為以下四類：[4-6]

存在性問題。某個對象是否存在？專家問題里涉及的概念需要明白無誤地與特定飛機系統或部件對應。比如駕駛艙顯示器的燃油簡圖頁畫面上有沒有表示燃油溫度的指示標識。

屬性的問題。對象的屬性是什么？通過某個飛機系統或系統部件找出所有的內在屬性。比如，高升力系統的襟翼張開的角度是多少。

關系的問題。兩個對象之間是這個關系嗎？在不同狀態下，要求明確給出不同系統或系統部件之間的關系。比如，在飛機單個發動機飛行狀態下，哪些飛行畫面要優先展示給飛行員。

推理的問題?；卮疬@樣的專家問題需要基于一定的規則或邏輯推理。在實例化系統或系統部件屬性之后，可以根據這些數據進行有意義的推理。比如，在航電的IMA資源分配的時候，在保證現有平臺資源安全冗余的條件下，能否為飛控系統的某駐留功能分配20 ms的周期性運行時間。

專家問題的提出不依賴任何目標系統規范的知識，只要是對專家所在系統的研制有意義就可以。專家問題需要由相關部門進行正式的認定和簽發，確實代表該部門對目標系統的實際要求。

3 解答專家問題

在確立系統架構進行系統設計過程中，系統工程師就可以利用規范里的術語來表達專家意見，以衡量系統規范的成熟度。系統工程師通過列寫出專家問題中的重要詞匯，與搜集到的參考資料中的概念進行分析比較，可以判斷這些參考資料的復用程度和使用價值。[5-6]

系統規范寫好后，大多數專家問題都應該得到了解決。當然，考慮到專家的知識背景和特殊的觀察視角，系統工程師不可能完全理解專家意見中所有詞匯的含義。這需要和有關專家進行溝通，進一步挖掘用戶和客戶需求。不過，這與讓專家學習系統規范不同的地方在于，系統工程師在理解了問題含義后，轉換成自己熟悉的系統專業詞匯來回答對方專家認為重要的問題，而不是學習對方詞匯來進行表達和推理。在雙方都在描述同一個知識領域的前提下，這點是可以在短時間內做到的。

上面已經提到，解答專家意見的過程就是利用新建系統規范的概念表示問題，并用定義的屬性和關系對問題進行推導的過程。簡單的問題，一句話就可以說清楚。對于復雜的情況，則可以使用用例/故事，描述操作場景，編寫具體算法或者測試用例的方式來說明。某些特定的復雜問題還可以借助Enterprise Archtect，Rational Rhapsody或CATIA等CASE工具，用UML/SysML模型或數字三維模型來回答問題。例如，在IMA的資源分配過程中就可以利用UML對駐留應用進行建模并利用內置算法來自動優化計算和通信資源。對于保真度要求較高的問題，還可以使用模擬器仿真。比如，評估駕駛艙顯示方案就可以在駕駛艙模擬器中進行，讓飛行員和有關專家身臨其境地評價和比較不同顯示方案的優劣。

讓專家僅憑閱讀文檔就表決通過一份系統規范是不現實的。以上各種手段的目的都是盡可能直接地向專家展示系統規范的表達能力和令人滿意的推理結果，讓對方相信他們關心的問題能夠利用系統規范得到解答。具體做法上，在系統規范和問題演示材料準備好后，先發送給對方專家并進行多次面對面或者郵件溝通，盡可能地達成一致意見。對于有分歧的部分，則可以由部門出面組織研討會，討論修改意見或者解決辦法。在飛機研制的重要評審會上，不僅要把定型的系統規范分發到相關專家和項目負責人，還要匯總說明各類專家問題的解決情況。對于影響較大的遺留問題，還需要在評審會上進行單獨討論。

4 總結經驗/教訓

專家意見的搜集和解答情況不僅僅標志著系統規范的成熟度，還體現著系統工程師對用戶需求理解的深度和廣度。每個問題的成功解答都是一個進步。即便系統規范還會隨著飛機研制的深入而變更，問題的表述方式會變化，但原理和實質不會變。之前通過表達和解決問題與專家達成的共識仍然有價值，解決問題的方法也可以借鑒的。而且，解決專家問題的過程也是和專家互動的過程。良性的溝通可以與專家建立了令人愉快的工作關系。

不可否認的是，肯定存在著某些問題不能得到很好表示或者推理無法令對方滿意的情況。對方專家指出的演示過程中的不合理部分將激發系統工程師對現有系統規范中的架構設計和需求描述方式的深入思考。對于有爭論問題，可以組織更高層級或者更大范圍的討論，聽取更多人的意見。確實有問題的要修改，即使系統規范要推倒重來，也是值得的。在概念和開發階段就發現問題并糾正，避免在驗證和生產運營階段出現更為嚴重的錯誤，這正是系統需求確認活動的意義。[1]

專家意見的解答方法可以寫成工程協調紀要，以備將來參考和復用。一些解答問題的方法，例如算法，模型和原型等，都可以作為系統后續設計的重要參考。另外，解決的專家問題也是培訓員工迅速了解本系統領域知識和工作方法的有效的第一手學習資料，可以幫助新員工或者剛接手相關事務的員工盡快上手，提高團隊工作效率。

5 結語

民用機載系統需求的確認是一個復雜的過程。一方面要多領域專家共同參與，廣泛聽取各方意見；另一方面，要有專門的術語系統，維護規范的內部一致性和準確性。這就需要從系統工程的高度進行頂層設計。本文提出以專家意見為紐帶構建一個框架：內部由系統工程師維護一套一致的、可自我辯護的術語體系；外部則讓不同角色的利益相關人都能在自己的知識層次上提出問題，并通過系統工程師的演示來確認在系統規范的知識體系內確實可以找到問題的合理解答，滿足預期的接口需求。本文提出的方法汲取了本體論研究成果，能夠較好滿足現有的航空工程實踐基礎的要求。

參考文獻

[1] SAE，ARP4754 REV.A，2010. Guidelines for Development of Civil Aircraft and Systems[Z].

[2] Borst，W.N.Constructing of Engineering Ontologies.PhD thesis， Institute for Telematica and Information Technology， University of Twente， Enschede， The Netherlands[Z].1997.

[3] Gómez-Pérez， A.Knowledge sharing and reuse. Handbook of Applied Expert Systems. Liebowitz， editor， CRC Press[Z].1998.

[4] Gruninger， M. and Fox， M.S. Methodology for the Design and Evaluation of Ontologies. In： Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing，1995，IJCAI-95， Montreal[Z].

[5] Gruber， T.R.A Translation Approach to Portable Ontology Specification[J].Knowledge Acquisition，1993，5：199-220.

[6] Uschold，M.and Gruninger，M. Ontologies：Principles，Methods and Applications[J].Knowledge Engineering Review，1996，11（2）.

[7] RTCA，DO-178C，Software Considerations in Airborne Systems and Equipment Certification[Z].2012.

[8] RTCA， DO-254，Design Assurance Guidance for Airborne Electronic Hardware[Z].2000.

[9] RTCA， DO-297，Integrated Modular Avionics （IMA） Development Guidance and Certification Considerations[Z].2005.endprint