航空發(fā)動機FADEC系統(tǒng)全數(shù)字模型協(xié)同開發(fā)與配置管理

（中國航發(fā)商用航空發(fā)動機有限責任公司 設計研發(fā)中心控制系統(tǒng)部，上海 200241）

0 引言

航空發(fā)動機FADEC（Full Authority Digital Electronic Control）系統(tǒng)主要由發(fā)動機電子控制器（EEC，Electronic Engine Control）、發(fā)動機監(jiān)視裝置（EMU，Engine Monitoring Unit）、燃油液壓部件、控制傳感器、執(zhí)行機構等組成。FADEC是一種典型的復雜嵌入式系統(tǒng)，具有控制任務多，功能邏輯復雜、控制難度大等特點，其設計安全等級為A類[1,2]，具有極高的可靠性和安全性要求。為提高研發(fā)效率和質(zhì)量，降低研發(fā)成本，基于模型的設計（Model Based Design，MBD）[3,4]為航空發(fā)動機FADEC系統(tǒng)的設計提供了一種有效的途徑。所謂MBD，是將設計過程表述為可執(zhí)行的規(guī)約，使用全數(shù)字模型作為載體驗證設計的符合性和準確性，MBD有助于更好地權衡FADEC系統(tǒng)設計方案，更早地發(fā)現(xiàn)設計缺陷，降低后期設計反復和試驗風險，最終縮短產(chǎn)品定型周期。

FADEC系統(tǒng)設計初期，設計人員需要根據(jù)航空發(fā)動機工作特點和工作方式制定可行的控制規(guī)律、診斷與處理算法、故障安全邏輯與策略等。目前廣泛采用的設計方法是基于MBD設計流程，借助計算機仿真技術開展需求迭代、功能分析和設計方案權衡，因此，在仿真工作開展之前，開發(fā)具有相似度很高的全數(shù)學模型就顯得尤為重要。當前，F(xiàn)ADEC系統(tǒng)全數(shù)字模型開發(fā)具有如下特點：1）模型開發(fā)由單學科演變成多學科人員共同完成；2）模型開發(fā)由串行開發(fā)過渡為并行開發(fā)；3）模型迭代頻繁，版本和配置管理要求苛刻；4）模型可移植性，可重用性，易更換性要求高；5）模型開發(fā)過程規(guī)范化，并逐步向自動化過渡。針對上述特點，如何保證多學科人員并行開展工作，如何有效控制模型配置項技術狀態(tài)，如何幫助設計人員將精力聚焦于設計工作本身，而不是工具使用和流程流轉上，是全數(shù)字模型開發(fā)和配置管理過程中面臨的新問題。本文基于IBM Rational配置管理工具ClearCase和變更管理工具ClearQuest開展了FADEC系統(tǒng)全數(shù)字模型的協(xié)同開發(fā)和配置管理方法探討，從多方面解決了上述問題。

1 FADEC全數(shù)字模型

根據(jù)國內(nèi)外航空發(fā)動機FADEC系統(tǒng)研制經(jīng)驗，基于MBD的FADEC原型軟件研制過程至少包括全數(shù)字模型仿真、全數(shù)字軟件仿真、軟硬件集成仿真，不同層級的被調(diào)對象逐步逼近真實機載軟件及其運行環(huán)境，以保證在所有狀態(tài)下系統(tǒng)功能、性能得到了嚴格地確認驗證。為實現(xiàn)不同仿真過程中采用同一用例，結果曲線一致的仿真效果，各階段的數(shù)字模型需保持嚴格的繼承關系，如圖1所示。為保證模型追溯關系和代碼一致性，在全數(shù)字模型開發(fā)過程中高效協(xié)同和配置管理就顯得尤為重要。

圖1 基于MBD的FADEC系統(tǒng)研制流程

全數(shù)字模型仿真發(fā)生在軟件代碼集成仿真之前，借助系統(tǒng)建模與仿真軟件（如Simulink）完成對FADEC系統(tǒng)建模、集成與仿真驗證。全數(shù)字模型主要包括系統(tǒng)環(huán)境（被控對象）模型（如飛機、發(fā)動機、燃滑油模型）、部件模型（如傳感器模型）、控制模型等，主要用于模擬FADEC系統(tǒng)外部環(huán)境和控制邏輯。多個型號項目中共用模型、算法、邏輯，可提煉形成通用全數(shù)字模型，一般地，其最小單元是系統(tǒng)部件及控制邏輯建模時考慮的最小邏輯單元；型號仿真上使用的全數(shù)字模型稱為實例化全數(shù)字模型，一般地，其最小單元對應型號上每一個具體物理部件，此時FADEC系統(tǒng)方案已確定；基于型號的控制仿真全數(shù)字模型除了包括型號實例化模型，還包含控制規(guī)律、診斷算法、故障安全策略等在內(nèi)的控制仿真模型，主要用于模擬型號FADEC系統(tǒng)接收外部指令和各種故障情況下，控制邏輯規(guī)律與控制對象之間的交互。通用模型、實例化模型、基于型號的控制仿真模型之間的關系如圖2所示。

圖2 FADEC系統(tǒng)全數(shù)字模型關系

2 協(xié)同開發(fā)策略

2.1 UCM流

為追蹤、管理和控制軟件開發(fā)過程中的變更，IBM Rational提出了一種基于流（Stream）的軟件變更管理方法，解決了不同地域和規(guī)模的開發(fā)團隊對軟件變更的控制要求，是用于軟件變更管理的“最佳實踐”流程，航空發(fā)動機FADEC系統(tǒng)全數(shù)字模型協(xié)同開發(fā)和配置管理活動也是基于該“最佳實踐”上開展的。

ClearCase提供的統(tǒng)一變更管理（UCM，Unified Changed Management）流功能，一方面將個人工作空間和團隊集成空間隔離，減少個人工作對項目技術狀態(tài)的影響和相互干擾；另一方面，提供了數(shù)據(jù)的手動提交和自動同步功能，實現(xiàn)個人工作空間和團隊集成空間的數(shù)據(jù)交互，并記錄不同空間的數(shù)據(jù)關聯(lián)關系。

全數(shù)字模型協(xié)同開發(fā)基于UCM流開展，如圖3所示，分三個層級，第一級為集成流，用于存儲和發(fā)布模型正式版本數(shù)據(jù)集、建立模型推薦基線，不開展任何研制活動；第二級為調(diào)試或測試流，在開發(fā)階段為調(diào)試流，在驗證階段為測試流，主要應用于模型集成與測試；第三級為調(diào)試或測試子流，主要給開發(fā)測試人員使用，可按需設置。

圖3 基于UCM流的協(xié)同開發(fā)策略

各流的研制活動和數(shù)據(jù)遷移關系如下：調(diào)試流從集成流同步數(shù)據(jù)，用于模型集成以及過程數(shù)據(jù)的存儲和提交，并最終將過程數(shù)據(jù)提交至集成流受控；調(diào)試流可設置多條子流，最終由集成人員將不同子流上的成果手動更新到調(diào)試流；測試流用于模型驗證、軟/硬件集成測試等過程的開展，如果測試中發(fā)現(xiàn)模型缺陷，在測試流完成模型修復并將數(shù)據(jù)同步到測試子流，繼續(xù)開展后續(xù)測試，直到缺陷修復。測試完成后，集成人員提交變更申請，將更改后的模型數(shù)據(jù)提交至集成流受控。

圖4 全數(shù)字實例化模型數(shù)據(jù)結構

為控制全數(shù)字模型數(shù)據(jù)狀態(tài)，幫助設計人員將精力聚焦于設計工作本身，對相關人員流操作權限進行約束，涉及項目負責人、配置管理人員、集成人員、開發(fā)和測試人員。項目負責人申請模型開發(fā)代號，由配置管理員根據(jù)代號創(chuàng)建工作空間；一級目錄由配置管理員創(chuàng)建，二級目錄由集成人員創(chuàng)建并由配置管理員檢入受控，不允許開發(fā)人員修改目錄結構；正式基線的建立由集成人員提交基線建立申請，經(jīng)配置管理員合規(guī)性審核，項目負責人審批，最終由配置管理員建立；集成人員負責非正式基線的創(chuàng)建及各流數(shù)據(jù)的提交和同步；開發(fā)和測試人員只對所負責的文件進行數(shù)據(jù)檢入、檢出操作，不需額外的工具和流程操作。

2.2 流數(shù)據(jù)結構

數(shù)據(jù)在工作空間中合理組織和存放有利于版本追溯與變更控制，也是模型協(xié)同開發(fā)的基礎，通過層次化的協(xié)同開發(fā)目錄結構實現(xiàn)模型數(shù)據(jù)統(tǒng)一存放和管理。數(shù)據(jù)結構分類原則：1）按功能劃分文件夾類別，不同子模型開發(fā)過程的數(shù)據(jù)隔離；2）不同的配置管理對象（配置項）數(shù)據(jù)完整，數(shù)據(jù)可追溯。實例化全數(shù)字模型數(shù)據(jù)結構示意如圖4所示。其中，全數(shù)字模型的配置項按功能劃入不同文件目錄，重要配置項（如模型程序、需求文檔、設計文檔等核心輸出物）版本通過在文件夾上加上版本號進行區(qū)分，整個全數(shù)字模型的升版，不影響其中一個配置項的版本變更。其他配置項如測試用例、測試報告、版本使用說明等只納入存儲范疇，不在數(shù)據(jù)結構中做版本標識。

3 配置管理

3.1 配置庫管理

圖5 配置庫管理示意圖

FADEC系統(tǒng)全數(shù)字模型功能邏輯復雜，需要在開發(fā)過程中對不同穩(wěn)定程度的數(shù)據(jù)版本進行區(qū)別控制，以防止重要版本的丟失或肆意篡改。參考國家軍用標準[11]要求，航空發(fā)動機機載軟件配置庫分為開發(fā)庫、受控庫和產(chǎn)品庫三庫，通過配置管理工具，通過基線創(chuàng)建和權限控制實現(xiàn)三庫邏輯上的分離。考慮到全數(shù)字模型為非機載軟件產(chǎn)品，模型配置庫分開發(fā)庫和受控庫兩庫管理，如圖5所示。開發(fā)庫是開發(fā)人員進行模型開發(fā)、測試、驗證的空間，用于收集所有模型開發(fā)過程中電子數(shù)據(jù)（模型、代碼、詳細設計說明、測試數(shù)據(jù)等），集成人員可自行建立非正式基線；受控庫保存正式基線數(shù)據(jù)，不開展任何研制活動，配置管理員有操作權限，其他人員僅有只讀權限，模型出、入庫和配置更改須遵守嚴格的控制流程。

開發(fā)庫的工作主要在子流和集成流上開展，通過流功能保持開發(fā)人員空間的隔離性，集成人員根據(jù)模型開發(fā)進展適時地創(chuàng)建推薦基線；開發(fā)人員通過復原（Rebase）操作，使各開發(fā)子流的基線同推薦基線保持一致，從而使開發(fā)成員在同一基礎上進行變更活動，當開發(fā)人員完成全部開發(fā)任務并經(jīng)過嚴格測試與驗證后，集成人員以流上的穩(wěn)定版本發(fā)起入庫流程，審批通過后，配置管理員建立此版本受控流，更新受控庫臺賬，建立模型推薦基線和讀寫權限，以維護受控數(shù)據(jù)的安全性與穩(wěn)定性。為保持數(shù)據(jù)追溯性，后續(xù)的軟件仿真和軟硬件集成等應用中如需用到受控的全數(shù)字模型，需提交出庫申請，并在相關文檔中說明引用全數(shù)字模型版本和及其追溯關系。

通用模型、實例化模型、控制仿真模型的管理過程遵守配置庫管理相關要求，模型追溯關系如圖6所示。當模型完成全部開發(fā)任務，具備入庫條件，集成人員需提交入庫申請，完成入庫受控，入庫單中需指明組成全數(shù)字模型各子模型版本，用以保持數(shù)據(jù)追溯關系。實例化模型開發(fā)中，對通用模型不做修改，通過增加可調(diào)特征參數(shù)方式或者新增邏輯模塊完成實例化建模；在控制仿真模型開發(fā)中，以實例化模型為基本單元，新增定義數(shù)據(jù)結構，構建相互連接的FADEC系統(tǒng)框架模型，以此框架模型與控制模型聯(lián)合開展控制仿真。

圖6 全數(shù)字模型追溯關系

3.2 配置流程管理

航空發(fā)動機FADEC系統(tǒng)的復雜性使得模型變更活動越來越頻繁，如果對全數(shù)字模型變更活動不加控制和管理，會大大增加原型軟件設計和驗證風險。基于流的開發(fā)活動同ClearQuest定義的流程模板關聯(lián)，保證了全數(shù)字模型開發(fā)過程中版本控制、基線管理、變更管理、出入庫流轉等重要技術活動真實有效，保證了數(shù)據(jù)的一致性和可追溯性。全數(shù)字模型配置管理相關流程如圖7所示。為保證每次變更在實施前都經(jīng)過授權，配置流程建立了配置管理委員會（Configuration Control Board，CCB）作為集中管控機構，委員會成員由專業(yè)副總設計師、項目負責人、模型集成人員、配置管理員等人員組成，配置流程的操作權限和人員職責由配置管理員統(tǒng)一發(fā)布和監(jiān)督執(zhí)行。

圖7 全數(shù)字模型配置管理流程

ClearQuest與UCM流集成的常見流程有：項目建立申請、基線建立申請、變更申請、出、入受控庫申請等流程，如圖8所示。

圖8 ClearQuest與UCM流集成常見流程

項目建立申請：全數(shù)字項目需求提出后，觸發(fā)項目建立申請。項目負責人按需發(fā)起項目建立申請，通過審批后，配置管理員建立配置管理項目代號和工作空間。如需調(diào)整項目描述、人員等信息，或增減項目子代號，項目負責人需發(fā)起項目變更流程。

基線建立申請：基線標志著模型開發(fā)過程一個階段工作的結束，是重要的模型數(shù)據(jù)集。全數(shù)字模型項目通過評審，由模型集成人員發(fā)起基線建立申請，通過審批后，配置管理員在集成流上建立穩(wěn)定版本的模型基線，作為后續(xù)模型使用的推薦基線。

入庫申請：全數(shù)字仿真模型已完成建立第一個基線，為便于后續(xù)變更管理和出庫使用需要，保證此版不被最新數(shù)據(jù)同步，需提交入受控庫申請。在庫中的版本為可提供后續(xù)使用的正式有效版本。

變更申請：模型已入庫受控，由于需求變化，在重新完成模型修復并測試通過后，集成人員提交變更申請，該流程自動觸發(fā)基線建立流程和入庫流程，在完成變更申請后，模型新版數(shù)據(jù)集再此作為推薦基線入受控庫管理。

出庫申請：全數(shù)字模型應用于軟件仿真或軟硬件集成仿真時，模型使用者需辦理出庫申請；通用模型庫可直接調(diào)用，無需辦理出庫申請。

4 應用效果

中國航發(fā)商用航空發(fā)動機有限責任公司控制系統(tǒng)部較早的開展FADEC系統(tǒng)全數(shù)字模型協(xié)同開發(fā)和配置管理的研究與探索，根據(jù)全數(shù)字模型開發(fā)和仿真特點，公司制定了體系化的模型開發(fā)和配置管理方法，支持多學科人員分工合作協(xié)同開發(fā)全數(shù)字模型，保證全數(shù)字模型整個生命周期過程產(chǎn)生的所有配置項的完整性、一致性、可追溯性。經(jīng)過多個全數(shù)字模型項目的檢驗，公司已初步形成了FADEC系統(tǒng)全數(shù)字模型通用庫、專業(yè)庫、控制仿真模型庫，通過模型分層管理和逐級引用，使得原來開發(fā)一套全數(shù)字模型需要數(shù)月時間大幅減少到幾周內(nèi)即可完成，大幅提高全數(shù)字模型仿真工作效率和質(zhì)量。實踐證明該方法在FADEC系統(tǒng)全數(shù)字模型開發(fā)和配置管理中切實可行，一方面，顯著提高了復雜模型開發(fā)的分工協(xié)作能力，加快模型開發(fā)進度，另一方面，通過模型配置管理，提升模型技術狀態(tài)管控能力，提高模型技術成熟度，有助于知識的積累和傳承，顯著降低開發(fā)和管理成本。

5 結束語

本文針對航空發(fā)動機FADEC系統(tǒng)全數(shù)字模型開發(fā)與管理難題，提出了一種模型協(xié)同開發(fā)和配置管理方法，并在民用航空發(fā)動機FADEC系統(tǒng)研制中取得了初步應用效果。由于篇幅所限，本文只選取了幾個方面進行了介紹，實際的管理方法更加流程化和體系化，確保管理方法的合理性和可操作性。后續(xù)將進一步研究FADEC系統(tǒng)全數(shù)字模型協(xié)同開發(fā)和配置管理特點，對協(xié)同開發(fā)和配置管理方法進行持續(xù)改進和優(yōu)化，通過已有工具的二次開發(fā)及與其他工具的集成，改善模型數(shù)據(jù)的交互策略，提高模型協(xié)同開發(fā)自動化程度和過程管控質(zhì)量；通過模型仿真與需求符合性驗證，持續(xù)提高全數(shù)字模型技術成熟度。