0 引　言

舰炮储运系统是一个融合机械、电气、控制、气动、软件等的较为复杂的多学科大系统，传统的设计方法主要依靠文档作为驱动，包括方案设计、详细设计、生产制造、多样机迭代试验验证等。随着装备复杂程度的提高，特别是全舰计算环境（TSCE）的提出及应用^[1]，目前舰炮武器装备亟需进行研发制造数字化转型，按照系统工程的方法开展正向研制。

基于模型的系统工程（MBSE）是对系统工程研制方法的正式化、规范化的应用，建模过程支持系统需求、设计、分析、验证和确认过程，基于统一系统模型进行数据传递，支撑从概念阶段开始，并持续贯穿到系统设计开发后的全寿命周期^[2]。通过各阶段需求模型、功能模型和逻辑模型的闭环仿真分析，完成顶层要求、系统需求、分系统需求等的正确传递，可显著提高舰炮武器装备设计研发效率。

目前，国内外学者对MBSE理论方法都进行了深入研究。MBSE在美国军工领域已得到广泛应用，NASA的火星探测车、Orion载人航天器，洛克希德•马丁公司的各版本的F-35战斗机等，使用MBSE的正向设计方法，通过系统建模语言SysML，对武器装备进行了多层次系统架构，通过既有装备模型数据的积累，实现了新式装备的方案快速成型，大幅降低了装备研发周期。在国内，航天五院“天宫”号空间站、航天八院“风云四号”微波星、中国商飞“灵雀”项目都进行了MBSE的尝试应用，利用可自动关联和追溯的系统模型，从系统架构至功能性能模型的构建，实现了产品的基于模型的正向设计，通过模型的多维度共用，可提高总体设计效率。

1 MBSE概述

MBSE最早由国际系统工程协会（INCOSE）在2007年提出，并推动了美国在2018年6月发布的数字工程战略^[3]，目前的MBSE落地应用通常指的是狭义的MBSE，其主要贯穿装备全寿期的战略筹划、装备论证、初步设计与详细设计阶段，各阶段对应了体系模型、需求模型、功能性能模型和设计模型，通过统一的数字主线实现数字模型的单向传递，保证了“需求规范可追溯、架构合理可验证、指标闭环可联动”的应用目标。

按照传统系统工程方法，以文档为载体进行正向研制，研制过程中需要从各类设计文档中获取输入信息，通过文档转换后形成下一阶段文档，由于文档信息无法使用计算机自动处理，各阶段需求无法进行闭环验证，设计改动也无法自动适应调整。文档要按照研制流程顺序流转，要等做出实物样机后，各子系统才能进行集成测试，导致大量工作难以并行，实物样机的迭代验证也极大地增加了开发周期和成本，在此研制路线下，国内舰炮行业目前主要依靠多轮的专家评审来避免出各类工程问题。

MBSE的三大支柱包括建模语言、建模方法以及建模工具。目前的建模语言主要指的是系统建模语言SysML，其本质是基于统一建模语言UML的一种扩展，是对象管理组织（Object Management Group）和系统工程国际委员会（International Council on System Engineering，INCOSE）推荐的系统建模语言，也是当前主流的MBSE建模语言。针对系统工程，SysML共定义了9种图，包括需求图、模块定义图、内部模块图、包图、参数图、活动图、序列图、状态机图、用例图。SysML的9种图如图1所示。

MBSE的建模方法论主要包括INCOSE的面向对象系统工程方法（OOSE），IBM公司提出的Harmony-SE方法，达索公司的MagicGrid方法，泰勒斯公司结合自身业务提出的Arcadia方法论，同时国内还有商飞公司提出的COMAC MBSE方法论等^{[4 − 5]}。MagicGrid方法论提出了基于需求、结构、行为、参数的SysML建模流程，包括问题域、解决方案域和实现域，每个域都表示为MagicGrid框架的单独一行，问题域包括两行，先从黑盒角度观察目标系统，然后从白盒的角度定义问题域，该域主要完成顶层要求到顶层需求的转换，解决方案域的内部被分成许多行，系统、子系统和组件等在不同颗粒度下完成逻辑架构。实现域主要完成各专业的需求定义、初步方案设计及详细方案设计，完成装备的物理模型开发。每个域都采用不同的逻辑视图表示了目标系统的需求、行为、结构和参数4个方面，这也与SysML的4类图相匹配。这些域与ISO15288定义的流程完全一致^[6]，问题域与利益相关者需求开发流程匹配，解决方案域与架构设计相匹配，实现域与设计定义相匹配。

舰炮储运系统作为舰炮装备领域，在模型体系中处于装备模型层，比较适合参照MagicGrid方法，通过剪裁后可形成舰炮装备正向设计系统方法论，舰炮储运系统的解决域的架构设计通常会借鉴现有成熟型号的逻辑架构，因此对于问题域的概念子系统，通常直接作为逻辑子系统开展迭代设计。

剪裁后的舰炮储运系统正向设计方法框架如图2所示。

2 舰炮储运系统问题域顶层需求分析

问题域需求分析主要是对舰炮储运系统的顶层需求进行分析，通过结构化文本或者需求图的形式，将储运系统的功能与非功能性需求得到清晰一致的描述，形成舰炮储运系统的设计要求模型，并作为装备数字样机模型的需求输入，相关需求通常由装备需求模型继承，在TBSE研制模式中由研制任务书的形式下发。

2.1 黑盒视角分析

首先将舰炮储运系统作为一个黑盒，所有的分析不关注系统内部结构和行为，通过分析目标系统在各种系统运行环境中的交互，完成舰炮储运系统的主要输入、输出以及量化指标^[7]。

储运系统捕获的顶层需求（部分）如表1所示。

根据顶层需求，对舰炮储运系统的运行环境进行定义，并确定舰炮储运系统的所有运行环境，其中提炼的“射击”运行环境如图3所示。

储运系统的“射击”运行环境确定了所有与其进行交互的外部系统，包括操作人员、舰炮和武器控制系统等，各系统运行环境采用用例图或者活动图捕获，该运行环境采用的用例图如图4所示。

储运系统“射击”运行环境下的每一项用例都包含一个主运行场景和多个备选场景，主要采用活动图如图5建立，活动图的每一个节点都代表了黑盒视角下系统的功能性需求。

对于储运系统的设计约束可采用有效性度量进行细化，通过SysML值属性定义系统供弹率、退弹率、总功率、寿命、通用质量特性等非功能性需求，并以参数图的形式完成需求追溯。

2.2 白盒视角分析

在黑盒视角完成舰炮储运系统的运行场景分析后，然后进入白盒视角分析储运系统内部功能，该阶段主要对储运系统黑盒分析过程中识别出来的每个功能进行深入分析，形成初步的逻辑功能块，该功能块和解决域的逻辑子系统相对应，也是概念子系统和逻辑子系统直接相关的地方^[8]。

以舰炮储运系统“转运弹药”功能（图示中的功能3）为例，以泳道表示各功能单元，采用活动图对用例场景连续细化，将功能分解至第二层，其活动如图6所示，其中功能单元1～功能单元4为储运系统的功能单元架构。

通过白盒场景完成目标系统的二级功能分解，舰炮储运系统的子系统功能架构便得到了识别，并执行储运系统的所有黑盒的预期功能，自此，白盒的功能分析结束，储运系统的概念功能架构完成，该阶段对应的模型域主要为功能模型。

3 舰炮储运系统解决域逻辑架构

通过问题域白盒和黑盒分析，舰炮储运系统的顶层需求转化为基于逻辑视图的系统需求，该需求对应于TBSE方法的装备研制设计输入文档，每个系统需求都由特定的顶层需求派生，并细化为问题域黑盒和白盒的多个SysML模型元素，该阶段通过逻辑架构完成系统与子系统组成划分，形成一维逻辑模型并仿真分析，形成系统的逻辑模型。

3.1 系统组成

舰炮储运系统的逻辑子系统和白盒分析得到的逻辑功能单元为派生关系，决定了各逻辑子系统由哪个概念功能单元识别并创建，其系统组成如图7所示。

系统组成采用模块定义图表示，子系统采用块元素，接口（信号的输入和输出）采用接口块泛化的代理端口。由于舰炮储运系统的系统机理在该层颗粒度下仍较为抽象，因此应直接进入逻辑子系统层，待在子系统层级颗粒度下组成分析完成后，再分析整个储运系统的机理。

3.2 子系统组成

子系统需求继承装备系统需求，每一项需求细化上文系统组成阶段的模型元素，采用需求矩阵表示该追溯关系。在该阶段需要对系统组成的机械子系统1、气动子系统、控制子系统和机械子系统2分别架构并得到下一级组件。以识别出的控制子系统为例，该子系统下的组件用块表示，各接口采用泛化的代理端口。该子系统组成如图8所示。

子系统内部各个组件之间的交互采用内部模块图表示，有了该子系统组成并确定组件之间的通信后，可对该子系统的行为进行分析，控制分系统主要完成对其他系统的机构控制，该子系统机理可采用状态机图分析。

完成子系统逻辑架构后得到子系统组成，可继续对组件架构建模，对于组件级模型，可采用面向对象的Modelica等语言继建^[9]，这也是单学科和多学科系统仿真模型的数据延续。控制分系统的控制器组件级的模型如图9所示。

3.3 系统性能仿真分析

根据系统与子系统逻辑架构，形成舰炮储运系统的总体机理模型（见图10），该模型定义了所有部件及组件之间的满足所有需求的逻辑接口，在逻辑层主要用状态机分析或者多学科系统仿真，完成的舰炮储运系统的验证^[10]，其中控制逻辑子系统集成行为分析状态如图11所示。

3.4 系统需求追溯

MBSE主要解决的是各领域的需求，并在解决需求的过程中完成了系统架构，完成系统架构和机理分析，需要建立系统配置和系统需求之间的追溯关系，以保证实现所有的系统需求。系统需求与系统架构之间的满足追溯关系如图12所示。

解决方案域实现舰炮储运系统从零维到一维模型的转换，得到系统逻辑架构，该模型为储运系统集总参数联合仿真模型，通过系统级的仿真验证，完成系统机理的确认，并以此作为物理实现域的设计输入。

通过将传统系统工程在物理域的迭代验证转为在设计阶段数字域的迭代仿真，迭代速度可大幅加快，并通过功能与逻辑架构仿真验证，实现各阶段需求的层层追溯，可大幅提高研制效率，降低实物样机制造成本，实现“物理样机一次成功”。

4 舰炮储运系统物理实现域详细设计

在解决方案域得到了系统的逻辑模型，并对储运系统的底层机理完成验证和确认，在物理实现域，通过MBD（基于模型的定义）对系统进行详细设计。舰炮储运系统作为信息物理融合系统，信息域详细设计为控制子系统的代码生成，物理域为气动子系统、机械子系统1和机械子系统2的三维详细CAD设计。

解决域逻辑架构得到了机械子系统某执行机构逻辑Modelica模型（见图13），逻辑架构的BodyShape元件的参数主要为质量、惯量等，以BodyShape的物理参数和运动副关系，通过CAD软件对物理模型重构并进行详细设计，这样可完成逻辑到物理模型的转换，形成该机构的三维CAD设计模型（见图14），并完成舰炮储运系统的物理域详细设计。

信息域的控制子系统通过逻辑架构模型得到控制时序和控制算法模型，通过一维模型生成可执行C代码，在仿真机上开展系统试验测试，调整参数保证控制代码满足性能要求，将代码烧录至目标硬件，完成控制系统详细设计。

5 结　语

舰炮储运系统作为较为复杂的信息物理融合系统，若按照传统的基于文本的系统工程研制方法，研制全程会形成大量非结构化的冗余信息，该信息计算机无法处理，系统工程师和各设计师还需耗费大量的精力来保证文本信息一致性，同时，只有在实物样机综合试验后才能发现顶层需求与专业设计之间的错误，研制成本高，周期长。基于MBSE的连续验证方式实现了模型的一致性传递，保证了研制全程需求同步追溯。基于MBSE的舰炮武器装备正向研究方法，从问题域黑盒与白盒视角，解决方案域和物理实现域各个阶段分析储运系统的组成和机理，形成系统的逻辑模型，采用SysML图形化建模实现了设计全程脉络清晰，减少了大量重复性工作，大幅提高了舰炮装备研制效率。