航空发动机研制需求管理探析

卢川川，李伦未，孙文斌，李 华，许 多

(中国航发四川燃气涡轮研究院，成都 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的需求验证计划与工作任务关联管理的细化方案等方面进行研究和探索。