State Machine Semantics for an Infusion Pump with Delivery and Alarm Regions
A medical infusion pump model has a composite state Running with two orthogonal regions, Delivery and Alarm. Delivery has substates Priming, Delivering, and Paused; Delivering has a doActivity that starts a 5-second occlusion timer. Alarm has Normal and Alert. The team added an internal transition on Running for the event pause, expecting the pump to leave Delivering and enter Paused. A separate transition labeled resume is drawn from the Running composite state to itself. Testers report two defects: pausing does not stop the timer, and acknowledging an alarm while Paused logs the acknowledgement but does not resume delivery. The model is also expected to defer a calibration event until the pump returns to Idle, but the current model consumes it in Alert. The team has a review in three days and wants to know whether these are modeling errors or code-generator limitations.
1. Explain the semantics of an internal transition on a composite state and why it fails to produce the intended pause behavior.
Read the worked answer
An internal transition is triggered and executed without leaving the state; it does not fire exit or entry actions of that state and does not change the active substate. Placing pause as an internal transition on Running therefore cannot move the pump from Delivering to Paused. The doActivity in Delivering continues because Delivering is never exited, so the 5-second occlusion timer keeps running. That is correct UML semantics, not a generator defect. If pause should suspend delivery, model it as an external transition from Delivering to Paused, with exit behavior on Delivering that stops or suspends the timer and entry behavior on Paused that records the remaining time. If pause must also be accepted in Priming, define a separate transition or a transition from a composite state that explicitly targets Paused, and verify the target substate rather than assuming re-entry. The review should ask for a statechart table listing source state, trigger, guard, target, and entry/exit/do effects, because the diagram alone hides the internal-versus-external distinction.
2. Why does acknowledging an alarm in Paused fail to resume delivery, and how should the regions and transitions be restructured?
Read the worked answer
The resume transition is drawn from Running to itself, so when it fires it exits the composite state and re-enters it, which means re-entering the initial substate of Delivery, Priming, not returning to Paused or Delivering. Depending on the region's default, acknowledgment may therefore not restore the prior delivery state at all. The model also conflates alarm handling with delivery control: Alarm is orthogonal, so its Alert-to-Normal transition should not be responsible for resuming delivery. Restructure so that Alarm acknowledgment raises a condition or event, and a transition inside Delivery from Paused to Delivering has a guard such as alarmAcknowledged and occlusionCleared. Specify the history pseudostate if resuming the last delivery substate is required, and make the resume target explicit. Keep the regions independent: the Alarm region reports status, while Delivery decides whether delivery may continue. Add guards so that acknowledgment in Alert while the pump is Paused does not bypass safety checks such as the occlusion timer. This makes the behavior readable and testable.
3. What does deferring a calibration event require, and why is the current model consuming it in Alert?
Read the worked answer
A deferred event is listed as a deferrable trigger on a state; while that state is active, the event is not consumed or discarded but is retained and offered again when the state machine reaches a state where it is not deferred. Deferral is therefore a property of the active state configuration, not of the event globally. If calibration is consumed in Alert, either Alert does not list it as deferred and the event finds an enabled transition, or the model places the deferral on the wrong state, such as Running rather than the specific states that should hold it. The fix is to declare calibration as a deferrable trigger on the states where it must wait, for example Alert and Paused, and ensure no competing transition handles it there. Then define the handling transition in Idle. Verify the semantics with a test that sends calibration in Alert and asserts that no calibration action executes until Idle is entered. Add a statechart review checklist item for deferrable triggers, because they are invisible in many diagram renderings and are a common source of field defects.