## 2 Simulation-Based Digital Twin Framework
### Implementation
#### 2.2.1 The Simulation Model  
The digital model itself was developed using AnyLogic, a powerful and well-documented agent-based simulation tool. Firstly, two types of agents were created:  
* _Main_--includes all graphical and logical elements, responsible for ascertaining the model's correct behaviour until the final predictions are derived. * _Product_--abstracts a product and describes it through four parameters: _brushLp_ and _brushDoven_, that specify the type, and _entryTime_ and _exitTime_, where the respective timestamps are stored. Unlike the _Main_ type, there can be more than one instance per simulation. Figure 3: Cross-functional flowchart. Afterwards, the physical system was represented using Conveyors, Positions on Conveyors and Transfer Tables, available at the Space Markup category from the Material Handling Library. The result is shown in Figure 4.  
With the aim of controlling the model's overall behaviour, the blocks diagram represented in Figure 5 was designed. For that, the following elements from the Blocks category of the Material Handling Library were used:  
* Source--launches a new _Product_ instance. The blocks from _sourceA_ to _sourceF_ deploy a product on the respective conveyor after the initial state is read from the file, whereas the _source_ block launches the remaining products. * Conveyor Enter--is placed after a source block and establishes, through Position on Conveyor elements, the newly-created product's initial position. Figure 4: Conveyor network’s 2D view. Figure 5: Simulation model’s blocks diagram. * Queue--stacks products in case they cannot be immediately added to the conveyor network. * Hold--blocks the natural course of an agent. It ensures that all products, from the initial state, were added before the conveyors start moving. * Convey--settles the sequence of conveyors that constitute the network by defining each segment of the path. * Sink--works as the endpoint of the production line, where products are dispatched. However, the diagram is incapable of limiting the amount of simultaneous products per conveyor and emulating the delays associated with the processing stations. Thus, several events (one that controls the products' insertion and one for each conveyor's station), variables (control flags, statistics data, etc. ), parameters and functions had to be used jointly with some inbuilt methods, so as to model the aforementioned behavioural nuances. One such example is the _loadState_ function, the first to be invoked immediately after the simulation starts, which is responsible for placing the due products on the respective conveyors, according to the initial state described in the database file. Additionally, it computes the remaining processing time for every suitable product and accordingly schedules the corresponding station's event. Given that this method is only invoked at the beginning of the execution, the model is insensible to changes in the physical system's configuration during the simulation. For that reason, it is assumed that the stations' location remains unchanged throughout the entire execution. The _insertProduct_ method plays a similarly vital role. It is called whenever the insertion's event reaches the timeout condition, by which time a product is injected on the network, provided that the entry conveyor is empty. If otherwise, the insertion's event is called off because the next attempt is made as soon as conveyor A becomes available. Furthermore, some occurrences throughout the simulation require extra algorithms. For instance, a product's leading edge crossing a Position on Conveyor element symbolises the arrival at a station. For that reason, each of these elements had to be endowed with the algorithms below. According to Figure 6, when a product arrives at a conveyor with a station, the conveyor is stopped and an event that emulates the processing delay is scheduled. Even if otherwise, if the next conveyor is busy, the current one is equally stopped.