水面舰艇作战系统是舰艇平台上用于执行警戒探测、指挥控制以及执行对目标交战的一类复杂系统^[1]。复杂系统的交付要求系统总体单位能够在规定的时间和规定的预算范围内完成符合一定质量要求的系统的设计和开发工作；而对于复杂系统的集成，即使是最详细的系统设计工作也弥补不了系统体系架构设计缺陷带来的先天性影响。近年来，软件在系统集成中得到广泛应用，系统集成的复杂性日益增强。在这一背景下，如何更快、更好地满足用户需求完成复杂系统的设计和集成工作，同时又能使系统具有良好的保障性是摆在系统设计师面前的一大难题。目前, 国外在应对这一挑战的最流行做法是利用基于模型的系统工程方法进行系统体系架构的设计和验证。

本文在对基于模型的系统工程方法的应用进行回顾的基础上，对水面舰艇作战系统中基于模型的系统工程方法的应用进行初步研究，并介绍本文具体实践使用的 Harmony 基于模型的系统工程方法，最后结合 Rhapsody 工具的使用对 Harmony 方法的具体应用进行详细说明。

国际系统工程委员会（INCOSE）在 2006 年 10 月发布的系统工程远景 2020 中，将基于模型的系统工程方法（以下简称“MBSE”）定义为^[2]：正式应用建模来支持系统需求、设计、分析、校核与验证，从概念设计阶段开始，在整个开发过程中以及后续寿命周期阶段继续运用。从 SysML 建模语言诞生以来，MBSE 逐渐浮出水面，成为人们研究软件密集型系统的一种热门方法。

通过建模解决工程问题具有如下优点：建模可以用来降低工程师手工劳动所花费的时间与精力，缩短设计周期；可以用来检验信息连续性与完整性，降低错误率，提高精确性；可以用来保留当前的工程结果，用于以后的维护、产品更新或产品更换工作；可以用来清楚地描述每一个符号与数字，并且意义确定唯一不具有二义性。模型能够确保在过程结束时所有必要信息都是有效的、正确的。当然，建模并不能代替创造性的工程思考与解决问题。

在基于模型的系统工程方法诞生之日起，美国国防部便开始了 MBSE 方法在国防系统体系架构开发中应用的研究，研究的结论是：DODAF 国防部体系架构框架只对开放系统架构的产品进行说明，但如何建模，使用什么样的语言和方法建模没有规定。国际上用于系统建模的各类建模语言有 IDEF、SysML、UML 等，其中 SysML 更加适合系统建模，可以用来设计符合 DODAF 规范的体系架构产品。对于方法的应用，有哈特利—皮尔布海（HP）方法、马丁方法等。IBM Rational 公司作为全球领先的 IT 技术及产品供应商，开发了一套集成系统与嵌入式实时开发流程 Harmony，这里我们称之为 Harmony 方法。该方法独立于工具之外，应用 SysML 为系统工程师提供了详细的、易于操作的流程指南。它从系统工程的视角出发，把系统的前期开发如系统工程的工作任务、责任范围，以工作流的方式，解剖的淋漓尽致，为系统的后续开发和系统的确认和验证，提供了无缝链接。

图 1 Rational 基于模型的嵌入式实时系统开发方法 Fig. 1 Rational model-based embedded real-time system development method

图 1 用典型的系统工程 V 模型展示了 Rational 集成系统/嵌入式软件开发流程^[3]-Harmony，V 模型的左边描述的是自顶向下的设计流，V 模型的右边展示了自底向上从单元测试到最终系统验收测试的集成各阶段。无论变更请求在哪个阶段出现，流程都将重新回到需求分析阶段。Harmony 流程包含 2 个子流程：Harmony/SE（系统工程）和 Harmony/ESW（嵌入式实时开发），本研究课题重点应用 Harmony/SE 流程，该流程是增量迭代的周期活动流。它由系统需求分析、功能分析和设计综合 3 个阶段构成，增量迭代是基于用例来完成的。

面向作战系统应用的基于模型的系统工程流程^[4] 如图 2 所示，该流程的主要目标是识别并推导出系统的功能，识别出相关的系统模式和状态，并把系统功能和模式/状态分配到相应的分系统中。

图 2 基于模型的系统架构开发流程 Fig. 2 Model-based system architecture development process

需求分析阶段的首要工作是分析得到系统工程流程的输入：海军用户需求。将涉众需求翻译成系统需求，系统需求是定义系统必须做什么（功能需求）以及如何执行好（服务需求的质量）。具体工作为将获得的用户需求进行收集整理，经过整理和分类的用户需求按照规范形成文档，导入到需求管理软件进行用户需求管理^[5]。对用户需求进行分析，分别定义环境与设计约束、定义运行与保障概念、定义效能指标，在充分理解了上述想定、边界、需求、目标之后，定义并推导系统功能与性能需求，这一过程一方面实现将定义好的功能和非功能性系统需求导入到需求管理软件进行管理。为了确保系统需求的完整性，并且满足用户及投资人的需求与规范，可以利用需求管理软件实现系统需求和用户需求的关联。

在需求分析中的下一个主要步骤是定义系统用例或者说是系统状态与模式，在作战系统设计中，我们可以将作战系统按照多任务的剖面对其进行用例划分，例如对空自防御任务、对海自防御任务以及对潜自防御任务等（见图 3）。为保证所有的功能性需求和相关的性能需求由这些用例所覆盖，跟踪性连接要分别对应建立起来，可以使用相应的系统建模工具进行。

图 3 多任务作战系统用例图（背景图） Fig. 3 Use Case Diagram (Context) for multi-mission combat system

系统功能分析阶段的主要重点是把系统功能需求描述成一个连贯的系统服务（业务操作）^[6]。分析是基于用例进行的，即：每一个由之前的需求分析阶段确认的用例翻译成一个可执行模型。该模型的基本需求将由模型的执行来验证。通常在需求分析阶段不对功能进行分解和设计，在功能分析阶段将对系统功能进行详细分析和分解并将最终经过功能分析确认的需求进行重新分解，功能分析阶段的成果是经过确认的功能阶段的用户需求以及可执行的功能分析模型。

功能分析模型由 3 个 SysML 图^[7] 来展现，而活动图、序列图和状态图。被称为黑盒用例的活动图，描述了用例整体功能流（故事板），以行动（相当于业务操作）的方式来组织功能需求，并显示这些行动是如何互相关联的。被称为黑盒用例的序列图，通过用例描述了一个特定的路径并定义了操作和角色之间的相互作用（信息或消息）。状态图把活动图和序列图的信息汇聚到了具有系统状态的背景当中，并增添了对不同优先级的外界激励而产生的系统行为，如图 4 所示。

图 4 功能分析阶段的对海战状态图 Fig. 4 State Chart Diagram for anti-surface use case in functional analysis step

设计综合阶段的重点是在所规定的作战系统反应时间、系统感知能力、系统打击能力、系统保障性等性能约束范围内，开发一个能够执行所需功能的具备一定能力的物理架构（如一组产品、系统或软件元素）。设计综合采用自顶向下的工作方法。设计综合阶段又分为 2 个大的分阶段，即架构分析和架构设计。架构分析也称为权衡分析^[8]，是针对一组满足于给定的功能和性能需求的分系统或设备配置方案，通过优化设计从中选取一个最优方案出来。优化设计是基于一套效能指标进行的，不同效能指标根据相对重要性进行加权，最终得出一个总体的效能指标，通过比较不同方案的总体效能指标从而得出最优解。架构设计阶段的重点是把功能性需求和非功能性需求分配到经过权衡分析得到的最优的系统架构中。这种分配过程是迭代式的，通常是通过与行业专家合作进行的。不同的分配策略可以进行分析，并带入对设计约束的考虑中，如在需求分析阶段所捕捉的性能需求、安全需求等。

根据对后续子系统开发交付要求，架构分析和架构设计阶段可以在架构分解的不同层次上重复进行。在最低层次，功能分配可以控制实现，即：哪些操作应该在硬件中实施，哪些操作应该在软件中实施。

详细架构设计阶段的重点是定义端口和接口，架构分解的最低层次系统模块基于状态行为。基于模型的系统工程方法设计的多任务作战系统内部框架如图 5 所示。

图 5 多任务作战系统内部框图 Fig. 5 IBD diagram for multi-mission combat system

本文所应用的方法已经在船载多用途任务系统研究项目中进行了实际应用。实践表明，基于模型的系统工程方法可以快速、有效指导作战系统进行体系架构的开发，具有流程清晰、逻辑严密等特点。需求管理工具和设计建模工具的应用，可有效减轻开发人员的重复劳动，辅助开发者对设计成果进行验证，对设计思路不断进行完善。此外，本文所提模型开发方法和工具主要针对系统的功能性开发进行了尝试，对于系统性能的分析和分配方法需要进一步深入研究。深入开展基于模型的系统工程方法的研究与实践，对于舰船作战系统设计、建设与维护来说有着十分重要的意义。