Robot Modes, Heartbeats, and a Contradiction
An autonomous warehouse robot has modes IDLE, NAVIGATING, CHARGING, FAULT, and MANUAL. A safety requirement says: if the bumper is pressed while NAVIGATING, the robot shall enter FAULT within 100 ms and cut motor power. Charging decomposes into DOCKING, CHARGING, and BALANCING. Separately, the robot and fleet manager exchange nine message types; the robot sends a heartbeat every 500 ms, and after a link loss the reconnect handshake can retry for up to 3 s. The team has one state machine with 40 states and one sequence diagram with 60 messages. Review finds a contradiction: the state machine permits FAULT to CHARGING directly, while the sequence diagram requires fleet-manager acknowledgement before charging begins.
1. How should behavior be partitioned between the state machine and the sequence diagram? State which questions each model must answer and which details do not belong in each.
Read the worked answer
The state machine should answer 'what mode is the robot in, what events move it, and what actions run on entry and exit?' It owns IDLE, NAVIGATING, CHARGING with substates DOCKING, CHARGING, BALANCING, FAULT, and MANUAL, plus the safety transition and motor-power action. It should not enumerate message names or retry handshakes. The sequence diagram should answer 'in what order do robot and fleet manager exchange the nine messages, and what happens on heartbeat loss and reconnect?' It owns lifelines, message order, time constraints for the 500 ms heartbeat and 3 s handshake, and alt/loop fragments. It should not duplicate the mode model. Put shared events (for example, chargeAck) in an interface or signal definition referenced by both. This partition keeps each model small and reviewable, and it gives a clear authority for each question instead of two 40-state/60-message monsters that contradict each other.
2. Model the bumper safety rule with precise UML elements. Include the 100 ms constraint and the motor-power action, and explain why a simple transition labeled 'bumper pressed' is insufficient.
Read the worked answer
Use a transition from NAVIGATING to FAULT with trigger bumperPressed, effect cutMotorPower(), and a duration constraint {100 ms} on the transition (or a time constraint on the action). If the tool supports it, attach the constraint to the transition or to the effect. FAULT should have an entry action that latches the motor-off state, and the transition should be documented as a safety requirement with an ID. A simple label 'bumper pressed' is insufficient because it does not state the deadline, the action, or whether the transition is preemptible. UML can express the timing with a duration constraint or a time event; it cannot by itself prove the 100 ms, so pair the model with a test or analysis. Use a composite state if NAVIGATING has substates, but keep the safety transition at the outer level so it preempts substates. Also state what happens if the bumper is pressed in MANUAL or CHARGING.
3. The contradiction between FAULT to CHARGING and the acknowledgement requirement: which model is authoritative, and how do you reconcile them without duplicating rules?
Read the worked answer
The state machine is authoritative for which modes may follow which, but the sequence diagram is authoritative for the message order that establishes the acknowledgement. Reconcile by making the FAULT-to-CHARGING transition guarded, for example [chargeAckReceived], and define chargeAckReceived as the event raised by the sequence's handshake. Alternatively, remove the direct transition and route through a composite state whose entry requires the handshake. Do not duplicate the handshake rules inside the state machine; reference the interface operation or signal. Add a trace link from both models to the charging requirement. The contradiction is a modeling defect, not a reason to pick one diagram and delete the other. Review both against the requirement, then keep one rule in one place: mode legality in the state machine, message protocol in the sequence, with a shared event name and precondition.