吳健

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

關(guān)鍵詞：系統(tǒng)工程 民用飛機(jī) 需求確認(rèn) 專家意見

中圖分類號：V37 文獻(xiàn)標(biāo)識碼：A 文章編號：1674-098X（2014）08（b）-0066-03

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

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

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

（3）用戶操作場景描述不準(zhǔn)確或相關(guān)條件尚未確定。

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

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

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

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

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

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

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

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

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

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

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

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

2 搜集專家意見

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

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

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

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

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

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

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

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

3 解答專家問題

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

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

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

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

4 總結(jié)經(jīng)驗/教訓(xùn)

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

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

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

5 結(jié)語

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

參考文獻(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