# Towards a Flexible Smart Factory with a Dynamic Resource Orchestration
## 3 The Orchestrator
### Architecture of the Orchestrator
That way, a resource will be recognizable at the entry to any system in a plug-and-produce fashion. Nevertheless, the customer is provided with an additional modelling tool aimed at the specification of smart resources. The Resource Modeller (part of the Modelling Tools component, 3b) serves the system similarly to the Process Modeller. It allows a customer to alter the existing resource model--that is otherwise automatically generated in a plug-and-produce fashion--or to create a new one from scratch. The latter is used in cases when legacy or non-smart resources have to be described and specified within KB. The Resource Modeller enables detailed description and specification of these resources and their connectivity interfaces relevant for the orchestration, from the ground up. All the resources, capabilities, and constraints are paired with their digital entities, and consequently form a detailed factory resources model that can be exported to, or imported from KB. Resource Modeller also provides the basis for formal modelling of all resources, not depending on their type. Consequently, it is an essential component for providing use-case-specific resource additions to the factory topology, and for subsequent uniform treatment of resources. An example of the Resource Modeller usage applied to an industrial use-case is further described in Section 4. The process specification that is a result of the reasoning and modelling phase is used as an input for the Resource Matcher (5). The main function of this component is to carry out the multi-step matchmaking of the capabilities required by the production process and capabilities offered by the existing resources. On one side, there are required capabilities, constraints, acceptance, and completion criteria provided on the input. On the other side, there are available resources' specifications stored in KB. Based on the resources' offered capabilities, the Resources Matcher matches them to the processes and the required capabilities. The first step of this matching process results in a set of possible production processes with already allocated resources. These are structured as a set of directed graphs in which each graph represents an individual process--practically a variety of production process specifications. The matchmaking continues with the enrichment of the previously generated production processes. The production process variations are expanded in a sequence of enrichers. The resource level enrichment comprises the preparation of a product order, in which additional production steps are inferred based on the physical organisation of available resources and the factory topology. Based on the same topology, the logistic enrichment additionally adds logistic steps to complete the material flow among the resources during the production process. The result of this step, and an output of the Resource Matcher component, is another set of directed graphs, in which each graph now represents an enriched variation of a process specification. The Production Scheduler (6) is one of the most complex components in the system, as it is inputted with a formed graph of all feasible process specifications matched with resources and offered capabilities, process steps, and material allocations. To deal with the complexity of scheduling, it is common and expected to apply certain restrictions and assumptions on several levels. Additionally, the datasets and objectives are large, so no optimal computation of the schedule could be calculated as it would require infinite time. Here, the Production Scheduler is based on a heuristic algorithm that leans on information already stored in KB. The algorithm takes into consideration assumptions and restrictions--i.e., regarding logistic steps, material allocation--which provides a (sub)optimal solution of process order. The infrastructure established here enables constant improvements of this component. It is possible to insert some use-case-specific algorithms and optimisation criteria for each domain in which the Orchestrator is applied.