## 2 Materials and Methods
### Flexible Automation Middleware (FAM)  
This subsection summarizes the agent-based middleware architecture for flexible automation production systems proposed by the authors in [26]. The general scenario is illustrated in Figure 4.  
FAM includes four agent types: two are part of the generic and basic architecture, whereas the other two are application dependent. Generic agents are able of managing different QoS:  
1. The _Middleware Manager (MM)_ is the main orchestrator. It is a unique agent in charge of managing the _System Repository (SR)_: a dynamic model that contains information about the current state of the automation application, which changes over time.
2. The _QoS Manager_ comprises a set of agents responsible for QoS fulfilment.  
Figure 4: General Scenario of the FAM (customization of [26]): the Middleware Manager and the QoS Manager (comprising the QoS Monitor Agent and the Diagnosis & Decision Agent) constitute the core of the middleware. The former is in charge of managing the execution and maintaining the state of Controllers and Plant AAS Agents. The latter is in charge of supervising the availability of the overall control system, detecting controller faults and, if possible, recovering the Plant AASs of the failed controller.  
Figure 3: Example of ProductionService to illustrate the concept of critical situation: the figure depicts the manufacturing sequence of a crane. The steps 42 to 44 are critical situations because the state of the system is uncertain during their execution (in case of failure there is no information about the exact position of the piece). Therefore, reconfiguration cannot be performed during such steps.  
_QoS Monitor (QM)_ agents are responsible for monitoring the specific QoS to be handled, generating triggers if they detect QoS losses. Hence, there are as many QMs as QoS to be met.  
_The Diagnosis & Decision (D&D)_ agent is unique in the system and it is responsible for launching diagnosis and decision algorithms as well as reconfiguration events.  
As commented above, the rest of agents in the system depend on the automation application. Applied to this work they implement both _Plant_AAS_ and _Controller_AAS_ assuring the availability. These agents guarantee the distributed intelligence, as their role is to collect information from the current state of the automation system as well as performing reconfiguration decided by the D&D:  
1. The _Plant_AAS Agent_ (APlant_AAS) manages the execution of the corresponding ProductionService's actions as well as collects, transmits, stores and makes diagnosis on the current state of this. The Component Manager of a APlant_AAS is implemented by a Finite State Machine that represents the possible states of the ProductionService lifecycle (detailed description can be found in [26]). Although each ProductionService can be replicated in a number of controllers, at runtime only one controller will be executing the ProductionService and its corresponding APlant_AAS will be in active state. For the rest of the controllers, the ProductionService is not executing and their corresponding APlant_AASs will be in tracking state.
2. The _Controller_AAS Agent_ (AController_AAS) registers its corresponding controller and the associated resources in the System Repository when the controller joins the system. It also registers itself in the Directory Facilitator of JADE offering as services the set of Productionervices that can run in the controller. Finally, it launches its corresponding APlant_AASs. There are as many AController_AAS as controllers in the system.