State Machine for Infusion Pump Modes and Concurrent Watchdog
An infusion pump has modes Idle, Priming, Infusing, Paused, Alarm, and Standby. The team modeled the mode logic as an activity diagram with a loop and decision nodes. During review, a safety engineer notes that the model cannot answer whether Pause from Infusing stops the motor before or after the occlusion alarm is evaluated, and it does not show that Alarm can be entered from every active mode. The pump also runs a concurrent watchdog task that must reset when the main state changes. The model has 14 activities but no state machine. The team must update the behavior model before a hazard analysis workshop in two weeks. They want to know which behavior formalism to use, how to represent the concurrent watchdog, and how to link behavior to the pump's structure. The pump block already has ports for the motor, occlusion sensor, and alarm. The watchdog is implemented in a separate software task.
1. Which SysML behavior diagram should own the mode logic, and why is the activity diagram insufficient for the safety question?
Read the worked answer
Use a state machine for the mode logic. The safety question is about event order and state legality: from Infusing, a Pause event must trigger a transition whose effect stops the motor, and the occlusion alarm must be evaluated according to the state's do/entry behavior or guard. An activity diagram shows control flow and decisions, but it does not natively express 'which events are accepted in which state', transition priority, or entry/exit actions. A state machine can make the order explicit: an Infusing state with a do activity 'run motor', a transition on Pause with effect 'stop motor', and a separate transition to Alarm guarded by occlusion. The activity diagram can remain as a subordinate behavior for the infusion process, but the mode logic should be a state machine owned by or classifier behavior of the Pump block.
2. How should the concurrent watchdog and alarm entry from every active mode be modeled?
Read the worked answer
Model the watchdog as a concurrent region, not as an activity loop. Put the main modes inside a composite state 'Active' with substates Idle, Priming, Infusing, and Paused. Add an orthogonal region for the watchdog with states Running and Reset; a change of the main state triggers the reset event, or the watchdog region has a transition on a 'stateChanged' signal. This shows true concurrency: the watchdog runs while the main mode is active. For alarm entry from every active mode, put a transition from the composite 'Active' state to Alarm on the alarm event; this covers all substates without drawing six separate transitions. Use a history pseudo-state on return from Alarm if the pump must resume the prior mode. If the watchdog is implemented in a separate software task, also allocate the watchdog region or a separate Watchdog state machine to the WatchdogTask block.
3. How should behavior be linked to the pump's structure, and what allocation relationships would you use?
Read the worked answer
Link behavior to structure in two complementary ways. First, make the pump's state machine the classifier behavior of the Pump block (or an owned behavior), so every pump instance has that behavior. Second, use «allocate» dependencies from behavior elements (actions, states, or the watchdog state machine) to the structural blocks that execute them: motor stop to MotorController, occlusion evaluation to SensorProcessing, watchdog to WatchdogTask. Use ports and signals for the events exchanged between the pump and its environment. Do not use «satisfy» for behavior-to-structure allocation; «satisfy» is for design-to-requirement. Do not put all actions inside the Pump block if they are delegated to subsystems; allocation preserves the separation while keeping traceability.