• a clear notion of progression and occurrence in the system
• explains the timeline of events
• could have been split into three, smaller diagrams, but these concepts are related to one another

Using the interface, the user will create a motion plan that will consist of a unique identification number (ID), and a series of individual movement commands (m1, m2, ...). Once created, the motion plan will be sent to the robot. How the robot stores the motion plan is beyond our system boundary, but it is assumed that it will do so. It could also be the robot will provide feedback to confirm the receipt of the motion plan, but there is no need to complicate the diagram by illustrating that.

The user will request that a specific motion plan be executed. The interface will direct that a specific motion plan entity be executed (hence why the interface doesn’t need to refer to a motion plan ID: it can refer to a specific entity). The interface will send an instruction to the robot to execute a specific motion plan ID. If the motion plan ID does not correspond to an ID currently stored in the robot, the robot will report an error, and that error message will be propagated to the user (of course, trying to execute a motion plan that isn’t stored on the robot is only one of many possible errors, but we chose to model this particular error to illustrate the timing of robot feedback). Otherwise, the motion plan will be carried out by the robot. This will take some time, as illustrated by the sloping arrow.

The user may request that a specific motion plan be deleted from the interface, and thereby the robot (if we assume concurrent deletion). The interface will refer to the motion plan directly to delete it, and a message will be passed to the robot to remove it from its system as well.