# Sequence Planner: A Framework for Control of Intelligent Automation Systems
## 2 The Sequence Planner Control Framework
### Intentions  
While the operations define interactions between resources via goal states and how they relate to the decision variables, _intentions_ model how to make the system do something useful. As an example, we will be using the door with the lock to secure a room where two autonomous roaming robots charge their batteries. The position of the robots is modeled as decision variables \(r_{1}\in outside,inside\) and \(r_{2}\in outside,inside\), where inside refers to being inside the room with the door. To define a task that locks both AGVs in the room, an intention is used. An intention defines a goal over the decision variables. In this case, we define a goal \(g\) as: \(g:=(dl\wedge r_{1}=inside\wedge r_{2}=inside)\).  
Definition 6: The intention \(k\) is defined as \(i_{k}=\langle p_{k},g_{k},\phi_{k},a_{k},s_{k}\rangle\), where \(p_{k}\) is a predicate over (all) the variables in the system, defining when the intention starts (automatically); \(g_{k}\) is a goal predicate defined over the decision variables; \(\phi_{k}\) is an optional LTL formula over the decision variables; \(a_{k}\) is a set of actions that can update (all) variables in the system, which are applied when the intention finishes; and \(s_{k}\in\{i,e,f\}\) is the state of the intention.  
The intentions are free to change the state of the system (\(a_{k}\)) in arbitrary ways upon finishing, in order to be able to create hard-coded state machines for deciding when each intention should be active. As the intentions exist on a high abstraction level, these state machines are generally quite small and can be managed manually. The planning problem can be constrained using the LTL formula \(\phi_{k}\), which allows for specifying, for example, sequencing constraints. We will come back to LTL in Section 2.6.  
Now, we would like to \"wire up\" the goal \(g\) we defined above to a button that calls the AGVs home. The button is a resource that has a measured state variable \(b_{?}\). We create an intention \(i\): \(\langle s_{i}=i\wedge b_{?},g,\phi_{i},s_{i}:=i,i\rangle\), i.e., it has a precondition that triggers on itself being in the initial state and the button being pressed, \(g\) is the goal predicate, it has an LTL formula \(\phi_{i}\) (defined later), it has a single action which resets the intention upon finishing (to be able to activate it immediately again), and its state is initially \(i\).  
It is easy to see how another operation for opening the door could be written, together with a similar intention, which could be wired up to a button \(b_{?}\). What happens when both buttons are pressed simultaneously? Since it is not possible to reach both locked and open at the same time, one of the intentions will fail. This is easily avoided by adding guard expressions to the intentions that forbids them from activating at the same time.  
The operation abstraction eliminates the need for reasoning about individual resource states. Details about whether the lock is initially locked or not, or whether the door is opened or closed or somewhere in between, can be kept out of the programming of the intentions. These details are instead off-loaded to the planning system.