基于MBSE思想的航空發動機控制系統設計方法

2021-08-27 06:54:24崔利豐郝彬彬文彬鶴

航空發動機 2021年4期

李琛，吳新，崔利豐，郝彬彬，左偉，文彬鶴

（1.中國航發沈陽發動機研究所，沈陽110015；2.中國航發控制系統研究所，江蘇無錫214063）

0 引言

隨著全權限數字電子控制（Full Authority Digital Electronic Control，FADEC）系統的應用，航空發動機控制系統功能不斷擴展，控制變量逐漸增多，系統的復雜度不斷提升。在以往研制過程中，控制系統暴露出較多技術問題，其中部分原因是系統設計要求不夠詳細，設計過程缺失，導致在詳細設計實現時存在不確定性，造成設計實現與設計目標偏離。這類問題常常在發動機使用過程中不斷地暴露，給試車、試飛帶來一定風險。現階段控制系統研制處于向自主研發的轉型階段，建立正向的控制系統設計能力越來越受到中國工程師的重視。基于模型的系統工程（Model-Based System Engineering，MBSE）的設計方法為復雜系統的設計提供了一種有效手段[1-3]，其核心是按照系統工程的分析過程，將系統需求條目化，并采用數字化、圖形化、建模等方式描述復雜系統設計過程，將需求量化、可測量、可追溯，將設計過程可視化[4-5]。

NASA是最早將MBSE應用于復雜系統設計中的科研機構之一，并將其研究結果大量應用于工程實踐，極大的提升了設計開發能力和產品質量，在航空發動機控制系統設計領域，通過搭建部件級仿真模型，實現了對發動機性能的分析、預估，開展了軍用級、民用級控制系統仿真模型的開發和驗證，為FADEC系統的快速成功研制奠定了基礎[6-8]。近些年，中國高校和航空航天院所才開始使用MBSE方法開展工程設計，初步理解了MBSE設計理念，構建了基礎的MBSE設計工作流程和設計方法[9-11]；張天宏等[12]將實時仿真技術應用于控制系統設計中，并指出基于模型的設計方法是開展控制系統正向設計不可缺少的重要手段。目前，中國控制系統設計多基于文本的形式提出，面臨的主要問題包括：（1）需求方與承研方對于需求的理解存在偏差，導致某些功能和性能不符合發動機的實際需求；（2）僅包括功能要求和性能概要要求，且每項要求的具體實現方法描述不夠清晰；（3）需求零散，無法將需求完整、有機地結合起來。

鑒于中國對MBSE方法研究正處于起步階段，本文從頂層需求角度出發，結合MBSE的設計思想，探索一種發動機控制系統正向設計方法。

1 MBSE設計思想

1.1 MBSE概述

MBSE是近年系統工程的一種全新探索，基本原理仍然是V字模型，如圖1所示。

圖1 系統研發V字模型

系統工程國際標準委員會給出的MBSE定義：規范化的應用建模技術來支持系統需求、設計、分析、驗證與確認，從概念設計階段直至生命周期的后期各個階段，持續貫穿整個產品的開發[13]。其核心思想是通過對系統建模，把待研究系統的特性抽象出來，并用數字化、標準化、圖形化等形式，將設計過程描述出來[14-15]。

1.2 MBSE特點

MBSE是區別于傳統的基于文本的系統工程（Text-Base System Engineering，TSE）而提出的，目的是為了解決傳統系統工程存在的諸多問題。傳統的TSE主要是基于文本、語言的形式來描述需求，由于語言描述內容豐富，并多采用形容詞等模糊描述，導致需求的一致性和準確性差，需求傳遞過程中產生偏差，并且基于文檔難以實現對需求的追蹤，當出現設計變更時，難以對變更進行準確評估。

MBSE相對于TSE優勢如下：

（1）需求條目化。需求多依據功能實現提出，如發動機控制系統應具備讓發動機停車的能力，內容含義豐富，無法直接用來進行系統設計。MBSE采用將需求中的名詞、形容詞、動詞等通過數字化、程序化的形式表達出來，將頂層需求條目化，從而實現需求的向下分解。

（2）語言量化描述。在以往的設計要求中大量采用描述性語言，無法明確地表達具體的內容含義。例如，發動機高原起動簡單描述為：發動機應具備高原起動能力。那么如何才算是具備高原起動能力？將語言量化后，表述為：發動機應具備在不低于2000 m的高原上起動能力，起動時間不超過60 s，起動過程中排氣溫度不超過500℃，起動成功率不低于98%，如圖2所示。將需求量化后才可保證需求無歧義，并且后續可驗證。

圖2 高原起動能力驗證

（3）設計過程顯形化。通過系統的輸入、輸出直接定義系統的行為，被稱為“黑盒式”設計，對于簡單系統的設計可以這樣做，但是對于發動機控制系統這種內部變量多、功能邏輯復雜的系統，若對內部設計過程不關注，一旦出現問題，后果是十分嚴重的。

控制系統多采用閉環控制方式，其原理如圖3所示。在以往的研制過程中，通常直接交由下游設計單位開展設計，若不了解內部的設計過程，在發動機試車驗證時出現問題，會造成設計反復，影響研制進度。

圖3 閉環起動原理

MBSE采用“白盒”設計思想，將內部設計過程顯形化，設計流程清晰PID參數設計技術路徑如圖4所示。

圖4 PID參數設計技術路徑

對上述過程進行參數化建模，如圖5所示。把閉環參數設計黑盒子解耦，將每項設計過程通過建模的形式展現，當在使用中出現問題時可以及時追溯，并快速開展仿真驗證。

圖5 參數設計過程建模

（4）邏輯功能完整。正常狀態的功能邏輯實現簡單明了，通常也可滿足預期的要求。但完整的系統設計應包含正常、非正常和故障工作狀態下的表現行為，且后2種情況下系統的工作狀態決定了系統設計能否滿足頂層的安全性要求。MBSE通過建模可將系統的各種工作狀態（如對信號故障表決過程）均定義完整，信號表決模型見表1。

表1 信號表決模型

2 基于MBSE的控制系統設計

本文主要針對需求分析、功能分解、功能描述等過程開展基于MBSE思想的設計方法研究。采用DOORS、Matlab/Simulink、Amesim等軟件進行需求管理和參數建模。

2.1 需求分析

需求分析包含對利益攸關者需求的捕獲和對需求的確認，以保證需求的無二意性。目前國際上多使用IBM Rational Doors工具來開展需求分析，如圖6所示。建立貫穿整個系統生命周期的需求符合性矩陣，，當需求發生更改時，需要更新需求符合性矩陣，保證需求變更可追溯。

圖6 需求分析過程

發動機控制系統利益攸關方需求主要包含“Re?quirements”和“Domain Knowledge”2方面。“Require?ments”可以理解為系統需求文件，應由具備相應工程研制經驗的控制系統工程師編制，應包含所有利益攸關方的需求、意見和期望，必須進行跟蹤、追溯和控制，需要經發動機和飛機方認可，并且未經允許不得擅自更改；“Domain Knowledge”為領域知識，包括前期工程研究中的設計經驗、對故障的分析歸零報告、設計體系規范等及發動機的控制要求等，需求內涵見表2。

表2 需求內涵

此階段將利益攸關方需求轉化為系統設計需求，并基于需求管理工具進行需求數字化管理，建立系統設計需求條目，實現利益攸關方-控制系統-子系統各級關鍵功能、性能指標的100%傳遞、關聯與追溯。

2.2 系統界面確定

界面也可以理解為上下游之間或互相之間開展設計工作的分界線。清晰、合理的界面劃分可提升工作效率，避免由于工作界面模糊而造成設計上的推諉。在發動機的FADECs系統設計中，電子控制單元（Electronic control unit，ECU）是整個控制系統的中樞，如圖7所示。不僅包含硬件設計，也包含軟件設計，而軟件在程序、邏輯的執行及系統的運行中都起著關鍵作用，本文開展設計的核心是依托于電子控制單元對系統軟件提出要求。

圖7 ECU外部交聯關系

把系統設計界面放在ECU上，并定義界面上的輸入、輸出信號關系，如圖8所示。依據在界面上的輸入、輸出，開展系統設計，并對輸入、輸出信號進行管理，實現系統設計的完整統一。對于傳感器、電纜和液壓執行機構等部件，一般是貨架產品，成熟度較高，可交下游供應商自行設計完成后提供給主機確認。

圖8 輸入、輸出信號定義

2.3 功能分解

2.3.1 功能定義

按照MBSE的設計思想，對于復雜的多功能系統，需開展功能分析，基于功能將復雜的系統劃分為不同模塊，要保證功能相對獨立，并按照設計使用方便的角度來劃分。參考ATA 100美國航空運輸協會規范[16]與GJB 4855-2003軍用飛機系統劃分及編碼[17]中對子系統的定義，控制系統可分解為起動、點火、燃油與操縱、發動機控制、發動機指示系統。

基于子系統劃分和需求分析，將需求整合劃分，定義出不同的功能模塊，主要有起動點火停車、控制規律、狀態監控、系統保護、電源、維護、熱管理、反推控制以及向飛機輸入等基礎功能模塊，如圖9所示。而各功能模塊的運行都離不開信號的串聯，因此將輸入、輸出獨立定義為功能模塊。單獨定義ECU內部模塊用于描述硬件相關需求。依據系統運行模式不同，具體實現功能要求也有差異，基于此考慮定義頂層工作模塊“模式模塊”，用于控制系統不同使用場景切換。對于不同的系統功能模塊劃分可依據具體的功能要求增加或減少。

圖9 功能模塊

2.3.2 功能要求的具體描述

MBSE要求對每項單一功能進行詳細地描述，如何通過MBSE思想完整全面地描述系統的功能要求，是本文研究的重點。將功能具體描述為10方面，保證每項功能都可以完整描述，見表3。這樣既可以強制要求設計人員在編制要求時更完整地考慮問題，又可以避免設計要求不完整或缺失。

表3 10方面描述內容

通過10方面要求的提出，使得系統設計之初就必須考慮該項功能與系統間的交互影響，詳細描述了具體邏輯與計算需求、參數設定等，并明確面對未來可能需要的功能擴展和問題，實現單項功能清晰、準確地描述。

2.4 數據流管理

將各功能模塊的輸入、輸出信號整合為數據字典，定義了系統需要關注的變量，通過數據字典管理輸入、輸出數據流向，將各功能模塊完整、有機地串聯，如圖10所示。

圖10 數據字典

3 設計應用

結合發動機信號模塊設計，對上述設計過程進行詳細闡述，以N1轉速測量為例。

3.1 需求分析

在控制系統頂層的需求中通常描述為：控制系統應準確、可靠地測量發動機的低壓轉子轉速用于發動機的推力控制。

該項需求可分解為幾個核心的關鍵詞：低壓轉子（名詞）、轉速測量（動詞）、準確（形容詞）、可靠（形容詞）。低壓轉子，傳遞了測量對象是發動機的低壓轉子轉速；轉速測量，需要考慮轉速測量方法，工程上常用測量發動機轉速的方法是采用磁電式轉速傳感器測量；準確測量轉速，說明對測量精度有相應要求；可靠地測量，表明測量應具備相應的可靠性，在應考慮故障狀態的處置邏輯。通過對關鍵詞的進一步分析，將頂層的軍方需求轉化為對系統的需求，如圖11所示。最后將需求分析過程錄入DOORS系統中，用于需求管理和追溯。

圖11 需求分解過程

3.2 功能分解

完成需求分解后，對功能實現過程進行定義。轉速測量過程可詳細分解為產生-測量-使用3個過程，主要包含發動機、傳感器、電子控制單元3部分，采用泳道圖的形式對功能需求進行定義，如圖12所示。前2項僅需把定量的要求向下游傳遞即可，而其核心復雜的要求在于數字電控制器對信號的處理過程。

試驗組45（100.00）的滿意度對比對照組滿意程度35（77.78）更高，差異有統計學意義（P＜0.05）。

圖12 功能定義

3.3 功能描述

完成功能需求分析、功能分解后，按照上文的10項內容對功能進行詳細描述。

3.3.1 輸入信號定義傳感器輸入信號如圖13所示。信號是傳感器直接測量的，未經處理的原始信號。

圖13 輸入信號定義

3.3.2 輸出信號此部分無ECU向外部輸出，因此無輸出信號。一般在驅動模塊才有輸出信號定義。

3.3.3 模塊間輸入信號

定義來自其它模塊的輸出，如圖14所示。信號來自模式模塊，因此在模式模塊的輸出部分一定存在該變量。需注意的是，若這2個模塊是由不同工程師設計的，相互之間需要協同定義。

圖14 模塊間輸入信號定義

3.3.4 模塊間輸出信號

與模塊間輸入信號相似，模塊間輸出信號也是本模塊產生的，在其它模塊中使用，如圖15所示。

圖15 模塊間輸出信號定義

3.3.5 單步周期規定了信號處理的最小計算周期要求，應在盡量節省運算資源的前提下保證計算速度滿足功能要求。需要注意的是在相同的功能模塊內，對于不同信號，計算周期要求可能也不同。選取50 ms作為N1信號的計算周期。

3.3.6 前序要求

N1信號不存在前序信號的處理，無前序要求。

3.3.7 精度要求

精度要求應與具體的工程項目要求相關，并依據頂層的性能指標分解。針對本文研究內容定義采集精度為±0.3%，控制精度為±0.5%。

3.3.8 模塊工作要求

N1轉速信號從測量采集到最終被轉化為可用的控制系統信號，需經過雙余度發動機信號處理過程，如圖16所示。數字電子控制器采集N1傳感器的2個余度，供A、B通道使用，使用前需進行傳感器硬件處理、傳感器信號驗證、真值表計算等3步。

圖16 雙余度發動機信號處理過程

（1）硬件處理要求。

a.機內檢測（Build-in Test，BIT）：該模塊包含必要的BIT檢測功能（斷路、短路、電路參數偏離），并提供診斷結果；

b.信號調理：供應商需保證ECU硬件和軟件設計可滿足信號采集精度和運算速率的要求；

c.N1信號測量：測量N1傳感器的頻率信號，將其轉化為相對物理轉速形式描述的數字信號；

d.最高轉速：N1傳感器可測最高轉速不低于發動機實際正常最大工作轉速的160%。

（2）N1信號驗證及真值表表決要求。

采用軟件對雙通道測量信號進行驗證，包括雙通道極值檢測、交叉檢測、積分檢測等。根據BIT診斷結果和極值診斷結果，給出通道驗證狀態信息；根據通道驗證狀態信息進行故障積分診斷，并且將故障積分后的狀態反饋給真值表進行信號表決；真值表表決后輸出N1信號表決結果及缺省值狀態。將文字描述為功能邏輯，如圖17所示。