# Towards a Flexible Smart Factory with a Dynamic Resource Orchestration
## 4 An Assembly Use-Case
The optionality of this execution is implicit and encapsulated within the element. The output of the previous process step is an input for the next one in the process flow, as seen in Figure 4, represented by a directed dashed line between the output element of _'Put Mainboard into the Case'_ and the input element of 'Customise Interface Layout'_. These output-input dependencies are depicted in the same fashion for the other process steps and sub-processes. The next process step is _'Put a case cover'_, which also requires the capability _'Assemble'_, with an uncovered controller on input, and covered controller on output. All used symbols are the same as already described and will not be repeated. The next three process steps--_'Inspect Device'_, _'Robust Tests'_, _'Hold Device'_--are to be performed simultaneously. The first two are directly dependant on, and cannot be executed without, the successful execution of the third one, as _'Hold Device'_ is started before and ends after the finalisation of the other two. This is depicted by two directed, dot-dashed lines marked with 'Start' and 'End', respectively. In the given example, 'Hold Device' marks the start, while 'Inspect Device' and 'Robust Tests' together mark the end for all three process steps. These three process steps are to be performed in collaboration with at least two allocated resources, as product inspection and product testing are carried out by separate resources, while one of the two can also hold the product being tested. This three-way execution of production is depicted with directed lines leading from and into rhombus noted with 'COL'. Listed production steps are also linked to corresponding capabilities (i.e., _'Test'_, _'Inspect'_, _'Hold'_), inputs and outputs--as previously described. Figure 4 depicts an example of a production process model of the assembling of Controller-A. The model example is created by using Multi-Level Production Process Modelling Language (MultiProLan) that is developed for production processes modelling, models of which are suitable for automatic generation of instructions [12]. Figure 4: Production process model, created in Process Modeller. Next to be executed is the sub-process '_Reassemble_'. It is an optional step and its execution depends on the output of the previously performed '_Inspect Device_' step. Unlike previously described in the case of '_Customise Interface Layout_', the optionality is here explicit and is depicted by lines directed from and into the rhombus decision element noted with the 'DEC' mark. Finally, the last sub-process to be executed is '_Packaging_'. Input for the packaging is either a checked or a reassembled controller, and the output is a ready-to-deliver Controller-A. Both '_Reassemble_' and '_Packaging_' encapsulate a more complex structure consisting of the previously described elements. As seen in Figure 4, colours are also used for semantic enrichment of the diagrams, i.e., Process step rectangles are green; Inputs and Outputs are of various shades of blue. This is only a brief description of the Process Modeller and the MultiProLan modelling language used here, as they are the focus of previously published papers [12; 13]. After the input of a modelled production process, the order is placed and the Orchestration Agent (2) initiates the Orchestrator mechanisms upon which the desired product is being processed. The Process Reasoner (3a) uses the necessary information and data specification of the previously generated production process to deduce all the production steps according to the factory-specific topology and the use-case. The semantic information stored in KB (4) is used by the Resource Matcher (5) to match the existing Resources (9) and their offered capabilities and capability related constraints, with the capabilities requested by the production process specification and previously deduced production steps. Any desired product is to be assembled out of parts available on the shop floor, using the resources specified in the KB and without any additional programming.