基于模型驅動構件庫的飛行控制軟件工廠研究

陳宣文， 馬 超， 馬 倩， 孟 強

(航空工業西安航空計算技術研究所，陜西 西安 710068)

1968年，在北大西洋公約組織(North Atlantic Treaty Organization,NATO)召開的軟件工程會議上，首次提出了軟件危機(Software Crisis)的概念[1]。會議上，Mcllroy 提交了一篇題為《Mass-Produced Software Components》的論文，首次提出了軟件構件(Software Components)和構件工廠等概念，指出軟件復用的一個重要基礎就是需要有充足的軟件構件，NATO 制定了關于軟件復用的一套指導性標準，其中就有關于構件的定義和利用標準構件來實現軟件復用的基本思路。2011年12月13日，美國航空無線電技術委員會(Radio Technical Commission for Aeronautics,RTCA) 正式發布了DO-331《Model-Based Development and Verification(基于模型的開發與驗證指南)》，標志著該技術在工程應用領域的成熟[2]。基于模型驅動的開發技術不僅在國外機載飛控、顯控軟件被廣泛運用，在國內民機軟件研制中也在推廣應用。例如，新舟600、ARJ21等型號的顯控系統軟件研制采用了Simulink 模型開發,C919 飛行顯控軟件研制也采用了SCADE 模型開發[3]。近年來，航空工業集團及其各院所對軟件的重視程度不斷提升，提出軟件“三化”(通用化、系列化和組合化(模塊化)的要求[4]。美國國防部也為美空軍的軟件現代化進程組建了越來越多的軟件工廠。目前，已有針對基于模型驅動的軟件開發技術、軟件構件產品庫復用技術和軟件工廠流水線技術的探索研究和實現，但是鮮見能把這三者有機結合在一起的方案。完整軟件生產模式使用了最先進的基于模型驅動設計技術，同時考慮了復用/定制功能，并且建設了規模化的構件產品庫，在可視化的管理平臺上采用軟件工廠流水線模式。為進一步提升型號飛行控制軟件開發效率、質量和工程化能力，把已經成為未來趨勢的基于模型的軟件開發設計技術運用到軟件工廠的構件庫建設中，并進行規模化的應用，開展了基于模型開發結合構件庫的飛行控制軟件工廠的研究并加以實現。

首先，對傳統飛行控制軟件架構進行了分解，分析了飛行控制軟件構件化的需求，給出了基于模型驅動開發構件庫的基本概念，并與傳統軟件開發方法和過程進行了對比分析；然后，針對飛行控制軟件快速開發需求，對飛行控制軟件進行分層和領域構件化分析，建立了軟件開發平臺框架，詳細討論了基于模型驅動開發的構件庫支持的軟件工廠的關鍵技術，提供了在可視化智能向導配置構件的管理平臺快速形成飛行控制軟件整體解決方案的工程化能力。

1 飛行控制軟件總體架構分析

飛行控制軟件駐留在飛控計算機中，接收飛機的姿態、速率、控制、導航、空速和發動機狀態等信號，進行控制狀態選擇、控制律計算和余度管理工作，向伺服放大器和伺服回路輸出控制信號，向電子飛行儀表系統輸出狀態信號，實現對所有飛行控制功能的計算和管理，飛行控制軟件總體架構如圖1所示。飛行控制軟件包括以下幾個部分。

圖1 飛行控制軟件架構

① 地面支持軟件是一套支持嵌入式實時操作系統的開發環境，可以使用開發環境完成應用程序的編譯、連接、加載和調試工作。

② 實時操作系統是飛控計算機的系統管理軟件，管理著系統中應用軟件的工作過程和任務的執行順序，具有快速實時響應、異常/看門狗處理、多任務調度、動態存儲器管理、二進制信號量、互斥信號量、消息隊列、系統時鐘、輔助時鐘支持能力和可剪裁能力。當飛控計算機硬件發生變化，系統可通過板級支持包BSP增、減以及修改相應的驅動程序，從而生成新的操作系統。

③ 飛行操作軟件是飛控的應用層軟件，完成系統的啟動/關閉、任務管理、硬件管理、余度管理功能，根據離散量狀態選擇某一確定飛行模態，進行相應控制律計算，通過D/A輸出將控制指令送給伺服放大器去控制舵機。

④ 自動駕駛儀系統機內自檢測(Built-In Test,BIT)，是計算機系統用于檢測系統各個硬件的功能和性能的所有軟件與硬件的總稱。BIT用于檢測計算機系統的功能和性能，可作為系統維護檢測與確認故障的重要手段。

隨著多余度飛行控制軟件架構規模和復雜度的急劇增加、安全性可靠性的要求大幅提高和軟件工程化管理要求的日益嚴格，傳統的飛行控制軟件開發過程中存在如下問題。

① 飛行控制軟件在需求分析階段不能有效進行需求復用，在設計階段無法有效實現構件復用,開發階段軟件人員對代碼僅僅是自發地選擇復用，沒有進行提前規劃，這樣“復用”以后的軟件仍然需要進行完整的單元、配置項測試和系統測試等過程驗證。

② 飛行控制軟件體系架構中領域專業相關的通用算法邏輯與型號定制算法邏輯沒有實現完全解耦，不具備良好的可擴展性，導致在開發具體項目的飛行控制軟件時，往往需要根據項目特定需求對通用算法進行適應性更改，影響了軟件的可靠性，缺乏體系級別的復用。

③ 在飛行控制軟件的數據輸入端口，存在大量傳感器信號、離散開關信號和總線信號等復雜信號且交聯關系煩瑣，缺少可復用的高可靠飛行控制軟件基礎構件，通過傳統人工編碼方式實現數據采集/還原工作量大且容易出錯。

④ 目前的飛行控制軟件與具體的機載操作系統、硬件驅動接口緊密關聯，如果系統實驗環境不具備，缺乏仿真環境會使余度管理軟件難以進行有效的早期驗證。

綜上所述，采用傳統的飛行控制軟件開發方式將導致“三化”成果無法融合，研制新的飛行控制軟件項目時手工選擇復用組織資產庫從頭開始研發，效率低、風險大，工具、數據獨立缺少集成，無法自動共享和建立關聯關系，數據操作切換頻繁，集成開發環境(Integrated Development Enviroment,IDE)與應用無關，領域支撐力度不夠。因此，需要在現有的能力基礎上，借鑒國外先進技術，學習和掌握新一代基于模型和構件的軟件研發和管理技術(例如，模型開發仿真技術、可定制快速原型仿真技術、全模態綜合調試驗證技術、多團隊統一開發和管理工具鏈技術的軟件流水線/工廠)，將驗證充分的軟件模型和構件放入數據/產品庫，后期研發時，只需逐級分解需求，根據需求配置、組裝已有的軟件模型和構件即可，采用該方式開發的軟件復用度高、軟件缺陷率低，可以大幅提升軟件研發能力，提高軟件成熟度，滿足新一代產品研發需求。

2 對飛行控制軟件進行分層和領域構件化分析

為了提升飛行控制軟件的研制工程支撐能力，根據構件的設計準則，對飛行控制軟件功能、性能、軟件和硬件組成及接口關系進行領域工程建模，對飛行控制軟件的共性通用部分和型號定制部分解耦后進行分層和領域構件化分析，如圖2所示。

圖2 飛行控制軟件構架設計

① IDE內核層。支持多目標機的軟件編譯器、系統調試、結果觀測和結果記錄等功能的調試；支持多余度的動態加載器和固化器，為用戶提供目標文件的燒寫固化、擦除、校驗、查詢校驗碼等功能，是軟件工廠開發平臺的基礎。

② 操作系統層。該層包括MSL設備管理器、OS內核管理器和任務藍圖規劃。其中，MSL設備管理器可對串行通信構件、網絡通信構件、看門狗構件、離散量構件、模擬量構件和總線通信構件等進行配置；OS內核管理器包括時間觸發操作系統、實時分布式操作系統和分時分區操作系統；任務藍圖規劃可根據選定的內核，提供智能導向式內核配置、任務規劃和速率組。

③ 領域設計層。通過推動軟件“三化”設計，形成系列的軟件“三化”構件，按照領域構件化設計思想進行優化設計，形成以同步構件、交叉傳輸構件、數據采集/還原構件、余度管理構件、BIT構件、濾波器構件和慣性結算構件為代表的系統構件和構件設計器。

④ 型號定制層。該層為不可復用的功能提供基于模型設計和手工編碼的設計和導入入口。

對飛行控制軟件進行分層和領域構件化分析后，可以逐層進行操作系統、領域設計和型號定制部分的需求分析和軟件設計，有效地分解和復用通用需求庫中的共性需求，完成完整的軟件需求分析過程。領域構件應形成底層模型庫和構件庫，并可對構件進行選取與組裝，從而搭建完整的飛行控制軟件架構。利用管理平臺相關的工具鏈生成飛行控制軟件的目標程序和文檔，快速形成飛行控制軟件整體解決方案，最后可以依托操作系統與數據接口，并結合仿真數據，即使在系統硬件環境不具備的情況下，也可以在早期有效地完成飛行控制軟件的驗證與測試。

3 基于模型驅動構件庫的軟件工廠

2019年時任美空軍采辦、技術和后勤的助理部長威爾·羅珀稱“美空軍要在21世紀突破機載軟件工作方式的界限，為軍種開辟出新的道路并使軟件日益成為制勝優勢的來源”。凱塞爾航線是美空軍首個軟件工廠，正式名稱是美空軍壽命周期第12支隊。該軟件工廠希望通過快速提高空軍軟件開發、采購和裝備速度，將長達數年的時間線縮短到幾個月，并在開發過程中節省資金。2022年2月，美國防部發布《國防部軟件現代化戰略》明確了美國軍方“建立美國防部全部門的軟件工廠生態系統的愿景目標”，這時美空軍已經建立了18個軟件工廠，如圖3所示。可以說在美國防部軟件現代化方面，美空軍已經走在了前列[5]。

圖3 美軍18家軟件工廠在美國大陸分布圖

使用軟件工廠的生產流水線技術快速開發飛行控制軟件的目標是在項目研制過程中直接使用被重用的構件時，研制流程不再進行需求分析、軟件設計、編碼、單元測試、軟硬件綜合測試、系統測試、軟件評測等重復工作；軟件開發人員有更多精力開展驗證、開發管理、軟件自動生成等關鍵性技術工作；促進飛行控制軟件研制走上軟件產品化、標準化的道路，建立現代工業流水線生產模式的飛行控制軟件研制工廠[6-7]。

飛行控制軟件開發可以在模型驅動構件化支持的軟件工廠管理平臺完成，軟件工廠管理平臺提供智能向導化的可視化配置流程，由開發者進行構件選取、配置來搭建飛行控制軟件架構。IDE內核層已經固化使用方式，僅需要簡單配置實際參數就可以使用。遵循自底向上集成的原則，開發者按照開發流程順序進行飛行控制軟件整體架構的搭建，如圖4所示。首先，應進行操作系統的選型和配置，然后選取和配置領域構件，最后完成型號定制部分。

圖4 飛行控制軟件工廠開發流程

3.1操作系統

3.1.1 MSL設備管理器

在飛行控制系統領域中,將在MSL設備管理層識別出的領域構件按照操作系統構件定義進行了生成與發布,并將系統資源按照不同功能進行劃分。MSL設備管理包括串行通信構件、網絡通信構件、看門狗構件、離散量構件、模擬量構件、總線通信構件、時鐘構件、中斷處理構件等CPU系統資源。

以總線通信構件為例，系統總線資源構件包括：① 低速串行總線構件;② 1553B 總線構件;③ 高速1394B 總線;④ 高速FC 總線構件;⑤ 高速DMA 傳輸構件;⑥ XML 能力構件。

如果選用的操作系統是VxWorks，則與飛控系統底層設備相關的總線資源構件均應按照VxWorks 操作系統標準I/O 設備操作規范編寫,從而保證設備的操作接口的規范化。

以高速1394B總線為例，1394B總線領域構件在VxWorks 5.5 構件配置樹(Tornado 2.2集成開發環境)中的表現方式如圖5所示。

圖5 Tornado/VxWorks環境下1394B總線構件的實現

3.1.2 操作系統內核管理器

根據選定的內核，提供智能導向式內核配置、任務規劃和速率組可視化配置，為飛行控制軟件的應用層提供支撐。在平臺上對任務完成執行周期、任務參數、執行時間和任務棧等屬性進行配置，并將任務調度周期可視化顯示,如圖6所示。

圖6 任務調度管理配置

3.1.3 操作系統任務藍圖規劃

操作系統任務藍圖規劃如圖7所示，包括以下需要配置的內容。

① 任務設置。可對啟動任務、任務基礎速率、各個任務的速率設置和后臺任務進行設置。

② 系統剩余時間設置。對系統剩余時間進行設置，以滿足余量要求。

③ 健康監控設置。健康監控定義并分類飛控系統中所發生的錯誤，分別在3個層次(進程級、分區級和模塊級)根據錯誤發生時的系統狀態，執行相應的錯誤恢復策略。

④ 非屏蔽中斷設置。對系統各級非屏蔽中斷的屬性進行設置，例如中斷號、中斷向量和連接中斷處理程序。

⑤ 高速緩存設置。對高速緩存總線的類型、余度配置、波特率等屬性進行設置。

⑥ 系統同步設置。對系統工作的同步總線進行設置，包括初始同步和周期同步。

圖7 系統任務藍圖規劃

3.2 領域構件配置界面

在各領域共性構件庫支持下，進行領域構件可視化配置，包括整體配置、信號輸入定義、總線及設備定義、離散量管理配置、數字量管理配置、傳感器管理配置、計算機管理配置、伺服器監控配置、積分器均衡、故障記錄、故障碼定義、故障綜合等。

以傳感器管理配置為例，如圖8所示，對傳感器的以下各屬性進行配置。

① 對傳感器信號的定義管理，包括新建、改名、確認和刪除等操作。

② 傳感器信號余度配置，包括是否單信號工作，是否帶有自監控信號、門限是否可變等。

③ 各余度傳感器監控時延設置，主要對時延格式進行設置。

④ 傳感器監控所屬的表決速率組、監控速率組，以及瞬時故障區設置等。

⑤ 傳感器信號出現故障時的運算安全值策略預設，可選擇表決值、歷史值、安全值和計算插值。

圖8 領域構件配置

在具體領域進行設計開發時，可以根據項目需求在領域構件可視化配置界面進行選型與配置，快速搭建飛行控制軟件解決方案。

在飛行控制軟件領域的具體應用中，根據領域應用的具體需求，在可視化界面完成參數化模塊配置后，構件層在通用構件庫中檢索相關構件，進行基于標準接口進行構件的快速復合組裝。基于領域工程的領域構件技術利用了領域工程的功能內聚性和穩定性等特點，有利于提高軟件的復用效率和軟件質量。

3.3 型號定制

早期的飛行控制軟件開發方式是根據文字化、條目化的需求進行自頂向下逐步分解、設計，之后手工編碼完成，這種項目開發方式的可視化和效率較為低下。現在，由于經常面臨緊迫的交付周期和激烈的團隊競爭，設計、編碼和測試過程高度交叉，軟件的規模也日趨龐大，為了將軟件設計人員從復雜的編碼工作中解放出來，將工作的重心轉移到飛行控制軟件的安全性、可靠性等關鍵需求分析上，有必要采用更高效的軟件設計方式。

基于模型驅動的開發使用更接近于人的理解和認識的模型，將需求與設計數據由文字描述的形式轉換為可視化的模型，有利于設計人員把注意力集中在系統工作邏輯相關的內容，而不用過早考慮與平臺相關的實現細節，并且在開發周期的早期驗證設計、測試用例和收集覆蓋率指標。實現環節通過自動代碼生成和自動代碼檢查提高軟件質量，并且可以運用工具鏈使用自動設計的測試用例進行測試和檢查。即使是當前不可復用的定制部分，仍然采用復用規范過程進行開發和管理，并在完成軟件測試后進入產品目錄、構件產品庫和模型庫。

模型驅動構件可定制開發技術的優點有：可顯著提升軟件按需定制和隨需應變的能力，使流程、數據、規則、資源和界面等構件要素實現了分離，減少了手工編程工作量，提高了軟件開發效率，降低了軟件開發和維護成本；降低對軟件開發人員要求，系統手工編程工作量的減少，使大部分軟件開發者能完成大部分模型定制工作；提高業務管理軟件的可靠性和可維護性，系統可靠性主要體現在模型定制、模型轉換和運行支撐等工具的可靠性上，而傳統手工編程方式難以保證業務軟件的可靠性，同時會導致系統內部和第三方測試的工作量增加。另外，當業務需求發生變化時，只需調整相應業務模型即可，系統可維護性也得到提高[8]。

針對具體項目的定制化需求，應用模型化設計，通過模型與需求對接，提升軟件設計、仿真驗證，形成了模型標準，納入軟件設計標準，規范了軟件模型設計，制定的開發規范包括：① 《模型命名方法》；② 《模型安全性設計方法》；③ 《模型外觀設計方法》；④ 《狀態機設計方法》；⑤ 《模型輸入輸出方法》；⑥ 《模型庫的使用》。

基于模型開發的主流工具包括SCADE和MATLAB/Simulink等，SCADE以高安全性領跑于模型開發領域，代碼生成器KCG通過了航空領域的DO-330(TQL-1)、核能行業領域的IEC 60880(核安全級)、軌道交通領域的EN 50128(SIL-3)等標準并在高安全性行業應用[9-10]； MATLAB/Simulink應用廣泛，擁有眾多自帶模型庫、算法庫、控制系統、環境模型以及優秀的專業協同設計兼容性，可以完成產品級別的聯合仿真、建模、設計、測試和報告平臺集成工作。以MATLAB/Simulink開發環境為例，基于模型的設計和形式化方法在符合DO-178C、DO-331、DO-333和DO-330的過程中，MathWorks工具可用于DO-178C項目的開發和驗證階段。Simulink?、Stateflow?和Requirements ToolboxTM被用于開發符合DO-331基于模型的開發和驗證的軟件。根據DO-331和DO-178C的要求，Simulink Report GeneratorTM用于提供設計描述文檔和跟蹤數據。通過Simulink CheckTM、Simulink TestTM、Simulink CoverageTM和Simulink Design VerifierTM對設計進行驗證。使用MATLAB CoderTM、Simulink CoderTM和Embedded Coder?開發系統的源代碼。使用Simulink Code InspectorTM、Polyspace Bug FinderTM和Polyspace Code ProverTM對源代碼進行驗證。可執行的目標代碼的驗證是使用Simulink Test和Simulink Coverage以及處理器在環(Processor in the Loop,PIL)中的測試功能來執行的。圖9為覆蓋DO-178C/DO-331 過程的MathWorks完整工具鏈路徑[11]。

圖9 覆蓋DO-178C/DO-331 過程的MathWorks工具鏈路徑圖

以飛控系統的工作狀態管理為例，飛行控制軟件在飛控系統工作全狀態下對5種工作狀態切換進行驗證。在對邏輯實現內容進行分析的基礎上，利用Stateflow 來實現狀態切換，并與Simulink 有機結合，共同建立了駕駛儀工作狀態仿真和應用，同時對Simulink/Stateflow/Model Advisor/Bug Finder工具鏈進行了驗證使用，最后對模型自動生成的代碼進行了優化，整個工作狀態仿真過程和結果如圖10所示。由Stateflow 所建立的圖形化模型邏輯結構簡潔、清晰，可用Simulink/Stateflow進行早期驗證，提高開發效率，縮短開發時間，自動生成的代碼經過驗證和檢查，表明其可滿足飛行/仿真要求。

圖10 飛行控制軟件工作狀態驗證仿真

綜上所述，對現有飛行控制軟件開發模式進行了對比和分析，如表1所示。探索、研究和實踐目前是基于模型驅動構件庫的軟件工廠的開發模式，采用了先進的開發方法和手段，對飛行控制軟件的通用部分和領域部分進行了解耦，在可視化智能化導向配置平臺的支持下，對模型開發形成的構件庫可以進行有效配置和復用，在軟件開發模式上和美軍軟件工廠模式保持同步，可以供業內軟件研發單位參考，進行工程化推廣應用。

表1 幾種飛行控制軟件開發模式的對比

4 構件產品庫開發和維護

構件產品庫的開發應遵循一系列模型驅動構件的開發規范，例如面向復用與共享的軟件需求分析規范、面向復用與共享的軟件構件設計規范、代碼復用工作流程及管理規范、面向復用與共享的軟件測試工作規范等。

基于模型開發的構件支持產品庫，在已經擁有可復用構件后，還應保證設計開發人員能夠快速、容易地找到和理解，這就是構件產品庫的主要作用。構件產品庫是用于組織、存儲和管理可復用組件的。在建立構件產品庫的同時，還需要建立配套的分類、檢索和復用的目錄，并可以對構件進行新建、檢索、更新和刪除的操作，以及對其進行有效的配置管理[12-13]。

5 結束語

與傳統的飛行控制軟件開發流程相比，基于模型驅動構件庫的軟件工廠的開發模式可以大幅提高飛行控制軟件的開發效率。在軟件工廠協同開發管理平臺的支持下，對飛行控制軟件進行可視化分析和配置，可有效復用通用需求庫中的共性需求，并可針對項目專用需求進行型號定制需求分析。在軟件設計階段，根據共性需求從通用領域構件庫中進行構件選取與組裝；其次根據項目型號定制需求完成定制部分算法模型的開發，快速形成飛行控制軟件整體解決方案，并且可以進行早期驗證和測試。實踐證明，基于模型驅動構件庫的軟件工廠的開發模式可以提高飛行控制軟件研發的安全性與可靠性，縮短軟件開發與驗證的周期。