## 5 Dynamic Reconfiguration of Security in FamiWare  
FamiWare also uses the VSpec tree described in the previous sections at runtime to drive the reconfiguration of the middleware with self-adaptation purposes. Concretely, FamiWare uses a [EMAIL_ADDRESS] [23] approach to generate and to interpret the reconfiguration plans with the tasks to execute for switching from a configuration of the middleware to a new configuration in response to context changes. By using a [EMAIL_ADDRESS] approach, the changes are performed at the architectural level, and thus, the architectural configurations running in each network device, and at all times, are correct according to the global network and system restrictions. Other approaches implement reconfiguration mechanisms at the code level [24, 25], but the main drawback is that everything is hard-coded, so the correspondence between the reconfigured code and the models used at design time is lost. This makes it impossible to ensure that each middleware instance will enter a valid state after a reconfiguration is executed in the whole system. Following an autonomic computing approach [26], the monitoring, context awareness and reconfiguration services, described in the previous section, collaborate in order to reconfigure the middleware at runtime. In Figure 9, we focus on the reconfiguration of security, but a similar process is followed to reconfigure any other functionality in the WSN. The only difference is the use of the INTER-TRUST modules that have been specifically introduced to manage security in FamiWare. Concretely, Figure 9 represents the process followed when the SDS-based election feature is selected from the VSpec tree shown in Figure 5. Steps A and B represent the context observation and context analysis tasks, while Steps C, D and E represent the dynamic reconfiguration of security in FamiWare. In Step A, we see how the reconfiguration of security can occur due to the monitoring of the security contexts previously modeled or by a renegotiation of the security policies using the INTER-TRUST negotiation service. When this occurs, the changes need to be analyzed (Step B) to decide whether or not the middleware self-adaptation is required. Using the models@runtime approach provided by FamiWare (C1), this self-adaptation (self-protection when we talk about security) implies: (1) the generation of a new reconfiguration plan (Step D) using the models available at runtime (C1 and C2), the contextual information provided by Step A and the SDS file generated by the policy interpreter module in Step B;and (2) the execution of the reconfiguration plan (Step E) to adapt the middleware services (security in this case). The reconfiguration plans are calculated by applying a difference operator between two configurations/products, the active one (C2) and the new configuration to be deployed (C3). The plans are carried out to guarantee that the system functions after a context variation, and the main goal is to change from a VSpec tree configuration to another valid configuration. The tasks are performed both at the VSpec tree level and at the implementation level with a semantic correspondence between them. As described in the previous section, at the implementation level, a task could be: modifying the parameter of a component, connecting two components, removing a component or sleeping sensor devices, _etc._ At the VSpec tree level, every task is interpreted as either a feature addition, a feature removal or a feature modification. The changes can be coarse grained (e.g., adding a new middleware component as, for instance, a new authentication component) or fine grained (e.g., modifying a parameter of an existing middleware component, such as, for instance, changing the certificate entity used by an existing authentication component). Figure 9: FamiWare runtime reconfiguration of security. FamiWare allows the generation of plans both at design and at runtime.