## 6 Evaluation
### Discussion  
Analyzing the overhead, latency and resource consumption, we can conclude that the adaptation of the security policies to the contexts has an extra cost (especially in tiny devices like sensors), but in return, we obtain secure applications optimized for the different situations. This implies that the applications will be more secure and will consume only the necessary resources. Nevertheless, in cases of critical situations, such as emergency scenarios, where the time response has to be very short at a certain moment, the reconfiguration must be postponed if and when the instantiating of the adapted security policies would not be strictly necessary for the correct functioning of the system. Therefore, in these cases, we must avoid the reconfiguration if it is only being done for the optimization of the security, especially if this reconfiguration implies having to self-adapt many devices and takes a long time. We therefore need to realize some trade-offs, taking into account the expected response time, the security needs and the reconfiguration overhead, to decide when the reconfiguration must be carried out.  
On the other hand, using [EMAIL_ADDRESS], the product running in each device corresponds to the resolved model that satisfies each context. Then, as we have generated them, respecting the constraints between the variable elements, we can ensure that the global system enters a valid state after the reconfiguration. Furthermore, as FamiWare defines the dependencies between the different sensor nodes as constraints between clones in the variability model, the running product after the reconfiguration maintains the compatibility between the devices. Nonetheless, the only models that are loaded in the sensors and sent over the network are the reconfiguration plans that consist of small files (around 500 bytes), twenty times smaller in size than the variability model.  
Therefore, we ensure the correct functioning of the system after the reconfiguration if the security policies and reconfiguration task implementations respect the models. However, thus far, we have not monitored this reconfiguration process, nor have we observed that the system works as expected at runtime. This is done in INTER-TRUST using both active testing and fuzz testing techniques [19], where these modules verify, before and during the operational phases, that the negotiated contracts are respected and that the security policies are respected in dynamic systems. However, these modules of INTER-TRUST have not been integrated into FamiWare, yet.  
Regarding the necessity of the evolution of these kinds of systems where new technologies are appearing everyday, using the [EMAIL_ADDRESS] and the SPL paradigm to model the security, the addition of new security policies (or the modification of existing ones) is very easy. As the security concerns are modeled in the VSpec tree shown in Figure 6, the new security policy has to be added to this composite variability, as well as the correspondent modules in the base model. FamiWare will then be in charge of reconfiguring the system for this new security policy in the same way as it did for the rest of the policies. Therefore, we can say that our process is prepared for the evolution. However, this evolution is not totally automatic, because the implementation code of the new policy and the specific reconfiguration actions has to be manually provided to FamiWare.  
Finally, we have tested our reconfiguration process for the ITS case study that has been previously used to validate both INTER-TRUST and FamiWare. However, INTER-TRUST has also been tested in an e-voting scenario, and FamiWare has been implemented for ambient assisted living applications. Therefore, it would be useful to also test our security reconfiguration process in both case studies.