航空發動機研制需求管理探析

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

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

1 引言

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

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

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

2.1 總體框架

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

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

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

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

2.2 組織模式

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

各層級需求管理IPT 涵蓋專業一般包括：氣動/性能設計，控制、起動、電氣及測試系統設計，空氣系統設計，結構設計，強度設計，材料工藝設計，六性及適航設計，標準化管理，系統工程及技術管理等。

2.3 管理工具

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

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

3 航空發動機需求管理應用

3.1 專項小組組建

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

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

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

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

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

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

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

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

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

3.2 工作要求

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

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

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

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

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

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

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

3.3 需求分析與定義

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

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

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

(3)根據必要權衡/整合結構、強度、六性、適航等需求；

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

圖6 需求Item 內容Fig.6 Requirement Item content

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

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

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

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

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

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

3.4 需求驗證策劃

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

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

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

(3)建立需求-需求、需求-驗證數據關聯，即追溯&驗證關系；

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

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

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

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

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

3.5 需求評審

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

4 結束語

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