## 2 Simulation-Based Digital Twin Framework  
### Architecture  
With the aim of covering the aforementioned gaps, a three-layered architecture for a DT of a previously developed distributed control system was proposed, as portrayed by Figure 1.  
The Distributed Control Layer (DCL) contains the demonstrator from [24], controlled by a fully working MAS capable of dynamically adapting its behaviour according to the production requirements and the available stations. The data model designed in [24] in order to abstract this MAS is presented in Figure 2.  
According to Figure 2, this data model describes four types of entities:  
Figure 1: Suggested three-layered architecture. * Conveyor--each conveyor, from conveyorA (entry) to conveyorF (exit), is able to carry one product at a time. * Resource--each resource is capable of adding/removing a product to/from the line or brushing it. A resource must be associated with one of the conveyors. * Skill--corresponds to each type of action performed by a resource. * Product--each product consumes different amounts and types of skills, i.e., products from type one consume one BrushUp, products from type two consume one BrushDown and products from type three consume one BrushUp and one BrushDown. More types can be easily added by editing the ontology. When launched, the MAS remains idle until a suitable production plan is introduced, by which time the first product is added to the conveyor network. The deployment of the remaining products happens periodically, after the entry conveyor's availability is ascertained. Whenever a product is removed from the line, the KPIs are updated. These events occur as many times as needed until the whole production plan has been processed. The Integration Layer (IL) is responsible for making the physical system's relevant information available to external applications. It contains a file, that plays the role of a database, where the demonstrator's current state and the remaining production plan are stored, and an Application Programming Interface (API), whose purpose is to interact with the database. For that, the latter provides two services which endure concurrent access. By sending a _GET_ request with no specific message, the API is instructed to return the production plan, after reading the file. On the other hand, through a _POST_ request, whose message body must contain the system's current state and the remaining production plan, one may ask the API to update the file. The first operation comes in handy before the insertion of a product, as it allows the client to check the next product's type, whereas the second is used whenever a product is added to the production line, changes position, its processing ends or when the production plan is first created. Finally, the Simulation Layer (SL) contains the digital model. So as to serve its purpose, a correct description of the system's initial state and the remaining production plan are required. This way, the model knows where to start simulating from and the type of products to be inserted afterwards. Additionally, the user is expected to configure the time interval between the insertion of two consecutive products and the delay associated with the consumption of each type of skill, according to the data model. Similarly to its physical twin, the digital model updates the KPIs whenever a product leaves the system, even though the simulation only ends upon the production plan's completion. Figure 2: Multi-Agent System’s data model. The interaction between all these modules is described in the cross-functional diagram from Figure 3.  
Although the authors could use any KPIs to develop and demonstrate the proposed approach's utilisation and performance, some constraints needed to be considered due to the system modelled. Since the demonstrator used for the research does not effectively produce or assemble a product, it is impossible to measure waste or quality values. Hence, only time-related KPIs could be used to evaluate the proposed research.