基于MBSE思想的航空發(fā)動機控制系統(tǒng)設計方法

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

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

0 引言

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

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

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

1 MBSE設計思想

1.1 MBSE概述

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

圖1 系統(tǒng)研發(fā)V字模型

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

1.2 MBSE特點

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

MBSE相對于TSE優(yōu)勢如下：

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

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

圖2 高原起動能力驗證

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

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

圖3 閉環(huán)起動原理

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

圖4 PID參數(shù)設計技術路徑

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

圖5 參數(shù)設計過程建模

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

表1 信號表決模型

2 基于MBSE的控制系統(tǒng)設計

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

2.1 需求分析

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

圖6 需求分析過程

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

表2 需求內(nèi)涵

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

2.2 系統(tǒng)界面確定

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

圖7 ECU外部交聯(lián)關系

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

圖8 輸入、輸出信號定義

2.3 功能分解

2.3.1 功能定義

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

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

圖9 功能模塊

2.3.2 功能要求的具體描述

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

表3 10方面描述內(nèi)容

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

2.4 數(shù)據(jù)流管理

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

圖10 數(shù)據(jù)字典

3 設計應用

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

3.1 需求分析

在控制系統(tǒng)頂層的需求中通常描述為：控制系統(tǒng)應準確、可靠地測量發(fā)動機的低壓轉(zhuǎn)子轉(zhuǎn)速用于發(fā)動機的推力控制。

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

圖11 需求分解過程

3.2 功能分解

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

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

圖12 功能定義

3.3 功能描述

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

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

圖13 輸入信號定義

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

3.3.3 模塊間輸入信號

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

圖14 模塊間輸入信號定義

3.3.4 模塊間輸出信號

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

圖15 模塊間輸出信號定義

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

3.3.6 前序要求

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

3.3.7 精度要求

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

3.3.8 模塊工作要求

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

圖16 雙余度發(fā)動機信號處理過程

（1）硬件處理要求。

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

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

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

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

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

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

圖17 雙余度信號驗證及真值表表決邏輯

采用Matlab/Simulink對功能邏輯建模，如圖18所示，用于對邏輯設計的準確合理性驗證及系統(tǒng)的早期驗證。

圖18 表決邏輯數(shù)學模型

3.3.9 說明

在不同模式狀態(tài)下，N1故障檢測閾值不同，參考示例見表4。

表4 故障檢測閾值

3.3.10 存在問題

在具體設計時還應對下列問題進行考慮：

（1）系統(tǒng)規(guī)范規(guī)定的參數(shù)范圍是從發(fā)動機提出的參數(shù)，在軟件和硬件實現(xiàn)時要考慮干擾和雷擊的影響，對參數(shù)進行調(diào)整；

（2）在轉(zhuǎn)速較低時（如7%以下），N1測試結果可能不準確，信號出現(xiàn)異常突跳，在硬件電路處理時需額外注意。

3.4 數(shù)據(jù)字典

最后將模塊中使用的輸入、輸出信號整理后錄入數(shù)據(jù)字典，如圖19所示。

圖19 數(shù)據(jù)字典

4 結論

（1）通過需求分析將利益攸官方需求條目化，建立了利益攸關方-控制系統(tǒng)-子系統(tǒng)各級關鍵功能性能指標的100%傳遞，對每條需求進行確認，保證了每條需求含義的準確傳遞，采用DOORS軟件進行需求管理，方便需求關聯(lián)與追溯；

（2）基于功能分解，以ECU為核心，將復雜的控制系統(tǒng)設計劃分為若干功能模塊的設計，并采用量化的要求和模型化、圖形化的設計過程，將每項功能詳細描述，有利于設計效率的提升，將功能描述為10方面，避免在設計過程中導致的不完整、不規(guī)范；

（3）使用數(shù)據(jù)字典對輸入、輸出數(shù)據(jù)流進行管理，識別每項功能邊界外的接口和信息，以數(shù)據(jù)的輸入、輸出為導向，使得設計過程更加清晰和規(guī)范，同時將各功能模塊有機地結合在一起，達到系統(tǒng)設計的完整統(tǒng)一；

（4）通過N1測量系統(tǒng)的設計過程，對設計方法進行了應用，該方法可使需求分析過程更充分，設計過程更完整，設計描述更清晰，設計實踐表明該方法可用于工程設計。