## 4 Assessment
It must be noted that each critical situation must consider the execution states of all the actuators performing parallel operations. The minimal POUs of the control code, generated following the methodology presented in [48], are stored in a model-oriented database (see Figure 6). On the other hand, developers with AML-based editor design Flexible Automation Production System as a set of Production Services. They also specify the identified critical situations. Part of the complete model is presented in Figure 8.  
The application of the transformation rules generates the flexible automation project of each PLC in the system containing the POUs, data types and global variables related to the production services it can offer. The code includes the POU that manages the activation/de-activation of the Control Logic (CL), as wells as state serialization FBs. The different parts of the Production Services contained in the flexible automation project for controller 1 are presented in Figures 10 and 12. Concerning the application agents, the Flexible Automation Framework generates the corresponding AController_AASs (see example in Figure 15), APIant_AASs (see example in Figure 13) and their corresponding diagnosis files. As a result of the automatic code generation, the Flexible Automation Projects, as well as the AController_AAss, APIant_AASs and the diagnosis information files, are deployed into the controllers. The assessment process comprises the analysis of two different features: evaluation of the reconfiguration capabilities using a concrete example, and the scalability of the proposed approach. The assessment of reconfiguration capabilities consisted of the following: initially, there was a unique control system (controller 1) in charge of the execution of the automation control software of the three APlant_Assets. At a certain point, a second controller (controller 2) joined the system. Figure 16 illustrates the sequence of interactions between agents in the assessed scenario. The reconfiguration process is divided in three steps:  
* Step 1--QoS Loss Detection: Registration of controller 2 unbalances the system as its current workload is too low. When the workload monitoring of controller 2 detects it, the AController_AAS2 (CA2 in Figure 16) triggers an event to notify the QM (\"QoS_Loss_Event(lowerLimit_reach;CA2)\" in Figure 16), that eventually leads to Production System reconfiguration (\"QoS_Reconfiguration_Event (systemLoad;lowerLimit_recovery;CA2)\" in Figure 16). * Step 2--Diagnosis and Decision: The D&D receives the reconfiguration event and proceeds to initiate a negotiation among controllers to decide the new distribution. For simplicity, this negotiation process is encapsulated in the \"Workload Optimization Process\" block in Figure 16. The new distribution depends on the CPU factors of the AController_AASs (CA1 and CA2 in Figure 16), current distribution of the Production Services, and the CPU workload limits introduced by the Production Service software modules. When the negotiation concludes, the D&D launches the relocation of the Production Services). * Step 3--Reconfiguration: Relocation is represented by the \"for loop: PSs to be relocated\" in Figure 16, which consists of the following steps. Firstly, the D&D forces the APlant_AASs (PSAi.j in Figure 16) of the affected production service software modules to move to wait decision state (wait in Figure 13). Similarly, the D&D also forces the former active APlant_AAS to stop in the next non-critical situation of the control code (\"change_State(waitDecision;nonCriticalStop)\" in Figure 16). At this point, the D&D commands the execution of the production service software modules from the last known state in their new locations (\"change_State(active;direct)\" in Figure 16). After the reconfiguration process, the control software of station 1 and station 2 _PlantAssets_ are running in controller 1 and the control software of station 3 is running in controller 2.