# Sequence Planner: A Framework for Control of Intelligent Automation Systems
## 2 The Sequence Planner Control Framework
### Operation Planner
### Non-Determinism

Because the resources are modeled as non-deterministic transition systems, it is possible that there are multiple effects from a single state. This is useful to model alternatives. However, the operation planner does not branch on these but will always \"choose\" the best possible outcome whenever there are multiple possible outcomes of an operation. While it is possible to compute plans that take branching into account, this increases complexity as the planning problem essentially becomes a controller synthesis problem [32]. In SP, the strategy is to let the planner decide on the \"correct\" outcome, and instead replan upon encountering an unexpected result. \begin{table}
\begin{tabular}{l l l l l l} \hline step 1 & controllable & \(a_{t}\) & step 1 & controllable & \(a_{t}\) \\ step 2 & effect & \(a_{2}\) & step 2 & controllable & \(b_{t}\) \\ step 3 & controllable & \(b_{t}\) & step 3 & effect & \(a_{?}\) \\ step 4 & effect & \(b_{?}\) & step 4 & effect & \(b_{?}\) \\ \hline \end{tabular}
\end{table} 
Table 2: Transition reordering. In order to also capture the non-determinism in the decision variables, \"variants\" of operations are allowed, which are copies of the same operation but with different actions and goal states. When an operation that has a variant is executing, the goal of the transition planner is set to the disjunction of the operation variants' goals. For example, consider a sensor (_sens_;) that scans the color of a product, determining that the product is either red or green. An operation \"scan\" could exist in two variants, one with a goal predicate \(sens_{? }=red\) and an outcome that a decision variable is assigned \"red\" and one with a goal predicate \(sens_{? }=red\) and the outcome that a decision variable is assigned \"green\". The goal for the transition planner would then be \(sens_{? }=red\lor sens_{?}=green\). When \(sens_{? }\) receives one of the values, the decision variable is updated accordingly. This may trigger replanning of the operation planner if the \"correct\" outcome was not achieved. ## 3 Application to an Industrial Demonstrator

To validate the design, the described framework has been applied to an industrial demonstrator. This case has been described in previous publications [10; 20; 22], but an overview is given here. The demonstrator is located in a manufacturing facility for truck engines, and it concerns the assembly of several components onto the engine block. The challenge is in the way that the operator and a collaborative robot have to perform operations. Namely, the operations can be executed either by the robot, the human, or in a collaborative fashion. An extensive software library, motion planning and vision algorithms, as well as a wide variety of hardware are used to achieve this. A photo of the assembly system can be seen in Figure 9, where an operator and a collaborative robot place a cover plate onto the diesel engine. To tackle different tasks in the system, it was necessary to dedicate eight computers. These computers run software for the physical resources of the system such as the Universal Robots collaborative robot, the Mir100 autonomous mobile platform, the end-effector docking station, the nutrunner lifting system, the RFID reader and camera system, as well as the nutrunner tool itself, which can be operated both by the operator and the robot. When developing this industrial demonstrator, the main focus was on the robustness aspects of performing a collaborative engine assembly using machines and operators. Even if important aspects such as operator safety, performance, and real-time constraints were considered in this work, they were not the main focus while developing this demonstrator. Such important aspects will be addressed in future work, especially the safety of human operators.