模型驱动的复杂装备系统设计与仿真验证研究

欧阳毅，孙 全，黄 旭，翟文华，吕炳均

（上海机电工程研究所，上海 201109）

随着信息网络技术的迅猛发展，武器装备不断优化升级和高科技作战手段不断更新，战场环境日趋复杂，现代地面防空作战面临更多的挑战［1］。复杂装备系统逐渐由大系统向巨系统发展，呈现出功能高度复杂、各领域耦合关联、跨域协同性强等特点。复杂装备的研制是一项跨层级、跨专业、跨领域的规模庞大，过程复杂的系统工程，涉及多个学科，需要根据各系统、学科之间相互联系，进行仿真验证、方案对比和多轮迭代，最终完成设计过程。

传统的系统工程设计方法是以文档为核心，技术状态分散于多份设计文件中，项目内的设计协调和任务传递主要依靠文档来完成。文件的静态性导致技术状态缺乏有效的验证手段，同时传递效率也较低，已无法满足复杂系统的研制要求。采用基于模型的系统工程（model-based systems engineering，MBSE）方法能够解决上述问题。它从需求阶段开始即通过模型的不断演化、迭代递增而实现产品的系统设计，可以根据用户需要刻画产品设计初期的需求，并根据需求设计产品的功能、结构以及参数等；再通过仿真分析发现不合理的设计方案，为各方提供了一个通用的、无二义性的设计信息交流平台。

近年来，基于模型的系统工程已陆续应用到相关装备论证和设计中，罗松等［2］针对面向对象设计方法开展一些功能的实现研究；汤超等［3］立足于战略层面，完成战略体系结构的建模，着重进行需求分析；刘宇等［4］针对火控系统的单机设备，开展了需求分析和系统设计。但目前文献中暂未涉及从作战体系需求分析到产品实现全流程的装备建模设计的案例，同时针对模型的有效性、完整性以及逻辑的一致性都无法通过合理的方法进行验证，使得模型的可信度降低，甚至影响到产品的设计结果。因此，本文在MBSE 深入研究的基础上，针对复杂装备功能高度复杂的设计难点，结合装备研制流程，提出了一种适用于复杂装备系统建模设计和仿真验证的方法，重点针对复杂装备软功能设计，即功能逻辑流程、输入输出流、接口等进行建模设计与仿真。

1 系统设计建模语言和建模工具

MBSE 的核心就是采用形式化、图形化的建模语言及相应的建模工具，优化研制过程的系统工程［5］。针对不同的建模类型可以采用不同的建模方法与技术。统一建模语言（UML）在软件工程领域的模型驱动软件设计中取得了巨大成功［6］，它具有极好的扩展性与开放性。在UML 2.0 的基础上，国际系统工程学会和对象管理组织对其进行面向系统工程的扩展，定义了一种新的系统建模语言标准——SysML。SysML来源于UML，规定了若干种自然语言外的符号，包括框图、线条、箭头等，来创建系统结构、行为、需求和参数模型。

建模工具是一类辅助工具，为用户在遵守建模语言规则下用SysML 语言创建形式良好的模型。常见的建模工具包括Enterprise Architect、MagicDraw、Rhapsody、源图等。在本文中综合选取了源图、Rhapsody、MagicDraw 作为建模工具，综合了三者的建模优势。

2 模型驱动的复杂装备建模方法

建模方法就是如何利用系统建模语言的各种图形来建立相关模型进行系统实现，这充分依赖于装备特点和研制经验。传统武器装备研制流程通常是个V字形，左侧是系统设计，主要包括需求分析、系统设计、分系统设计、分系统实现，右侧是系统集成验证，主要包括分系统集成调试、系统集成调试、系统交付验收等环节，如图2所示。

图2 传统武器装备研制流程Fig.2 The traditional development procedure of weapon equipment

本文结合传统武器装备研制流程，根据模型设计特点，将系统建模设计分为作战体系需求分析、系统功能分析、系统架构设计、分系统功能分析、分系统架构设计、分系统产品实现和全系统集成等活动，设计师在每个活动上通过建模完成分析、设计和验证，活动与活动之间通过模型进行传递，各个活动产生的模型都纳入到模型库中，推进后续装备设计时产品化复用，如图3所示。

图3 基于模型驱动的复杂装备系统设计流程Fig.3 Model-driven design process of complex equipment systems

2.1 需求分析

系统工程一般从用户需求开始实施，用户需求是系统的顶层能力，是针对用户以面向问题的角度进行的表达。通常结合装备的顶层作战使命以及环境约束，通过作战活动图形式对每个作战场景描述作战过程，形成作战活动图和作战时序图，基于系统视角开展系统功能分析，形成系统功能流描述视图，并对参与作战的各个作战单位形成所需要的作战能力和作战活动映射表，完成系统需求的捕获。

2.2 系统功能分析

系统功能分析是以面向解决问题的角度，将系统功能需求转化为对系统功能的描述，称为黑盒阶段。功能分析主要是对系统的功能进行定义，首先通过创建活动图来分析用例的功能流，然后通过时序图确定系统与外界的交互，最后通过状态机图来描述系统基于状态的行为。在功能分析的最后阶段，这些附加需求需要得到用户的认可，并被导出到需求管理工具。

在功能分析阶段，活动图只分析系统与外部的交互情况和系统自身的运行情况，不涉及系统内部的结构，被称为黑盒活动图［6］。和活动图类似，在功能分析阶段，时序图被称为黑盒时序图。状态机图将活动图中的功能流和时序图中的交互集中在一起，包含了黑盒活动图和黑盒时序图的信息。功能分析阶段输出主要是系统功能条目和系统黑盒模型。

2.3 系统架构设计

系统架构设计目的是设计合理的系统架构，并将系统功能进行分解。在架构分析阶段，对系统进行权衡分析，在功能分析的基础上，确定实现系统功能的最佳方法。由于确定了系统架构和系统内部各模块与系统外部的交互，所以将架构设计过程称为白盒阶段，将该阶段的各个视图称为白盒视图。系统架构可以是权衡分析的结果或者传统架构，对各模块或子系统的行为、子系统之间的交互和子系统与系统外部的交互进行建模，将功能分析阶段的黑盒视图转化成白盒视图。架构设计过程和功能分析过程类似，白盒视图同样包括活动图、时序图和状态机图。

系统架构设计阶段输出主要是系统白盒模型和分系统需求条目。

2.4 分系统功能分析

分系统功能分析是根据上一阶段输出的顶层需求，将分系统看成一个黑盒，对每个业务用例通过活动图、时序图和状态图进行描述，对分系统需求条目进行抽象、合并、拆分，得到细化的功能需求，并形成分系统需求列表和分系统黑盒模型，如图4所示。分系统功能分析输出主要是系统白盒模型和分系统需求条目。

图4 黑盒活动图示意图Fig.4 The black-box diagram

2.5 分系统架构设计

分系统架构设计目的是设计合理的子系统架构，并将分系统功能进行分解，分配到架构内各模块（软件）中。若分系统存在三、四级子系统，则依次类推，对分系统进行逐层分解。分系统架构建模可分为机械架构建模、电气架构建模和软件架构建模，通过建模可快速开展工程设计的迭代仿真验证。随着产品硬件的系列化、产品化，作战指挥、发射控制等分系统架构设计更多偏重于软件架构设计。通过对软件用例过程的描述，完成软件架构中各分析类的逻辑、接口和数据的设计，并牵引出逻辑模型和数学模型体系。

最终分系统（软件）架构中各个分析类以活动图、时序图、接口图等形态呈现，可以直接用于软件专业开展分系统软件开发，如图5所示；逻辑模型和数学模型体系中各个模型以类对象的形式封装，并通过接口图描述其输入输出接口，可以直接用于模型专业进行模型设计和开发。

图5 分系统（软件）设计Fig.5 Subsystem software design

2.6 产品实现

各分系统（软件）专业根据分系统架构设计输出的各个分析类相关的时序图、接口图，将分析类转换为设计类，并据此开展软件开发。数学模型体系中各个模型以类对象的形式封装，最终完成各分系统（软件）设计。

各分系统产品实现后，交付总体开展系统半实物仿真验证和系统外场对接联调等集成验证工作。

3 复杂装备系统模型仿真验证方法

3.1 系统模型构建

基于复杂装备系统建模设计方法，本文建立了装备系统典型工作过程的系统模型。首先，针对用户需求，通过需求清单进行了总结，如图6所示。在装备系统典型作战过程中，用户需求主要包括对装备系统需要的感知能力、打击能力、通信能力以及指控能力。

图6 用户需求清单Fig.6 List of user requirements

针对典型工作过程，根据用户需求，将其归纳为2个用例：目标探测和目标打击。通过与利益攸关方进行关联，可得到如图7所示的用例图。

图7 装备系统用例图Fig.7 Use case diagram of equipment system

基于上述用例，分析装备系统与系统运行环境之间各要素，结合其他利益攸关方之间的交互动作，可以通过活动图来对用例进行细化，其中目标探测用例的活动图如图8所示。指挥员通过操作员向装备系统下达目标探测指令，随后系统综合内外目标信息，通过计算处理，得到目标数据，显示目标位置。

图8 目标探测活动图Fig.8 Activity diagram of target detection

装备系统与系统外部的接口以及输入输出定义，具体如图9所示。

图9 装备系统接口定义Fig.9 Equipment system interface definition

定义了系统接口以及输入输出后，装备系统的运行环境以及各语境要素均已完善。通过定义系统运行环境可以更加准确地定义系统与用户以及外部系统的交互关系。系统运行环境中的其他要素之间的交互如图10所示。

图1 SysML所有图形的层次结构Fig.1 The Architecture of SysML diagrams

图10 装备系统运行环境Fig.10 The operating environment of equipment system

进入白盒阶段意味着针对系统内部进行深入分析，理解系统如何运作，深入分析拆解系统功能，从而识别功能模块及所属的逻辑子系统。同时，系统行为和结构的细分是多层迭代的，以实现问题域定义的相关粒度。本文通过从系统到子系统的分解来描述系统功能逐层分解的方法。

通过用例细化得到的活动图，对装备系统进行更深层次的功能分析，针对属于装备系统的活动可继续向更深层次进行分解，其中目标打击中的制导飞行动作可以向下分解，如图11所示。

图11 制导飞行活动图Fig.11 Activity diagram of guided flight

功能分析的完成帮助识别了装备系统的逻辑子系统。同时在建立子系统连接的过程中及实现系统功能的过程中，需要考虑与其他系统连接的接口。装备系统的架构通过模块定义图进行表示，如图12所示。装备系统的内部结构如图13所示。

图12 装备系统架构及子系统接口定义Fig.12 Equipment system architecture and definition of subsystem interface

图13 装备系统内部模块图Fig.13 The IBD of equipment system

完成了逻辑子系统分解之后，可以将功能行为分配到相对应的逻辑子系统中，完善功能分析。

确认解决方案结构中的子系统后，开始进行子系统的系统结构设计分析工作。从定义子系统的内部结构开始，构建子系统的解决方案结构，并指定其各个部分的操作，及与外部的交互。

完成了系统结构及子系统结构定义，需要对系统行为进行定义。首先定义子系统行为，通过系统结构定义好的接口将所有子系统行为进行集成，完成系统行为定义。如图14所示，装备系统在典型作战过程中的各类行为已通过状态机进行定义。

图14 装备系统状态机图Fig.14 The state machine diagram of equipment system

3.2 系统活动模型仿真

测试系统之间是否按预期进行相互通信成为系统工程师下一步的主要工作。基于系统的运行环境，系统与利益攸关方和外部系统进行交互作用，通过设计定义的接口接收和发送各类物质、能量、信号与信息流，随后系统、子系统将通过一系列的动作和行为来实现系统的预期功能。

在上述过程中，系统会进入不同的工作状态。在不同的状态下，系统所执行的动作也各不相同。通过控制信号来触发系统状态的改变，从而使系统实现不同阶段所需要的功能。

基于4.1 章节中建立的装备系统功能模型，本章将通过对系统的行为、状态、接口、输入输出进行仿真分析，验证上述模型的逻辑一致性、接口定义的准确性以及系统功能实现的预期情况。

首先，针对目标探测用例进行仿真。基于用例指导所建立的活动是系统设计的基础，其中包含了系统预期的全部功能，其仿真过程如图15所示。

图15 目标探测活动仿真Fig.15 Simulation of target detection activity

其次，指挥员向操作员下达目标探测命令；随后，装备系统开始并行执行3 个动作：请求上级信息，请求导航数据，以及搜索空中目标信息，并发送相应的请求信号。

在搜索空中目标信息中，通过选择框来完成“目标是否捕获”判断，模拟实际流程中可能出现的多种情况，保证模型逻辑的正确性与一致性。在搜索空中目标信息过程中，子系统3 在经过多次未捕获目标后，完成对目标的捕获，并将目标信息通过接口发送给子系统1，实现信息的传输。如图16所示。

图16 搜索空中目标信息Fig.16 Search for airborne target information

当装备系统完成目标搜索，得到上级信息及导航数据后，开始进行下一步的目标信息综合处理计算，并完成后续一系列的动作，直至完成整个目标探测活动，验证该活动逻辑的完整性。

3.3 系统状态机模型仿真

在状态机图中，系统通过触发控制信号实现状态的切换，并根据自身所处的状态执行相应的动作。系统的一个状态可能会包含几个子状态，这些子状态同样会根据触发信号实现切换。在不同的子状态下，系统本身还在执行相应的动作，但类似于活动的分解一样，状态的分解同样会让系统在同一状态下执行分解后的动作。

如图17所示，对装备系统状态机进行仿真验证分析。首先，装备系统经过上电开机自检后，进入到待命状态，等待外部的控制信号。

图17 装备系统状态机仿真过程Fig.17 Equipment system state machine simulation process

在接收到目标探测指令后，装备系统进入目标探测状态，并随后进入到信息收集子状态中的请求导航数据子状态、请求上级信息子状态以及搜索空中目标子状态。在子状态中，装备系统分别执行相对应的动作，并在完成后退出信息收集子状态。

随后经过综合目标处理计算以及显示目标位置，系统返回到待命状态，并等待后续的控制指令。在接收到目标打击指令后，装备系统通过参数装订、导弹加电、导弹发射和命中目标一系列状态并完成相应动作后，返回到待命状态。

3.4 系统接口与输入输出模型仿真

经过上述两节的仿真分析，明确了装备系统行为模型（活动与状态机）逻辑的完整性和一致性，因此后续将继续对模型接口定义以及输入输出流的正确性进行仿真验证。

由于系统、子系统的接口以及输入输出是基于系统的外部环境以及内部结构而定义的，因此，无法脱离系统的运行环境和结构单独证明接口以及输入输出流是否定义正确。图18综合展示了装备系统的运行环境以及内部结构。

图18 系统运行环境及内部结构Fig.18 System operating environment and internal structure

由于装备系统的接口与输入输出流数量多，本文选取导航数据进行仿真分析，具体流程如下。

首先，指挥员向操作员下达目标探测命令，并由指挥员向装备系统下达目标探测指令。在接到指令后，装备系统便向导航系统发送请求导航数据。导航系统接收到请求导航数据的指令后，向装备系统发送系统的导航数据，并由装备系统向子系统传递该数据，此时系统便记录下导航数据。最终由子系统接收并记录数据，目标数据如图19所示。

图19 导航系统返回导航数据Fig.19 The navigation system replies with navigation data

仿真结果证明，装备系统的导航数据接口能够实现与利益攸关方以及外部系统进行信息交互的功能，包括发送请求信息并收到相对应的数据。同时，装备系统能够实现与子系统之间的信息传输。

基于上述系统模型的仿真验证方法，通过分析仿真结果，可以证明依据本文所提出的系统设计方法建立的系统模型具有良好的逻辑完整性和一致性，且接口与输入输出流的定义准确，能够实现系统、子系统与外部环境和内部结构的复杂交互。

4 后续展望

本文提出的模型驱动的复杂装备系统设计与仿真验证方法，基本实现了从作战需求分析到产品实现的全流程建模，对提高装备设计质量和效率具有很大意义。然而由于研究时间的限制等，还存在许多问题需深入研究和加强攻关。

（1）对性能指标迭代验证需要加强。目前建模工作侧重于对各级系统功能需求的捕获和验证，偏重于逻辑控制层面，缺少对系统性能指标需求的捕获和验证，如电磁仿真、力学分析等性能指标分析。

（2）提升建模设计自动化水平。现有的建模工具难以实现自动化智能化建模，整个建模设计过程均需设计师手动完成。事实上，功能分析、架构设计和软件设计之间存在一种映射关系。因此，如何利用现有技术基础提高建模的自动化水平，实现自动辅助建模和自动软件代码生成值得研究与探索。

（3）探索机电液等物理建模方法。复杂产品具有其自身的许多特点，如多物理域、连续动态行为等，需要对机电液等多个物理域建模实现对复杂系统更为全面的描述。实现系统功能逻辑与物理性能的联合仿真，验证系统功能逻辑和物理性能的匹配性，对于全流程建模的研究具有重要意义和价值。

5 结 论

本文针对复杂装备功能高度复杂的设计难点，结合装备研制流程，提出了一种适用于复杂装备系统全流程建模设计与仿真验证的方法，覆盖了从作战需求分析、系统功能分析、系统架构设计、分系统功能需求分析、分系统架构设计、产品实现等装备研制全过程，极大地提高设计效率和质量，具有较高的实用价值。同时探讨该方法在性能指标迭代、建模自动化、物理建模等方面需要提升的地方，这些也是基于模型驱动建模在装备研制应用中需要尽快开展重点研究和攻关的方向。