航空市场对国产商用发动机的需求日渐迫切，相关客户服务产品（ 客服产品 ）的研制也应随之开展。但目前针对国产商用航空发动机客服产品的研制方法尚不成熟，缺乏明确方法指导，亟须进行针对性的探索。

根据《航空器制造厂商运行支持体系建设规范》（MD-FS-AEG006）的明确规定，商用航空发动机客服产品的研发是航空器制造商运行支持体系建设的基本任务之一。在型号研制阶段，设计商用航空发动机客服产品既是符合适航规章要求获得市场准入的前提，也是支持发动机持续适航、实现安全可靠运行的需要。随着民航竞争日益严峻，客户需求多样，新技术大幅应用，客服产品越来越复杂，维修与运行支持服务产品的集成愈发明显，将创新的、定制化的客服产品快速推向市场的能力成为核心竞争力。

在商用航空发动机数字化客服产品的开发实践中，需要探索出一套基于系统工程的“从客户需求到客户满意”正向设计方法，以避免出现初始需求捕获不完整、需求与设计的一致性难以保证、跨业务沟通效率低下、设计方案难以迭代更新、早期发现问题能力不足导致产品开发周期长、效率低等问题。针对上述问题，本文探索了基于系统工程的商用航空发动机客户服务产品功能设计方法。

方法构建

本文建立的方法包括需求管理流程、评审管理流程、开发管理流程、双场景模型、利益攸关方识别清单、服务产品架构模型设计方法、服务产品架构模型仿真方法及客服产品架构设计工具等内涵，如图1所示。

建立“端到端”全流程的客服产品开发管理流程，实现需求闭环

以产品开发为最终目标，识别出产品涉及的所有利益攸关方和产品及利益攸关方的所有活动，即从“需求发起”到“需求关闭”。 以需求牵引客服产品开发设计全过程，包括需求分析、产品方案论证、产品设计开发、产品定型阶段和产品批量生产阶段。

建立利益攸关方识别模型，定位需求收集对象

建立“面向发动机全生命周期+面向商用发动机项目”的利益攸关方识别模型。该模型主要定义3类利益攸关方类型：上游利益攸关方——项目投资方和上级客户（如飞机主制造商）；中游利益攸关方——发动机主制造商、行业竞争者、政府机构、民航局、环保协会等；下游利益攸关方——客户、第三方维修和培训服务商、机场、数据通信服务商等。

基于以上分析，商用航空发动机客服产品的主要利益攸关方包括但不限于适航当局、飞机主制造商、发动机主制造商、发动机客户、航空公司、机组、机场、维护维修人员、培训人员、子系统供应商等。

“利益攸关方+场景”是一种高效的需求识别方法：建立发动机运行场景，从操作人员和用户的角度，构想预期的客服产品在预定环境中如何运行，基于发动机运营概念，形成服务支持概念，获得客户需求。

建立基于场景的客服产品功能分析过程

在利益攸关方需求分析的基础上，分析客服产品与其环境要素（如使用者、作用对象、运行环境等）之间的交互过程/相互作用关系，得到客服产品的功能性需求，使用“场景”来描述客服产品与其运行环境之间的相互作用。

为了更好地开展客服产品功能分析、场景建模，应系统地识别和分析发动机使用和维护的各项场景。基于场景的客服产品功能分析过程包括：构想客服产品在发动机运行和维修等预期环境的工作过程；识别发动机运行和维修过程中与客服产品交互的使用场景；识别场景的利益攸关方和各种环境要素；从利益攸关方的需求出发，分析归纳客服产品的功能。

建立需求管理流程

客服产品开发项目的需求管理过程分为需求收集阶段、需求分析阶段、需求分解阶段、需求跟踪管理阶段、需求变更阶段。在需求收集阶段，可利用客户大会、客户拜访、用户调研和访谈等机会捕获客户需求，还可通过标杆研究、竞争者信息、文献研究、专利研究等方式针对性地收集需求。在需求分析阶段，根据客户需求及KANO模型，将需求分为基本型需求、期望型需求和兴奋型需求。在需求分解阶段，利用视点分析（VPA）方法，将客户需求逐步转化为客服产品需求、客服产品功能需求、客服产品设计要求。建立客户服务需求管理流程，规范需求管理与变更。

建立基于DoDAF的客服产品架构设计方法，整合设计开发各要素

基于DoDAF的客服产品架构设计方法，能够从全局视角、能力视角、活动视角、系统视角、服务视角、项目视角、数据和信息视角、标准视角等实现多角度考虑客服产品架构，把商用航空发动机的运行场景作为需求捕获的源头，基于场景分析利益攸关方活动，强调从利益攸关方的初始需求中提炼客服产品功能，梳理整合客服产品复杂接口关系，传递落实需求实现闭环。

建立模型仿真工具，数字化手段保障设计阶段正确性

在系统工程的标准建模语言SysML的基础上，结合发动机客服产品的设计特点，形成符合DoDAF2.0标准的客户服务系统架构模型设计工具。用模型表达的客服产品架构的特点是系统功能明确、系统数据底层逻辑清晰、数据交互内容清楚、不同系统间的接口关系明显。这种模型化的系统架构有效消除自然语言引起的歧义，避免文档材料带来的理解偏差，有助于不同专业技术人员快速对齐理解，提升跨专业沟通效率。

采用仿真手段验证客服产品架构设计的功能逻辑，可在设计阶段消除不合理设计，以加速优化迭代。使用具有不确定性的测试用例可将系统使用环境中的随机因素纳入其中架构的仿真验证。这种验证方式不但提供可视化手段对架构模型逻辑的自洽性进行推演，还能显性化各利益攸关方的活动和资源交换，为架构模型迭代设计提供便利。

建立评审和开发管理流程

梳理客服产品的架构组织系统中元素和它们之间的关系，如功能、功能流、接口、数据、资源交互等。因架构设计还需考虑客服产品的需求、产品使用场景、发动机运行场景、利益攸关方的活动和对产品的期望等因素，所以在客服产品架构设计过程中应频繁地与各利益攸关方保持沟通，有必要邀请其参与各阶段评审，以保证各利益攸关方的关注点通过合适的视图在架构模型中得以表达。此外，客服产品架构设计结果应与需求、业务使命等同步迭代，为客服产品的设计开发提供各方满意的解决方案。

客服产品从设计开发到批量生产包含产品开发阶段、产品定型阶段和产品批量生产阶段，通过在每一个阶段结束时设计一个决策评审点，成立专家组以评审的形式决定是否进入下一个阶段。在每个阶段设立技术评审点，关注技术实现成熟度，以实现客服产品开发的管理。

方法实践

为了应对《航空器制造厂家运行支持体系建设规范》中提出的“建立全面的使用信息收集和处理流程，了解航空器的使用情况”的要求，协助航空公司达到《航空承运人运行监控实施指南》（AC-121-FS-2019-133）中提出的“运行监控是运行控制的重要组成部分”的要求，发动机主制造商需提供一种客服产品：利用机载传感器获取发动机运行使用状态，监控发动机实时性能，评估发动机系统及部件的健康状态，为客户提供发动机健康状态信息和运行使用建议。该客服产品就是航空发动机健康管理（EHM）地面系统，本文以EHM地面系统设计为例，阐述如何实践上述方法。

EHM地面系统利益攸关方识别及需求捕获

根据“面向发动机全生命周期+面向商用发动机项目”的利益攸关方识别模型，通过调研、标杆研究，结合发动机在翼运行阶段，得到EHM地面系统主要涉及的利益攸关方为中国民航局、航空公司、电信运营商、大数据运营商和发动机主制造商。

民航局和航空公司的需求可归纳为：在发动机运行使用阶段，EHM地面系统通过发动机运行使用数据分析发动机趋势状态，协助航空公司在运营过程中满足民航规章要求及安全性，优化发动机运行状态，降低发动机维护成本。电信运营商和大数据运营商参与EHM机载系统与地面系统空地链路数据传输，其需求可归纳为数据传输协议应符合现有行业标准。发动机主制造商作为发动机和服务产品的提供者，其需求则是能建立发动机运行使用数据反馈机制，反哺发动机设计与制造，提升发动机质量。

基于双场景的EHM地面系统功能分析

商用发动机交付使用过程中主要经历运行、维修、退役，其运行场景如图2所示，服务场景如图3所示。

EHM地面系统主要通过航线运行下的发动机运行、航前、短停、航后检查等4个服务场景参与发动机的运行。发动机运行时，通过机载系统获取发动机状态快照数据，经空地数据传输链路传送至地面系统用于开展发动机状态远程监控；在航前、短停、航后检查时通过机务人员手动下载或无线Wi-Fi传输的方式获取发动机状态连续数据和维护数据，用于发动机故障分析与诊断；EHM地面系统制定运行、预测性维修建议供航空公司参考使用，协助航空公司安全经济地运营发动机。

结合发动机运行场景和服务场景、EHM地面系统需求，根据航空发动机运行监控典型场景和活动流程进一步确定可参与的其他系统，并确定EHM地面系统的顶层功能。如机载EHM负责在发动机起动后连续数据的收集以及产生补充报文、手动报文、航后报文等；航电系统负责收集机载EHM以及飞机通电后的数据并进行存储，在各个飞行阶段产生相应报文并进行异常判断、处理和存储；运行使用数据管理系统负责数据接收并解码译码后入库保存，将发动机主制造商快速响应系统的解决方案导入案例数据库。在这其中，EHM地面系统需求为应实现发动机状态数据处理和分析、对发动机异常分级告警并建立追溯流程、发布维修建议书、向设计研发反馈监控方案更新需求等。

基于DoDAF的EHM地面系统架构设计

客服产品架构模型设计工具使用不同的DoDAF视角能够整合双场景、利益攸关方及其需求和客服产品需求，并考虑相关行业技术标准实现EHM地面系统架构设计，其包含系统架构分析、业务分析、服务设计和系统架构等4个步骤。一是架构分析，明确EHM地面系统的业务需求，使用全局视角定义EHM地面系统参与的运行场景和服务场景，使用能力视角对EHM地面系统建模。二是业务分析，基于顶层需求对EHM地面系统活动进行分析，使用活动视角建模。三是服务设计，分析具体活动应由何种服务功能实现并使用服务视角建模。四是系统架构，根据活动视角和服务视角分析结果，明确系统功能，使用系统视角建模。EHM地面系统架构模型设计过程应依据不同视角交叉检验，不断迭代优化，直至完成建模，如图4所示。

架构模型仿真流程

为了验证在不同运用场景下，EHM地面系统架构的逻辑正确性、功能可达性和完整性、需求覆盖完备性，需要对架构模型进行逻辑自洽仿真和验证。根据典型运行监控场景设计测试用例文档，测试用例应当在每一个视角分别构建，并能够完整覆盖整个运行流程的正常和异常情况。在客服产品架构模型设计工具中，完成代码框架生成，并运行仿真模型，分别完成逻辑自洽验证和测试用例验证，并根据验证及业务反馈结果，完成模型迭代优化。

EHM地面系统架构模型仿真不同于常见模型（如流体/结构三维模型）的仿真，前者仿真过程也是仿真结果的可视化展现。执行仿真时，通过分析各视图模型的状态响应能否满足业务要求，来判断模型行为逻辑及功能是否完整、正确。现阶段，仿真过程正确性的判断依赖于测试人员对EHM地面系统业务的熟悉程度和理解深度，以测试用例为体现。因仿真操作需借助工具实现，此处不赘述具体步骤。

结束语

基于系统工程的数字化客服产品设计方法既是秉承系统工程思维的正向设计方法，也是基于模型的系统工程（MBSE）的实践，为客服产品详细设计与开发提供更可靠的输入。因目前缺乏商用航空发动机运行仿真软件，模型的仿真验证只能实现定性的模型逻辑自洽的验证，尚不能达到定量分析客服产品各项指标。在未来的工作中，可进一步探索如何实现定量分析，指导客服产品全生命周期的设计开发工作。

（马进锐，中国航发商用航空发动机有限责任公司，高级工程师，主要从事商用航空发动机健康管理地面系统设计与开发）