# Towards a Flexible Smart Factory with a Dynamic Resource Orchestration
## 3 The Orchestrator
### Architecture of the Orchestrator  
The Architecture of the Orchestrator described in this Section is a resulting artefact of Step III of the DSR methodology described in Section 2. Architectural elements of the Orchestrator are presented in Figure 2. Differentiated here are the internal, core infrastructure components--enclosed within the dashed-line rectangle--and external components, that are more oriented towards users of the Orchestrator. Users of the system are not only the end-customers but also plant managers, process engineers and quality engineers, among others. The plant manager specifies the factory's shop floor model and oversees the production, while process and quality engineers specify process models. On one side, the Orchestrator can be seen as a self-contained black-box. For end-customers, the output of the black-box is the desired product, the specification of which is given as an input to the system, while the entire production system is self-orchestrated in the background. On the other side, several elements of the Orchestrator are pluggable, to provide process and quality engineers with the possibility of adapting the solution to various use-case or even factory-specific requirements, e.g., the user interface. The plus symbols in Figure 2 denote these pluggable elements. The full red line depicts the orchestration 'Happy flow' (i.e., 'Happy path'), which is a default orchestration scenario that follows the numbered elements. The outset is the user interface (number 1) and the closure is the execution of production using available Resources (number 9) without experiencing any error states or unexpected behaviour. Other elements, although not numbered, contribute to the integrity and completeness of the solution. Description of other orchestration scenarios goes beyond the scope of this paper. The overall architecture of the presented system is modular and is implemented as a set of software components packaged within Docker containers. Every software component is a software agent. Each respective entity has some intelligence attached to the software components, enabling the realisation of a modular, smart, and pluggable software infrastructure. The high scalability of the system and running on cross-platform with minimum time to set up is allowed by introducing de-coupled containers. They are started, stopped, and run in multiple instances independently and can be seen as isolated and complete micro-services. These containers are run and instantiated on-demand, depending on a multitude of factors such as the load on the existing container instances or the number of concurrent requests. Figure 2: Architecture of the Orchestrator with the denoted ‘Happy flow’. The entry point of the system is the Customer Interface (1). It is structured in a way that supports the development of flexible ways to interact with the complete production facility. This is one of the components suitable for factory-specific or user-specific adjustments. Its pluggable fashion enables a customer to express an individually customised product in various input formats, depending on the particular use-case. These inputs are later converted into a more generic product model or even a standardised digital product-specification (such as Computer-Aided Manufacturing (CAM) or Computer-Aided Design (CAD) models). An individual customer-defined product specification is simultaneously an input for the Orchestration Agent (2) and an order for the Orchestrator system. The Orchestration Agent is a principal component in charge of all other processes inside the Orchestrator. An agent can be seen as a state machine that runs each user's product order through various states--from matching to execution--to create the desired product. For each new order, a new Order Agent is instantiated and resides in the Orchestration Agent that stores the current state of the actor's state machine.