## 3 Digital Twin Representation
### Processes and Tasks  
The business processes in our environment are modelled around an assembly process that requires a number of input parts and produces an output part. The actual assembly process can take place at the locations of specific workstations, where worker agents can manufacture one item at a time. For this purpose, the required input parts have to be transported to these locations by dedicated transportation agents. Below, Figure 4 visualises the task tree of the production process, modelled as a Petri Net [48].  
Figure 3: Visualisation of an example environment configuration. Displayed are the areas for storage of workpieces in light grey (left and right) and assembly (centre), that are partially enclosed by obstacles (walls). Additionally, a number of agents are shown (rectangles and circles with arrows indicating the orientation) and the edges and vertices of the navigation graph, that are used to support the agents’ navigation (darker grey circles and dashed lines).  
For the actual implementation, we distinguish the task types _idle_, _move-to_, _pick-up_, _put-down_, and _assemble_. Each of these tasks typically have an expected non-zero duration, which could actually be infinite, e.g., in case of deadlocks. Tasks of the types _pick-up_, _put-down_, and _assemble_ take the identifiers of the components that are supposed to be affected by the given action. In addition, tasks of type _move-to_ also specify the target coordinates. To simplify the visualisation, the model presented above does not include the transitional states that would reflect the associated action execution of the transitions _Transport_ and _Assembly_. Below, Figure 5 provides the actual model for these processes too.  
Preconditions for the execution of these processes is the ability of the agent to actually execute them, e.g.,  
* The availability of the specified parts in the vicinity of the agent is checked before task execution.  
Figure 4: Petri net reflecting the task structure for the manufacturing processes in an example application environment.  
Figure 5: Petri nets for the subprocesses in the environment.  
Only assembly agents are able to execute the _assemble_ action, while, on the other hand, only transportation agents can move. Assembly agents are modelled as being permanently stationary.
* The capability of an agent to carry one or many instances of a load item can be constrained arbitrarily. In our implementation, only one item of any kind can be picked up by a transportation agent. Assembly agents can pick up one item of each type for the execution of the assembly process.  
The task instances are created and persisted in the environment's DT and can then be assigned to agents for execution.  
A new task starts with the state _\"queued\"_ which means that it has been assigned to an agent and will be executed in the near future, probably at the _\"planned_start\"_ timestamp. When it is getting executed it changes its state to _\"started\"_. There should always be only one task for each agent in the _\"started\"_ state. After the execution, the task changes to the success-state if it was _\"successful\"_ or _\"failed\"_ if something goes wrong. It can also be cancelled by the user. For logging purposes, we store those tasks and assign them the _\"cancelled\"_ state.