劉富榮

(中國航發(fā)商用航空發(fā)動機有限責任公司設計研發(fā)中心，上海 201108)

基于模型的商用發(fā)動機機載軟件開發(fā)方法

劉富榮

(中國航發(fā)商用航空發(fā)動機有限責任公司設計研發(fā)中心，上海 201108)

隨著仿真技術和軟件工程的發(fā)展，基于模型設計(MBD)軟件開發(fā)技術已廣泛應用于國外商用航空發(fā)動機全權限電子控制軟件，以解決經典軟件開發(fā)過程中的難題，但該技術在國內剛剛起步。針對經典軟件開發(fā)流程存在的諸多問題，基于模型的軟件設計方法，從人員組織、研制流程、工具使用三個方面對經典開發(fā)流程進行了優(yōu)化，解決了經典軟件開發(fā)流程存在的弊端。介紹了軟件開發(fā)組織與研制流程的變革，定義了基于模型的軟件設計流程，描述了流程中各個工作階段涉及的人員、工作依據、活動、輸出，介紹了開發(fā)工具以及基于Matlab/Simulink的模型設計標準，驗證了該方法的正確性和可行性?？偨Y了基于模型的軟件設計優(yōu)勢、項目實踐經驗，探討了該方法面臨的挑戰(zhàn)和后續(xù)工作重點。

航空航天；發(fā)動機； 機載軟件； 設計流程； 基于模型設計； 設計標準

0 引言

航空發(fā)動機以電子設備與機載軟件為核心，實現發(fā)動機的控制和監(jiān)視。機載軟件具有大規(guī)模、高安全、研制周期長、成本高的特點。先進航空發(fā)動機機載軟件代碼量都超過30萬行，成本約百美元/行。為提高機載軟件質量、縮短研制周期、降低研制成本，基于模型設計(model-based design，MBD)軟件等新興研制技術逐步應用于經典軟件研制體系中，成為當前機載軟件開發(fā)的主流趨勢[1]。

經典軟件開發(fā)流程由系統總體提出需求，并將其作為軟件開發(fā)的輸入；軟件專業(yè)設計人員根據該輸入進行軟件設計與編碼、編譯鏈接生成可執(zhí)行的代碼，并對可執(zhí)行的代碼進行測試驗證。這種流程的弊端體現在：首先，數據的傳遞依靠文本和語言交流，易造成需求、實現不一致；其次，測試在代碼完成后才開展，發(fā)現問題再修復導致研制周期變長；最后，需求提出者與設計實現者不同，需求傳遞過程中易造成理解差異，導致實現與需求不一致。采用基于模型的軟件設計，從人員組織、研制流程、工具使用三個方面對經典開發(fā)流程進行了優(yōu)化，從不同層面規(guī)避了上述弊端[2]。

本文首先介紹了基于MBD的軟件設計方法，包括開發(fā)組織架構、開發(fā)流程、開發(fā)工具，以及由此引入的設計約束等；然后詳述了該方法在機載軟件開發(fā)中的實施情況；最后總結了流程實踐經驗，闡述了該方法面臨的挑戰(zhàn)和后續(xù)的工作重點。

1 開發(fā)組織架構

國內軟件工程普遍采用經典軟件開發(fā)流程，開發(fā)組織的作用通常是：系統總體提出文本化軟件研制任務要求，軟件開發(fā)部門根據該要求進行需求分析、設計與編碼。軟件驗證、系統總體、部件設計等專業(yè)人員不直接參與軟件設計。

MBD設計流程將文本化的需求和設計演變成可仿真驗證的模型與自動化代碼，使得開發(fā)組織演變?yōu)樘岢鰳I(yè)務需求、開發(fā)模型，最終由軟件工程專業(yè)人員將模型生成代碼并與手寫代碼集成的良性開發(fā)組織。該流程使得系統總體、部件設計專業(yè)作為需求提出者直接參與到軟件設計中，將其需求通過MBD模型轉化成軟件產品的一部分。MBD軟件開發(fā)組織如表1所示，其中，“√”表示參與該項職責的成員。

表1 MBD軟件開發(fā)組織

1.1 專業(yè)分工變化

組織架構的變革導致專業(yè)間分工的變化?；贛BD的開發(fā)組織由軟件工程專業(yè)、系統與部件專業(yè)共同組成。軟件項目研制由軟件工程專業(yè)牽頭，系統和部件專業(yè)共同參與。

軟件工程專業(yè)主責軟件方案與項目策劃、流程標準的建立、工具的保障、軟件體系結構設計與集成、驗證、質量保證、配置管理與交付。系統與部件專業(yè)主責與其專業(yè)相關的需求定義與驗證、模型開發(fā)和驗證，最終將模型交付軟件工程專業(yè)進行代碼生成與集成調試。

1.2 組織挑戰(zhàn)

非軟件工程專業(yè)的人員參與到軟件設計中，給開發(fā)組織帶來一定的挑戰(zhàn)。

①組織能力：要求非軟件工程專業(yè)的設計人員具備一定的軟件設計能力。需對其定期開展設計流程與標準宣貫、方法指導與工具培訓等。如對使用CAD建模與結構分析的液壓專業(yè)人員開展軟件工程培訓，使其掌握需求分析方法與需求管理工具的使用；理解設計標準與流程，并掌握Matlab/Simulink工具的使用方法等。

②流程與標準：為面向不同專業(yè)的設計人員，開發(fā)流程需足夠嚴苛以保證軟件設計質量，并能兼顧開發(fā)效率；要求開發(fā)標準內容全面，可操作性強，能依靠工具落地。

③工具鏈：要求工具鏈高度集成化，最大程度實現流程流轉與標準檢查的自動化；將復雜操作封裝在后臺，盡量簡化面向設計人員的操作步驟。為強化需求和設計的驗證，需開發(fā)被控對象模型并且要求驗證場景盡量逼真，以達到需求和設計的驗證要求。

2 開發(fā)過程

基于MBD的軟件開發(fā)過程包括需求分析、軟件設計、編碼實現、集成調試，MBD的軟件開發(fā)過程框圖如圖1所示[3]。

圖1 MBD的軟件開發(fā)過程框圖

2.1 需求分析

經典軟件開發(fā)流程中的需求錯誤往往在系統集成或測試階段才被發(fā)現。基于MBD的軟件開發(fā)流程，將后端驗證工作提前，在需求階段僅進行初步軟件設計并構建仿真環(huán)境開展驗證。

由系統總體牽頭，組織各專業(yè)依據系統方案與部件技術要求進行需求分析。系統總體負責與被控對象本體相關的控制需求，如發(fā)動機穩(wěn)態(tài)控制等；部件專業(yè)負責與部件特性相關的需求，如傳感器信號處理、作動機構閉環(huán)控制等；軟件專業(yè)則負責操作系統、數據存儲等需求的開發(fā)與驗證。

各專業(yè)將算法與邏輯采用Matlab/Simulink建模并轉化成代碼，并將代碼在全數字仿真環(huán)境中驗證。同時在需求管理工具DOORS中將算法與邏輯文本化并管理，建立需求管理屬性、追溯性關系，避免需求之間存在矛盾、重復、不可驗證等。各專業(yè)對需求過程的數據進行評審，并將數據傳遞給軟件專業(yè)開展軟件設計。

2.2 體系結構設計

軟件體系結構設計由設計與集成工程師依據需求、安全等級、目標環(huán)境約束等，按照功能高內聚與數據低耦合的原則設計軟件靜態(tài)與動態(tài)結構、時序規(guī)劃與模塊定義[4]，模塊MBD與非MBD實現方式劃分如圖2所示。MBD實現方式的優(yōu)勢在于將軟件設計工作圖形化、可視化、可仿真化；劣勢在于生成的代碼效率低，可實現的功能有限。因此MBD與非MBD實現方式的劃分原則如下：①偏重于數值計算和邏輯計算的需求采用MBD方式實現，例如信號處理算法、控制律管理算法、故障診斷邏輯等；②非數值與邏輯計算的需求、與硬件資源密切相關的需求采用非MBD方式實現，例如信號采集、輸出信號管理、設備的自檢等[5]。

圖2 MBD與非MBD實現方式劃分圖

采用MBD實現的模塊，由設計與集成工程師構建Matlab/Simulink模型框架，定義模型的輸入、輸出、調用關系。模塊框架本質上為空模型，可動態(tài)驗證模型間的一致性關系。非MBD方式的模塊以接口定義文件(.h)的形式定義靜態(tài)組織關系、接口形式、數據關系等，作為編碼實現與集成調試的依據[6]。

體系結構設計通過DOORS文本化，并由設計與集成工程師建立與需求的追溯性關系，組織各專業(yè)對設計結果進行評審，并在詳細設計過程中跟蹤、管控軟件體系結構。接口文件、模型框架通過配置管理工具ClearCase統一協同開發(fā)環(huán)境發(fā)布，供詳細設計過程使用。

2.3 詳細設計

詳細設計分為手寫代碼設計與MBD模型設計。編碼工程師依據結構設計結果開展手寫代碼設計，同時依據編碼過程的反饋逐步完善，并以文本形式呈現。各個專業(yè)模型設計工程師在MBD模型框架中開展MBD。MBD模型框架提供了各個模型之間的調用關系和接口管理，不包含具體邏輯。模型設計工程師根據分配給各個模型的功能需求，在MBD模型框架中完善具體邏輯。

模型設計工程師根據體系結構設計分配給模型的需求，開展模型、用例設計、仿真驗證；使用Matlab/Simulink Model Advisor對模型進行靜態(tài)檢查，生成檢查報告與設計報告，設計過程的數據均在ClearCase受控，并由設計與集成工程師組織各專業(yè)評審。

2.4 編碼實現

編碼實現包括手工編碼與自動代碼的生成。編碼與實現工程師遵照編碼標準與手寫代碼詳細設計文檔開展手工編碼，并不斷迭代詳細設計文檔。自動代碼生成是由設計與集成工程師依據體系結構設計與接口文件，配置模型及其數據自動生成代碼。

除代碼外，代碼生成過程還會生成代碼與模型的信息文件與追溯性關系。信息文件記錄了模型與代碼版本，編譯配置信息。再次生成代碼過程中，自動代碼生成工具自動比對當前狀態(tài)與信息文件記錄狀態(tài)的差異，決定是否進行代碼生成，在保證代碼與模型一致性的同時提高代碼生成效率。自動代碼不允許人為修改，調試過程中若發(fā)現問題，先變更模型再重新生成代碼。追溯性顆粒度為函數單元級，以C語言函數為單元與模型中的單元建立追溯性。

2.5 集成調試

集成調試由軟件設計與集成工程師牽頭、組織需求與編碼工程師，對標軟件高層進行需求分析。其分為軟件集成調試與軟硬件集成調試兩個階段，前者在全數字集成環(huán)境中進行調試，后者在目標集成環(huán)境中進行調試[7]。兩種環(huán)境基本架構一致，包括上位機調測軟件、被控對象模型、機載設備及其軟件。上位機調測軟件實現激勵注入與數據觀測與保存，機載設備與軟件根據輸入激勵實現被控對象的閉環(huán)控制[8]。

軟件集成與軟硬件集成工作的側重點不同。前者將手寫代碼與MBD自動代碼集成，并根據軟件高層需求開展功能調試，驗證應用軟件設計滿足需求[9]；后者在此基礎上將應用軟件與平臺軟件編譯鏈接加載到目標控制器中，復用集成調試階段的用例開展軟件功能調試，通過比對軟件集成調試與軟硬件集成調試結果的一致性，定位并解決由于目標平臺引入的電氣特性、硬件操作、時序調度等問題，驗證軟硬件集成的正確性[10]。

3 開發(fā)工具

軟件開發(fā)工具包括需求管理工具DOORS、結構化分析工具RTCase、配置管理工具ClearCase、質量流程管理工具ClearQueas、模型設計工具Matlab/Simulink、編碼工具Visual Studio 2010、編譯工具Score，以及自主開發(fā)的被控對象模型、全數字集成環(huán)境、目標集成環(huán)境等。MBD流程工具鏈如圖3所示。

圖3 MBD流程工具鏈

Matlab/Simulink作為MBD流程的核心工具，提供了不同的工具包。為節(jié)約license數量，分配給不同人員的工具包也不同。Matlab、Simulink、Stateflow作為基礎工具，每一個項目成員均配備； Real-Time Workshop (RTW)用于代碼生成，只為軟件專業(yè)配置。

Matlab/Simulink提供了model reference引用機制，以實現模型的協同開發(fā)。上層模型通過reference模塊引用下層模型，建立調用關系。每一次打開上層模型時，系統都會根據搜索路徑自動定位下層模型。其優(yōu)勢在于頂層模型與下層模型彼此獨立，在下層模型接口不變的情況下，不同層模型的開發(fā)工作互不干擾。

4 設計約束

Matlab/Simulink在工業(yè)界主要用于系統仿真，在機載軟件開發(fā)領域的應用才剛起步。面對機載軟件的高安全性要求，中國航發(fā)商用航空發(fā)動機有限責任公司(以下簡稱“中國航發(fā)商發(fā)”)制定了模型設計標準，約束Matlab/Simulink的使用，為項目組提供統一的模型設計指南與約束，確保模型與C代碼風格統一，具有一定的可讀性與維護性。

模型設計標準以汽車行業(yè)MAAB(Matlab Automotive Adivisory Borad)、美國NASA Orion GN&C Matlab/Simulink Standards為雛形，結合項目實踐迭代形成，并持續(xù)完善。標準對文本注釋、模型結構、設計風格、可用庫、仿真配置項等進行了約束。模型可用庫由Link型庫、Ref型庫、仿真配置項以及模型設計模板三部分組成，其中的元素默認設置與設計標準的要求一致。

Link型庫以Library形式呈現，通過庫鏈接定位其在庫中的位置；庫模塊更新后，其在被使用的位置自動更新。模型可用Link_Lib庫如圖4所示。其主要分為三部分：標準工具庫由Matlab/Simulink模塊裁剪而成，包括離散庫、非連續(xù)庫、邏輯與位操作庫、數學操作庫、端口和子系統庫、信號發(fā)生器庫、信號特征庫、狀態(tài)機庫；用戶自定義庫分為基礎函數庫、查表函數庫、控制算法庫；其他庫中包括注釋模塊庫、測試樁模塊庫。測試樁模塊庫通常用于調試，包括示波器、信號激勵源等；其不包含在軟件產品模型中，在庫中使用紅色標志，起到警示作用。

圖4 可用Link_Lib庫

Ref型庫以獨立模型的形式供用戶使用，在被使用的位置通過雙擊reference模塊直接打開并定位。Ref型庫包括模型、數據定義文件、代碼生成配置文件，由Link型庫中的模塊或引用Ref型庫中其他模型形成。Ref型庫主要定義不同項目之間的通用算法或邏輯，較Link型庫層次更高。

面向不同的仿真需求，可用庫提供了8種不同的仿真配置項與模型設計模板。仿真配置項包括仿真迭代算法、仿真步長、診斷選項設置等。配置項通過reference的形式被模型引用，用戶不能修改。

模型發(fā)布時，配置管理的對象以模型為中心，包括模型與數據定義文件、用例與仿真工程、靜態(tài)檢查報告與設計報告。模型發(fā)布后應能夠獨立仿真并生成代碼，若模型中調用了手寫代碼或反包裝的S-function，則應將被調用文件一同發(fā)布。工具自動生成的文件不允許人為修改；若要修改，需先修訂模型后通過工具再次生成。表2給出了具體的模型發(fā)布文件要求。

表2 模型發(fā)布文件要求

設計標準的條款分為強制項與建議項，強制項必須執(zhí)行，否則需說明理由；建議項為參考項，可根據實際情況決定是否遵守。Matlab/Simulink提供了靜態(tài)檢查工具包Model Advisor，對條款進行自動化檢查。中航工業(yè)商發(fā)對Model Advisor工具包進行了裁剪，并開發(fā)了新的檢查項，以最大程度實現條款自動化檢查。該檢查包并未覆蓋所有條款，對于未覆蓋到的條款采用人工方式檢查，并在檢查報告中給出結論。

5 經驗總結

MBD開發(fā)流程的優(yōu)勢表現為：第一，將系統總體、部件設計專業(yè)加入到軟件設計過程中，將其需求通過MBD模型轉化為軟件產品，建立了良性開發(fā)組織；第二，將需求與設計數據由文本化形式轉化為模型，以模型作為溝通介質，減少理解差異引入的錯誤；第三，編碼過程由人工編碼變?yōu)橛赡Ｐ妥詣由纱a，避免由人為編碼習慣引入的錯誤；第四，強化需求和設計的驗證，將驗證工作提前，盡早發(fā)現并解決問題。

項目實施過程中，積累了如下經驗。

①保持工具版本穩(wěn)定，避免在模型集成聯調時報錯；確保同一基線中的模型運行環(huán)境一致，生成代碼風格一致。

②流程、標準、工具手冊需定義清晰，并定期開展培訓。項目反饋的經驗應盡早落實到流程與標準中，并及時宣貫到位。

③指定特定人員維護模型可用庫，及時修正各個項目發(fā)現的庫缺陷，避免同一問題在不同項目中反復出現。

基于MBD的軟件開發(fā)技術才起步，目前該方法仍然面臨諸多挑戰(zhàn)。

①系統設計與軟件設計緊密結合，界面定義模糊，軟件需求層級劃分及其驗證手段和目標不夠明確；

②技術狀態(tài)管控難度較大，集成人員無法獲取準確的模型版本，模型與代碼的版本一致性難以保證；

③工具鏈集成程度不夠，依靠人為過渡的環(huán)節(jié)較多，對標準的自動化檢查力度不夠，工作效率較低。

6 結束語

中國航發(fā)商發(fā)經過3年多的項目實踐，建立了MBD軟件開發(fā)流程，并通過工具鏈有力地支撐了流程的落地。該MBD軟件開發(fā)流程是有效、可行的，采用該方法有利于提升軟件質量、加快軟件研制進度。后續(xù)工作重點在工具鏈的定制開發(fā)以及適航要求的落實。

[1] 方偉,周彰毅.Scade在航空發(fā)動機Fadec軟件開發(fā)中的應用[J].航空發(fā)動機,2016,42(5):43-47.

[2] TAMBLYN A S,HENRY E J,KING E .A model-based design and testing approach for orion gn&c flight software development[C]//IEEE Aerospace Conference,2010:1-12.

[3] 馬恩,劉富榮,王鴻鈞.基于MBD的商用航空發(fā)動機控制軟件架構設計[J].航空計算技術,2013(6):95-99.

[4] 王釗.功能模塊的設計與應用研究[J].自動化儀表,2015,36(11):4-7.

[5] HART J,KING E.Orion gn&c architecture for increased spacecraft automation and autonomy capabilities[R].Honolulu:AIAA,2008.

[6] RAYMOND G,ESTRADA J R,GEN S. Best practices for developing do-178 compliant software using model-based design[C]//AIAA Guidance,Navigation,and Control and Co-located Conferences,2013.

[7] 祝軻卿,王俊席,吳晨楠,等.基于Targetlink的嵌入式系統控制軟件開發(fā)[J].系統仿真學報,2007,19(7):1476-1479.

[8] IMON C.Development of a modeling and simulation environment for real-time performance analysis of electric actuators in maneuvering flight[C]//USA:51st AIAA Aerospace Sciences Meeting Including the New Horizons Forum and Aerospace Exposition,2013.

[9] KEISHI T,MINA S,YASUSHI A M.Applying model-based development(MBD) to embedded systems[C]//Structural Dynamics,and Materials Conference,2014.

[10]SCOTT A K.Model-based design strategies for real-time hardware-in-the-loop rocket system simulations[C]//USA:AIAA Modeling and Simulation Technologies Conference,2012.

Model-Based Developing Approach for Airborne Software of Commercial Engine

LIU Furong

(R&D Center,AECC Commercial Aircraft Engine Co.,Ltd.,Shanghai 201108,China)

With the development of simulation technology and software engineering,the model-based design (MBD) approach for software has been applied to full rights electronic control software of foreign commercial aircraft engines,to solve the difficulties of classical software development process.But this technique is just getting started in China.Aiming at the problems existing in classic software development process,based on MBD,the classical software development process is optimized from three aspects,i.e.,personnel organization,development process and tools; and the disadvantages of classical software development process are resolved.The transform of development organization and development process is introduced; and model-based software design process has been defined; and the personnel,work basis,activity and output involved in each work phase of the process are described; the development tools and the model design standards based on Matlab/Simulink are introduced; and correctness and feasibility of the method are verified.The superiority of MBD for software and project practical experiences are summarized,and the challenges and follow-up priorities of this approach are discussed.

Aerospace; Engine; Airborne software; Design process; Model-based design(MBD); Design standard

劉富榮(1984—)，女，碩士，工程師，主要從事航空發(fā)動機控制系統、機載軟件開發(fā)及其適航技術的研究。 E-mail:lfr1204@163.com。

TH701；TP311

A

10.16086/j.cnki.issn1000-0380.201706007

修改稿收到日期:2017-02-08