Module 8: IBM Harmony
A use-case-driven, architecture-centric approach with strong behaviour emphasis — with a running medical infusion pump example.
Prerequisite: MBSE Module 7 — MagicGrid
Harmony Origins
IBM Harmony (formally known as Harmony for Systems Engineering, or Harmony-SE) is an MBSE methodology developed at IBM Rational, based primarily on the work of Bruce Powel Douglass. Douglass, a prolific author on real-time and embedded systems design, shaped Harmony into a practical, behaviour-focused process that could be applied from small medical devices to large defence systems.
From software to systems
Harmony originally began as a software engineering process — Harmony for Software — tailored around UML and object-oriented design for real-time embedded software. Recognising that the same rigour was needed at the systems level, IBM extended the method upward into Harmony-SE, adapting it for multi-discipline system design using SysML. The two layers (software and systems) are designed to work together seamlessly: Harmony-SE produces the system architecture that Harmony for Software then implements.
Core philosophy
Harmony is built on two pillars:
- Use-case-driven: The entire process is organised around use cases — each use case captures a scenario of how the system interacts with its environment. Use cases drive the identification of functions, behaviours, and ultimately the physical design.
- Architecture-centric: A robust system architecture emerges early and is continuously refined. The architecture is not an afterthought; it is the backbone around which all analysis and design activities are organised.
Harmony was developed inside IBM Rational — the same division that produced Rational Rhapsody, one of the most widely used SysML/UML modelling tools. As a result, Harmony has historically been tightly integrated with Rhapsody, although the methodology itself is tool-agnostic and can be practised with any SysML-capable tool.
The Harmony-SE Process
Harmony-SE organises the systems engineering effort into three main phases, each producing specific model artifacts that feed the next. The process is iterative — you may loop back from later phases to refine earlier work — but the overall flow moves from problem understanding to solution design.
Phase overview
| Phase | Focus | Key Artifacts |
|---|---|---|
| 1. Requirements Analysis | Understanding what the system must do from the users' perspective | Use case diagrams, use case descriptions, actor definitions, system context diagram |
| 2. System Functional Analysis | Decomposing how the system behaves internally to fulfil each use case | Activity diagrams, sequence diagrams, state machine diagrams, functional block definitions |
| 3. Design Synthesis | Allocating functions to physical subsystems and defining interfaces | Physical architecture (BDD/IBD), allocation matrices, interface definitions, port specifications |
Table 1 — The three phases of Harmony-SE
Flow between phases
The phases are connected by clear handoffs:
- Requirements Analysis → System Functional Analysis: Each use case identified in Phase 1 becomes the input to Phase 2. For every use case, engineers create activity diagrams (to decompose the function), sequence diagrams (to explore interaction scenarios), and state machines (to capture modal behaviour).
- System Functional Analysis → Design Synthesis: The functions and behaviours identified in Phase 2 must be allocated to physical components in Phase 3. This is the critical transition from the functional (logical) world to the physical (design) world.
Harmony is behaviour-first. Unlike some methodologies that start with structure (defining subsystems and then asking "what do they do?"), Harmony insists on fully understanding the system's behaviour before deciding on the physical architecture. This is particularly valuable for safety-critical and real-time systems, where behavioural correctness is paramount.
Requirements Analysis
The first phase of Harmony-SE focuses on capturing what the system must do from the perspective of its users and external systems. The primary vehicle is the use case — a narrative of a complete interaction between an actor and the system that delivers a meaningful result.
Identifying actors
An actor is any entity outside the system boundary that interacts with the system. Actors can be human users, external systems, or even the physical environment. For our running example — a medical infusion pump — the key actors are:
- Nurse — the primary operator who programmes the pump, starts/stops infusions, and responds to alarms.
- Patient — the recipient of the medication; the pump must detect conditions that affect the patient (e.g. occlusion, air-in-line).
- Pharmacy System — an external IT system that supplies drug library data and dosage limits to the pump.
Defining use cases
Each use case describes a goal-oriented interaction. For the infusion pump, the primary use cases include:
| Use Case | Primary Actor | Description |
|---|---|---|
| Programme Infusion | Nurse | The nurse selects a drug, sets the dose rate, volume to be infused, and confirms the programme. The pump validates against the drug library. |
| Deliver Medication | Nurse / Patient | The pump delivers medication at the programmed rate, monitors flow, and tracks volume delivered. |
| Detect Occlusion | Patient (indirect) | The pump detects that the IV line is blocked (pressure exceeds threshold) and transitions to an alarm state. |
| Raise Alarm | Nurse | The pump generates audible and visual alarms, pauses delivery, and waits for the nurse to acknowledge and resolve the condition. |
Table 2 — Primary use cases for the medical infusion pump
System boundary
A clear system boundary separates what is inside the system (the pump hardware, firmware, sensors, actuators) from what is outside (the nurse, patient, pharmacy system, hospital network). Harmony insists on drawing this boundary explicitly in a system context diagram before any functional decomposition begins.
Think of the system boundary like the walls of a restaurant. Inside the walls are the kitchen, waitstaff, and equipment — that is your system. Outside are the customers (actors) who interact through well-defined interfaces (the menu, the service counter). You must know exactly where the walls are before you can design the kitchen layout.
System Functional Analysis
Once the use cases are defined, Harmony-SE moves into its most distinctive phase: System Functional Analysis. This is where the system's behaviour is modelled in detail using three complementary diagram types.
Activity diagrams — functional decomposition
For each use case, an activity diagram breaks the high-level function into smaller sub-functions (actions) connected by control and data flows. For "Deliver Medication," the activity diagram might decompose into: validate programme → prime line → start pump motor → monitor flow rate → track volume delivered → stop when complete.
Sequence diagrams — interaction scenarios
Sequence diagrams capture specific scenarios — the "happy path," error paths, and edge cases. They show the time-ordered exchange of messages between the system's internal functional blocks and external actors. For the infusion pump, a key scenario is the occlusion detection sequence: flow sensor detects back-pressure → controller evaluates threshold → controller commands pump stop → alarm manager activates alarm → display shows error code.
State machine diagrams — modal behaviour
State machines capture the system's modes and transitions. For the infusion pump, the top-level state machine is:
- Idle — pump is on but no programme is active.
- Programming — the nurse is entering infusion parameters.
- Infusing — medication is being delivered at the programmed rate.
- Paused — delivery is temporarily halted (nurse-initiated or automatic hold).
- Alarm — a fault condition has been detected; delivery is stopped and the alarm is active.
Transitions between states are triggered by events: nurse presses Start (Idle → Programming), programme confirmed (Programming → Infusing), occlusion detected (Infusing → Alarm), nurse acknowledges alarm (Alarm → Paused or Idle).
Why behaviour modelling matters for safety-critical systems: In domains like medical devices, automotive, and aerospace, regulators (e.g. the FDA, EASA) require evidence that the system behaves correctly in all modes — including failure modes. State machines make every possible mode and every transition explicit, leaving no room for unanalysed behaviour. This is why Harmony's behaviour-first philosophy is especially well suited to safety-critical development.
Design Synthesis
Design Synthesis is the phase where the model transitions from "what" the system does to "how" it does it. The functions and behaviours identified during System Functional Analysis are now allocated to physical subsystems, and the interfaces between those subsystems are formally defined.
Allocating functions to physical subsystems
Allocation is the act of assigning each logical function to one or more physical components. This is captured in an allocation matrix or through SysML «allocate» relationships. For the infusion pump:
- The "deliver medication" function allocates to three physical subsystems: the pump mechanism (peristaltic motor and rotor), the flow sensor (ultrasonic or drip-count sensor), and the controller board (embedded processor running the control algorithm).
- The "raise alarm" function allocates to the alarm speaker, LED indicator panel, and the controller board.
- The "programme infusion" function allocates to the touchscreen display, keypad, and controller board.
Defining interfaces
Once functions are allocated, the interfaces between subsystems become clear. The controller board must communicate with the pump mechanism (motor speed commands), the flow sensor (flow rate readings), and the display (UI updates). Each interface is defined with specific signal types, data rates, and protocols — captured as SysML ports and flows.
The physical architecture
The result of Design Synthesis is a physical architecture — typically represented as a SysML Block Definition Diagram (BDD) showing the subsystem hierarchy and an Internal Block Diagram (IBD) showing how subsystems are connected through ports and connectors. This architecture becomes the specification that hardware, software, and integration teams work from.
The transition from functional to physical architecture is often the most challenging step in any MBSE methodology. Harmony helps by ensuring that the functional model is thorough before allocation begins. Because every function has been explored through activity diagrams, sequence diagrams, and state machines, engineers have high confidence that the allocation is complete — no function is "orphaned" without a physical home.
Three-Way Comparison
With Modules 6, 7, and 8, you have now studied the three most widely adopted MBSE frameworks: OOSEM, MagicGrid, and IBM Harmony. Each has distinct strengths. The table below provides a comprehensive comparison to help you choose the right framework for your context.
| Dimension | OOSEM | MagicGrid | IBM Harmony |
|---|---|---|---|
| Primary Driver | Stakeholder needs and mission requirements | Model organisation by abstraction level and concern | Use cases (actor-system interactions) |
| Process Style | Comprehensive, top-down lifecycle process (analyse → design → verify) | Matrix-guided: fill cells by abstraction level (Problem, Solution, Implementation) and concern (Requirements, Behaviour, Structure) | Three-phase linear flow: Requirements Analysis → Functional Analysis → Design Synthesis |
| Behaviour Emphasis | Moderate — behaviour is one of several parallel concerns | Moderate — behaviour occupies one column of the grid | Strong — behaviour modelling is the centrepiece; functional analysis is the most elaborate phase |
| Model Organisation | Organised by process phase (stakeholder needs, requirements, logical arch., physical arch.) | Organised by a 3×4 matrix (or 4×4 with parametrics); highly structured and navigable | Organised by use case — each use case has its own set of activity, sequence, and state machine diagrams |
| Best For | Large-scale, multi-discipline programmes requiring comprehensive traceability across the full lifecycle | Teams that value a structured, navigable model and clear separation of concerns; good for onboarding new modellers | Safety-critical and real-time systems where behavioural correctness is paramount (medical, automotive, defence) |
| Learning Curve | Steep — many concepts and a broad process to master | Moderate — the grid provides a clear roadmap; easier to know "where am I?" | Moderate — the three-phase process is intuitive; deep behaviour modelling requires practice |
Table 3 — Harmony vs. OOSEM vs. MagicGrid comparison
No single framework is universally "best." Many organisations adapt elements from multiple frameworks. The key takeaway is:
- Harmony is strongest when you need behaviour-first rigour — especially for safety-critical systems with complex state-based behaviour.
- OOSEM is strongest when you need a comprehensive lifecycle process that covers everything from stakeholder analysis to verification.
- MagicGrid is strongest when you need model organisation — a clear, navigable structure that scales and helps large teams stay aligned.