基于MBSE的民机系统功能建模方法

王文浩, 毕文豪, 张 安, 范秋岑

(西北工业大学航空学院, 陕西 西安 710072)

0 引 言

民机研制是一个涉及多学科、多领域的高度集成复杂的系统工程[1]。传统的民机研制都是基于文档管理的,一方面由系统设计师人工链接设计成果与需求之间的关系,迭代开发周期长;另一方面,不同领域的设计人员从文档中读取信息很容易产生理解偏差,从而导致在设计过程中需要反复迭代修正,严重影响了复杂系统的开发效率[2-3]。

系统工程是一种自上而下的综合、开发和运行的一个真实系统的迭代过程,以接近于最优的方式满足系统的全部需求[4]。系统工程革新的推动力来自克服已知缺陷和不利的需求,这些因素会对系统体系结构设计产生不利影响。近年来,在需求牵引和模型化技术的推动下,基于模型的系统工程(model-based systems engineering, MBSE)应运而生[5-6]。2007年国际系统工程学会在《系统工程远景2020》中将MBSE定义为“支持以概念设计阶段开始并持续贯穿开发和后期的生命周期阶段的系统需求、设计、分析、验证和确认活动的正规化建模应用”,用于解决具有跨平台、跨领域、高综合性等特点的复杂系统开发中遇到的系统问题,并联合对象管理组织(object management group, OMG)在统一建模语言(unified modeling language, UML)的基础上开发了用于描述大型复杂系统的系统建模语言(system modeling language, SysML)可以支持民机系统全寿命周期内的需求分析与管理、功能设计与分配、模型架构与管理、系统建模与仿真以及测试评估与计划管理工作[4-7]。

敏捷系统工程的意义在于控制系统和流程所展示出来的不可预见性、不确定性和变化的条件下能够保持有效的运行。敏捷的价值主张是增量式的迭代和风险的管控,根据需求演进的可能成本进行权衡分析,并针对不同情形和变化做出适应和响应,能够在系统设计早期,推动持续的验证和测试驱动的开发,从而降低系统研发的风险[8-9]。本文引入MBSE理论和敏捷系统工程设计方法,研究敏捷系统工程框架下的民机MBSE设计方法,针对关键子系统用例展开基于场景的用例分析,采用循环迭代的方式构建描述子系统行为的活动流和黑盒状态机,并将需求与场景交互请求即功能相链接。

1 基于MBSE的民机系统研制流程

基于系统工程方法论和敏捷系统相关概念[5-10],构建基于敏捷系统工程的民机系统研制流程,如图1所示。首先开展运行分析,深入剖析民机市场运行与系统概念设计的内在机理,然后将捕获到的需求定义进行分析和管理,定义利益相关方需求。将其作为设计研发的目标与约束,进行利益相关方需求用例场景分析,提高利益相关方在系统设计早期的参与程度。在这一过程中,以文本需求和基于顺序图的场景来捕获利益相关方需求,深入剖析需求与系统服务请求之间的链接关系,将需求聚集成相关集合,称为用例,用以描述系统的运行能力。

图1 基于敏捷系统工程的民机系统研制流程Fig.1 Civil aircraft system development process based on agile system engineering

通过反复迭代将更新后的需求与相应的系统设计参数相结合,定义系统需求并展开用例场景分析,建立描述系统黑盒视图的活动功能流和状态机视图。继而开展系统架构的分析与设计,将选取的系统架构方案与相应的跨学科和子系统接口转交下游工程,通过反复迭代最终得到符合客户需求的产品。

MBSE的核心是采用模型驱动的方式进行系统设计,对设计中每一阶段的中间产出物进行统一的模型化管理,提供可追溯性的连接,保持数据在工作产品和工作活动间的一致性[5-6]。如图2所示,在基于模型的系统研发过程中,系统模型的中间产出物主要由功能模型(一系列可执行的状态机和活动流)、架构模型(系统及子系统模块定义)、需求模型(用例场景)和参数模型(系统的设计约束)所构成[4,11-12]。在正向设计和反向迭代的过程中,子系统模型的主要内容也可以从这4个视角去描述。

图2 MBSE设计中间产出物Fig.2 Intermediate output of MBSE design process

其中,功能模型是表达功能之间依赖关系的静态描述和功能实现过程的动态模拟,从SysML语言规范出发,通过分析各种模型元素的特点,构建出可重用的SysML功能模型库。需求模型则是以用例(以及相关案例叙述)的形式来代替传统基于文字的功能性描述,或者以SysML需求图的形式来显示系统需求和系统模型的依赖元素及追溯关系[13-14]。

值得注意的是,在利益相关方需求分析、系统需求分析和系统架构阶段,对于设计过程中需求演进的可能成本进行增量式的迭代更新,克服会对系统体系结构产生不利影响的需求。同时,项目的风险控制、研发的过程管理、需求与模型的变更管理和基线管理等将贯穿系统的整个开发过程。

2 基于场景的功能建模方法研究

作为民机系统研发的关键任务,功能建模[15-18]是建立技术系统功能模型的设计活动。1969年Simon在《人工科学》杂志中提出系统具有内部和外部环境,而功能则视为是内部环境的抽象,位于内部和外部环境的接口处[19]。1998年Chakrabarti提出了行为和目的两种函数视图,将功能视为满足目的所做的行为,并提出了本体论的目的论建模。2007年Gero建立功能-行为-结构(function-behavior-structure,FBS)本体[16-17],从语义的角度介绍了功能、行为、结构的概念及其与主观和客观领域需求之间的关系。国内陈勇等人[20-21]在FBS本体理论的基础上提出状态-行为-功能(state-behavior-function, SBF)的观念,旨在解决技术系统的多状态分析问题,并将其用于机械系统的功能建模中。除此以外,IDEFO[22]和功能方法树等方法也都分别用在系统功能建模中,但只有SysML被应用于基于Harmony-SE的民机研制领域,并得到了广泛验证[23-28]。

在功能建模的过程中,场景是特定条件下系统某一部分的执行样例[29],是执行用例的系统与系统所在环境中参与者间的特定交互。而用例则是系统功能的顶层描述,是外部执行者能够直接触发或者参与的系统行为[8,30]。通常情况下,用例与场景之间的关系是一对多的映射关系。如图3所示,在系统运行过程中,其功能体现在与系统交互的参与者与所感兴趣之系统的交互请求,在特定的运行环境中,通过按照特定值和特定时间顺序执行的请求集和响应集来满足系统设计需求。

图3 系统运行环境与服务请求Fig.3 System operating environment and service request

基于场景的功能建模方法就是以这种请求集和响应集(场景流)为出发点,模拟系统的实际运行阶段,对每一个用例构建一个可执行的模型,然后通过执行或仿真,演示系统执行用例的输出结果是否满足设计需求。基于场景的功能建模流程如图4所示,主要分为以下5个步骤。

图4 基于场景的功能建模流程Fig.4 Scenario-based function modeling process

(1) 识别系统用例

首先是识别系统用例,根据系统需求即复杂系统的功能描述建立顶层用例视图,并将系统需求分配到对应的用例中[31]。对于民机系统来说,其系统需求的类型主要由运行需求、设计需求、服务品质需求(quality of service,QoS)和后勤保障等需求构成,如图5所示。值得注意的是,将飞机置于其运营体系也就是航空运输系统中,其体系需求主要体现在与空中交通控制系统、燃油分配系统、机场系统和票务系统的交互过程中。根据飞机级需求种类构建飞机级功能如图6所示,在识别系统用例的过程中,需要考虑系统的状态和模式、信息的一致性、产品的领域背景、技术的局限性等。需要注意的是,对于图5中所列出的系统功能并不是都需要使用用例来描述,例如结构完整性功能、升力和阻力控制等。用例是外部执行者能够直接触发或者参与的系统行为,只有这部分行为(功能)才需要使用用例进行建模。

图5 民机系统需求种类Fig.5 Classification of civil aircraft system requirements

图6 民机飞机级功能Fig.6 Aircraft level functions of civil aircraft

假设一个系统S一共包含n个系统需求,记为SR={R1,R2,…,Ri,…,Rn},1≤i≤n,建立l个用例SUC=(UC1,UC2,…,UCj,…,UCl),1≤j≤l,第j个用例包含的需求个数为tj,则满足

(1)

理想情况下式(1)为等式,用例之间满足独立性原则的同时与系统行为紧密耦合,能够单独对系统行为进行推断。一般来说,用例包含用例名称、目的、描述、前置条件和后置条件,如表1所示。

表1 用例的基本属性Table 1 Basic attributes of use cases

对于民用飞机而言,根据飞机的任务剖面构建其顶层用例如图7所示,以下降用例为例,其使命表达式如图8所示。

图7 民机飞机级用例Fig.7 Aircraft level use cases of civil aircraft

图8 下降用例使命表达式Fig.8 Mission expression of altitude descent use case

(2) 定义用例场景

其次是定义用例场景,对于上一阶段定义的系统用例,结合用例的接口和端口以块的形式描述参与者与用例之间的输入输出流数据,使用顺序图展示特定条件下系统某一部分的执行样例(俗称场景),通常单个顺序图表示单个场景,用例由多个场景所构成,包括正常场景和雨天场景。

假设第j个用例包含m个场景,记为SCEj={Scej1,Scej2,…,Sceji,…,Scejm}。第k个场景中包含的需求个数为rk,则满足

(2)

理想情况下式(2)为等式,用例满足独立性原则且需求在用例场景中唯一显示,能够单独对系统的运行场景进行约束。一般来说,场景包含所属用例、场景ID、描述、前置条件和后置条件。场景的意义在于识别对系统可能产生不利影响的需求,在图4中场景分析的内容是定义执行用例的系统与系统所在环境中参与者间的特定交互,从中发现对系统产生不利影响的需求并最终导致需求变更。在这一过程中,敏捷系统工程体现在系统需求的反复迭代中,用例包含的每一个需求与参与者和所感兴趣之系统的服务请求相关联,并按照时间的先后顺序排列。

(3) 定义用例活动功能流

活动图是描述系统功能的黑盒视图,用来展示系统在有限范围内的行为和功能流(物质、能量)[8,30]。在这一阶段中,将主要场景作为备选流来添加(决策)或者合并(汇合)运行,使用活动图对系统的行为特性进行建模。通常用例与活动图一一对应,活动图中每一个平行的流构成一个单独的场景集,场景集内决策点的每个流构成一个不同的场景。

(4) 定义接口与端口

系统用例和参与者之间的服务请求是基于事件的,在这一过程中,根据迭代完成的场景时序图和活动图中流的信息,迭代更新系统用例的端口和接口,用来导出用例的状态机视图。

(5) 导出用例状态机

状态机图是一种行为图,和活动图以及顺序图一样是系统的一种动态视图,不同之处在于其关注的是系统如何根据随时间发生的事件改变状态[8,30]。在这一步骤中,根据所构建的场景顺序图和活动图,逐步迭代构建用例的完整状态机,用来描述系统随事件的变化过程。通常情况下,状态机由状态、事件、守卫和动作集构成,如图9所示。状态之间的转移过程由事件触发,守卫判断是否满足状态转移条件,如果满足则执行预设的动作集,并完成系统状态之间的转移过程。

图9 系统状态之间的转移Fig.9 Transition between system states

3 民用飞机系统级功能验证

下面以民机自动飞行控制系统(automatic flight control system, AFCS)为例,来验证上述基于场景的功能建模方法。现代民机上的AFCS主要在飞行管理计算机的统一管理下,配合自动油门系统实现飞机的自动控制和对发动机推力的控制,实现飞机的起飞、爬升、巡航、下降、进近和着陆阶段的自动控制。本节针对民机AFCS的基本功能描述构建其顶层用例视图,使用黑盒顺序图、活动流和状态机对高度控制用例展开功能分析,迭代更新其系统需求。

3.1 AFCS用例建模

AFCS的功能主要包含飞机的姿态控制、空速与马赫数控制、航迹控制(结合飞行管理计算机系统)、高度与侧向偏离控制、协调转弯控制、自动油门控制和自动配平。根据民机AFCS的功能描述,构建其顶层用例视图,如图10所示。其中,马赫数配平是为了防止跨音速飞行时飞机进入马赫下俯姿态,系统应在俯仰通道中设置自动抬头补偿来克服这种危险。当纵向AFCS脱离对飞机的控制时,为了减小或完全抵消舵机上产生的铰链力矩,系统应能够进行俯仰自动杆力配平,维持飞机纵向力矩的平衡。

图10 民机AFCS用例Fig.10 Use case of civil aircraft AFCS

以高度控制用例为例,根据中国民用航空规章CCAR-25-R4定义其部分系统需求如图11所示,对其展开基于场景的用例分析,在分析过程中对需求进行增量式的迭代更新,克服会对系统体系结构产生不利影响的需求,降低系统研发的风险。

图11 高度控制用例系统需求Fig.11 System requirements of altitude control use case

3.2 AFCS场景活动流建模

定义高度控制用例的接口与端口,表示参与者与系统用例之间的交互请求,如图12所示。

图12 高度控制用例的接口和端口Fig.12 Interface and port of altitude control use case

选择正常飞行场景如图13所示,飞行员选择目标爬升高度和爬升率,确认后飞机开始爬升或下降至指定高度,由高度保持系统维持目标高度巡航。在该场景中,前置条件是飞机处于巡航状态,自动驾驶仪、自动航向、自动速度均已打开,后置条件是飞机到达指定高度,重新回到巡航状态。

图13 高度控制用例正常操作场景Fig.13 Normal operation scenario of altitude control use case

通过对该场景进行分析,可以发现当飞机处于爬升状态或者巡航(高度保持)状态时,AFCS应该具有相应的指示灯提示驾驶员,所以AltitudeLight()和ClimbRateLight()又可以衍生出更多的合理系统需求。例如，在爬升过程中,爬升指示灯常亮、高度保持等熄灭,爬升结束后高度保持灯常亮、爬升指示灯熄灭。同时,在飞行过程中,仪表盘需要显示当前的速度、航向和机内自检状态等信息。对所有可能的场景进行建模,逐步迭代构建高度控制用例活动流。在这一过程中,假设飞机高度调整精度为100 ft,如果飞行员对飞机高度进行微调,则采用内置爬升率,每次高度变化为100 ft。如图14所示,飞机从默认高度的巡航状态开始,飞行员选择指定高度和爬升率,确认爬升后自动飞行控制系统产生高度控制指令,从而改变飞行高度。

图14 高度控制用例活动流Fig.14 Activity flow of altitude control use case

图15 高度控制用例状态机Fig.15 State machine of altitude control use case event[guard]/action_list

3.3 AFCS状态机建模

从高度控制用例的场景活动流模型中可以看出,AFCS在实现高度控制的过程中有3种状态:飞行状态(高度保持)、爬升状态和选择状态。高度控制用例的状态机如图15所示,飞机的默认状态就是在当前高度的飞行状态,由飞行状态到选择状态的迁移,由事件“选择高度和爬升率”触发,存在最大爬升率和最大爬升高度限制,执行的动作集为仪表盘上显示的预选高度和爬升率的变化。从选择状态到爬升状态的迁移,由事件“确认爬升计划”触发,执行高度控制指令。由爬升状态到飞行状态的迁移由事件“爬升正常结束或中止爬升计划”触发,更新之后的用例接口和端口如图16所示。

图16 高度控制用例接口与端口(建模后)Fig.16 Interface and port of altitude control use case

在图15所示的状态机中,3个关键的状态特性是进入动作(entry)、内部执行(do)和退出动作(exit)。进入动作是每当进入一种状态时执行的动作列表;内部执行是在该状态内执行的动作集;退出动作是每当离开这一状态时采取的动作。带箭头的实线是转移,表示系统处于前一状态且触发转移的事件发生时,通过该路径进入新状态。转移的语法如下所示:

ｅｖｅｎｔ ［ ｇｕａｒｄ ］／ ａｃｔｉｏｎ ＿ ｌｉｓｔ

其中,事件event是在状态机中触发状态转移的事件。转移上的事件是可选的;若省略,则一进入该状态就会发生转移。守卫guard用来判断是否满足状态转移条件,若满足则执行动作集action_list,并完成系统状态之间的转移过程。

至此,民机自动飞行控制系统的高度控制用例建模已基本完成,得到可执行的状态机和对应的接口与端口。由于篇幅有限,本文只选取了高度控制用例展开基于场景的用例分析建模,模拟系统的实际运行过程,在系统开发早期识别系统缺陷,降低系统研发的风险。在实际的建模工作中,应该对图10中所示的所有用例展开建模分析工作,得到每一项能力的系统模型,将其整合成一个完整的飞机子系统接口模型,为后续的架构设计工作提供支撑。

4 结 论

本文将敏捷系统工程概念引入到民机研制过程中,提出了敏捷框架下的民机研制流程,并结合系统建模语言定义了基于场景的功能建模方法,最后采用该方法对民机AFCS的高度控制用例展开基于场景的用例分析建模工作。在功能建模过程中,使用需求图分配系统需求到目标用例、使用顺序图和活动图定义场景活动流、使用块图和状态机构建系统在实现目标用例时的状态转移过程和接口控制。该方法模拟了系统的实际运行过程,迭代更新了系统设计需求,提高了模型的可靠性和可信度,显著降低了复杂系统的研发风险。