# Towards a Flexible Smart Factory with a Dynamic Resource Orchestration
## 4 An Assembly Use-Case
In the next phase, the Resource Matcher (5) first produces a production process variation in which it assigns resources to their dedicated production steps for the assembly of Controller-A, i.e., 'Operator2' is matched to execute '_Put mainboard into the case_' and '_Put a case cover_'; 'Cobot' and 'Operator1' are to execute the collaborated test and inspection; 'Operator1' is to perform the reassembly. The next phase carried out within the Resource Matcher component is the logistic enrichment, performed according to the information stored in KB; availability of the resources on the shop floor, the current topology of the resources (also seen in Figure 6), physical limitations of the collaboration between resources, etc. Upon this phase, material flow steps are deduced, which leads to the creation of additional production steps. In the concrete use-case, as seen in Figure 7, the inferred steps are '_Pick Device_' and '_Move to Inspection Bench_'. Either 'AGVI' or 'AGV2' will be assigned to perform them, consequently carrying the necessary production parts and the assembled product between the resources carrying out the assembly, inspection and packaging. This results in Resource Matcher not only offering a match for every production step described in the generated or created production process but also providing an optimal match for all the inferred logistic steps. Figure 6: The topology layer of the resource model. The Production Scheduler (6), as soon as the matching process has been performed, is to find an optimal schedule by analysing the execution order of all the matched production steps. The execution time and the uniform resource utilisation were the two optimisation criteria used for this use-case, intending to assemble a controller as quickly as possible while equally using all available resources. A completely orchestrated production process, the result of the matching and scheduling phase, can be reviewed on a detailed level in the Process Modeler. Figure 7 depicts only an extract of the enriched production process model created for the assembling of Controller-A, as seen in Figure 4. 'Cobot' is assigned to execute '_Hold Device_' and to simultaneously perform '_Robust Tests_', while 'Operator1' is performing '_Inspect Device_' in parallel. 'AssemblyRobot' will never be assigned to carry out the testing, although it is capable of it, as it cannot simultaneously hold the device targeted for testing. 'Operator1' and 'Operator2' are capable of performing the collaborated inspection, but 'Operator1' is a more experienced worker and will more likely be assigned for the testing unless he is already assigned for the '_Reassemble_' sub-process--as 'Operator2' is not capable of performing it. After the completion of the matching and scheduling phases, each command is propagated to the individually assigned resource via a dedicated Communication Protocol (7). Answering its main purpose, every Protocol translates the generic command into resource-specific commands for the execution. These proxies are leaning on the Digital Twin (8) component that is practically acting as an executor, by propagating factory-specific instructions to the designated resources. In the described use-case, commands for robots are sent via a bridge based on Robot Operating System (ROS) framework, while a tablet application is developed to serve the Operator as a communicator with SF, within which the Operator receives execution commands and confirms the status of the execution. Similar to what has been presented previously in [19], the simulation is created using a proprietary graphical editor in a way to resemble the real-life shop floor as much as possible. Additionally, the execution process can simultaneously be reviewed in the Process Modeler tool,  
Figure 7: An extract from the orchestrated production process model. thus acting as a secondary DT or a process monitoring tool.