MBSE方法论之Harmony SE

1、Harmony概述

下图采用”V“模式显示了集成的基于模型的系统/嵌入式软件开发流程Harmony。左侧描述了自顶向下的设计流程，而右侧显示了自底而上的从单元测试到最终系统验收测试的集成过程。

基于模型的系统工程流程包括两个紧耦合的子进程：

• 1）基于模型的系统工程（Model Based Systems Engineering, MBSE）Harmony-SE
• 2）基于模型的嵌入式实时软件开发Harmony-ESW

2、Harmony-SE方法论

2.1、Harmony-SE概述

基于模型的系统工程Harmony-SE的关键目标是：

• 1）确认与导出所需的系统功能
• 2）确认相关的系统模式和状态
• 3）把已确认的系统功能和模式/状态分配到子系统结构

这些目标意味着采用自顶向下的高层抽象的建模方式。重点是在确认与分配所需的功能和基于状态的行为，而不是其功能行为的细节。下图描述了Harmony-SE的工作过程，以及每个过程主要的输入与输出。

2.2、Harmony-SE过程

2.2.1、需求分析

在需求工程阶段,重点是分析流程的输入，涉众需求被推导成系统需求：功能性需求、QoS需求(非功能性需求)。定义需求，建立可用需求库。当需求被充分理解后, 需求被组合成用例( use case)。

下图表示了Harmony-SE在需求工程阶段的工作流。

2.2.2、功能分析

在系统功能分析阶段,重点是将功能性需求转化为与其一致的系统功能(operations)，将需求阶段产生的每个用例转化为一个可执行的模型，目的是通过模型的执行来确认、验证和理解需求。这一阶段输出系统级别的ICD (Interface control document) 它定义了系统和外界的接口是以后黑盒测试阶段的重要输入基础。

下图展示了Harmony-SE的功能分析工作流。

• 1）定义用例上下文
• 用例上下文模型用Internal Block Diagram来定义，每个Block代表用例和相关的Actor，在此阶段，Block没有内容和外界关系。
• 2）定义黑盒活动图
• 用例工作流用黑盒活动图来定义，用Actions和它们之间的联系阐述系统功能需求。
• 3）生成黑盒时序图
• 用例场景从黑盒活动图推导而来，并用顺序图来描述，同时描述了系统的功能(operations/messages)，顺序图由活动图自动生成尽量不手动修改。
• 4）定义接口和端口
• 从黑盒顺序图中推导出Port/interface，其中包含了actor和用例之间的互动关系。
• 5）绘制黑盒状态机
• 用例状态行为用block的状态机来描述，状态机包含了活动图和顺序图的流程和交互信息，是功能分析阶段最重要的过程，状态机给出了系统的模式/状态的重要信息。
• 6）执行黑盒模型
• 通过状态机的执行来验证用例模型，按照黑盒顺序图(场景)确定输入激励。
• 7）扩展用例模型
• 出错情况处理将初始需求中没有描述到的“Rainy Day”在系统中表达出来，其过程为状态机修改->活动图修改->Block Diagram修改->顺序图记录。
• 8）连接功能点至需求
• 建立功能到需求的链接，可进行需求功能的覆盖率分析。
• 9）更新系统需求
• 如果在建模过程中出现了新需求或者更新/推导出新需求，系统需求文档(system Req. Spec.)要被更新。

2.2.3、设计综合

设计出能满足功能性和非功能性需求的架构，并指导软硬件的开发。下图显示了综合设计工作流。

• 1）估算架构模式
• 即找到一中最优的系统架构，首先定义关键子系统的功能，再为已找出的关键子系统功能找出多种候选方案，这时需要多领域专家共同合作完成。候选的方案须考虑前期已有的硬件/软件、商用硬件/软件以及现有开发经验。定义权横点，例如客户的条件、非功能性的限制以及成本，同时为它们赋权重。效能曲线(Utility Curve)用0—10之间的值来衡量每个权衡点的效能值(Measure of Effectiveness)，输入的值一般是基于设备的规格书 (spec.)或者基于相关计算。最后计算各个候选方案的效能值，作出决策。合并候选方案形成系统架构，每个关键子统功能的选中方案将合并形成系统架构最终的合并方案，这是基于整个架构的权衡分析(假设每个关键系统功能是独立的)，是后续的架构设计的基础。
• 2）定义白盒子结构
• 架构分解。
• 3）定义白盒活动图
• 分配系统功能到子系统(parts)，将系统功能(system operation)按用例去分配到白盒活动图。
• 4）分配非功能需求
• 将非功能性需求分解到子系统(parts)。
• 5）定义白盒顺序图
• 白盒顺序图可以从白盒活动图中推导出来。
• 6）定义接口和端口
• 子系统port/interface可从白盒顺序图推导而来。
• 7）定义子块状态机
• 子系统的状态行为可从子系统白盒顺序图和活动图中推导而来。
• 8）验证架构模型
• 主要是通过执行架构模型来验证架构模型。

2.3、系统工程的交付

在基于模型的开发中，系统工程所交付到后续系统开发的关键工件是可执行的基线模型。这个模型是个存储库，规格文档（即硬件/软件需求规格，控制接口文档…）可以从这个库中生成。交付的范围和内容取决于项目的特点和嵌入其中的系统工程组织结构。

如果被开发系统是一个特定的软件配置项（CI），系统工程可以停留在系统功能分析的水平。在这情况下，所交付的是可执行的用例模型。

从组织的角度来看，如果系统工程和子系统工程之间存在分割，系统工程可以停在第一层的系统架构分解。在这种情况下，所交付的是一组相关的子系统可执行模型。

如果系统工程师交付的规格直接面向硬件/软件开发，则交付的将是相应的可执行硬件和/或软件配置项（CI）的模型。

无论何种情况，交付内容应该包含以下方面：

• 1）基线化的可执行配置项模型
• 2）分配的配置项操作的定义（包括相关系统的功能与性能需求的链接）
• 3）配置项端口和逻辑接口的定义
• 4）状态图中表示的配置项行为的定义
• 5）测试场景，源自系统级用例场景
• 6）非功能性需求所分配的配置项

3、工具支持

目前支持Harmony-SE方法论的工具是IBM的Rhapsody软件，采用SysML作为建模语言。Rhapsody是市面上非常主流的一款MBSE建模软件，支持UML、SysML、UPDM等建模语言，支持模型的仿真验证。