# Towards a Flexible Smart Factory with a Dynamic Resource Orchestration
## 3 The Orchestrator
### Architecture of the Orchestrator
The Production Scheduleroutputs a sequence of resources assigned with operations and timing constraints, ready to be executed on the shop floor. The Communication Protocols (7) are a group of software components developed for each communication protocol, which oversees translating generic execution commands sent to a DT into instructions passed to the physical resources through an appropriate protocol. The Orchestrator automatically generates execution commands based on the semantic specification of resources in KB and generated production process specifications. The structure of execution commands inside the Orchestrator is common and shared among all resource types. However, every communication protocol acts as a resource proxy and is in charge of translating generic commands received from the Order Agent. The generic commands are translated into resource-specific commands that are to be executed, thus making this component the actual Orchestrator executor. Although the executor handles generic commands, different resources will communicate via various protocols and interfaces; the operator interacts via a human-machine interface (HMI) while machines communicate via standardised industrial interfaces. The Communication Protocols component of the Orchestrator is still very factory-specific and will continue to be so until a larger proportion of standardisation within 14.0 implementations is achieved. Together with the Communication Protocols, the Digital Twin (8) is an essential component in the chain of execution of the concrete production process steps. DT partially takes an executor role and oversees the final execution of commands. It is an interface between an individual Communication Protocol in the orchestration layer and a targeted resource in the physical layer of the system. The complete factory shop floor is faithfully mirrored in the DT, wherein each digital element reflects an actual resource that it is paired with and can communicate with. High-level information about resources is stored in KB and is used for matching. In addition to this, DT includes a dynamic store containing low-level data needed for the production scheduling and final steps of process execution. The last state stored in DT is a starting point used for scheduling. All this provides the possibility to utilise the DT as the simulation only, as well as to simultaneously execute the production process while visually presenting it. DT sends the appropriate command for each production process step. This command is then propagated to a targeted resource via a corresponding Communication Protocol. Resources (9) are all the assets involved in the production. In the described system, various types of resources--humans, robots, software agents, and machines--are all treated uniformly and are only differentiated by their capabilities, interactions, and interface specifications. Together they constitute a shop floor, upon which the production itself is being orchestrated and the assigned tasks executed. All the resources are modelled in a corresponding resource model included within KB. A human worker, the Q4.0, is modelled with its capabilities (i.e., inspect, analyse, turn) that are not necessarily different from robot capabilities (i.e., pick-and-place, drill, turn) but are differentiated by adequate constraints. Although robots and machines can operate with heavier loads or without fatigue, Operator 4.0 is considered to be the most flexible asset in SF [21]. Therefore, it is not strange that the biggest variety of capabilities and constraints are related to this resource type. Additionally, some competencies and man-machine interactions--e.g., operator and cobot collaboration--are unlikely going to be replaced by a single device, unless production is based entirely on Artificial Intelligence (AI). The communication between the Orchestrator components is established through an internal communication layer based on a highly scalable communication backbone. Intra-component communication is implemented through a broker-based messaging system.