原创：
郭宇，臧睿等
科技导报
基于模型的系统工程（MBSE）采用模型的表达方法描述系统的整个生命周期过程中需求、设计等活动，以其无歧义、模块化等优点迅速覆盖了航空航天、船舶等相关工程领域。本文总结了 MBSE的方法论、建模语言和建模工具，通过不同角度对不同方法、工具进行对比，为寻找适合航空发动机功能建模的解决方案进行了初步探索。
在系统工程初期阶段，系统产生的信息均以文档形式描述和记录。但是随着系统规模和复杂程度的不断提高，基于文档的系统工程面临的困难越来越突出，如信息表示不准确造成歧义、难以从海量文档中查找所需信息、无法与其他工程领域的设计相衔接（如软件、机械、电子等）。于是基于模型的系统工程（
MBSE
）应运而生，这也是未来系统工程发展的必然趋势。
MBSE
基本概念
国际系统工程学会（
International Council of Systems Engineering
，
INCOSE
）在
2007
年提出了基于模型的系统工程，它是系统工程领域发展的一种基于模型表达的方法。一方面，
MBSE
通过标准系统建模语言构建需求模型、功能模型、架构模型，实现需求、功能到物理架构的分解和分配；另一方面，
MBSE
通过模型执行实现系统需求和功能逻辑的确认和验证，并驱动产品设计、实现、测试、综合、验证和确认环节。
MBSE
的优势
相对基于文档的系统工程方法，
MBSE
的优势主要体现在以下
4
个方面：（
1
）信息表达唯一性。系统模型具有直观、准确唯一、结构化的优点，可以准确统一地描述系统的各个方面，对整个系统内部的各个细节形成统一的理解。（
2
）一体化设计。系统模型提供了一个覆盖全生命周期的完整的、信息一致且可追溯的系统设计方案，避免各组成部分间的设计冲突，降低风险。（
3
）知识积累和沉淀。成熟型号的知识是以系统模型的形式表示和存储的，便于捕获、查询、理解和重用，而且重用的级别可以大幅度提高。（
4
）早期全系统仿真。利用系统建模语言及支持软件，可以建立动态可执行的系统模型，对系统模型进行全系统仿真、随时仿真和全周期仿真，及时发现设计的问题并加以修改。
MBSE
过程最终的输出是一个可重用的系统数据模型。
MBSE
的落地实施依赖于
3
个方面：建模语言、建模工具和方法论。
系统建模语言
SysML
为了支持
MBSE
，
INCOSE
和对象管理组织（
Object Management Group
，
OMG
）联合提出一种通用的针对系统工程应用的“标准系统建模语言”
SysML
（
Systems Modeling Language
），它可以支持系统工程应用的多领域系统，包含硬件、软件、信息等系统的需求分析、系统设计、功能描述及系统验证等。
建模工具
建模工具是利用
SysML
实现
MBSE
的关键，业界主流建模工具包括
Rhapsody
、
CORE
等，建模工具厂商结合各自对
MBSE
的不同理解，开发出各具特色的建模工具。
IBM Rational Rhapsody
产品系列是一个协作设计和开发环境，以分析需求、在开发生命周期的早期优化设计决策和验证功能、执行设计复审并实现高质量创新产品的自动交付；
Modelio
是由法国
Modeliosoft
公司开发的一款提供分析、设计和开发环境的建模工具，其开发环境可以整合到整个产品开发生命周期中并帮助管理复杂性；
CORE
是
Vitech
公司为实现其系统建模方法论的建模工具，以需求分析、功能
/
行为分析、架构综合、设计确认和验证这
4
个系统工程活动为基础，注重实用性；
Enterprise Architect
是
Sparx Systems
公司开发的产品，覆盖了系统开发的整个周期，可以进行用例分析、场景分析、状态与模式分析，支持双向工程（
RoundTrip-Engineering
）。
各主要建模软件对比见表
1
，从工具应用情况可以看出航空航天行业国内以
Rhapsody
为主，国外以
CORE
为主。
表1 主要建模工具对比
方法论
MBSE
问世之后，国内外围绕这一思想核心在不同系统、不同建模背景下进行实践，总结出诸多具有国际影响的方法论，这些方法论规定了系统开发过程所包含的模型构建内容，以及各个阶段模型所产生的视图产品和模型视图的时序关系，规定了图形的使用、模型的组织结构等（图
1
）。
图1 MBSE实施的基本方法
面向对象的系统工程方法（
object-oriented systems engineering, OOSEM
）集成使用
OMG SysML
标准，包括分析定义系统需求、定义逻辑体系结构、合成候选分配架构、优化和评估可选方案、验证和确认系统等开发活动；
Harmony-SE
采用了“服务请求驱动”的系统建模方法，使用
SysML
建模标准，利用
SysML
结构视图中的
block
作为描述系统结构的基本单元，利用活动图、状态图、序列图描述系统结构组成部分的行为；
Vitech MBSE
方法采用
MBSE
的系统定义语言（
system definition language
，
SDL
）管理模型产品；
state analysis
以目标为导向的闭环运转，是时间区间上状态变量的约束。
国外在
MBSE
的方法及应用方面开展了广泛研究与实践：空客公司在
A350
系列飞机的开发中全面采用
MBSE
，在飞机研制中逐层细化需求并进行功能分析和设计综合；洛克希德·马丁公司采用
MBSE
统一进行需求管理和系统架构模型，并向后延伸到机械、电子设备以及软件等的设计与分析之中；罗·罗公司依据
INCOSE
系统工程手册制定了其自身的系统工程能力框架，实现了从航空动力系统到子系统到部件的系统工程迭代；波音公司构建了以任务和需求定义、逻辑和功能集成、功能和逻辑架构设计为核心的、覆盖产品全生命周期的
MBSE
过程，从运行概念到需求到设计到生产。
近年来，中国航空航天领域也开展了
MBSE
的应用研究，中航工业西安航空计算研究所利用基于模型的系统工程需求分析、功能分析、架构设计方法在某型动力电子控制系统设计中得到了初步应用；中国空间技术研究院载人航天总体部将
MBSE
方法应用于载人飞船交会对接任务中，提高了设计效率、改善了人员沟通、进一步降低了设计风险；中航工业飞行自动控制研究所对
MBSE
流程进行了结构化定义，明确了系统工程活动、输入输出及相应的岗位角色，并在飞控、惯导等复杂系统开发过程中进行了
MBSE
方法论与工具的实践；中航工业第一飞机设计研究院采用
Rational DOORS
进行需求管理，并按照
Harmony-SE
流程，采用
Rhapsody
工具完成空中交通防撞系统以及航电系统的系统分析、设计与建模。
一般地，航空发动机
3
个主要用例场景分别为发动机装配、运行和维护，如图
2
所示。其中，装配场景包括发动机制造组装、物料清单（
BOM
）跟踪确认、运输、接收等子场景；运行场景包括发动机起动、运行、停车、在翼运行、试车台运行等子场景；维护场景包括发动机健康数据分析、维修和替换组件、上载全权数字电子发动机操给机构（
FADEC
）数据等子场景。
图2 航空发动机全生命周期功能场景分解
本文主要聚焦航空发动机地面起动场景，将
MBSE
应用于航空发动机控制设计过程。采用
SysML
语言，在
Rhapsody
软件上进行航空发动机控制设计的功能分析和系统建模，从而探索适合航空发动机功能建模的解决方案。
航空发动机地面起动过程包含起动机运转、点火、供油、关闭点火、进入慢车等主活动及起动故障处理等其他活动。通过用例图、活动图、时序图、状态机图等模型对地面起动过程进行建模分析，发现并完善了自然语言在起动控制逻辑描述方面存在的不足。最后利用状态机进行了发动机地面起动模型仿真，对地面起动控制逻辑进行了验证。
在利用活动图梳理发动机地面起动功能流过程中，发现使用自然语言描述复杂系统时存在以下
2
类问题。
1
）文字表述存在二义性。
例如，发动机起动时间的描述“发动机应在
t
时间内完成起动”存在歧义。对于“发动机应在
t
时间内完成起动”的理解，设计方案想要描述的是“起动机带转发动机的起动时间最长为
t
，否则需要关闭起动机”；设计人员的理解为“若发动机起动时间超过
t
，则需要终止发动机起动全过程”，两者存在理解分歧。
2
）存在功能逻辑缺失。
例如，方案中描述“当高压相对物理转速达到一定速度时，开始供油”，若高压相对物理转速未达到限定速度，发动机需要进行的动作和所处状态未明确。
通常，使用类似
Visio
的图形设计工具辅助描述设计信息。然而，由于缺乏统一的语义规范和信息关联机制，无法对活动流程中的并行、引用、延时等特殊状态进行准确唯一的描述，这类图形信息就相当于图形化的自然语言。在描述发动机起动时间控制逻辑中，设计人员会用一个框图表示，如图
3
红框所示。如果想要描述更加详细的控制逻辑，只能用更加复杂的活动流图代替之前的框图，从而导致整个活动流缺乏层级，逻辑混乱。如此一来，既不利于设计人员理解设计方案，也会造成不同人员的理解偏差，带来信息二义性。
图3 航空发动机起动时间控制Visio
在
MBSE
方法论中，通过
SysML
中的标准模型元素来准确表达设计信息，得到如图
4
所示的发动机起动时间的活动图，其中红色区域表示发动机正常起动的活动流，黑色区域表示同时进行的发动机起动时间控制活动流。其中黑色区域所表示的活动流采用子活动图的方式表达，子活动图的具体信息如图
5
所示。
图4 航空发动机起动时间控制活动
图5 航空发动机起动时间控制子活动
SysML
模型中的时序图是根据活动图所描述的行为逻辑，建立多个对象之间的动态协作和行为顺序关系以及不同对象之间的消息传递，明确了起动过程中的系统与外部角色之间的交互关系，从而确定系统与外部的接口和端口关系。
状态机通过分析和确认每个对象所经历的状态序列、在特定状态下的行为、引起状态转移的条件、因状态转移而伴随的动作、以及对异常做出的响应等内容，确立系统在其生命周期内的完整动态行为。发动机地面起动过程主要包含以下状态：等待驾驶舱指令状态、起动状态、故障处理状态、慢车状态和关闭起动状态。根据不同的判断条件和触发事件，发动机处于其中某一个状态，并且可以在不同状态之间进行切换。
Rhapsody
提供了通过界面交互方式执行状态机的模式，通过给定的
Web
界面，可以通过参数注入的方式输入测试用例，实现不同场景、不同状态之间的仿真测试，从而验证功能逻辑完备性和需求满足性。
通过传递参数，状态机图实现了地面正常起动、起动超温、余热超限、滑油压力低等
10
余种测试用例的仿真测试。以滑油压力低为例，表
2
列出发动机地面起动过程发生滑油压力低时的参数注入信息，当对状态机注入以下参数时，发动机进入地面起动滑油压力低故障处理状态，验证了故障处理控制逻辑的正确性，如图
6
所示。
表2 航空发动机地面起动滑油压力低测试用例参数
图6 航空发动机地面起动滑油压力低状态机仿真
由于
SysML
语言来源于
UML
语言，擅长对离散事件驱动的系统，即发动机控制功能逻辑描述和仿真，但对于真实连续运行的物理系统的描述仍存在局限性，有待进一步的研究。
从系统建模语言、建模工具和方法论
3
个方面详细介绍了基于模型的系统工程相关理论知识，并且通过不同角度对不同方法、工具进行了对比，为寻找适合航空发动机功能建模的解决方案进行了初步探索。在航空发动机控制设计起动场景功能建模实践中，选用
Rhapsody
建模工具，基于
Harmony-SE
方法论开展
SysML
建模，详细描述了利用活动图、时序图描述复杂系统交互活动的过程，解决了自然语言无法描述复杂活动的问题；利用状态机图通过参数注入方式进行起动功能逻辑的仿真和验证，为后续航空发动机全系统建模和功能逻辑仿真提供了解决思路。
