航空發(fā)動機研制需求管理探析

盧川川，李倫未，孫文斌，李 華，許 多

(中國航發(fā)四川燃氣渦輪研究院，成都 610500)

1 引言

航空發(fā)動機研制是一個以需求為根本出發(fā)點，自頂向下逐層分解、自底向上集成驗證的正向研發(fā)過程[1]。研制需求是航空發(fā)動機研制項目一切活動的起點、考核依據(jù)和最終目標。需求管理既是系統(tǒng)工程管理(技術(shù)管理)的基礎工作，也是科研項目管理的基礎工作，其過程一般包括需求捕獲、需求分析與定義、需求分解分配、需求驗證策劃、需求驗證和確認、需求變更、需求追溯及需求驗證跟蹤管理等活動，覆蓋了航空發(fā)動機研制全過程[2]。

目前，在飛機領域研究者們針對需求管理已開展了不少相關研究工作。如季建琴[3]、郭博智[4]、董亮[5]、田彬[6]等論述了基于系統(tǒng)工程V 模型的飛機需求管理過程、需求信息架構(gòu)設計、需求層級及需求分解演變過程，王煥青[7]、王瑾[8]、周璇[9]等論述了飛機需求變更管理技術(shù)，陳重陽等[10]討論了海軍裝備發(fā)展作戰(zhàn)需求生成流程和機制，鄭占君等[11]提出了基于DOORS 的飛機設計需求數(shù)據(jù)管理方案，董亮等[12]闡述了航空產(chǎn)品研制條目化需求管理的關鍵技術(shù)并介紹了幾款需求管理工具的特點。但在航空發(fā)動機領域，雖然對需求管理方法和工具進行了一定的研究和應用，如羅婷婷[13]闡述了商用航空發(fā)動機需求管理及其系統(tǒng)構(gòu)建方法，史妍妍等[14]提出了基于產(chǎn)品分解結(jié)構(gòu)的航空發(fā)動機需求管理模型及其一般流程，卻遠不及其他領域廣泛。鑒于此，本文基于系統(tǒng)工程需求管理過程的主要內(nèi)容，探索出一種適合軍用航空發(fā)動機研制的需求管理總體框架、組織模式，以及基于Teamcenter 的需求數(shù)據(jù)追溯管理方案，并闡述了具體項目需求管理的實施路徑。

2 航空發(fā)動機研制需求管理實施方案

2.1 總體框架

作為武器裝備的重要組成部分，航空發(fā)動機研發(fā)按階段進行控制和管理[15]。因此，航空發(fā)動機研制需求管理亦可面向研發(fā)全過程按階段/批次實施，如圖1 所示，維持需求和需求驗證的繼承性：①項目/產(chǎn)品層面維持一套需求。以產(chǎn)品研制總要求、型號規(guī)范等最終考核、鑒定要求為核心，隨著“論證-方案-工程研制-狀態(tài)鑒定-列裝定型-在役考核”研制階段的推進而演化和更新。②各階段/批次維持自身的需求。該需求來自于項目/產(chǎn)品層面的需求，但可針對本階段/批次的驗證目標進行調(diào)整，驗證情況和結(jié)果亦可反饋于項目/產(chǎn)品層面的需求，為其演化和更新提供依據(jù)。

圖1 航空發(fā)動機研發(fā)全過程需求管理Fig.1 Requirements management through aero-engine development

各階段/批次內(nèi)均須開展需求分析與定義、需求驗證策劃、需求分解分配、需求驗證、需求變更和需求數(shù)據(jù)鏈維護等工作。自用戶層需求開始，隨著設計(方案)的不斷細化，逐層(包括發(fā)動機、部件/系統(tǒng)等)分析和定義需求。

需求分析與定義、需求確認和驗證是一個不斷迭代和遞歸的過程：①上級對象的需求及設計(方案)作為下級對象需求的輸入，但視需求驗證情況，下級對象的設計(方案)將可能影響上級對象的設計(方案)，引起需求必要的調(diào)整；②下級對象的需求驗證作為上級對象需求驗證的輸入，下級對象的需求驗證結(jié)果將可能影響兩級對象的需求確認/驗證，引起需求驗證策劃的必要調(diào)整。

2.2 組織模式

為便于需求權(quán)衡和整合，以及統(tǒng)籌需求驗證策劃，采用覆蓋多專業(yè)的聯(lián)合工作團隊(IPT)，針對每個層級協(xié)同開展需求捕獲、需求分析與定義、需求驗證策劃等工作，重點解決各層級結(jié)構(gòu)、強度、六性、適航和材料工藝等需求分散、需求重合或沖突的問題。

各層級需求管理IPT 涵蓋專業(yè)一般包括：氣動/性能設計，控制、起動、電氣及測試系統(tǒng)設計，空氣系統(tǒng)設計，結(jié)構(gòu)設計，強度設計，材料工藝設計，六性及適航設計，標準化管理，系統(tǒng)工程及技術(shù)管理等。

2.3 管理工具

業(yè)內(nèi)目前常用的兩款需求管理工具為Teamcenter(簡稱TC)和DOORS。采用TC 可管理航空發(fā)動機需求驗證(設計、分析、試驗等)的文件，并能便捷實現(xiàn)需求與上述數(shù)據(jù)的關聯(lián)管理；而DOORS 是獨立的需求管理軟件，可以方便地管理需求數(shù)據(jù)，但要實現(xiàn)與TC 中需求驗證數(shù)據(jù)的集成管理則需作接口開發(fā)。兩者均能實現(xiàn)結(jié)構(gòu)化需求創(chuàng)建、需求屬性定義及內(nèi)容編寫、需求審批發(fā)布及需求驗證符合性分析等基本功能，如圖2 所示。

鑒于TC 能提供產(chǎn)品BOM(物料清單)關聯(lián)管理的解決方案[16]，本文構(gòu)建了以需求為源的研發(fā)過程數(shù)據(jù)集成管理及其與研發(fā)任務的關聯(lián)管理框架，如圖3 所示。其中，產(chǎn)品研發(fā)全過程數(shù)據(jù)關聯(lián)、維持均基于TC；而任務管理基于MPM，通過WBS 與需求驗證計劃關聯(lián)，通過平臺集成實現(xiàn)與TC 產(chǎn)品數(shù)據(jù)(WBS 交付物)關聯(lián)。

3 航空發(fā)動機需求管理應用

3.1 專項小組組建

按照一體化/協(xié)同化IPT 組建要求，成立發(fā)動機需求管理工作專項小組，確定其共同工作職責如下：

圖2 DOORS 與Teamcenter的比較Fig.2 Comparison of DOORS and Teamcenter

圖3 以需求為源的數(shù)據(jù)集成管理Fig.3 Data integration management based on requirements

(1)負責各功能體需求來源識別、需求分析和整合，將需求條目化、結(jié)構(gòu)化并導入TC；

(2)負責完善需求屬性、內(nèi)容，建立需求與需求間的關聯(lián)；

(3)負責各功能體間的需求分解、分配、傳遞和對接，解決需求沖突和不一致；

(4)開展需求評審，負責建立和發(fā)布需求基線，以及實施(必要的)需求更新/更改；

(5)開展需求驗證策劃，確定相應的工作項及交付物；

(6)負責建立需求與理論驗證、試驗驗證文件間的關聯(lián)，跟蹤需求驗證狀態(tài)，判定需求符合性。

3.2 工作要求

工作要求是制定發(fā)動機需求管理計劃、需求分析指南和基于TC 的需求管理辦法，明確需求分類、需求條目化顆粒度、需求相關要素等具體要求。需求分類的定義見表1。

表1 需求分類說明Table 1 Description of requirements classificaiton

針對不同產(chǎn)品層級(整機、部件/系統(tǒng)、零組件/成附件等)，分別定義和編寫其需求，形成以產(chǎn)品對象為中心的條目化、結(jié)構(gòu)化需求BOM，如圖4 所示。

圖4 需求BOM 示例Fig.4 Example of requirements BOM

最底層為具體的需求條目，在此定義其屬性、內(nèi)容和上下游數(shù)據(jù)關聯(lián)等要素；其他層為對需求的歸類。對于不同層級間存在需求分解、分配關系的，除在需求屬性中標識外，通過跟蹤鏈接建立跨需求BOM 之間的關聯(lián)。對于從功能、性能、結(jié)構(gòu)、強度、六性、適航、材料、工藝等多個專業(yè)角度提出的同類需求，需要進行權(quán)衡和整合。

需求顆粒度一般應符合以下要求：①一條需求僅表述同一件事或同一個主題，如不同狀態(tài)點的性能要求應分開定義；②同一主題的多個參數(shù)或指標應合在一起，如主燃燒室出口徑向、周向溫度場不均勻度不應分開定義；③一條需求應針對單一產(chǎn)品對象表述，即不同對象的需求應分開定義，如不同零件的強度要求；④沒必要逐一在零組件層級定義的需求(例如選材)，僅在部件/系統(tǒng)層定義。

每一條需求包含以下要素：①標題——簡明、扼要地概括一條需求的主要內(nèi)容，見圖5；②屬性——定義一條需求的相關特征，如需求編碼、需求來源、需求級別、需求類型、優(yōu)先級、驗證狀態(tài)等，見圖5；③內(nèi)容——準確、詳細定義一條需求的內(nèi)容，如設計參數(shù)、技術(shù)指標、約束條件等(包括圖、表等)，見圖6；④驗證方法——定義一條需求對應的驗證方法和輸出物，在②和③中均體現(xiàn)；⑤數(shù)據(jù)關聯(lián)——定義一條需求與上下游數(shù)據(jù)對象的追溯和傳遞關系，見圖7。

3.3 需求分析與定義

按以下步驟開展各功能體的需求分析與定義：

(1)梳理需求來源文件(型號頂層文件和其他約束文件)；

(2)分別梳理每個功能體相應的每一類需求；

(3)根據(jù)必要權(quán)衡/整合結(jié)構(gòu)、強度、六性、適航等需求；

圖5 需求Item 標題和屬性表Fig.5 Requirement Item title and properties

圖6 需求Item 內(nèi)容Fig.6 Requirement Item content

圖7 需求跟蹤鏈接Fig.7 Requirement traceability chain

(4)確定每一條需求相應的驗證方法、輸出物；

(5)基于PDM/TC 完成各功能體需求BOM 構(gòu)建；

(6)完成需求評審并歸檔發(fā)布，建立需求基線。

其中，最為關鍵的步驟為需求條目化+適用性分析(針對需求源文件，形成需求源文件分析說明)，以及需求權(quán)衡整合(面向產(chǎn)品對象，形成各產(chǎn)品對象需求分析說明、需求文檔(或需求規(guī)范))，如圖8 所示。

圖8 需求分析與定義關鍵步驟Fig.8 Critical steps of requirements analysis and definition

3.4 需求驗證策劃

按以下步驟開展各功能體的需求驗證策劃：

(1)基于需求驗證方法及輸出物，形成研發(fā)WBS；

(2)建立需求驗證文件體系；

(3)建立需求-需求、需求-驗證數(shù)據(jù)關聯(lián)，即追溯&驗證關系；

(4)建立與MPM 任務關聯(lián)。

圖9 需求驗證策劃過程示意Fig.9 Example of requirements verification process

如圖9 所示，以產(chǎn)品對象需求BOM 中的需求條目(權(quán)衡整合后)為源，分析為驗證該條需求所需開展的驗證工作(包括設計、分析、計算、試制、試驗等)，形成研發(fā)WBS，研發(fā)WBS 的輸出物即構(gòu)成了驗證文件體系。其中，需求、設計、工藝、試驗、制造研發(fā)數(shù)據(jù)納入PDM/TC 管理，研發(fā)任務納入MPM 管理并與研發(fā)數(shù)據(jù)建立關聯(lián)。

為便于管理，在此基礎上進一步對驗證文件進行分類(圖10)，其策劃制訂的文件包括：①項目管理類文件——沿用以前批次文件；②系統(tǒng)工程管理及技術(shù)管理類文件——大部分沿用以前批次文件，新文件約20 余項；③技術(shù)狀態(tài)文件——根據(jù)GJB 3206A-2010《技術(shù)狀態(tài)管理》的定義確定，新文件約180 余項；④設計類需求驗證文件——不含技術(shù)狀態(tài)文件，新文件約200 余項；⑤制造類需求驗證文件——主要指工藝類文件和制造信息文件，由制造廠產(chǎn)生；⑥試驗類需求驗證文件——正在策劃；⑦其他文件。

圖10 驗證文件分類體系Fig.10 File classification system

3.5 需求評審

組織專家對發(fā)動機各功能體需求分析、需求驗證策劃工作進行審查/評審。對專家評審提出的共性問題進行相應的整改，逐步完善需求管理工作。

4 結(jié)束語

上述工作實現(xiàn)了航空發(fā)動機需求管理工作由文件化向工具化、由碎片化向集成/綜合化的模式轉(zhuǎn)變，并構(gòu)建了需求管理所有工作的基礎——需求及需求驗證數(shù)據(jù)鏈，為后續(xù)各功能體需求審批發(fā)布、需求文檔/規(guī)范輸出、需求基線維持、需求驗證符合性分析和審查、需求變更管理等創(chuàng)造了條件，奠定了以需求為牽引驅(qū)動正向研發(fā)的基礎。后續(xù)應繼續(xù)對需求捕獲及分析方法，航空發(fā)動機性能指標分解、指標映射/承接關系構(gòu)建，需求親和與需求編寫、需求變更與符合性管理的細化方法，以及基于TC 和MPM的需求驗證計劃與工作任務關聯(lián)管理的細化方案等方面進行研究和探索。