0 引言

在信息化支持下,飞机研发正向着数字化、集成化、高度并行化、多组织供应链协同化转变。飞机研发模式的演进,其本质是生命周期流程的再造和持续优化的升级,而信息技术是关键的推动力和使能工具。IT工具和信息化环境的支持加速了飞机研发流程中的迭代速度,从而也导致了飞机系统研发模式的变化。对此,国际先进航空航天国防企业在国际系统工程学会先导预研支持下,通过理论方法的不断创新应用,用基于模型的系统工程MBSE^[1-2]等先进理论应用来应对挑战。将MBSE概念不断延伸应用到设计、仿真、制造等环节,逐步构建并完善联系数字和物理两个空间的媒介体系,可以改变传统的基于文件的传递信息方式,建立整体性、动态性信息传递方式,实现工程技术人员既能看到结构又能继续捕获到系统行为,从而通过信息、计算和软件来搭建传统系统与复杂系统之间的桥梁。针对航空行业军机^[3-4]和民机^[5-6]两大方向,诸多学者对此展开了研究,但大多均是基于MBSE展开飞机三维结构设计的研究^[7-11],鲜有基于MBSE,对飞机系统级的全生命周期研发方法进行探索。

副翼及其操纵系统的研制是一项复杂的系统工程,其研制过程不仅涉及研发单位内部之间需要跨学科、跨部门协作和集成研发的问题,而且还涉及与不同供应商之间的协同设计问题,如与制造单位的设计制造一体化、与试飞中心的试飞管理协同、与适航当局的适航取证管理和数据协同等问题。因此,为解决副翼及其操纵系统设计研制中的上述众多问题,应用基于模型的系统工程研发模式,实现副翼的快速研制具有重要的意义。

本文针对某型号飞机副翼及其操纵系统设计及研发过程,以需求R、功能F、逻辑L、物理P的基本数据模型为核心,结合基于模型的完整上下文关系,提供针对不同层级系统间、基于模型的数据追溯性。采用达索系统工程建模方法论MMS,利用达索3DExperience平台,进行副翼及其操纵系统的场景验证,试图寻求一种采用基于模型的系统工程方法进行复杂系统设计的一般流程。

1 MBSE方法

在副翼及其操纵系统架构设计过程中,基于达索MMS系统工程方法论,主要通过使命(Mission)、服务(Service)、功能(Function)及组件(Component)层的分析以及用例图、功能图、场景图、顺序图等来展开系统设计,并建立基于RFLP统一架构的系统模型,如图1所示。

主要分析视角如下:

1)使命层,定义系统的运行环境,以确定系统的使命及利益相关者的需求,从而识别通过实现业务活动以完成使命的候选系统;

2)服务层,通过分析系统的服务场景及用例等业务活动,定义系统的服务和需求,从而满足系统运行环境业务活动和利益相关者的需求;

3)功能层,通过开发满足系统服务和系统需求的功能架构和功能设计需求,定义功能解决方案;

4)组件层,通过分析系统分配的技术功能和流程,满足系统的服务性能和功能需求,获得实现系统设计要求的组件体系结构和逻辑解决方案。

通过基于RFLP的系统架构设计,清晰地回答了如何应用系统工程方法论定义产品系统架构,实现了基于模型的系统工程中最关键的基于模型的统一架构。

1.1 使命层分析

副翼及其操纵系统需求开发是把用户的需求及外部环境的约束变换成系统要求。其目的是将利益相关者期望的服务作为需求的驱动,并将其转换为以技术为驱动的产品,该产品可提供所需的服务,如图2所示。该活动将构建满足利益相关者需求的副翼及其操纵系统形式,从而产生可度量的副翼及其操纵系统需求,该系统需求可从用户的视角规定应有哪些特征以及多大数量。该系统需求是副翼及其操纵系统研发的顶层需求,是系统工程研发活动的起点。

通过分析复杂系统,定义副翼及其操纵系统全生命周期状态、利益相关者、场景和需求实现副翼及其操纵系统的定义。

1) 首先使命层的分析源头是副翼及其操纵系统顶层需求,针对顶层需求进行需求工程分析,通过对副翼及其操纵系统的概念设计制造运营退役的全过程分析,根据所需要分析的对象、场景确定系统所处的生命周期状态。副翼及其操纵系统的生命周期状态示例图,如图3所示。

2) 根据系统所处的生命周期状态,分析系统的使命边界,定义系统的顶层使命,系统的顶层使命是系统要完成期望的行为,顶层使命具有高概括性,后续的使命需求分解也是依据系统顶层使命展开。通过系统顶层使命识别与之交互(输入与输出)的外部角色,按照利益关切程度定义利益相关者,以及与其对应的业务活动。副翼及其操纵系统的利益相关者视图,如图4所示。

利益相关者与系统之间的交互构成了实现系统使命的业务活动,通过将业务活动分配给利益相关者,从系统顶层层面实现系统使命,清晰地定义了使命与利益相关者、系统之间的关系。定义的系统业务活动,将作为下层进一步分析的理论依据。

3) 当完成系统业务活动后,为描述使用场景利益相关者与系统之间的交互,通过对使用场景的动态模拟,从系统顶层层面实现系统的业务活动(黑盒),从而定义清楚系统的使用场景。同时通过分析可得到利益相关者与系统交互的控制流及对应的接口,副翼及其操纵系统的利益相关者视图,如图5所示。

通过系统与利益相关者业务活动的动态模拟,描述了利益相关者对于系统的要求,将具有功能性的使命需求细分为功能需求,功能需求是进行下一层分析的源头。

4) 利益相关者对于系统除了功能性的要求以外,还与使用场景对应所处的环境(包括利益相关者)存在拓扑关系,通过环境分析系统,将产生副翼及其操纵系统与环境的边界,边界内是系统,边界外是外部角色。通过系统和环境的信息交互分析,产生接口需求,通过环境对系统的约束等产生性能需求,如图6所示。

1.2 服务层分析

通过使命层分析将使命需求细分为功能、接口、性能需求,故此形成了服务层所需的服务需求,然后对服务需求进一步分析、分解和分配,进行服务层活动分析。

1)系统工作模式(黑盒状态行为)分析,通过对系统所处的生命周期状态、使用场景、业务活动的分析定义系统的工作模式。

系统工作模式(黑盒状态行为):系统工作模式描述的是系统在其生命周期内的动态行为,表现为系统所经历的状态序列、在特定状态下的行为、引起状态转移的条件、因状态转移而伴随的动作以及对异常做出的响应等。

根据系统所在的生命周期状态及对应的业务活动建立一个具有统一共识的、能够完成使命的系统工作模式,系统工作模式给出了系统功能所运行的状态与模式条件,有助于清晰地定义后续系统功能需求。副翼及其操纵系统的系统工作模式视图,如图7所示。

在系统工作模式分析示意图(状态/模式迁移)中,详细地说明了每个状态与模式的迁入与迁出条件。通过分析可知,系统工作模式属于黑盒功能分析,系统的工作模式随着使用场景的变化而变化,系统状态分析完成后得到系统工作模式图(服务状态图)。

2)系统不同的工作模式对应不同的工作流程,对不同的工作流程进行黑盒系统的功能流程分析。在系统不同工作模式下定义系统用例,定义利益相关者与系统交互产生实现使命的服务,即系统用例功能,它是以活动(在基于模型的系统工程中等同于操作过程)的方式来组织功能,并显示这些活动是如何相互关联的。副翼及其操纵系统的用例视图,如图8所示。

系统用例的分析不仅实现了系统黑盒功能定义,而且定义出了系统的上下文关系,为后续白盒的功能、逻辑分析起到了关键作用。

3)通过特定的系统用例创建时序图。根据系统所处的使用场景、系统工作模式以及服务架构分析系统工作动态时序过程,验证服务静态架构的逻辑性、合理性。时序图中系统之间的行为(箭头)是功能的连接类型(流)。副翼及其操纵系统的服务场景视图,如图9所示。

针对每个系统用例进行具体的功能分析,当满足每个系统用例的要求时判断需要用哪些系统内部功能进行支撑,同时分析出相应的系统功能需求。针对系统功能进行分析,识别、定义、设计、分析系统功能的接口,包括定义系统功能之间的接口类型、数据交互、能源媒介等。

基于系统用例进行功能分析过程中,需求被细化,产生或识别新需求时,都需要将新需求时刻文档化,并在系统中进行需求更新,在系统用例分析完成后,都需要利益相关者审批这些衍生或新产生的需求。

系统除了应具备相应的功能以外,还需满足环境对系统的拓扑要求,此时需要分析副翼及其操纵系统的安装、使用、可达性等,从而定义出系统框架,如图10所示。

1.3 功能层分析

针对服务层形成的最终版需求,分析满足需求的系统功能单元,并确定各系统功能单元之间的逻辑关系,即输入输出关系,功能视图描述了功能单元之间的关系。

系统功能层分析的主要重点是把系统功能需求转化为一个个连贯的系统功能描述(操作)。分析是基于用例进行的,即:系统是如何通过一步一步的操作实现用例,形成系统功能架构模型。

1)根据系统上下文关系和系统用例,定义系统操作的静态。功能静态模型主要是分析系统功能之间的行为逻辑、工作流程,是系统功能分析中最重要的一部分,是对系统功能一个全面的、完整的理解与梳理。系统功能之间的行为逻辑、工作流程分析是白盒设计过程,主要定义系统功能之间的控制流,通过设计出一系列功能操作实现系统服务,可以是一个或一组功能操作完成一个服务,也可以是一组功能操作完成整个服务架构,详细地说明系统为了完成服务,需要通过哪些具体操作及数据/逻辑关系流定义系统功能。

2)功能架构动态模型是通过白盒功能流程分析获得,白盒功能流程分析描述了用例通过某一个特定路径,定义系统的操作和角色之间的互动(信息或消息)。白盒功能流程分析清晰地说明为了完成该系统功能,各分系统之间都需要如何配合,分别执行哪些动作。副翼及其操纵系统的功能动态视图,如图11所示。通过分析在每一个使用场景或是异常场景下系统功能之间的行为逻辑关系,确保定义的系统功能逻辑的正确性与完整性,并且通过场景分析还能够定义系统功能与外部的交互关系,产生对应层级的需求,如图12所示。

1.4 组件层分析

组件层分析的关注点是在所规定的性能约束范围内,将功能向组件分解分配,从而得到一个逻辑架构(如一组产品,系统或元素)。

架构设计的目的主要是定义实现功能的系统逻辑组件,实现系统行为建模与仿真。逻辑架构视图是逻辑组件及其交互关系(端口、流)的抽象表达。因此,系统逻辑组件的组成、交互关系及其行为是搭建逻辑架构的关键。

1) 组件静态模型是通过功能动态分析,实现功能到系统组成的分配及逻辑架构的定义。通过功能向系统组成的分配,使得对系统组成的每个组件的功能有了清晰的定义,从而能够实现每个组件的接口定义,以及每个组件要向外传递的数据。副翼及其操纵系统的组件静态架构视图,如图13所示。

逻辑架构的关注点是接口定义,以及架构分解的最低层次系统的动态行为,其描述了分系统与外部角色的交互以及分系统之间的交互,通过每个组件接口定义,产生相应的组件需求,如图14所示。

2)组件拓扑模型定义系统级区域中的各个分系统/组件的拓扑关系,根据系统拓扑限定和逻辑架构设计定义各个分系统/组件的几何、物理和材料等。组件拓扑模型定义了组件三维几何性质,同时将性能指标转换为部件的设计约束(例如将总体规范中的重量要求分配到每个组件)。

2 系统建模与仿真

在副翼操纵系统逻辑层级结构搭建完成后,在此逻辑模型上指定各分系统的所有行为预期,来评估基于虚拟样机的总体设计的可行性。

2.1 副翼及其操纵系统设计

结合设计需求和功能分析,基于副翼操纵系统逻辑架构,为副翼操纵系统的逻辑组成定义行为,并能够进行行为模型设计。利用Modelica多领域统一物理建模语言以及其各专业模型库,为副翼操纵系统详细的功能、逻辑组件建立各自的行为模型,实现副翼操纵系统行为的完整定义。

2.2 副翼及其操纵系统建模

在确定副翼操纵系统架构及行为后,利用3DExperience的动态行为建模功能进行多学科系统统一建模工作,建立副翼操纵系统模型,实现系统集成。

通过功能层和组件层的分析,副翼操纵系统实现副翼作动主要由三部分子系统组成:

1)操纵子系统,通过电传飞行控制系统将飞行员的操纵信号由指令传感器转变成电信号,传递给飞行控制模块,飞行控制模块同时接收液压助力器和操纵面的反馈信号,并将这些信号进行综合比较和运算处理,按照既定的控制规律,将控制指令输送液压系统并实现对飞机姿态的控制。

2)液压驱动子系统,主要包括油箱、液压泵、液压油滤、蓄压器、液压马达,实现液压油向各个作动系统的流量分配。

3)作动器子系统,主要包括作动缸、流量控制阀、方向控制阀、压力控制阀等。通过液压助力器提供巨大的输出力矩驱动舵面偏转,同时将舵面的作动信息实时传送给操纵系统,实现副翼作动的控制。副翼及其操纵系统行为模型,如图15所示。

2.3 副翼及其操纵系统仿真

通过系统模型和系统设计模型关联,在副翼及其操纵系统设计阶段,从逻辑角度、功能角度、性能角度,对分析设计得到的系统模型(系统功能、架构及接口)进行确认和验证,同时利用副翼三维模型创建的多体运动学模型,将其与副翼操纵系统一起进行动态行为仿真,用以验证副翼及其操纵系统是否满足初始的系统设计需求,实现需求闭环验证。副翼及其操纵系统仿真,如图16所示。

3 结论

以文档为中心的需求管理等传统研发方法,往往因语义的二义性等给飞机研发过程带来诸多问题,为了避免此问题,本文引进了先进的系统工程理论,采用达索系统工程方法论,以副翼及其操纵系统研发过程为应用验证场景,探索了基于模型的系统工程在飞机研发过程中的实践新方法。

探索并发现,基于3DE平台,在保证统一数据源的前提下,可实现操纵子系统、液压驱动子系统、作动器子系统和副翼多体运动学模型的集成仿真,验证副翼及其操纵系统的功能和性能等指标,实现与初始系统需求的闭环验证;避免不同工具数据流转带来的风险,实现需求、功能、逻辑、物理到仿真验证的产品研发全过程可追溯可验证。推进了基于模型的系统工程的方法在飞机研发过程中的深度应用。

基于模型的系统工程在飞机研发过程中的实践新方法,需求、功能、逻辑、物理到仿真验证的产品研发全过程的建模仿真过程,以及使用的3DE平台具有通用性和可扩展性。

参考文献