## 4 Integration of FamiWare and INTER-TRUST
### Generation and Integration of the Security Reconfiguration Actions into FamiWare  
In order to maintain the correspondence between the running code and the model, FamiWare defines a two-level mapping between the modifications of the features in the VSpec tree and the implementation level tasks [21] to be executed for the system reconfiguration. The first mapping is a table that specifies for each feature of the VSpec tree how the presence/absence of that feature implies the execution of a set of generic reconfiguration tasks. Examples of these generic tasks are activating or deactivating a sensor, changing the role played by a sensor, adding a service to a certain FamiWare middleware instantiation, removing a running service or changing the configuration of a service. Since these tasks are generic, they are already provided by FamiWare and are directly reusable in the extension of FamiWare with INTER-TRUST. An example of this correspondence would be: \"when the cypher feature was not selected in the running product and is now selected in the VSpec tree representing the adapted product, a reconfiguration task to add the service for encrypt/decrypt messages has to be executed\". At the implementation level, this corresponds to the task \(AddService(Device_{n},Service_{m})\) with two input parameters (the device identification and the service name). Then, the tasks can have input parameters; thus, we define a task as \(t(p_{1},...,p_{n})\), where \(n\) is the number of parameters, which can be variable. A FamiWare reconfiguration plan is a sequence of tasks specified in OWL-S [22], an ontology of services for semantic descriptions of web services. For instance, examples of tasks, in this reduced version of OWL-S, to add the encryption service to a traffic camera and to configure it with a particular encryption algorithm, would be like this:  
```
<AtomicProcessID=\"AddService\"> <InputID=\"TrafficCamera2\"/> <InputID=\"Encryption\"/> </AtomicProcess> <AtomicProcessID=\"ConfigureService\"> <InputID=\"Encryption\"/> <InputID=\"encryptAlg2\"/> </AtomicProcess>
```  
Using these generic reconfiguration tasks, FamiWare permits the reconfiguration of both the hardware of each device and its internal FamiWare architecture. Regarding hardware reconfiguration, FamiWare could, for instance, switch the radio chip of the sensor to on/off or change the whole state of the sensor. With regards to the modifications in the software architecture, it is possible to perform coarse-grained modifications, such as remove or add a service, and it is also possible to make fine-grained modifications, like changing some parameters of a service. The second mapping specifies how these generic reconfiguration tasks are implemented for each device, application and/or new service. Since the implementation may be different for each device, application and/or service, a list of specific reconfiguration actions need to be implemented for each generic task. Some actions are specific to a concrete type of device, as is the case of putting to sleep a sensor device (_i.e._, switching off a MICAz mote), or to a concrete application, such as the specific places in the application where a security concern needs to be ensured (e.g., authentication must be ensured when the vehicle interacts with the server for the first time). The current implementation of FamiWare already provides the code of the device-specific actions for a broad range of sensors/devices and platforms (e.g., TinyOS, SunSPOT). However, in the case of the reconfiguration actions that are specific to a certain application or to a new service (e.g., security), the code of the particular actions to be executed for reconfiguring the systems must be manually provided to FamiWare. Thus, according to the second step shown in Figure 4, the integration of INTER-TRUST into FamiWare requires that the FamiWare variability models of Figures 5 and 6 are complemented with the list of security reconfiguration actions that need to be executed to reconfigure the application security level at runtime.