模块 8：IBM Harmony
一种用例驱动、以架构为中心的方法，强调行为建模 — 以医用输液泵为贯穿案例。
Harmony 的起源
IBM Harmony（正式名称为 Harmony for Systems Engineering，简称 Harmony-SE）是由 IBM Rational 开发的一套 MBSE 方法论，主要基于 Bruce Powel Douglass 的工作。Douglass 是实时与嵌入式系统设计领域的多产作者，他将 Harmony 打造成一个实用的、以行为为核心的流程，可应用于从小型医疗设备到大型国防系统的各种项目。
从软件到系统
Harmony 最初作为软件工程流程 — Harmony for Software — 围绕 UML 和面向对象设计为实时嵌入式软件量身定制。IBM 认识到在系统层面同样需要这种严谨性，因此将该方法向上扩展为 Harmony-SE，使其适用于基于 SysML 的多学科系统设计。软件层和系统层的两个 Harmony 流程可以无缝衔接：Harmony-SE 产出系统架构，Harmony for Software 负责实现。
核心理念
Harmony 建立在两大支柱之上：
- 用例驱动：整个流程围绕用例组织 — 每个用例捕获系统与环境交互的一个场景。用例驱动功能、行为的识别，并最终驱动物理设计。
- 以架构为中心：健壮的系统架构在早期就开始形成，并持续精化。架构不是事后补充，而是所有分析和设计活动围绕的骨架。
Harmony 诞生于 IBM Rational 部门 — 同一部门还开发了 Rational Rhapsody，这是最广泛使用的 SysML/UML 建模工具之一。因此，Harmony 在历史上与 Rhapsody 紧密集成，但该方法论本身是工具无关的，可以使用任何支持 SysML 的工具来实践。
Harmony-SE 流程
Harmony-SE 将系统工程工作组织为三个主要阶段，每个阶段产出特定的模型制品，并为下一阶段提供输入。流程是迭代的 — 你可以从后续阶段回溯以完善早期工作 — 但总体流程从问题理解推进到方案设计。
阶段概览
| 阶段 | 关注点 | 关键制品 |
|---|---|---|
| 1. 需求分析 | 从用户视角理解系统必须做什么 | 用例图、用例描述、参与者定义、系统上下文图 |
| 2. 系统功能分析 | 分解系统内部如何运作以实现每个用例 | 活动图、序列图、状态机图、功能模块定义 |
| 3. 设计综合 | 将功能分配给物理子系统并定义接口 | 物理架构（BDD/IBD）、分配矩阵、接口定义、端口规格 |
表 1 — Harmony-SE 的三个阶段
阶段之间的流转
各阶段通过明确的交接相连：
- 需求分析 → 系统功能分析：第一阶段识别的每个用例都成为第二阶段的输入。针对每个用例，工程师创建活动图（分解功能）、序列图（探索交互场景）和状态机（捕获模态行为）。
- 系统功能分析 → 设计综合：第二阶段识别的功能和行为需要在第三阶段分配给物理组件。这是从功能（逻辑）世界到物理（设计）世界的关键转换。
Harmony 是行为优先的。与某些从结构开始（先定义子系统，再问"它们做什么？"）的方法论不同，Harmony 坚持在决定物理架构之前充分理解系统的行为。这对于安全关键和实时系统尤为重要，因为行为正确性是最优先的。
需求分析
Harmony-SE 的第一阶段聚焦于从用户和外部系统的视角捕获系统必须做什么。主要载体是用例 — 描述参与者与系统之间一次完整交互、并产生有意义结果的叙述。
识别参与者
参与者是系统边界之外与系统交互的任何实体，可以是人类用户、外部系统或物理环境。以我们的贯穿案例 — 医用输液泵 — 为例，关键参与者包括：
- 护士 — 主要操作者，负责对泵进行编程、启停输液，并响应报警。
- 患者 — 药物的接受者；泵必须检测影响患者的异常情况（如管路堵塞、管路进气）。
- 药房系统 — 一个外部 IT 系统，向泵提供药物库数据和剂量限值。
定义用例
每个用例描述一次以目标为导向的交互。输液泵的主要用例包括：
| 用例 | 主要参与者 | 描述 |
|---|---|---|
| 编程输液 | 护士 | 护士选择药物、设定输注速率和输注量，并确认程序。泵根据药物库进行验证。 |
| 输送药物 | 护士 / 患者 | 泵按设定速率输送药物，监控流量，并跟踪已输送量。 |
| 检测堵塞 | 患者（间接） | 泵检测到输液管路被阻塞（压力超过阈值），转换到报警状态。 |
| 触发报警 | 护士 | 泵产生声光报警，暂停输送，等待护士确认并处理异常。 |
表 2 — 医用输液泵的主要用例
系统边界
清晰的系统边界将系统内部（泵体硬件、固件、传感器、执行器）与系统外部（护士、患者、药房系统、医院网络）分隔开来。Harmony 要求在进行任何功能分解之前，在系统上下文图中明确画出这条边界。
可以把系统边界想象成一家餐厅的墙壁。墙壁内是厨房、服务员和设备 — 那就是你的系统。墙壁外是顾客（参与者），他们通过明确定义的接口（菜单、服务台）与系统交互。在设计厨房布局之前，你必须先知道墙壁在哪里。
系统功能分析
用例定义完成后，Harmony-SE 进入其最具特色的阶段：系统功能分析。在这个阶段，使用三种互补的图类型对系统行为进行详细建模。
活动图 — 功能分解
针对每个用例，活动图将高层功能分解为较小的子功能（动作），并通过控制流和数据流连接。对于"输送药物"，活动图可能分解为：验证程序 → 排气/充盈管路 → 启动泵电机 → 监控流速 → 跟踪已输送量 → 完成时停止。
序列图 — 交互场景
序列图捕获特定场景 — "正常路径"、异常路径和边界情况。它们展示系统内部功能模块与外部参与者之间按时间顺序的消息交换。对于输液泵，一个关键场景是堵塞检测序列：流量传感器检测到回压 → 控制器评估阈值 → 控制器命令泵停止 → 报警管理器激活报警 → 显示屏显示错误代码。
状态机图 — 模态行为
状态机捕获系统的模式和转换。输液泵的顶层状态机包括：
- 空闲（Idle） — 泵已开机但没有活跃的输液程序。
- 编程（Programming） — 护士正在输入输液参数。
- 输注（Infusing） — 药物按设定速率输送中。
- 暂停（Paused） — 输送暂时停止（护士手动暂停或自动保持）。
- 报警（Alarm） — 检测到故障条件；输送停止，报警激活。
状态之间的转换由事件触发：护士按下启动键（空闲 → 编程）、程序确认（编程 → 输注）、检测到堵塞（输注 → 报警）、护士确认报警（报警 → 暂停或空闲）。
行为建模对安全关键系统为何重要：在医疗设备、汽车和航空航天等领域，监管机构（如 FDA、EASA）要求有证据表明系统在所有模式下行为正确 — 包括故障模式。状态机使每一种可能的模式和每一次转换都显式化，不留下未分析的行为空间。这就是 Harmony 的行为优先理念特别适合安全关键开发的原因。
设计综合
设计综合是模型从"做什么"过渡到"怎么做"的阶段。系统功能分析中识别的功能和行为现在被分配到物理子系统，并正式定义子系统之间的接口。
将功能分配到物理子系统
分配是将每个逻辑功能指派给一个或多个物理组件的行为，通过分配矩阵或 SysML «allocate» 关系来捕获。对于输液泵：
- "输送药物"功能分配到三个物理子系统：泵机构（蠕动马达和转子）、流量传感器（超声波或滴计数传感器）和控制器板（运行控制算法的嵌入式处理器）。
- "触发报警"功能分配到报警扬声器、LED 指示面板和控制器板。
- "编程输液"功能分配到触摸屏显示器、键盘和控制器板。
定义接口
功能分配完成后，子系统之间的接口就变得清晰了。控制器板需要与泵机构通信（马达转速指令）、与流量传感器通信（流速读数）、与显示屏通信（UI 更新）。每个接口都定义了具体的信号类型、数据速率和协议 — 以 SysML 端口和流的形式捕获。
物理架构
设计综合的产出是物理架构 — 通常以 SysML 模块定义图（BDD）展示子系统层次结构，以内部模块图（IBD）展示子系统如何通过端口和连接器相连。这一架构成为硬件、软件和集成团队的工作规范。
从功能架构到物理架构的过渡通常是任何 MBSE 方法论中最具挑战性的步骤。Harmony 通过确保在分配开始之前功能模型足够完整来帮助解决这一问题。因为每个功能都已通过活动图、序列图和状态机进行了深入探索，工程师可以高度确信分配是完整的 — 没有功能被"遗弃"而没有物理归属。
三方框架对比
通过模块 6、7 和 8，你已经学习了三种最广泛采用的 MBSE 框架：OOSEM、MagicGrid 和 IBM Harmony。每种都有其独特的优势。下表提供了全面的对比，帮助你根据具体情况选择合适的框架。
| 维度 | OOSEM | MagicGrid | IBM Harmony |
|---|---|---|---|
| 主要驱动力 | 利益相关者需求和任务需求 | 按抽象层次和关注点组织模型 | 用例（参与者-系统交互） |
| 流程风格 | 全面的自顶向下生命周期流程（分析 → 设计 → 验证） | 矩阵引导：按抽象层次（问题域、方案域、实现域）和关注点（需求、行为、结构）填充单元格 | 三阶段线性流程：需求分析 → 功能分析 → 设计综合 |
| 行为强调程度 | 中等 — 行为是多个并行关注点之一 | 中等 — 行为占据矩阵的一列 | 强 — 行为建模是核心；功能分析是最详尽的阶段 |
| 模型组织方式 | 按流程阶段组织（利益相关者需求、系统需求、逻辑架构、物理架构） | 按 3×4 矩阵（或含参数化的 4×4 矩阵）组织；结构化程度高，易于导航 | 按用例组织 — 每个用例拥有自己的活动图、序列图和状态机图集 |
| 最适合 | 需要跨完整生命周期进行全面追溯的大型多学科项目 | 重视结构化、可导航模型和清晰关注点分离的团队；适合新建模人员入门 | 行为正确性至关重要的安全关键和实时系统（医疗、汽车、国防） |
| 学习曲线 | 陡峭 — 概念众多，流程范围广 | 中等 — 矩阵提供清晰的路线图；更容易定位"我在哪里？" | 中等 — 三阶段流程直观易懂；深入的行为建模需要练习 |
表 3 — Harmony vs. OOSEM vs. MagicGrid 对比
没有哪个框架是普遍"最好的"。许多组织会从多个框架中借鉴元素。核心结论是：
- Harmony 在需要行为优先严谨性时最强 — 特别适合具有复杂状态行为的安全关键系统。
- OOSEM 在需要全面的生命周期流程（从利益相关者分析到验证的完整覆盖）时最强。
- MagicGrid 在需要模型组织（清晰、可导航的结构，帮助大型团队保持一致）时最强。