航空發動機FADEC系統全數字模型協同開發與配置管理

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

0 引言

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

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

1 FADEC全數字模型

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

圖1 基于MBD的FADEC系統研制流程

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

圖2 FADEC系統全數字模型關系

2 協同開發策略

2.1 UCM流

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

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

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

圖3 基于UCM流的協同開發策略

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

圖4 全數字實例化模型數據結構

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

2.2 流數據結構

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

3 配置管理

3.1 配置庫管理

圖5 配置庫管理示意圖

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

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

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

圖6 全數字模型追溯關系

3.2 配置流程管理

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

圖7 全數字模型配置管理流程

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

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

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

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

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

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

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

4 應用效果

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

5 結束語

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