航空發(fā)動機FADEC系統(tǒng)數(shù)字原型構(gòu)建技術(shù)

相對于傳統(tǒng)的實現(xiàn)方式，基于模型的FADEC系統(tǒng)軟件開發(fā)可以在前端完成約55%的設(shè)計活動，通過更早地發(fā)現(xiàn)、解決設(shè)計中存在的問題，提高了迭代效率。航空發(fā)動機全權(quán)限數(shù)字式電子控制（FADEC）系統(tǒng)基于模型的軟件開發(fā)的工作量大且過程繁復。傳統(tǒng)的開發(fā)模式是先對主機需求直接進行分解，再傳遞給軟件開發(fā)人員進行手工編碼和報告，然后在半物理模型上進行驗證和調(diào)試。這種模式缺少桌面設(shè)計過程（即多專業(yè)協(xié)同，完成信號處理、故障檢測、余度管理、故障對策、控制律、健康監(jiān)視與告警等算法與邏輯的設(shè)計建模與模型集成，模型集成前需由各專業(yè)設(shè)計人員自己完成相應模塊的單元測試），在軟件完成編碼、半物理或臺架試驗甚至是飛行試驗時才會暴露問題，迭代成本和風險都很高；而且手工編碼和報告的效率低，無法滿足主機日益頻繁的變更需求。針對上述問題，創(chuàng)新團隊引入了桌面原型技術(shù)，如圖1所示。通過構(gòu)建系統(tǒng)級的詳細設(shè)計數(shù)字原型，借助建模仿真手段，將設(shè)計與驗證活動前移，在軟件開發(fā)之前先進行設(shè)計驗證與迭代，從而更早發(fā)現(xiàn)設(shè)計問題，提高研發(fā)效率，具體如圖2所示。圖1

桌面原型流程

圖2

原路徑與基于模型的FADEC系統(tǒng)軟件開發(fā)技術(shù)實施路徑對比模型構(gòu)建為了降低建模門檻、提高建模效率，創(chuàng)新團隊從底層的基準模塊庫、頂層的通用模型架構(gòu)和中間層的應用算法共用基礎(chǔ)模塊（CBB）等3個維度構(gòu)建基礎(chǔ)模型。基準模塊庫創(chuàng)新團隊基于Simulink建模元素和Stateflow建模工具，針對FADEC系統(tǒng)的特點開發(fā)了基準模塊庫，主要包括基準邏輯庫和基準動態(tài)庫?；鶞蔬壿嫀彀ㄈ舾蛇壿嫿ＤK，具備一定復雜度的獨立邏輯功能?；鶞蕜討B(tài)庫包括各類動態(tài)算法，與Simulink自帶的傳遞函數(shù)相比，考慮了軟件離散化的特性，并增加了狀態(tài)量的過程控制接口。用基準動態(tài)庫建模帶來的好處是能支持自動代碼生成，仿真狀態(tài)與實際FADEC系統(tǒng)的產(chǎn)品狀態(tài)更接近，能實現(xiàn)Simulink自帶模型庫無法實現(xiàn)的工程應用中碰到的各類變種算法。通用模型架構(gòu)根據(jù)FADEC系統(tǒng)的特點，項目構(gòu)建了通用模型架構(gòu)。項目研發(fā)時，只需在確定的模型架構(gòu)下設(shè)計局部的算法，節(jié)省了模型架構(gòu)的設(shè)計時間，保證了不同項目結(jié)構(gòu)的一致性，便于設(shè)計結(jié)果和設(shè)計人員的高效復用。通用模型架構(gòu)的頂層結(jié)構(gòu)包括飛機模塊（plane）、電子控制器模塊（EEC）、執(zhí)行機構(gòu)模塊（actuator）、發(fā)動機模塊（engine）和傳感器模塊（sensor）。應用算法CBB對于FADEC系統(tǒng)中信號處理、故障檢測、余度管理、控制律等一些通用算法，可以整理、封裝，形成應用算法CBB庫。仿真驗證建模規(guī)范與檢測工具開發(fā)FADEC系統(tǒng)建模規(guī)范主要出于以下幾個方面考慮：一是減少模型及基于模型生成自動代碼的缺陷；二是增加模型的可讀性；三是規(guī)避Matlab工具本身存在的一些缺陷；四是更好地支持驗證與確認、報告自動生成等工具的使用；五是專業(yè)層面的特殊約束要求。建模規(guī)范主要包括如下幾類內(nèi)容：命名規(guī)范、模型體系架構(gòu)設(shè)計、Simulink建模規(guī)范和Stateflow建模規(guī)范。為了確保設(shè)計人員按照建模規(guī)范進行模型構(gòu)建，創(chuàng)新團隊開發(fā)了與建模規(guī)范對應的模型規(guī)則檢查工具，設(shè)計人員完成建模后，運用該工具對模型進行自動分析檢查，對檢查出的不符合項進行更改完善。形式化模型驗證對于集成后的FADEC系統(tǒng)模型，創(chuàng)新團隊采取如下分級測試的方式：一是將模型按照系統(tǒng)功能劃分為幾大部分，如主燃油控制、風扇導葉控制、壓氣機導葉控制等，借助Matlab自帶形式化驗證工具（designverifier）對每個功能模塊進行修正判定條件（MC/DC）100%覆蓋度測試；二是系統(tǒng)模型整體測試，以滿足系統(tǒng)需求為主，不要求MC/DC100%覆蓋度。模型變更模型設(shè)計與仿真驗證完后，需要建立模型與需求的雙向追溯關(guān)系，追溯顆粒度為最小模型模塊（對應軟件的單元函數(shù)），主要有確認設(shè)計與需求的符合性和便于變更域影響分析兩個用途。創(chuàng)新團隊開發(fā)的變更域影響自動分析工具主要有兩個功能：如有模型變更，自動識別并篩選出與該模型相關(guān)的需求；如有需求變更，自動識別與該需求相關(guān)的模型，生成模型清單并可通過超鏈接定位到模型。報告生成為了使設(shè)計人員的精力集中在模型設(shè)計本身，將繁復的報告撰寫工作交給機器，創(chuàng)新團隊開發(fā)了桌面原型設(shè)計報告自動生成工具。當設(shè)計人員完成建模、信息注釋、數(shù)據(jù)定義并建立需求與模型的雙向追溯關(guān)系之后，文檔生成引擎從這些數(shù)據(jù)源提取信息，自動生成符合歸檔要求的設(shè)計報告。桌面原型設(shè)計報告數(shù)據(jù)源關(guān)系如圖3所示，其中信息注釋為記錄的關(guān)鍵設(shè)計思路，嵌入在模型中的注釋模塊中，數(shù)據(jù)字典為所有模型數(shù)據(jù)。圖3

桌面原型設(shè)計報告數(shù)據(jù)源關(guān)系桌面原型設(shè)計報告自動生成工具主要功能有：開發(fā)注釋插件；模型注釋信息提??；基于鏈接關(guān)系提取需求；模型參數(shù)信息生成；通用基礎(chǔ)模塊識別；模型版本差異信息生成；通用、專屬信息分離等。符合性測試與驗收以模型為基準的軟件符合性測試驗收的對象包括各個層級，除了軟件單元測試，其他層級的軟件測試模型均為介入式。對不同層級的軟件測試采取不同的手段，包括軟件代碼仿真測試和目標機系統(tǒng)測試等，如圖4所示。圖4

以模型為基準的軟件符合性測試驗收方法軟件代碼仿真測試為了加快研發(fā)速度，降低對硬件環(huán)境的依賴，大量的軟件測試工作在仿真下完成，包括開環(huán)測試和閉環(huán)測試。開環(huán)測試在軟件部件測試、集成測試和系統(tǒng)測試都有涉及，閉環(huán)測試只在系統(tǒng)測試層級涉及。對于開環(huán)測試和部件測試，基于模型進行符合性驗收的介入方式不一樣。在開環(huán)測試中，對于基于模型自動代碼生成的項目，應用桌面原型完成模型測試和代碼測試，將測試結(jié)果傳遞給軟件工程師，納入整個軟件測試結(jié)果中，對模型產(chǎn)生的代碼部分軟件工程師不再額外測試。閉環(huán)測試的4種方式中有兩種與開環(huán)測試的方式相同，即將基于模型產(chǎn)生的測試數(shù)據(jù)傳遞給軟件仿真測試平臺，或者將軟件仿真的測試數(shù)據(jù)傳遞給模型。此外，還有兩種在線符合性測試方法。與離線符合性測試相比，在線符合性測試可以實現(xiàn)隨機測試輸入的注入，即測試人員可以隨機任意給出模型和軟件的輸入，看二者運行結(jié)果是否一致。目標機系統(tǒng)測試軟件在真實目標機（電子控制器）中運行時的某些時序特征，如低優(yōu)先級大周期速率組任務被高優(yōu)先級小周期速率組任務中斷等，在仿真測試模式下無法體現(xiàn)，因此軟件代碼仿真測試層級主要測試軟件邏輯，對于時序的符合性測試主要在目標機系統(tǒng)測試層級進行。針對軟件多速率組任務調(diào)度與時序特征，需要在常規(guī)模型的基礎(chǔ)上，額外增加功能模型模擬，這一部分模型模擬目標機本身的時間機制和操作系統(tǒng)調(diào)度機制，不參與應用軟件的自動代碼生成或手工編碼。由于目標機本身的時序運行結(jié)果是受自身硬件特征和操作系統(tǒng)特征確定，無法通過任務調(diào)度模型的仿真數(shù)據(jù)控制，因此以模型為基準的軟件符合性測試方法可以采用如下離線符合性測試方法：將目標機系統(tǒng)閉環(huán)測試數(shù)據(jù)傳遞給任務調(diào)度模型仿真測試平臺，將軟件測試用例注入到模型，將模型運行結(jié)果與軟件運行結(jié)果進行一致性對比。結(jié)束語創(chuàng)新團隊聚焦航空發(fā)動機FADEC系統(tǒng)詳細設(shè)計，研究了基于