專家意見驅(qū)動的民用機載系統(tǒng)需求確認方法

吳健

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

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

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

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

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

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

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

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

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

1 專家意見驅(qū)動的需求確認方法

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

（1）該系統(tǒng)規(guī)范覆蓋什么領域？

（2）該系統(tǒng)規(guī)范用來干什么？

（3）該系統(tǒng)規(guī)范能回答哪些類型的問題？

（4）誰使用和維護該系統(tǒng)規(guī)范？

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

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

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

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

2 搜集專家意見

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

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

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

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

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

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

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

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

3 解答專家問題

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

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

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

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

4 總結經(jīng)驗/教訓

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

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

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

5 結語

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

參考文獻

[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