Operational layer¶

The question this layer answers

Why does the device exist, for whom, and in what setting?

The operational layer models the work the device enters, before it names any part of the device. Its heart is four elements: the goal a user pursues (UseCase), the workflow that realises it, the scenarios that are paths through the workflow, and the actions those scenarios are made of. Everything else on this page supports those four.

The colours say which part of MEMO an element belongs to: blue is architecture, red is assurance. A solid line is one of MEMO's own relationships, a dashed line is native SysML, a diamond is containment, and a dotted line is a reference. How to read the figures

Building it up¶

Step 1 · The work¶

Start from the goal. A UseCase is a standard SysML use case: a goal held by an actor, with the system as its subject. An OperationalWorkflow is how the work toward that goal is organised, and it realises the use case (RealizesUseCase). Many workflows can realise one use case.

A workflow contains its scenarios (OperativeScenario): one nominal path, and alternate paths for exceptions and recovery, told apart by scenarioKind. Each scenario contains the actions (OperativeAction) it is made of, ordered natively with first … then, and an action can nest finer steps.

Step 2 · Who and why¶

A User pursues the use case as its native actor, and performs actions (perform). Who performs an action is a relationship, not a type, so an action can move from the user to the system without being remodelled.

The goal exists for reasons. A Need, from Requirements, motivates the use case (Motivates). Above it all, the IntendedUse is the device's declared purpose (IEC 62366-1, ISO 14971). It requires operational capabilities (OperationalCapability, via RequiresCapability), and each capability enables use cases (EnablesUseCase).

Step 3 · Where¶

A scenario happens in a UseContext: its care setting, its jurisdiction, and whether use is connected. The context is situated in a UseEnvironment, the physical and organisational environment (IEC 62366-1, 3.20). Keeping the two apart lets one environment serve several contexts.

Step 4 · Supporting detail¶

A workflow's decisions, forks, joins and handoffs are control nodes inside it (WorkflowControlNode). A TaskDifficultyAssessment records how demanding an action is in its context (AssessesDifficulty), which feeds the human-factors analysis.

Where it leads¶

Down to Functional: the functional layer answers this one. An action performs (perform) the function that carries it out, and functional steps refine operational actions (#refinement).
Across to assurance: a task is where a use error is committed (CommitsUseError, Human factors); risk items and threats play out in scenarios (HazardRelatedScenario, RealizedByScenario); and a validation case validates a use case or task (Validates, Verification and validation).

In the running example¶

In the temperature alarm, the ICU nurse is the user. Monitor patient temperature is the use case the nurse initiates, and acknowledge alarm is a high-criticality task inside the work of reviewing an alarm.

part icuNurse : User {
    attribute :>> actorKind = ActorKind::clinician;
    @MemoIdentity { :>> providedId = "TA-USR-001"; }
}
use case ucMonitorTemp : UseCase {
    attribute :>> useCaseKind = UseCaseKind::clinical;
    @MemoIdentity { :>> providedId = "TA-UC-001"; :>> label = "MonitorPatientTemperature"; }
    attribute :>> goalStatement = "Continuously monitor core temperature and be alerted when it leaves the safe range.";
    subject supportingSystem;
    actor icuNurseInitiator = icuNurse;
}
action actAcknowledgeAlarm : OperativeAction {
    @MemoIdentity { :>> providedId = "TA-ACT-001"; :>> label = "ReviewAndAcknowledgeAlarm"; }
    attribute :>> criticality = CriticalityKind::high;

    action taskAckAlarm : OperativeAction {
        attribute :>> criticality = CriticalityKind::high;
        @MemoIdentity { :>> providedId = "TA-TASK-001"; :>> label = "AcknowledgeTemperatureAlarm"; }
        attribute :>> taskGoal = "recognize, assess, and acknowledge the alarm";
        attribute :>> potentialHarm = "delayed intervention for hypo-/hyperthermia";
        attribute :>> severityIfFailed = SeverityKind::serious;

The GPCA infusion pump shows the full shape: a workflow such as manage active therapy contains a nominal scenario and alternates such as bolus request during lockout. Read it layer by layer.

Every element and relationship in this layer (generated from src/architecture/operational/)

Elements¶

Activities

Element	SysML kind	What it is
`OperativeAction`	`action def`	Operative action definition specializing `MemoAction`.
`TaskDifficultyAssessment`	`part def`	Difficulty of a task in a particular context (§17). Associated by typed references, not inheritance; assessments are evidence-bearing.

Context

Element	SysML kind	What it is
`OperationalParticipant` (abstract)	`part def`	Operational participant definition specializing `MemoPart`.
`User`	`part def`	A human who interacts with the medical device (IEC 62366-1 intended user). User is the only human actor type: do not add an alternative type name. The human actor.…
`ArchitectureDescription`	`part def`	Architecture description definition specializing `MemoPart`.
`ModelKind`	`part def`	Model definition specializing `MemoPart`.
`CorrespondenceRule`	`part def`	Correspondence rule definition specializing `MemoPart`.
`UseContext`	`part def`	Use context definition specializing `MemoPart`.
`UseEnvironment`	`part def`	The physical/organizational environment of use (IEC 62366-1 3.20), separable from the care-setting context so environments are reusable.

Scenarios

Element	SysML kind	What it is
`OperativeScenario`	`action def`	A scenario is a `MemoConstrainedOccurrence`: it carries the native `precondition` and `postcondition` constraints a function does, redefined with an expression (`constraint :>> precondition { level >= 0 }`).…

Structure

Element	SysML kind	What it is
`IntendedUse`	`requirement def`	Intended use definition specializing `MemoMission`.
`OperationalEntity`	`part def`	Operational entity definition specializing `MemoPart`.
`OperationalCapability`	`part def`	Operational capability definition specializing `MemoPart`.

Use cases

Element	SysML kind	What it is
`UseCase`	`use case def`	Use case definition specializing `MemoUseCase`.

Workflows

Element	SysML kind	What it is
`OperationalWorkflow`	`action def`	Operational workflow definition specializing `MemoAction`.
`WorkflowControlNode`	`action def`	A workflow control node. The role is given by controlKind; the kind-specific fields below are set only for the relevant controlKind. handoff = transfer of responsibility between roles (shift change, room-to-lab).
`WorkflowResource`	`part def`	Resources a workflow requires: information, materials, or equipment by reference.

Connections at a glance¶

Each arrow is one relationship, from its source end to its target end. A grey box belongs to another layer.

flowchart LR
  TaskDifficultyAssessment["TaskDifficultyAssessment"]
  OperativeAction["OperativeAction"]
  anyElement["any element"]:::other
  MemoPart["MemoPart"]:::other
  UseContext["UseContext"]
  UseEnvironment["UseEnvironment"]
  IntendedUse["IntendedUse"]
  OperationalCapability["OperationalCapability"]
  UseCase["UseCase"]
  Need["Need"]:::other
  OperationalWorkflow["OperationalWorkflow"]
  MemoAction["MemoAction"]:::other
  InteractionFlow["InteractionFlow"]:::other
  RequirementDriver["RequirementDriver"]:::other
  OperativeScenario["OperativeScenario"]
  UseError["UseError"]:::other
  MemoEvidence["MemoEvidence"]:::other
  MemoNeed["MemoNeed"]:::other
  OperationalParticipant["OperationalParticipant"]
  RiskItem["RiskItem"]:::other
  TaskDifficultyAssessment -->|AssessesDifficulty| OperativeAction
  anyElement -->|Governs| MemoPart
  MemoPart -->|InteractsInContext| anyElement
  UseContext -->|AppliesInContext| MemoPart
  UseContext -->|SituatedIn| UseEnvironment
  IntendedUse -->|RequiresCapability| OperationalCapability
  OperationalCapability -->|EnablesUseCase| UseCase
  Need -->|Motivates| UseCase
  OperationalWorkflow -->|RealizesUseCase| UseCase
  MemoAction -->|Transforms| MemoAction
  InteractionFlow -->|FlowServesUseCase| UseCase
  RequirementDriver -->|RealizedByScenario| OperativeScenario
  OperativeAction -->|CommitsUseError| UseError
  MemoEvidence -->|EvaluatesTask| OperativeAction
  MemoNeed -->|HeldBy| OperationalParticipant
  RiskItem -->|HazardRelatedScenario| OperativeScenario
  classDef other fill:#eef1f4,stroke:#9aa7b2,color:#4a5a66

Relationships declared here¶

Relationship	From	To	What it says
`AssessesDifficulty`	`TaskDifficultyAssessment`	`OperativeAction`	Typed relationship from `TaskDifficultyAssessment` to `OperativeAction`.
`Governs`	any element	`MemoPart`	Typed relationship from `any element` to `MemoPart`.
`InteractsInContext`	`MemoPart`	any element	The single relation a system context view draws. A context diagram labels its edges with open-ended verbs — "directs procedure", "electrical power", "fluid supply", "environmental conditions".…
`AppliesInContext`	`UseContext`	`MemoPart`	Typed relationship from `UseContext` to `MemoPart`.
`SituatedIn`	`UseContext`	`UseEnvironment`	Typed relationship from `UseContext` to `UseEnvironment`.
`RequiresCapability`	`IntendedUse`	`OperationalCapability`	The intended use requires these operational capabilities (ARCADIA: Mission Requires Capability).
`EnablesUseCase`	`OperationalCapability`	`UseCase`	An operational capability enables a use case (the ability the actor draws on to accomplish the goal). Capability is tied to the use case, not to individual activities.
`Motivates`	`Need`	`UseCase`	Typed relationship from `Need` to `UseCase`.
`RealizesUseCase`	`OperationalWorkflow`	`UseCase`	The use case a workflow realizes. Many workflows may trace to one use case; the use case does not own its workflows (the trace points upward, workflow → use case).
`Transforms`	`MemoAction`	`MemoAction`	Typed relationship from `MemoAction` to `MemoAction`.

Relationships from elsewhere that reach this layer¶

Relationship	Declared in	From	To	What it says
`FlowServesUseCase`	implementation	`InteractionFlow`	`UseCase`	Typed relationship from `InteractionFlow` to `UseCase`.
`RealizedByScenario`	cybersecurity	`RequirementDriver`	`OperativeScenario`	Typed relationship from `RequirementDriver` to `OperativeScenario`.
`CommitsUseError`	human-factors	`OperativeAction`	`UseError`	Typed relationship from `OperativeAction` to `UseError`.
`EvaluatesTask`	human-factors	`MemoEvidence`	`OperativeAction`	Typed relationship from `MemoEvidence` to `OperativeAction`.
`HeldBy`	requirements	`MemoNeed`	`OperationalParticipant`	Whose need this is. The holder is a modelled participant — a User, with the profile IEC 62366-1 asks for, or another operational participant — so "which users does this need serve" is a question the model answers rather than a sentence a reader interprets.
`HazardRelatedScenario`	safety-risk	`RiskItem`	`OperativeScenario`	Typed relationship from `RiskItem` to `OperativeScenario`.

Enumerations¶

Enumeration	Values
`DemandLevelKind`	`minimal`, `low`, `moderate`, `high`, `extreme`
`GovernKind`	`correspondence`
`ScenarioKind`	`nominal`, `alternate`
`UseCaseKind`	`clinical`, `service`, `manufacturing`, `development`
`WorkflowStateKind`	`asIs`, `toBe`, `contingency`, `deprecated`
`StepTransformationKind`	`preserves`, `automates`, `augments`, `eliminates`
`ControlNodeKind`	`decision`, `handoff`
`TransformKind`	`step`, `workflow`, `replacesWorkflow`