A New Component Model for Lightweight Software Reconfiguration in ...

ReWiSe: A New Component Model for Lightweight Software Reconfiguration in Wireless Sensor Networks Amirhosein Taherkordi, Frank Eliassen, Romain Rouvoy, and Quan Le-Trung University of Oslo, Department of Informatics P.O. Box 1080 Blindern, N-0314 Oslo {amirhost,frank,rouvoy,quanle}@ifi.uio.no

Abstract. Wireless Sensor Networks (WSNs) are increasingly being deployed for applications with dynamic requirements. Moreover, these applications are likely to be run on nodes with different sensing parameters and capabilities. Addressing such issues in the middleware layer and application layer, beside the consideration in the lower layers, is of high importance. Reconfiguration of application software has been identified as an effective approach for handling dynamicity issues. However, the special characteristics and limitations of WSNs make the requirements to the reconfiguration mechanism quite different from what has been previously proposed for other types of platforms. In this paper, we propose a new software component model, named ReWiSe, for achieving lightweight and fine-grained software reconfiguration in WSNs. In this model, a component can be reconfigured at the behavior-level instead of at the component-level. We discuss how the new component model can make the reconfiguration process lightweight in terms of component state preservation, component dependency checking, and new update unit granularity. Keywords: Component Model, Wireless Sensor Networks, Reconfiguration, Adaptation.

1

Introduction

Deployments of WSNs have increased considerably over the past few years. There are more applications running on WSN platform, and more technical issues on different aspects arise. Challenges become more significant when WSNs are exploited in the new emerging applications not limiting themselves to a single function called “sense and send” with trivial local data processing tasks [1], [2]. Applications for WSNs are gradually moving towards ubiquitous computing environments, where a high number of computing devices deal with dynamic requirement and unpredictable future events [3]. In such an environment, in addition to the basic tasks, an application needs to adapt its behaviors and functionalities to cope with changing environmental conditions, and with different capabilities of each individual sensor node in the network. As different R. Meersman, Z. Tari, and P. Herrero (Eds.): OTM 2008 Workshops, LNCS 5333, pp. 415–425, 2008. c Springer-Verlag Berlin Heidelberg 2008 

416

A. Taherkordi et al.

nodes are expected to run different tasks, software with adaptable functionalities becomes an essential need. Moreover, application in which a high number of nodes are deployed in inaccessible places, individual software updating becomes an impractical solution. One of the popular mechanisms for handling application dynamicity is the provision of a set of generic middleware services performing reconfiguration tasks [4]. The main advantage of this technique is that the reconfiguration mechanism is kept separated from the application logic. The performance of the middleware proposal for dynamic applications depends on two major factors. Firstly, we should examine to what extent a typical application module is reconfigurable. In some cases, due to the tight coupling between the modules reconfiguring a module needs to update some other parts of application, while in a highly reconfigurable model the update is limited to the part that really needs to be updated. Secondly, the mechanisms by which a module is reconfigured effects the performance of such middleware. In this paper, we focus on the first factor and propose a model as the building block of reconfigurable WSN application in order to improve the performance of the reconfiguration process. The techniques for application module development in the WSNs are highly dependent on the kind of software unit provided by the underlying operating system. Since the most popular operating systems for sensor nodes such as TinyOS [5] or Contiki [6] are based on software component models, contributions to the application and middleware are mostly inspired by such models. To generalize the proposal of reconfigurable application module, we adopt the software component model as unit of development in the WSNs and describe our new model. Beside the earlier component models not supporting dynamic reconfiguration of components [7], [8], [9], some recent component models are enhanced with features enabling reconfiguration of software component [10], [11]. Basically, these models are targeting large-scale systems with sophisticated models of component integration and high amount of computing resources. In this paper, we propose a new component model which is more suitable for performing lightweight reconfiguration and adaptation in sensor applications. Using this model, the reconfiguration is limited to the part of a component that really needs to be updated, rather than replacing the whole component with the new one. New concepts in the proposed model simplify the general steps of a typical reconfiguration model. By exploiting this model in designing WSN application software, the reconfiguration program performs its task in a lightweight manner. The notion of behavior reconfiguration makes it possible to upload only the changed part of software to the nodes, instead of uploading the whole software component. We believe that this model can be also exploited in other application areas such as mobile applications and embedded systems. The rest of this paper is organized as follows. The next section introduces the concept of reconfigurability. In Section 3, we describe the ReWiSe component model and its constituents. Then, in Section 4 we discuss how a ReWiSe-based system can be reconfigured in a lightweight manner. Related work is presented in Section 5. Finally, Section 6 concludes the paper and discusses future work.

ReWiSe: A New Component Model

2

417

Reconfigurability

Dynamic reconfiguration of software components has been a popular approach to meet the dynamic requirements of applications. Dynamic reconfiguration might include stopping and starting of applications and their components, configuring their connections and parameters, or changing device settings [12]. A reconfiguration service is responsible for safely reconfiguring from the currently running application variant to a new application variant selected by a professional user of the system or existing adaptation mechanism. In the context of WSNs, reconfiguration become fully effective if the reconfiguration service retains fine-grained control over what is being reconfigured, by updating only some selected functionalities to minimize energy consumption. In other word, the ideal way of WSN application reconfiguration is to limit updates to only the portion of software which really needs to be updated rather than updating the full application image. However, in some sensor platforms, for software updates to be successful, the whole system is required to be restarted after performing reconfiguration. Basically, reconfiguration mechanisms are proposed based on the type of application building blocks. For a component-based framework, two main mechanisms could be employed, namely, parameter and component [12], [13]. In the former, a component is reconfigured by updating its configuration parameters. This mechanism supports fine tuning of applications through the modification of the values of component configuration parameters and deployment parameters. In fact, in this method the behavior of a component is controlled by manipulating the component or application configuration parameters. As an example, the component collecting sample data from a sensor can be reconfigured through updating only the value of the SampleRate attribute (the frequency at which sensors send messages). In employing component reconfiguration mechanism, the whole component can be reconfigured. In particular, component-scope reconfiguration allows the modification of service implementation (replacement of a component), adding a new component, and removing running components. Parameter-scope is an effective way to implement variability, but it is less powerful than component adaptation. In our model, the dynamic reconfiguration mechanisms are described based on software architecture elements known as components. The component model defines constructs for structuring the code on the sensor nodes. Basically, every component represents a single unit of functionality and deployment. As illustrated in Figure 1, every component can interact with its outside through property, interface, and receptacle. An interface specifies a set of operations provided by a component to others, while receptacles specify the set of interfaces a

Fig. 1. A typical component model

418

A. Taherkordi et al.

component requires from others. Therefore we are able to reconfigure the system by switching from an old component to a new one implementing the same interfaces.

3

ReWiSe

As mentioned in the previous section, component-scope reconfiguration is proposed for manipulating the whole component. In general, four forms of component reconfiguration can be envisaged: adding a new component, removing an existing component, replacing a component with a new one and migrating a component. Depending on the form of reconfiguration, system consistency should be preserved during reconfiguration time. For instance, in the component replacement form, the currently running component might be in interaction with others, thereby the reconfiguration mechanism should check somehow the dependencies of the replacement candidate to other components. Likewise, the state of a new component should be updated with the last state of the old component. Therefore, for each form of configuration, several checking tasks should be carried out in order to keep system integrity and consistency at an optimum level. Let us consider the sample component configuration depicted in Figure 2. Suppose the Sampler component is the candidate for replacement with a new component. We also assume that the difference between the old and new version is in the implementation of the IReport interface. The four main tasks in carrying out the reconfiguration are as following: (i) checking that the component is not being in interaction with the Logger component before starting reconfiguration, (ii) checking that the component is not being in interaction with the Publisher component before starting reconfiguration, (iii) storing the state of the component, and (iv) creating the new component and transferring the last state to it. Moreover, there are some other small tasks that should be considered for executing a perfect reconfiguration. Although it seems that these steps are necessary in general regardless of the underlying platform limitations, we believe that it is possible to skip some of these steps in order to have a lightweight fashion of reconfiguration. Especially, in the context of WSNs, existing limitations such as resource usage and network bandwidth motivate us to have a more fine-grained approach to the component construct and its interaction model. ReWiSe is a novel definition of software component that is empowered with new features for having a more dynamic component model, along with the basic functionalities of a typical component model. The question that may arise from the above sample is: “for updating an interface implementation in the Sampler component why do we need to replace the whole current component with a new one?” To clarify, it might be better to update only the part of the component that really needs to be updated rather than replacing it with a new one. ReWiSe aims to achieve such a reconfiguration mechanism. Figure 3 illustrates the constituents of the ReWiSe component model. Like other popular component models, the interaction of ReWiSe with other

ReWiSe: A New Component Model

419

Fig. 2. Sample component configuration

components is established through interfaces, receptacles, events, listeners and properties. In fact, the outer white box is similar to what has been described in the previous models [15]. The main dissimilarity is in the implementation of component interface. Particularly, in this model an interface is not implemented as a method within the component body, but it is implemented in a separate component containing “just” the implementation of that interface, and no more functionalities. Let us call these components TinyComponent. Therefore, for each interface of the main component, we have a corresponding TinyComponent implementing that interface. The main component is wrapped with Interface Interceptor Wrapper to route the interface calls of other components to the corresponding TinyComponent of an interface.

Fig. 3. ReWiSe Component Model

Figure 4 shows the template for declaration of a ReWiSe component. In the top box, the main component is described and two next boxes illustrate the implementation of TinyComponents. In the following sections, we explain the concepts of ReWiSe in detail according to the template illustrated in Figure 4. 3.1

TinyComponent

TinyComponent is the representative of an interface implementation. For each interface of the main component, there is a corresponding TinyComponent containing just one method that realizes the interface. For example, in the bottom of Figure 4 there are two TinyComponents implementing the two interfaces of MainComponent. New issues arise related to interaction between TinyComponent and other elements inside the main component, while its connection with the out-

420

A. Taherkordi et al.

Fig. 4. Declaration of a Component in the ReWiSe model

side world of the main component is in the same fashion as in previous models. Firstly, unlike direct interface implementation in the main component which has easy access to the main component variables, in the ReWiSe model TinyComponent is located outside the scope of the main component, so a TinyComponent is not able to reach to the variables of the main component. This problem is resolved by passing a reference of the main component to the TinyComponent, thereby the scope is reachable for TinyComponent through a variable containing a pointer to the main component (see Figure 4). Second question that arises is how TinyComponents can interact among themselves, like what occurs between methods in common component models. Like the first problem, this case is originated from the fact that the scope of the main component is not accessible from the TinyComponent. Similarly to the resolution of the first question, the reference of the main component passed to the TinyComponent can give access to every thing inside the main component, namely, variables and interfaces. In the next section, we discuss in more details how Interface Interceptor Wrapper facilitates such a calling among TinyComponents.

ReWiSe: A New Component Model

3.2

421

Interface Interceptor Wrapper

To systematically access TinyComponents, ReWiSe should be enhanced with a mechanism capable to route calls for a specific interface to the corresponding TinyComponent. Since TinyComponents are going to become the new candidate for replacement in the forthcoming reconfiguration mechanism, component can not maintain the name of a TinyComponent in a hardcode manner. Therefore, the interface interceptor wrapper is responsible for handling dynamically the references to TinyComponents. The first time a service is executed, the wrapper reads from its mapping configuration file the name of the TinyComponent implementing the service and then caches the reference to the corresponding TinyComponent in its local data. Afterward, other requests for that service will be automatically forwarded to the assigned TinyComponent (see Wrapper block in Figure 4). The configuration file contains a set of structured data indentifying the name of the corresponding TinyComponent for each interface. Moreover, the wrapper is responsible for passing the reference of the main component to the TinyComponent (“this” in Figure 4). 3.3

Component Context

One of major challenges in reconfiguration mechanisms is how to preserve the state of a component during the reconfiguration period. Since the unit of replacement in ReWiSe is the stateless TinyComponent, the replacement candidate has not any state to miss. In fact, the state of the component is preserved in the main component. Component Context is an abstract concept indicating the current values of all private and public member variables in the main component. The context is accessible for TinyComponent through the main component reference passed to the TinyComponent method.

4

ReWiSe-Based Reconfiguration

Let us refer again to the sample component configuration shown in Figure 2, and consider how the specification of ReWiSe modifies the reconfiguration mechanism. Figure 5 illustrates the new situation, where Sampler is redesigned according to the standards of the ReWiSe model. Therefore, the three interfaces exposed from Sampler should be implemented in three separate TinyComponents. The reconfiguration logic is still the same as the previous one: updating the implementation of IReport interface. To this end, at the first step the interaction of Sampler with the other components should be checked to make sure that the component is in a safe state for removal. As illustrated in Figure 5, in this case only the dependencies of TinyIReport to others should be checked instead of checking the dependencies of the whole main component to others (later in this section the checking mechanism is explained). Upon transition to a safe state for reconfiguration, rationally the state of Sampler should be considered.Since in the new model the state is captured by Sampler, not by the replaceable TinyComponents, we do not need to consider the step of state preservation.

422

A. Taherkordi et al.

Fig. 5. Sample component configuration based on ReWiSe model

Basically, the three main design concepts of ReWiSe keep the component in a high degree of reconfigurability. Firstly, the notion of TinyComponent makes the behavioral-level reconfiguration possible; thereby if a portion of component (interface implementation) needs to be repaired we do not need to change the full component image. The other advantage of using TinyComponent is that the safe state can be determined only by checking the interactions of the candidate TinyComponent with others rather than checking the interactions of the whole main component. Secondly, the interface interceptor wrapper undertakes the action of switching from the old TinyComponent to the new one. As mentioned before, a mapping configuration file is attached to the wrapper to specify the map between each interface and its corresponding TinyComponent. The final improvement is offered by component state management mechanism. In fact, in previous component models for WSNs, the stateful main component is subject to replacement, while in ReWiSe the stateless TinyComponent becomes the new replaceable unit. Consequently, component variables maintain their values (component context) during the component lifetime. In this paper, we discussed the reconfiguration of TinyComponents, whereas the main component containing TinyComponents may need to be reconfigured as a whole. Since ReWiSe follows the standards of popular component models, the available reconfiguration mechanisms for such models are applicable reconfiguring a complete ReWiSe component as well. 4.1

Safe State for Reconfiguration

The safe state for performing reconfiguration is defined as a situation in which all instances of a component are temporarily idle or not processing any request. That is, in a typical component model the interactions among components must be monitored in order to determine when the target component reaches a configurable state. In ReWiSe, the interface interceptor wrapper is enhanced with a farFromSafety variable for each exposed interface. This variable will be updated in the application scope each time that the interface is called. Before calling a service, farFromSafety is increased by one and after running the service, this variable is decreased by one. Thus, at the arbitrary time of application execution, the value of farFromSafety for a specific interface indicates the number of TinyComponent instances running in the memory. In the template declared in Figure 4, the safe state checking code appears in the Wrapper block, before and after calling the method of TinyComponent. Once this value reaches zero,

ReWiSe: A New Component Model

423

all other requests for that interface will be blocked and the reconfiguration unit loads the new TinyComponent. Afterwards, the blocked requests are served by the new TinyComponent in stead. 4.2

A Typical ReWiSe-Based Application

We are currently working on a home monitoring application. Home monitoring systems have been in use for many years [17]. The emergence of wireless technologies reduces the cost of employing such application through easy deployment of monitoring devices. Future home monitoring applications are characterized as being filled with different sensor types that can determine various types of context information and react to them through actuators, e.g., if the temperature sensors in a room report unusual data for a time period the smoke detector sensor should react and increase the sensing sample rate. The various dynamic scenarios in such applications make the application design method different from others in terms of application reconfigurability and adaptability. Our hypothesis is that by using ReWiSe as the building block of such application the cost of dynamic reconfiguration will be reduced.

5

Related Work

The early well-known component models in distributed system area do not support inherently dynamic reconfiguration of components [7], [8], [9], because these models provide the basic building blocks for component-based software, and the core design aspects of such models do not consider features such as reconfigurability of component. In the context of reconfigurable component models, Fractal has been known as a pioneering model for dynamic software applications [10]. Fractal can be used with various programming languages to design, implement, deploy and reconfigure various systems and applications, from operating systems to middleware platforms. Although Fractal is a comprehensive and extensible model for component composition and assembly, its minimal core is a heavyweight extensible unit with various features suitable for large scale applications needing different degrees of reconfiguration for different software granularity. Moreover, concepts in ReWiSe and Fractal are different to some extent. For instance, the content part of Fractal is devoted for handling component compositions, while in ReWiSe we adopt component context to preserve component state. Also, the interactions among TinyComponents in ReWiSe are handled more easily in compare to the model of interactions between sub-components in Fractal. A few works have been done recently to enable high-level software reconfiguration for WSN applications [14], [15], [16]. All these proposals adopt the general common component model as the basic building blocks for application, regardless of the complexity of reconfiguration in terms of space, computation and communication.

424

6

A. Taherkordi et al.

Conclusions and Future Work

This paper presented a new component model, called ReWiSe, to facilitate dynamic reconfiguration of applications in resource-limited networks such as WSNs. The component model introduces the notion of TinyComponent for achieving a lightweight behavior-level reconfiguration for WSNs. Using ReWiSe, not only a consistent reconfiguration is guaranteed, but also the reconfiguration overhead is reduced by updating only the portion of a component (TinyComponent) that really needs to be updated. We are currently developing a middleware to enable reconfiguration and adaptation for dynamic WSN applications. The performance of the middleware is expected to be better when the application building blocks are ReWiSe components. One possible future work is to exploit ReWiSe in other computing areas such as mobile or embedded systems. Acknowledgments. This work was partly funded by the Research Council of Norway through the project SWISNET, grant number 176151.

References 1. Puccinelli, D., Haenggi, M.: Wireless Sensor Networks: Applications and Challenges of Ubiquitous Sensing. IEEE Circuits and Systems Magazine 5(3), 19–31 (2005) 2. Costa, P., et al.: The RUNES middleware for networked embedded systems and its application in a disaster management scenario. In: Proc. of the 5th Int. Conf. on Pervasive Communications (PERCOM) (2007) 3. Akyildiz, I.F., Kasimoglu, I.H.: Wireless Sensor and Actor Networks: Research challenges. Ad Hoc Networks Journal 2(4), 351–367 (2004) 4. Alia, M., Hallsteinsen, S., Paspallis, N., Eliassen, F.: Managing Distributed Adaptation of Mobile Applications, In: Proc. of the 7th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS) (2007) 5. Hill, J., et al.: System Architecture Directions for Networked Sensors. In: Proc. of International Conference on Architectural Support for Programming Languages and Operating systems (ASPLOS) (2000) 6. Dunkels, A., Gr¨ onvall, B., Voigt, T.: Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors. In: Proc. of the First IEEE Workshop on Embedded Networked Sensors (2004) 7. Microsoft, COM, http://www.microsoft.com/com 8. Sun Microsystems. EJB, http://java.sun.com/products/ejb/index.html 9. OMG. CORBA, Object Management Group, http://www.omg.org 10. Bruneton, E., Coupaye, T., Leclercq, M., Quma, V., Stefani, J.B.: The FRACTAL component model and its support in Java. Softw., Pract. Exper. 36(11-12), 1257– 1284 (2006), http://fractal.objectweb.org 11. Coulson, G., et al.: A generic component model for building systems software. ACM Trans. Computer Systems, 1–42 (2008) 12. McKinley, P.: Composing Adaptive Software. Computer 37(7) (2004) 13. Poladian, V., Sousa, J.P., Garlan, D., Shaw, M.: Dynamic Configuration of Resource-Aware Services. In: ICSE, pp. 604–613. IEEE Computer Society, Los Alamitos (2004)

ReWiSe: A New Component Model

425

14. Costa, P., Coulson, G., Mascolo, C., Mottola, L., Picco, G.P., Zachariadis, S.: A Reconfigurable Component-based Middleware for Networked Embedded Systems. International Journal of Wireless Information Networks 14(2) (2007) 15. Mottola, L., Picco, G., Sheikh, A.: FiGaRo: Fine-Grained Software Reconfiguration for Wireless Sensor Networks. In: Verdone, R. (ed.) EWSN 2008. LNCS, vol. 4913. Springer, Heidelberg (2008) 16. Balasubramaniam, D., Dearle, A., Morrison, R.: A Composition-based Approach to the Construction and Dynamic Reconfiguration of Wireless Sensor Network Applications. In: Proc. of the 7th Symposium on Software Composition (SC) (2008) 17. Mozer, M.: Lessons from an Adaptive Home. In: Smart Environments: Technology, Protocols, and Applications, pp. 273–298. Wiley, Chichester (2004)