Christophe Hurlin
email: christophe.hurlin@univ-orleans.fr

Christophe Pérignon
email: perignon@hec.fr

Victoria Stodden
email: victoria@stodden.net

RunMyCode.org: a novel dissemination and collaboration platform for executing published computational results

Keywords: reproducible research, reproducible computational science, dissemination platform, collaborative networks, cloud computing, executable papers, code sharing, data sharing, open science I

We believe computational science as practiced today suffers from a growing credibility gap -it is impossible to replicate most of the computational results presented at conferences or published in papers today. We argue that this crisis can be addressed by the open availability of the code and data that generated the results, in other words practicing reproducible computational science. In this paper we present a new computational infrastructure called RunMyCode.org that is designed to support published articles by providing a dissemination platform for the code and data that generated the their results. Published articles are given a companion webpage on the RunMyCode.org website from which a visitor can both download the associated code and data, and execute the code in the cloud directly through the RunMyCode.org website. This permits results to be verified through the companion webpage or on a user's local system. RunMyCode.org also permits a user to upload their own data to the companion webpage to check the code by running it on novel datasets. Through the creation of "coder pages" for each contributor to RunMyCode.org, we seek to facilitate social network-like interaction. Descriptive information appears on each coder page, including demographic data and other companion pages to which they made contributions. In this paper we motivate the rationale and functionality of RunMyCode.org and outline a vision of its future.

gone is the traditional image of the scientists as a solitary person working in a laboratory or scribbling in the back aisles of the mathematics library. This transition has not been smooth, and we believe it has already brought us to a state of crisis. The vast majority of scientific results generated by current computational science practice suffer a large and growing credibility gap: it is impossible to replicate and verify most of the computational results published or presented in conferences today.

There have traditionally been two branches of the scientific method, the deductive and the inductive. The deductive branch encompasses fields such as mathematics and logic, and the inductive field comprises the empirical sciences. There has been much discussion, even at very high policy levels, over the last few years regarding the emergence of new branches of the scientific method arising from the computational revolution [START_REF]Digital research data sharing and management[END_REF]. Both cpu-intensive simulation and the data deluge are provoking discussion of third and fourth branches of the scientific method, but we cannot elevate computational science to a new branch of the scientific method until we can generate reliable verifiable computational knowledge.

The central motivation for the scientific method is the ubiquity of error -the phenomenon that mistakes and selfdelusion can creep in absolutely anywhere in the process of generating scientific findings, and that the work of the scientist is primarily about recognizing and rooting out error. Both the deductive and inductive sciences are error prone and have consequently developed standards for the dissemination of results. In the deductive sciences the formal notion of the mathematical proof is a mature response to the ubiquity of error. Similarly, the empirical sciences employ the machinery of hypothesis testing, controlled experiments, and the disciplined reporting of data, material, and methods in a standard format in published research articles. In the computational sciences Jon Claerbout, professor emeritus of geophysics at Stanford University, pioneered a system for linking code and data with the final paper or thesis and giving the reader the capability to regenerate the results. His insight is as follows, "an article about computational science in a scientific publication is not the scholarship itself, it is merely advertising of the scholarship. The actual scholarship is the complete software development environment and the complete set of instructions which generated the figures" [START_REF] Buckheit | Wavelets and statistics, chapter Wavelab and reproducible research[END_REF]. In this way, the code and data that produced the computational results are available alongside the published paper, enabling readers to verify and validate the results.

The efforts pioneered by Claerbout were emulated by David Donoho, professor of statistics at Stanford University. Starting in the early 1990's, his approach was to supply the details underlying the datasets, simulations, figures, and tables in a uniform way in the standard MATLAB scripting language, and makes these files available on the Internet. Interested readers could then reproduce the calculations underlying that paper. Donoho required his students to work in this fashion. At the time he was working in computational harmonic analysis (wavelets, wavelet packets, time frequency methods) and very few computational tools were available. After several papers on the subject of wavelets had been written, it became possible to combine all the tools into a single package, WaveLab, which contained a unified set of wavelet and time-frequency tools and reproduced all the calculations in any of several papers. WaveLab emerged as a standard in the field. Since then Donoho and his students have released several subject-oriented dissemination platforms in the WaveLab framework for several research domains:

• Atomizer. This is a toolbox for overcomplete signal representation via l1 minimization; originating from Scott Chen's thesis [START_REF] Chen | [END_REF] and other related journal articles [START_REF] Chen | Atomic decomposition by basis pursuit[END_REF][START_REF] Chen | Atomic decomposition by basis pursuit[END_REF]. • BeamLab. This is a toolbox for multiscale geometric analysis, originating from Xiaoming Huo's and Ofer Levi's theses [START_REF] Huo | Sparse image representation via combined transforms[END_REF][START_REF] Levi | Multiscale geometric analysis of three-dimensional data[END_REF], Georgina Flesia's postdoctoral work [START_REF] Flesia | Beyond wavelets, chapter Digital Implementation of ridgelet packets[END_REF][START_REF] Donoho | Beyond wavelets, chapter Digital ridgelet transform based on true ridge functions[END_REF], and other related journal papers [START_REF] Donoho | Beamlab and reproducible research[END_REF][START_REF] Averbuch | Fast slant stack: a notion of radon transform for data on a cartesian grid which is rapidly computable, algebraically exact[END_REF][START_REF] Donoho | Beamlet pyramids: a new form of multiresolution analysis, suited for extracting lines, curves and objects from very noisy image data[END_REF][START_REF] Donoho | Beamlets and multiscale image analysis[END_REF][START_REF] Donoho | Modern Signal Processing, chapter Fast X-ray and beamlet transforms for three dimensional data[END_REF][START_REF] Donoho | Multiscale geometric analysis for 3d catalogs[END_REF]]. • SymmLab. This is a toolbox for multiscale analysis of manifold-valued data, originating from Inam Ur-Rahman's thesis and other related journal articles [START_REF] Rahman | Multiscale decomposition of manifold-valued data[END_REF][START_REF] Rahman | Multiscale representations for manifold-valued data[END_REF]. • SparseLab. This is a toolbox for the estimationg f overcomplete models and facilitating sparsity-seeking decomposition and reconstruction, originating from Victoria Stodden, Joshua Sweetkind-Singer, and Yaakov Tsaig's theses [START_REF] Stodden | Model selection when the number of variables exceeds the number of observations[END_REF][START_REF] Sweetkind-Singer | Log-penalized linear regression[END_REF][START_REF] Tsaig | Sparse solution of underdetermined linear systems: algorithms and applications[END_REF], Iddo Drori's postdoctoral work, and other related papers [START_REF] Donoho | Sparse solution of underdetermined linear equations by stagewise orthogonal matching pursuit[END_REF][START_REF] Donoho | Fast solution of l1 minimization problems when the solution may be sparse[END_REF][START_REF] Donoho | Extensions of compressed sensing[END_REF][START_REF] Hurowitz | Virtual northern analysis of the human genome[END_REF]]. • SphereLab. This is a toolbox for multiscale decomposition of data on the sphere, originating from Morteza Shahram's postdoctoral work [START_REF] Shahram | Multiscale representation for data on the sphere and applications to geopotential data[END_REF].

In 2004, Gentlemen and Temple Lang [START_REF] Gentleman | Statistical analyses and reproducible research[END_REF] introduced the concept of the compendium: a new way of disseminating research results that provides not only the article, but also the software tools and data required to reproduce the published findings. These pioneering efforts serve as the model upon which we built RunMyCode.org, introduced in section IV.

II. WHY PRACTICE REPRODUCIBLE COMPUTATIONAL SCIENCE?

We believe researchers will conduct better science if they begin a computational project with the knowledge that their code and data will be revealed at the time of publication, with the aim of giving independent readers the ability to verify their results. The primary reason to practice really reproducible research is for oneself. Research coding typically uses short term memory and with sufficient time, the detailed series of small decisions made in the course of research will often be difficult for even the original programmer to recreate.

Computationally oriented co-authors also need access to the data and code associated with publications to which they are making contributions, not only to understand the results they are taking responsibility for, but also to verify the integrity of the work. Incoming graduate and postdoctoral students typically replicate previously published results when starting research in a new area. If they have access to the underlying code and data the efforts expended duplicating the research will be greatly reduced. Referees of papers and grant proposals can verify and better understand submitted findings, and even future employers can obtain a sense not only of the technical expertise of the authors, but also of their awareness of the important of generating reproducible computational science.

Data are noisy, multiple steps are typically taken to ready the data for analysis, and the analysis itself can comprise a variety of different parameter settings and other decisions that affect the outcomes and findings, sometimes greatly. These steps and settings are not fully reported in a typical published article, such that the computational results can be conveniently replicated by others.

III. BARRIERS TO PRACTICING REPRODUCIBLE COMPUTATIONAL SCIENCE

In a 2009 survey conducted on the machine learning committee, 723 US-based academics were asked their reasons for sharing or withholding code and data [START_REF] Stodden | The scientific method in practice: reproducibility in the computational sciences[END_REF]. Topping the list was the time it takes to document and clean up the code and data, and then comes providing user support. Next is concern about not receiving attribution, and potential loss of future publications is seventh. These objections and problems, including the time it takes to carry out really reproducible research, the lack of credit, advantaging competitors, and prohibitive complexity of the computational environment, are echoed in other published literature [START_REF] Donoho | Reproducible research in computational harmonic analysis[END_REF]. Arguments are given to counter each of these reasons and paraphrased as follows. Having students carry out reproducible research actually decreases the amount of time supervision takes, and makes it much easier to verify and explain any of your own results should the need arise. If the concern is potential lack of credit, the very fact that you are a pioneer in reproducible research practices means the effort is more likely to be noticed and more likely to be recognized and rewarded. Enabling strangers to compete with you might happen if you release code and data, but it can also happen if you publish papers at all. Complicated computing environments pose an issue to reproducible research, but they are also a case where reproducibility is more important than the simpler case. A more complex computing environment has more possibilities for failure and fewer opportunities to check one's work. In it in these cases that reproducibility is especially important, even if it is harder to reveal one's work.

IV. WHAT IS RUNMYCODE.ORG?

The RunMyCode.org website was launched in January 2012 to disseminate code and data associated with published computational results, resolving some of the problems described above. It is a non-for profit academic website based on the innovative concept of a companion webpage associated with a scientific publication (article or working paper). Specifically, a companion webpage is a webpage that allows people to run computer codes associated with a scientific publication using their own data and parameter values, or download the code and data directly. The service only requires a web browser as calculations are done on a dedicated cloud computer. Once the results are ready, they are automatically displayed to the user, as a SaaS (Software as a Service), see Figure 1. Both the use and the creation of the companion webpages are free and do not require any particular programming skills.

This concept can be viewed as a novel attempt to provide, on a large scale, an executable paper solution. The only difference with the executable paper approach proposed by the scientific publishers (see for the instance the Elsevier's Executable Paper Grand Challenge, 2011) is that the companion webpage is not encapsulated within the text of a scientific publication [START_REF]Elsevier's Executable Paper Grand Challenge[END_REF]. In that sense, a companion webpage can be considered as providing additional material for a scientific publication.

RunMyCode.org has three main objectives: (1) to allow researchers to quickly disseminate the results of their research to an international audience, (2) to provide a very large community of users with the ability to use the latest scientific methods in a user-friendly environment, and (3) to allow members of the academic community (researchers, editors, referees, etc.) to replicate scientific results and to demonstrate their robustness. Figure 2 shows an example of a companion webpage for a published paper in econometrics on the estimation of the future volatility of an economic variable. The page provides a link to the published paper either on the publisher website or on a pdf archive platform such as arXiv.org or SSRN; both the underlying code and data are available for download and permit the execution of the code in the cloud to directly verify published results. RunMyCode.org houses close to 100 authorcontributed datasets and models today, all accessible via download and through the computational facilities at RunMyCode.org. Note that coder profiles are maintained within RunMyCode.org and displayed on each companion page to which they have contributed. This permits credit to be given to those who contributed to the programming and datasets involved in the research, and forms the basis for collaborative social networks.

There are three main parts in a companion webpage. The upper section provides information on the original scientific paper including a link, along with information about authors. The middle part displays information about the coders, i.e., the individuals who wrote the computer code that allows to implement the methodology presented in the paper, or to reproduce the findings reported in the paper. Note that the coders can be different from the authors. Finally, the lower part of the companion webpage allows users to choose parameter values and to upload data; either data provided by the coder or users' own data. Computation is launched by clicking the RunMyCode green button in the lower right corner.

Figure 2. Example of a scientific paper's companion webpage on RunMyCode.org

Each contributor within RunMyCode.org is given a unique profile called a "code page." Figures 3 and4 illustrate the link to the coder profiles from a sample companion page, and a coder profile for a contributor to RunMyCode.org. RunMyCode.org allows researchers to create a companion webpage online without any particular computing skills. There are four main steps in the companion webpage creation process. In the first step, the researcher provides information about the scientific paper, coders, and computer code (including software version, input, and output). In practice, the companion webpage reproduces the output of the computer code (tables, figures, numerical values, text, image, etc.) as they would appear on the researcher's personal computer. The final task for the researcher is to preview and validate her companion webpage.

Note that the creation of a companion webpage does not require any modification to the scripts and, as such, requires no additional effort from the researcher. Depending on the complexity of the script, type and number of constraints, input, and output, the creation of a new companion webpage by the RunMyCode.org team takes anywhere between 20 minutes and a few hours.

Next, the editorial team checks whether the topic complies with the editorial policy of the website, similarly to any peerreviewed academic journal. Then a technical validation of the code is undertaken, which at time the companion webpage will be certified by RunMyCode.org. The RunMyCode Lab checks four different dimensions of the code: (1) compatibility of the software; (2) robustness of the code: testing parameter values and constraints; (3) security of the code; and (4) CPU requirements and computing time. Then, the code is uploaded on the cloud and the companion webpage goes online.

Currently, it is possible to create a companion webpage from code written in C++, Fortran, MATLAB, R, and Rats. More software will be added in the near future. For all the applications, cloud facilities are provided by the French National Research Agency (CNRS)'s TGE Adonis.

The RunMyCode.org website was first developed in social sciences, with a strong emphasis on economics and management. An important stream of research in this field is the modeling of financial risk. Some of the risk measures developed by academics have played a central role in the current debate on banking regulation (Dodd-Frank Wall Street Reform and Consumer Protection Act, 2010) [START_REF]Dodd-Frank Wall Street Reform and Consumer Protection Act[END_REF]. In this perspective, a companion webpage allows people to better assess the properties of a given risk measure and its expected consequences on financial markets.

With the financial support of the Alfred Sloan Foundation and of the HEC Paris Foundation, RunMyCode.org is being extended to other computational sciences, including applied mathematics, statistics, and image processing.

V. WHAT PROBLEMS DOES RUNMYCODE.ORG SOLVE?

In many computational sciences, the algorithm accounts for a significant fraction of the scientific contribution. However, lack of disclosure of the computer code associated with the scientific paper has two pernicious effects. First, it prevents people from using the method or replicating the findings without recoding the algorithm in the paper. Second, it prevents editors and referees from checking the codes in order to check the accuracy of the results.

Furthermore, even when the computer code is publicly disclosed, many potential users cannot use it because they do not have the necessary coding skills to implement it, nor the right versions of the software/compilers, nor the appropriate computing capacities. This situation is frustrating for the original researchers because it prevents their research output from being broadly used and cited. Similarly, potential users of the research output, including other researchers, students, corporations, administrations, and sometimes the general public, can only access and benefit from a tiny fraction of the overall scientific output. This leads to an obvious mismatch between the supply and the demand of new research ideas and methods, and little transfer of technology from the academia to society. We think that RunMyCode.org alleviates some of these problems.

First, it makes research easier to use and replicate, which in turn can boost the transfer of technology. Indeed, when a companion webpage is available for a given piece of research, all potential users can give a try right away. Of particular interest is the fact that RunMyCode.org constitute an effective way to democratize the access to the latest academic research in developing or emerging countries. Over the past six months, around 15% of all our site visits were from developing countries.

Second, RunMyCode.org enriches the refereeing process as editors and referees can now access and assess the computer code associated with a submitted paper. This additional piece of information can help them to make a more informed decision in a short period of time. They can evaluate the robustness of the methodology proposed by the authors to some changes in parameter values and data without any extra programming effort.

When results are produced by RunMyCode.org a suggested citation is supplied, for both the code and data that were used in generating the results, and for the RunMyCode.org website.

VI. WHAT IS THE VISION OF RUNMYCODE.ORG?

There are many areas in which we hope RunMyCode.org will help make scientific research easier to verify and use.

• We would like RunMyCode.org to become a leading repository for scientific code and data in in computational fields. Alternatively, a more advanced solution would be to create a companion webpage directly associated with a course, and not with a single paper. This would allow different methods to be run on a unique dataset, for example. • We would like RunMyCode.org to become a market for scientific talent. Employers can look for people with a particular expertise in a given scientific area, especially using the "coder page" associated with each contributor. • We would like to leverage the social network aspects built into RunMyCode.org and further encourage researchers to discover and interact with others, including messaging and interfacing with other social network sites.

• We would like RunMyCode.org to be used by funding agencies to impose standards for research grants in terms of disclosure of data and code. • We would like RunMyCode to collaborate with publishing companies to link published papers to their RunMyCode.org companion webpages. • We would like RunMyCode.org to model best practices for reproducible research.

RunMyCode.org solves several of the problems given in section III confronting computational scientists who wish to practice really reproducible research. It removes the difficulty of hosting the code and data, it removes the difficulty of installing and running (even correct) code on a local computer system, and by providing the ability for users to execute the code in the cloud, it minimizes the amount of support coders and authors are asked to supply. RunMyCode.org also provides suggested citations, to help encourage a reward system that encourages code and data release, by giving credit for these scientific contributions. RunMyCode.org provides a public date of creation of the companion webpage, helping to ensure primacy to those who release code and data and encourage attribution. Perhaps most importantly, RunMyCode.org provides a central field-independent platform to facilitate both code and data sharing, and the verification of published computational results [START_REF] Stodden | Trust your science? Open your data and code[END_REF].

Figure 1 .

 1 Figure 1. Structure of the RunMyCode.org website. Researchers provide the code and data associated with their publication. Users provide their own data, which are sent to the cloud along with the computer code. When ready, the results are sent back to the user.

Figure 3 .Figure 4 .

 34 Figure 3. Abbreviated example of a scientific paper's companion webpage on RunMyCode.org, showing the link to the contributor's "coder page"

•

  We would like RunMyCode.org to operate on a global scale, with support units and computing facilities in various institutions throughout the world.• We would like RunMyCode.org to help change the refereeing process of scientific papers. We see great value to the scientific progress if academic journals' editors could access an anonymized companion webpage before reviewing the paper. Referees can then use the companion webpage to validate the main findings and check their robustness. Once the paper has been accepted, there is no need for the companion webpage to remain anonymous and the researchers' names can be added. • We would like RunMyCode.org to become a scientific social network, on which researchers present and promote their research. The researcher can decide on whether she wants to share her code and data with the entire planet or restrict part of her material to a smaller group of people. By doing so, the researcher can better control citations of her work. Such a social network would also encourage collaborative code development. • We would like RunMyCode.org to become a certification device for computer code and data in science. The RunMyCode.org certification will help researchers to publish and promote their research.

	• We would like RunMyCode.org to become an
	innovative teaching tool allowing professors to bring
	research into the classroom and expose students to the
	latest research developments. There are two ways we
	can suggest using RunMyCode.org in a course. First,
	the instructor can create a portfolio of existing
	companion webpages within the RunMyCode.org
	platform. Students access a login that allows them to
	directly access this portfolio of companion webpages.


Nadia Gamez

Daniel Romero
email: daniel.romero@inria.fr

Lidia Fuentes

Romain Rouvoy
email: romain.rouvoy@inria.fr

Laurence Duchien
email: laurence.duchien@inria.fr

Constraint-based Self-adaptation of Wireless Sensor Networks

Keywords: H.1 [Models and Principles]: Miscellaneous; D.2.10 [Software Engineering]: Design -methodologies Design, Performance Constraint-Satisfaction Problem, Dynamic Software Product Lines, Self-adaptation, Wireless Sensor Networks

In recent years, the Wireless Sensor Networks (WSNs) have become a useful mechanism to monitor physical phenomena in environments. The sensors that make part of these long-lived networks have to be reconfigured according to context changes in order to preserve the operation of the network. Such reconfigurations require to consider the distributed nature of the sensor nodes as well as their resource scarceness. Therefore, self-adaptations for WSNs have special requirements comparing with traditional information systems. In particular, the reconfiguration of the WSN requires a trade-off between critical dimensions for this kind of networks and devices, such as resource consumption or reconfiguration cost. Thus, in this paper, we propose to exploit Constraint-Satisfaction Problem (CSP) techniques in order to find a suitable configuration for self-adapting WSNs, modelled using a Dynamic Software Product Line (DSPL), when the context changes. We exploit CSP modeling to find a compromise between contradictory dimensions. To illustrate our approach, we use an Intelligent Transportation System scenario. This case study enables us to show the advantages of obtaining suitable and optimized configurations for self-adapting WSNs.

INTRODUCTION

Wireless Sensors Networks (WSNs) refers to the set of sensor nodes connected by a wireless medium that are able to perform distributed sensing and convey useful information to control stations [START_REF] Akyildiz | Wireless sensor and actor networks: research challenges[END_REF]. They are attracting huge interest due to their potential of applicability in a variety of pervasive systems, such as smart spaces, intelligent transportation systems or ambient assisted living applications. However, they impose several requirements, compared to traditional information systems, mainly due to their resources scarceness (e.g., battery or memory).

An important issue in WSNs is their reconfiguration regarding changing conditions or context changes to reduce network degradations or to improve the functioning. Such reconfigurations have to be done considering sensor deployment in remote and unattended areas as well as the satisfaction of conflicting objectives (e.g., accuracy versus energy consumption). The former requires WSNs having an autonomous behavior, i.e., networks that exhibits "self-*" properties [START_REF] Ibm | An architectural blueprint for autonomic computing[END_REF] in order to react by themselves to the context changes. The latter requires a decision making mechanism in the reconfiguration process that takes into account not only the context changes but also the resource scarceness of WSNs or other sensors specific characteristics to deal with conflicting objectives.

In order to achieve self-adaptations in WSNs, in a previous work [START_REF] Gámez | Autonomic computing driven by feature models and architecture in famiware[END_REF] we proposed Famiware, a family of middleware for Ambient Intelligence (AmI) systems, deployed in sensors devices and smartphones. Famiware uses feature models and Dynamic Software Product Lines (DSPLs) to drive the self-adaptation process. The reconfiguration consists in replacing the current feature model configuration by a new configuration more suitable to the new context situation.

In this paper, we focus on the decision making mechanism of the reconfiguration process defined by Famiware considering that multiple target configurations can satisfy the new context. Given the resource scarceness in WSNs, the resulting target configuration have to be optimal as possible regarding dimensions such as resource consumption and reconfiguration cost. However, such selection can not be done to the detriment of other dimensions such as the Quality of Service (QoS) offered by the network. Therefore, we propose a decision making mechanism for FamiWare, which deals with the trade-off of different dimensions by using multi-objective optimizations. Our approach provide the flexibility to specify the dimensions to consider for the self-adaptation. In this way, the resulting configuration respect the context but at the same time is the most suitable regarding additional critical dimensions in WSNs.

After this introduction, this paper is structured as follows. We start by describing a motivation scenario and identifying the challenges associated with the selection of the new network configuration (cf. Section 2). Then, we present FamiWare (cf. Section 3) the middleware that we extend in order to improve the self-daptation process (cf. Section 4). We continuous with the discussion about the advantages of our work (cf. Section 5) before discussing some related works (cf. Section 6). We finish with some conclusions and perspectives of our work (cf. Section 7).

MOTIVATION & CHALLENGES

In order to motivate our work, we use an Intelligent Transportation System (ITS)1 scenario.

This kind of systems uses sensors, on board computers, GPS and other devices to improve the mobility, safety, and security, while ensuring energy efficiency and reducing environmental impacts of transportation systems. In a particular ITS application, we have several static sensors placed in a road sensing movement, light, noise and temperature in order to collect data about traffic, possible accidents or environmental issues. In the feature model of Figure 1, a WSN is made up of one or more sensors (feature with 1..* cardinality).

An important characteristic of this kind of networks is its routing protocol that allows the communication between sensor nodes. In this feature model are represented six routing protocols: DD, Drip, ACM, TinyHop, AODV and TYMO. The protocol running in every node has to be the same for all the sensors (cf. RProtocol feature and its xor children in Figure 1), but also the sensors can have optionally preinstalled other protocols (cf. Routing feature in Figure 1). In addition, other characteristics of sensors relevant for our scenario are the role that they can play in the network (ordinary node, cluster-head, or sink), the state of the node (alive or slept) and the frequency of the sensing tasks. Let us suppose that the road in the scenario becomes a secondary road because a nearby highway is open. Then, the use of the road is drastically reduced and the information collected by its sensors is not as critical as before. To increase the lifetime of the network, the system can be reconfigured to save energy. To do that, several options are possible:

• Change of the routing protocol : Figure 2 depicts the feature diagram of one partial configuration of the network with some energy efficient protocols, i.e., TYMO, TinyHop and AODV. To save energy in this configuration, we can select the most energy efficient routing protocol namely AODV. However, by doing that we could impact the response time of the whole network since this protocol is not necessarily the fastest protocol. Additionally, if we choose the AODV protocol which is not preinstalled in several nodes, we produce additional reconfiguration costs in terms of energy expense by sending large size messages that contain the protocol functionality.

• Deactivation of sensor nodes: Another way to save energy is by sleeping nodes on the network. For example, we can decide to deactivate the 50% of nodes. But, how do we select the candidates? We could do it randomly or arbitrarily. However, this deactivation has to be executed carefully because we can sleep a cluster head node or a sink making the network or part of it useless. In a similar way, depending on the network topology, we can sleep several consecutive nodes seriously affecting the network accuracy.

• Reduction of the monitoring frequency: Finally, we can reduce the frequency of the monitoring tasks in sensors. Nevertheless, if the WSN response time increases a lot, we cannot ensure more the safety of the transportation system.

By using these different alternatives, we can find several valid configurations that will reduce the energy consumption in the network.

However, as we just mentioned, we cannot only consider the energy saving to select the new configuration. We need also to include other aspects of the network such as reconfiguration cost and QoS properties (e.g., accuracy), which lead us to find contradictory objectives.

Challenges.

From the previous scenario we have identified the following challenges:

1. How to select the best fitting target configuration: As already said, WSNs are characterized by resource scarceness. The message exchange as well operations required to reach the new configuration (e.g., code installation and changes on nodes properties) have to be minimized in order to preserve the network resources and the correct operation. Therefore, the new selected configuration of the WSN should be the most adequate one, regarding specific dimensions such as energy consumption or accuracy of the sensed information. Thus, one of the challenge will be to identify the dimensions to optimize the targets configurations.

2. How to deal with conflicting objectives: In the process of finding the most adequate target WSN In this case, the energy saving and the reconfiguration cost dimension can be considered as contradictory objectives. Then, in order to solve this kind of situations, we will need to consider multiple criteria in the selection process. It is necessary to find a suitable trade-off between such objectives.

In the following section we present the FamiWare middleware, which we extend in order to deal with the mentioned challenges.

SELF-ADAPTATION IN FAMIWARE

FamiWare is a family of middleware for Ambient Intelligence (AmI) systems to be deploy in several kind of devices as sensors. FamiWare applies the Software Product Line (SPL) [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF] approach to characterize the inherent variability of the AmI domain by means of Feature Models (FM) [START_REF] Lee | Concepts and guidelines of feature modeling for product line software engineering[END_REF]. This FM is the base of a model driven process that derives a configuration adapted to the requirements of each system device. Furthermore, FamiWare has a mechanism to achieve self-adaptation by applying the Autonomic Computing paradigm at middleware level [START_REF] Gámez | Autonomic computing driven by feature models and architecture in famiware[END_REF].

FamiWare Reconfiguration

As part of the autonomic computing architecture developed in FamiWare, in every instance of the middleware there are several monitoring services observing the context.

The sensed data are analyzed by the context-aware service to check on context changes. When a context change is detected, the self-adaptation process is triggered.

Figure 3 summarizes the process to configure and to reconfigure FamiWare. At design time, the middleware architect defines the feature model that represents the family of middleware 1 . Then, this family is customized by following the application requirements provided by the application developer 2 .

As we mentioned before, in FamiWare the reconfiguration is driven by feature model runtime configurations. Then, the first step to reconfigure the system is to find the target runtime feature model configuration fitting the new context. The Hydra feature modeling tool2 , used by Fami-Ware, is able to find a set of valid configurations (called feature model specialization) respecting the new context 4 . However, we need to select the most suitable configuration in this set considering additional information. Therefore, as contribution of this paper, we extend FamiWare by allowing application developer to specify such dimensions 3 , which are used by a CSP service to find the new configuration 5 .

Finally, once the target configuration is obtained, the reconfiguration service provided by FamiWare is responsible for executing the required actions to reach that target configuration. But the reconfiguration execution is out of the scope of this paper. Here we focus only in the decision of the adequate target configuration.

Reconfigurable Parts in FamiWare

In order to identify what dimensions we can optimize in the self-adaptation process, firstly we have to specify the parts of FamiWare we can reconfigure.

The internal architecture of FamiWare is composed by a microkernel and several provided services. The microkernel is responsible for the composition of the application and the services. The microkernel also exposes a data delivery service to transmit the data over the network using a specific network routing protocol. Every particular middleware configuration is installed in each sensor node of the network. Then, we can reconfigure hardware of every sensor node or its internal FamiWare architecture. Regarding hardware reconfigurations, we can switch off and on the radio chip of the sensor or change the whole state of the sensor (e.g., slept, idle or alive). The reconfigurations in the FamiWare software architecture include coarse-grained modifications, like removing or adding a service or changing the routing protocol, and fine-grained modifications, like changing some internal parameters of a service.

In the next section, we introduce our proposal to improve the selection of the new configuration of the network in FamiWare.

PROPOSAL

In FamiWare, the reconfiguration process is based on the context information and can have different granularity levels (from parametrization to component replacement). In Section 3.1, we have provided an overview of the whole reconfiguration process. In this section, we focus on how to find the most suitable feature model configuration to adapt the system to a new context situation.

We propose that in order to improve the functioning of the WSNs, a new configuration has not only to satisfy the context but also to improve the network regarding additional aspects. For example, in our motivation scenario (cf. Section 2), we search configurations that reduce the energy consumption. But, in this search we need also to consider dimensions such as accuracy or response time, which are relevant taking into account the network objectives. A network that is energy efficient but has a low accuracy or takes a lot of time to provide information is not acceptable in the case of intelligent system transportations. Thus, the consideration of different dimensions can lead to conflicting objectives.

To deal with these conflicts, in this section we define an approach based on Constraint Satisfaction Problem (CSP) methods, to find a suitable configuration of the WSN considering multiple dimensions such as resource consumption and Quality of Service (QoS) at the same time.

The advantage of our approach is double: i) to provide a flexible reconfiguration process that allows application developers to refine the selection of the new network configuration when required and, ii) to deal with conflicting objectives. We start with the identification of the dimensions that we can use to select the new configuration by exploiting FamiWare and then we present the CSP modeling of the configuration selection.

What dimensions we can measure?

In order to optimize the self-adaptation of the WSNs, we need to identify dimensions that will be used in the selection process. To do this, we consider the quality of the network operations, the impact related to the reconfigurations actions and, of course, the maximization of the network life as relevant for the reconfigurations of WSNs. They are reified by the following dimensions:

• Quality of Service (QoS): In WSNs, QoS properties such as latency and accuracy of the sensed information may be critical. The latency to retrieve the monitored data from each node depends on the frequency of the sensing tasks but also on the selected routing protocol. There are routing protocols that send many messages to ensure that the information arrives to the destination as soon as possible, but this has a penalty in the energy saving, since communications have a high cost. On the other hand, the accuracy of the sensed information will depend on the number and position of active nodes that are sensing this data. In our scenario (cf. Section 2), to save energy in the whole network we can deactivate some nodes during a period of time and activate them again when the battery of rest of the nodes drops. In this way, we extend the life of the global network, but of course, the accuracy is reduced.

• Reconfiguration Cost: It is related to the number and size of exchanged messages for realizing the reconfiguration. As stated by [START_REF] Akyildiz | A survey on sensor networks[END_REF], the communication tasks consume more energy that the processing task in tiny devices such as sensor nodes. Therefore, we prefer parameterization on the installation of new functionality when possible, since this implies to send large messages with pieces of code. For example, if we need to choose between the addition of a new component or the use of a preinstalled component in a sensor node, we give the priority to the second choice. Thus, we reduce the size of the exchanged messages.

• Resource Consumption: The last dimension considered in the optimization of the reconfiguration is the resource consumption of the target configuration. In WSNs, we need to save resources in order to maximize the operation time of the network. In particular, we can reduce the energy consumption by reducing a(SN i ))

ReCosQoS min (

i=|S| i=1 sel(SN i ) * Y i )
communications, the frequency of monitoring tasks, but also disabling sensor nodes when they are not required.

The previous dimensions are computed from information kept or employed by FamiWare such as node state and frequency of sensing tasks. This means that their usage in the reconfiguration process does not introduce an additional overhead in terms of energy consumption. In the following section, we present our model applying CSP in order to include different and conflicting objectives based on the presented dimensions.

CSP Model in FamiWare

As we have already said, when we reconfigure the wireless sensor network considering several dimensions we can find conflicting objectives. For example, the reduction of the energy consumption by deactivating nodes impacts the accuracy of the sensed information. In a similar way, the usage of a routing protocol that consumes a low quantity of energy can have a high reconfiguration cost if such protocol is not deployed on the whole network. Our model deals with these conflicts by means of CSP. In particular, we improve the decision-making service from FamiWare with such a model (cf. Figure 3). Once, FamiWare has identified a set of target configurations dealing with the new context, our approach gives to application developers the opportunity of defining dimensions which constitute an additional filter to reach the new target configuration. In this way, at the end of the reconfiguration process, we will have a network configuration that is suitable considering multiple dimensions. Although our approach is based on FamiWare capabilities, it can be extended and generalized to include other dimensions or other generic WSN applications.

In this section, we explore the different optimizations based on several combinations of the mentioned dimensions.

Optimization based on the Resource Consumption and the Reconfiguration Cost

In this kind of optimization we can deal, for instance, with the trade-off between energy consumption and the reconfiguration cost. We search to choose a new configuration with an energy efficient routing protocol. However, at the same time, as communications are expensive in WSNs, we also need to reduce the reconfiguration cost by using the protocol that, if it is possible, was previously deployed on most sensor nodes. The RCReCos function in Table 1 searches to satisfy both objectives by minimizing the numbers of nodes where the new protocol must be installed and the energy used by the protocol.

The expression Ii(Pj) returns 1 if the i th sensor node has pre-installed the Pj protocol (which is part of the set P of protocols used in the network) or 0 on the contrary case. E(Pj) retrieves the energy used by the Pj protocol, which value is extracted from the protocol specification and experimental results.

Below we present the only constraint required in the RCReCos optimization:

C1RCReCos (∀ Pi, Pj|Pi ∈ P ∧ Pj ∈ P : (s(Pi) = 1 ∧ s(Pj) = 1) ⇒ Pi = Pj): Only one protocol is chosen for the new configuration.

In our ITS scenario we have six possible routing protocols, as it was shown in Figure 1, but not all of them are energy efficient. In fact, only three (TYMO, TinyHop and AODV) are the ones that FamiWare selects as suitable protocols for saving energy as it was shown in Figure 2. FamiWare obtains the set of valid configurations of the figure, taking as input a previous running feature model configuration and the new context constraints (e.g. new enery saving situation). In this figure, we can see that the DD and TYMO protocols were the protocols deployed on the different sensor nodes and that DD, DRIP and ACM protocols have been removed of these configurations since they are not energy efficient. This classification of protocol is made by FamiWare basing in previous simulations. In order to define the new configuration, we apply RCReCos on TYMO, TinyHop and AODV. AODV is the more energy efficient protocol over the other two but TYMO protocol has the lowest value for RCReCos. It is expected as TYMO is deployed on most of nodes and the cost for reconfiguring the system with AODV that is is not pre-installed is higher.

Optimization based on Quality of Service and Resource Consumption

Here, we search for a balance between the accuracy offered by the whole network (QoS) and the consumed energy (resource consumption). The QoSRC objective function models this optimization. In this function we minimize the number of active sensor nodes in the network. In particular, the expression a(SNi) indicates if the SNi node is active [START_REF] Akyildiz | A survey on sensor networks[END_REF] or not (0). Since sink and cluster-heads manage nodes, their deactivation introduce an additional cost on the reconfiguration because other nodes would have to take their responsibilities. Then, in our model, sink and cluster-heads cannot be deactivated. Therefore, we have the following basic constraints in order to optimize QoSRC:

C1QoSRC (∀ SNi|SNi ∈ CH : a(SNi) = 1): All the nodes that are cluster head are always active.

C2QoSRC (∀ SNi|SNi ∈ SIN : a(SNi) = 1): All the sink nodes are active.

With the previous constraints, the minimization of active nodes will get a configuration where all the ordinary nodes will be deactivated, but this would be inadmissible. In a similar way, in the ITS, it does not have sense to sleep all the first sensors placed in the road and only maintain active the last ones. Then, we have to avoid the deactivation of many consecutive nodes in order to get a suitable accuracy. For this reason, we define the following constraint:

C3QoSRC 1 -laN ≥ X, X > 0: The network offers at least an accuracy of X.

In this constraint, we assume that the accuracy is between 0 (excluded) and 1 included. The laN value represents the lost accuracy in the network in function of the nodes that are deactivated. To calculate laN we use the algorithm 1.

In this algorithm, we assume that all the nodes have the same contribution on the accuracy. Therefore, we compute the lost accuracy as the arithmetic mean of the deactivated nodes (cf. line 5, algorithm 1). However, in WSNs the accuracy is also impacted by the distance between nodes that are still active. Then, in line 7 we look on the neighbors of each node and increase by m -2 the lost accuracy when one of the neighbors is not active, with m being the number of nodes in the network. As one of the preconditions of the algorithm is that sink and cluster heads are always active (i.e., a(SN ) = 1 for all SN sink or cluster head), the laN never will be greater than one. Furthermore, the satisfaction of this condition is guarantee by C1QoSRC and C2QoSRC constraints. if (SN.activate() = f alse) then 5:

la N ← la N + (1/m)

6:

SN.visit(true)

7:

for all (N E ∈ N SN ) do

8:

if (N E.visited() = f alse and N E.active() = f alse) then 9:

la N ← la N + (1/m 2 )
10: 4 depicts a simplification of the ITS scenario with five consecutive nodes (i.e., m = 5). The Sensor4 is a sink, therefore it will be always active. Considering X = 0.6, we can not just leave Sensor4 active because laN would be 0.92. With Sensor1 and Sensor4 active, laN = 0.68 and with Sensor3 and Sensor4 active, laN = 0.64. If 1, 3 and 5 are active, laN = 0.4 and 1, 2, 3 and 5 are active, laN = 0.2. However, with the QoSRC objective function we minimize the number of active nodes, and then we prefer the solution with three active nodes that respects C3QoSRC . Therefore, nodes 2 and 4 are deactivated and the other nodes are kept active as depicted by Figure 4.

N E.visit(true)

Optimization based on the Reconfiguration Cost and the Quality of Service

With this optimization, in order to save energy, we want to reduce the monitoring frequency (QoS) of the different nodes in the network. But at the same time, we search to reduce the reconfiguration cost, which means to select a minimal number of nodes to reconfigure. To do that, we define ReCosQoS. In this function, we use sel(SNi) expression which indicates if the node has to be reconfigured. Yi represents the factor to reduce the monitoring frequency of the i th sensor node.

From the ReCosQoS definition, it is clear that we want to minimize the number of nodes to reconfigure. However, to guarantee a suitable monitoring frequency (QoS) we include the following constraint in the optimization:

C1ReCosQoS (∀ SNi|SNi ∈ S : ((mf (SNi) * Yi) ≥ X1i) ∧ ((mf (SNi) * Yi) ≤ X2i) ∧ (X1i ≤ X2i) ∧ (X1i ≥ 0)):
All the sensor nodes have a monitoring frequency in a given interval.

In this constraint, the mf (SNi) indicates the current monitoring frequency of the SNi node. On the other hand, X1i and X2i are the lowest and highest frequency that the SNi node can have in the new configuration of the WSN. Such values are specified by the application developer. The minimal Yi factor for the i th node is determined according to mf (SNi) and the C1ReCosQoS constraint.

DISCUSSION

Implementation Considerations

In order to validate our approach, we have implemented a prototype of CSP service that includes the objective functions described in Section 4. We propose a modular architecture of the service to make the addition of new optimizations easier and foster their reuse. In this way, the three optimization described in Section 4 are implemented in three different modules.

To reduce the overhead introduced by the optimizations at the execution, we avoid the usage of a CSP solver when possible. Additionally, we benefit from the data holding by FamiWare (cf. Section 4.1) to compute some information in advance. In particular, for the optimization based on the resource consumption and reconfiguration cost (cf. Section 4.2.1) we are able to compute the value of the RCReCos function for each protocol. We keep a list sorted in ascending order of those values. In this way, we select just the protocol which value is on the top of the list. The RCReCos values are updated just when we decide the installation of protocols during the reconfiguration. In those cases we use an efficient sort algorithm such as quicksort, to introduce the new value into the list.

Regarding the optimization related to accuracy and energy saving (cf. Section 4.2.2), we reduce the overhead by generating, at design time, a table containing the 1 -laN values for the different configurations of active and deactivated nodes. For each row in the table, we have the 1-laN value and the list of nodes to be deactivated to reach such value. The rows are ordered in descending order. This ordering allows us to apply a binary search algorithm to find the configuration that satisfy the X value for the accuracy.

m k = 2 m -1,
where m represents the number of ordinary sensor nodes.

In the table generation, we apply the algorithm introduced in Section 4.2.2, which have a complexity of O(n 2 ) in the worst case, when the WSN topology is fully connected.

In the case of the ReCosQoS function optimization we used the JaCoP (Java Constraint Programming) solver 3 . The selection of this library is motivated because of its simplicity and spread usage in the scientist community. The X1i and X2i values are defined by the developer at design time. We measure the overhead of the optimization by executing several tests with different configurations. Each test was executed 10000 times. We calculated the average time of the execution by excluding the first 1000, which were considered as part of the warm-up. Table 2 summarizes the obtained results. In the different tests, we use the energy efficient configuration depicted in Figure 2 which has, for each node, 13 features to model the routing protocols, state, role and frequency of the node. In each test we varied the number of sensors nodes in the network. As observed, for networks with less of 1000 sensor nodes, we rest under 30ms (cf. tests a to d ). With more complex networks configurations (cf. test e) the latency increases considerably even if it remains less than one second. However, the different tests confirm that we can use a CSP solver in the optimizations when required with a reasonable overhead.

Benefits of the Approach

In FamiWare the selection of a target configuration takes less than a minute for a feature model configuration with 4000 features. With our approach we introduce an additional overhead of 7ms for 6500 features (cf. Table 2, configuration c). With a more reasonable feature model configuration of 100 features, FamiWare is able to find the valid configurations in one second while our approach increases this time in 1ms for 60 features. Therefore, as expected, the usage of CSP in the reconfiguration process introduces an additional cost. However, this cost is negligible considering the benefits of our approach, which we detail now.

First, the usage of additional dimensions derived from the same context information enables FamiWare to find a configuration that not only respect context but also optimize the reconfiguration itself. For instance, in our ITS scenario without using our proposal, FamiWare chooses TinyHop (the more on the left subfeature of RProtocol in Figure 2) to save energy changing the routing protocol. In our scenario, 3 JaCoP Solver: http://www.jacop.eu/ this protocol is not preinstalled in several nodes. Therefore, the reconfiguration cost is higher since the code with the new protocol has to be spread through the network. This would implies a spend of energy, since the most costly operation is the communication. In our approach, we actually seek a better use of the reconfiguration opportunities regarding the resource scarceness in WSNs.

Second, our approach searches to improve the network configuration regarding multiple and conflicting objectives. In general, it is not suitable to configure the network by considering only one objective since other aspects can be affected. Continuing with our ITS scenario, we cannot just reduce the energy consumption by deactivating nodes. For example, FamiWare does not consider the penalty in the accuracy when consecutive sensor nodes are not active. This means that the configuration chosen by the middleware platform could sleep several consecutive nodes having as a result a network that will not provide right information about the entire road. With our CSP based solution, we find a compromise between this kind of conflicts.

Third, the integration of our approach with FamiWare is easily configurable to be used just when it is required. In the case of our scenario, the execution time of the whole reconfiguration triggered by context changes is not critical. Objectives like the reduction of the energy consumption or keeping a degree of accuracy are more important. Then, we can applied our CSP based solution. Nevertheless, in cases where the time in the reconfiguration is critical such as emergency situations, the optimizations can be ignored. In these cases, it is only important reconfigure the network to deal with the new context. Then, we will choose one of the next target configuration for the new situation without regarding other dimensions. This new configuration will be not necessarily the most suitable to extend the WSN live but at least it will works according to the new context.

Finally, in our approach we do not consider the combinatorial explosion related to variants. In fact, it worths notice that FamiWare defines a high amount of dependencies between the features in its feature model. This reduces the combinatorial explosion of possible variants. Furthermore, as what we propose here is to reason about the set of possible configurations provided by FamiWare, it is out of the scope of this paper to discuses about the combinatorial explosion problem.

RELATED WORK

In the literature, we find several works [START_REF] Zhang | Multi criteria adaptation mechanisms in homological sensor networks[END_REF], [START_REF] Avvenuti | An application adaptation layer for wireless sensor networks[END_REF], [START_REF] Delicato | Reflective middleware for wireless sensor networks[END_REF], [START_REF] Boonma | Evolutionary constraint-based multiobjective adaptation for self-organizing wireless sensor networks[END_REF], [START_REF] Boonma | Monsoon: A coevolutionary multiobjective adaptation framework for dynamic wireless sensor networks[END_REF] dealing with the adaptation of WSNs with similar motivation as our approach. However, many of them [START_REF] Zhang | Multi criteria adaptation mechanisms in homological sensor networks[END_REF], [START_REF] Avvenuti | An application adaptation layer for wireless sensor networks[END_REF], [START_REF] Delicato | Reflective middleware for wireless sensor networks[END_REF] focus in how to realize this adaptation over the network instead to search for a suitable configuration of the whole system as we propose. In [START_REF] Zhang | Multi criteria adaptation mechanisms in homological sensor networks[END_REF], an adaptation mechanism based in an algorithm to detect coverage and topology of sensors is presented. They use the life time of the network as a goal as we do. Similarly, in [START_REF] Avvenuti | An application adaptation layer for wireless sensor networks[END_REF], the energy is the most important requirement in the adaptation of the WSNs. However, again they do not explain which will be the reconfiguration of the system. They focus on how to reconfigure using a mechanism of code injection. Authors in [START_REF] Delicato | Reflective middleware for wireless sensor networks[END_REF] present a reflecting middleware for WSNs that adapts the network to maintain the QoS requirement. Nevertheless, they only pay attention to QoS dimension instead to provide a mechanism to optimize the network regarding the context changes and other dimensions. Finally, in [START_REF] Boonma | Evolutionary constraint-based multiobjective adaptation for self-organizing wireless sensor networks[END_REF] and [START_REF] Boonma | Monsoon: A coevolutionary multiobjective adaptation framework for dynamic wireless sensor networks[END_REF] the authors try to deal with the adaptation taking into account conflicting objectives. However, they use a biological adaptation mechanism to reconfigure the system regarding only the latency, cost and success rate. Instead, our dimensions are more generic and cover more objectives.

Out of the WSN domain, CSP, Dynamic Software Product Lines and Feature Models are widely used to perform self-adaptation. [START_REF] White | Software engineering for self-adaptive systems. chapter Using Filtered Cartesian Flattening and Microrebooting to Build Enterprise Applications with Self-adaptive Healing[END_REF] uses feature models and a heuristic algorithm to derive configurations that meet resource constraints. However, these constraints are more relaxed that the constraints that we must deal with for the sensors devices. In [START_REF] Brataas | Scalability of decision models for dynamic product lines[END_REF], product lines are applied to support selfadaptative applications. In this work, the authors focus in dealing with the the combinatorial explosion of variants. As we mentioned in the past section, FamiWare reduce this problem exploiting the dependencies between features. Furthermore, in this work we only focus in the selection between a bounded set of configurations. In a similar way, in [START_REF] Rosenmüller | Tailoring dynamic software product lines[END_REF] tailor Dynamic Software Product Lines feature models. They try to bridge the gap between the features and the component-based runtime adaptation. Then, they go a step forward than us, since our purpose is to choose the new feature model configuration and then to map this configuration into the architecture of the system.

CONCLUSIONS

In this paper we presented an approach to enable the selection of a new WSN configuration when multiple configurations satisfy the current context. In particular, we applied multiobjective optimizations to deal with conflicting objectives. The optimizations are based on the resource consumption, the QoS offered by the network and the reconfiguration cost, which are important dimensions to consider in the configuration to be reached. Our approach is integrated into the FamiWare middleware that provides a feature driven reconfiguration support for WSNs.

Given the limited capabilities of WSNs, our approach searches to improve the reconfiguration process looking for a suitable configuration of the network. Our discussion shows that in some situations we can avoid the usage of CSP solvers to reduce the overhead introduced by the optimizations. Nevertheless, we can still use solvers with a reasonable overhead as it is confirmed by the executed tests. Additionally, as the reconfiguration time of the network can be critical in some situations, we also provide the flexibility to use it only when considered appropiate.

Future work includes the definition of new objective functions considering other dimensions such as reliability and data routing. We also plan to extend our optimizations to enable software modifications in the sensor nodes. Currently, we are limited to parametrization of the network. By benefiting from the FamiWare capabilities in terms coarsegrained modifications like removing or adding services in the nodes we can also optimize the software running on the sensor nodes.

Figure 1 :

 1 Figure 1: Feature Model for the ITS Scenario

Figure 2 :

 2 Figure 2: Network Configuration with Energy Efficient Protocols

Figure 3 :

 3 Figure 3: FamiWare Configuration and Reconfiguration Process

Algorithm 1

 1 Computation of lost accuracy laN value Require: A set of sensor nodes S Require: A set of neighbors N SN for each SN ∈ S Require: (∃SN |SN ∈ S : a(SN ) = 1) Ensure: The lost accuracy la N according to the deactivated sensor nodes 1: la N ← 0 2: m ← S.size() 3: for all (SN ∈ S) do 4:

Table 1 :

 1 Objective functions. -I i (P j )) + E(P j )), P j ∈ P

	i=|S|
	RCReCos (1 QoSRC min ( i=1 min ( i=|S|
	i=1

Table 2 :

 2 CSP results for the ReCosQoS optimization.

	Test	Feature	Sensor	CSP Latency(ms)
		Number Number
	a)	57	4	0.08
	b)	1305	100	1.35
	c)	6505	500	6.89
	d)	13005	1000	25.05
	e)	52005	4000	362.73
				k=m
	The number of rows in the table is
				k=1

IEEE Intelligent Transportation Systems Society: http://sites.ieee.org/itss/

The Hydra feature modeling tool: http://caosd.lcc.uma. es/spl/hydra

ACKNOWLEDGMENTS

This work has been partially supported by the projects TIN2008-01942 funded by Spanish Ministry of Science and Innovation and P09-TIC-05231 (FamiWare) funded by Andalusian Government.