Efficient and Portable Reprogramming Method for High ... - IEEE Xplore

First International Workshop on Wireless Communication and Networking Technologies for Rural Enrichment

Efficient and Portable Reprogramming Method for High Resource-constraint Wireless Sensor Nodes Xing Liu, Kun Mean Hou, Hongling Shi

Chengcheng Guo

LIMOS Laboratory UMR 6158 CNRS Blaise Pascal University Clermont-Ferrand II Clermont-Ferrand, France {liu, kun-mean.hou, hongling.shi}@isima.fr

Laboratory of Internet and Information Technology Wuhan University Wuhan, China [email protected]

Haiying Zhou School of Computer Science & Technology Harbin Institute of Technology Harbin, China [email protected] Abstract—Wireless sensor networks (WSNs) will play a significant role in precision agriculture to support sustainable development. Since it’s a more economic and practical solution to deploy reprogrammable sensor nodes than non-reprogrammable ones, sensor node reprogramming technique becomes a key issue. Currently, the challenge of sensor node reprogramming mainly results from the resource constraint and diverse platforms in WSNs. In our work, we firstly ported a small footprint Java Virtual Machine simpleRTJ to wireless sensor nodes based on AT91SAM7S256 microcontroller for a reprogramming task. This method not only facilitates the application development but also shows its advantage in heterogeneous environments. However, the high memory resource requirement of simpleRTJ makes it inappropriate for some ultra low power 8-bit microcontrollers, such as ATMEGA1281, which has particularly constrained resource. Thus we propose a new efficient and portable reprogramming method (EPRM) by using pre-linked native code to reduce memory footprint and by the way to reduce energy consumption. To validate this new approach, EPRM is implemented on two platforms (32-bit and 8-bit cores) and its efficiency in terms of resource consumption (memory and energy) is evaluated by comparing with simpleRTJ ones. The obtained results show that EPRM is well adapted to high resource-constraint wireless sensor nodes. Keywords - reprogramming; wireless sensor resource-constraint; embedded Java virtual machine

networks;

I. INTRODUCTION Wireless sensor networks (WSNs) have played an important role in precision agriculture. Sensor nodes can monitor the agriculture environment, collect and process the sensing data, and do decisive self-adapting operations if the decision support system has been implemented. Recently, the rapid technology development in WSNs makes it become more and more significant and practical to deploy wireless sensor nodes in agriculture areas. Since it’s essential and economic to implement sensor nodes with changeable functionality, sensor nodes

978-1-4577-2014-7/11/$26.00 ©2011 IEEE

455

reprogramming technique becomes an important issue in WSNs. In addition, the application design-implement-test -debug development cycle also requires sensor nodes to be reprogrammed. The primary challenge for reprogramming wireless sensor nodes is the constraint resources: memory and energy [1]. In addition, WSN hardware and software environments are diverse. Thus the portability is also a key feature for the reprogramming method. Currently, many different reprogramming mechanisms have been developed, including full image replacement [2, 3, 4], script language [5, 6], virtual machine [7-12], loadable modules [13-16] and diff-based approaches [17-22]. However, most of these methods require important memory resource [3-6, 15], specific utilities [17, 19] or Operating System (OS) support [7, 14], which limit their applicable domains. The first contribution of this paper is the performance evaluation of reprogramming wireless sensor nodes by using embedded Java Virtual Machine (JVM). The second contribution is the design and implementation of a new efficient and portable reprogramming method (EPRM) which can be used even on high resource-constraint wireless sensor nodes. Furthermore, the performances of these two methods are compared from several aspects in the experimental work. Finally, the alternative and ongoing work is addressed. II.

RELATED WORK

Many different reprogramming methods have been developed for wireless sensor nodes. Some focused on application development facility [5, 6, 7], some had the objective of addressing scale and heterogeneity challenges [8, 11, 12], while others motivated by the potential of decreasing energy consumption with compact code [7, 18, 19, 20]. In this section, five different kinds of reprogramming approaches for sensor nodes are introduced.

contain the function changes within a given region as far as possible. Li et al. [20] considered the code shift problem from the compiler's viewpoint by keeping the new code the same as the old one as much as possible when compiling. While Rajesh et al. mitigate the function and global variable shift effects by two multi-hop incremental reprogramming protocols Hermes [21] and Zephyr [22].

A. Full Image Replacement This mechanism, which is typically used in TinyOS [2], has been adopted in Deluge [3] and XNP [4]. The main drawback of these methods is the poor ability to scale to large networks due to the high overload of energy and time consumption during the transmit process. B. Script Language BASIC variants, Python interpreters and TCL machines are some script language examples for embedded system. SensorWave [5] supports Tcl-based control scripts for reprogramming, while Tinypy [6] implements python machine with only 64 kilobytes of code. However, most script interpreters target at platform with rich resource. C. Virtual Machine Since Virtual Machine (VM) can not only simplify the application programming with high level abstractions, but also address the heterogeneous environments challenge due to the platform-independent code support, many researchers have focused on this area. Maté [7] is a sound VM targeting at facilitating application development and leveraging energy-efficient large-scale software updates for wireless sensor nodes, whereas it has some limitations in flexibility, concurrency and propagation. Levis et al. enhanced Maté by designing application specific virtual machines ASVMs [8] which supported a wide range of application domains. MagnetOS [9], a distributed OS that abstracts the whole network as a unified JVM, offers a runtime environment for java programs. VMStar [10], which is a framework for building specific VM application, has been used by Koshy et al. to implement a subset of JVM. Darjeeling [11], a small footprint and feature-rich VM for WSN, enables meaningful Java applications. And MiniMV [12], which bases on TinyOS and acts as an embedded middleware for WSN system, is a recent implementation of Embedded JVM. D. Loadable Modules Typically, this mechanism requires the Operating System support. SOS [13] is an OS with a small kernel which allows energy-efficient reprogramming by using dynamically loadable modules, however, position independent code is used in this system which limits its applicability. Contiki [14] is another example of OS that support loadable modules reprogramming by implementing run-time dynamic linking mechanism. Impala [15] is a layered middleware which support application modularity and reparability; it performs software update by linking in updated modules. And TOSthreads [16], a fully functional thread library designed for TinyOS, can also support the functionality of replacing the application modules dynamically. E. Diff-based Approaches Reprogramming with diff-based approach is an advisable choice for a small update in the system code, e.g., a bug fix, as only minor differences between modified and original binary need to be distributed. Reijers et al. [17] produce an edit script based on the binary differences and inject it into the network after various optimizations. Jeong et al. [18] develop a similar approach by using rsync algorithm. Koshy et al. [19] reduce the effects of code shift by modifying the linking procedure to

456

III. REPROGRAMMING WITH EMBEDDED JVM The original sensor nodes developed by us, named as Live nodes [23], are equipped with AT91SAM7S256 microcontroller with 64 kilobytes of RAM and 256 kilobytes of ROM, a GPS transceiver, as well as a set of sensors and a Zigbee Pro transceiver. SimpleRTJ [24] is chosen on this platform to evaluate the performance of reprogramming based on JVM. SimpleRTJ is a small footprint and clean room implementation of JVM for embedded and customer devices. It's designed to run as a stand-alone miniature Java OS, implements thread support with object's monitor locking and wait/notify synchronization, be able to handle asynchronous events response as well as create software timers in single shot or periodic mode. Optimized set of standard libraries is used in simpleRTJ to preserve small memory footprint of Java applications, and in contrast to the other VM implementation that uses dynamic class loading, simpleRTJ executes pre-linked Java applications by linking all the class files comprising the application together and replacing all the symbolic references inside with offsets and indexes. This process not only simplifies the Java VM run-time architecture, but also improves the application code execution time. Moreover, numbers of start-up configuration options allow simpleRTJ to execute different Java applications without the need to reload each time. Besides the features above, some other features that led us to choose simpleRTJ for Live nodes reprogramming includes: 

SimpleRTJ divides the whole software space into both application and system space. It provides a set of high-level abstract interfaces, which facilitates the application development as the users merely need to focus on the application space other than the whole one. Furthermore, it reduces the reprogramming code size by transmitting only the application code.



SimpleRTJ execute platform-independent application code, enabling applications to be deployed uniformly in heterogeneous environments.



Compared with C language which is traditionally used for embedded applications, Java language provides many benefits for developers, such as to perform sound, robust, and reusable software as well as to facilitate the application design, development, test and maintenance process.



Standard Java Development Kit (JDK) can be used to compile Java applications for simpleRTJ, no special utilities are required to produce the final application image.

The implementation and test of simpleRTJ on Live nodes platform prove that it's a sound choice for sensor nodes reprogramming, especially in hybrid networks. However, some drawbacks are likewise observed during the experiment work. Firstly, even for a simple led blink program, the java application image size is more than 3 kilobytes, which is relatively too big for wireless sensor nodes reprogramming task. This drawback mainly results from the interpretive character of Java language, as some additional information besides the executive bytecode should be included in each class to support the run-time interpretation. Since sending one bit of data is equal to 3000 instructions processing on a general-purpose processor with 100MIPS/W power [25], enormous energy will be consumed if reprogramming with simpleRTJ, making this method a severe impediment for energy constraint sensor nodes. Some related methods, e.g., Maté, reduced the application code size by using an assembly-like language with a limited number of instructions, whereas it lost the advantage that JAVA language possesses. Meanwhile, it can only be used for a specific application and should implement on top of TinyOS. Secondly, although simpleRTJ is a small footprint implementation of JVM with the requirement of no more than 18-24 kilobytes of ROM and about 0.2 kilobytes of RAM to run [24], it still becomes a challenge for some high resource-constraint sensor nodes. E.g., our new generation sensor nodes, named as iLive nodes, are designed to use ATMEGA1281 microcontroller due to this microcontroller’s predominant features in low energy consumption and embedded size. Since the operating system, full-compliant Zigbee protocol stack and peripheral hardware drivers have taken up 7.1 kilobytes of RAM and 106.2 kilobytes of ROM resources, only 1 kilobyte of RAM and 22 kilobytes of ROM resources are left which are insufficient for the execution of simpleRTJ and its Java application code, not to mention the other functionality extension on the sensor nodes.

Like what simpleRTJ does, EPRM may be considered as middleware (intermediate layer) to separate the application code from system one, which can ease application development, and more significantly decrease the energy consumption by transmitting only application code.



Use the same programming language in both application and system space to avoid the necessity of establishing a new run-time environment in EPRM for the application code execution. With this mechanism, the EPRM run-time architecture can be simplified, which will decrease memory footprint as well as facilitate the portability process.



Use native code instead of bytecode to avoid the extra energy and time consumed during the interpretation process.



Use pre-linked code other than dynamic loadable modules, because dynamic loadable mechanism mostly depends on a given OS and requires more resources.

In conclusion, EPRM can be defined as a reprogramming method, which acts as a middleware between the applications and hardware platform, executes pre-linked native binary code, consumes less memory and energy resources, as well as can be ported easily to different wireless sensor platforms. B. Implementation of EPRM According to the design principle described above, we implemented EPRM on the iLive nodes platform with C as the development language and AVR GNU as the compiler. The implementation work can be summarized into the following four steps: 1) Function Declaration. As the whole software project will be divided by EPRM into both application project and system project. Thus two kinds of functions should be defined: application consumer functions and system implementer functions. Consumer functions can be followed to access the services and resources provided in the system implementer functions. Fig. 1 briefly depicts the ERPM software structure.

Thirdly, simpleRTJ's advantage of deploying applications uniformly in heterogeneous environments is under the precondition of porting it across various node architectures, whereas the portability of simpleRTJ is not easy because of the major numbers of bytecode implementation functions and the different memory access operations in different platforms.

Application Project

In addition, compared with binary code, the extra interpretation operation of bytecode increases the execution time, and then consumes more energy. Thus for high energy constraint application, simpleRTJ is not suitable.

Customer function call

System Project EPRM

These drawbacks motivate us to design and implement a new efficient and straightforward portable reprogramming method that can be applicable to the wireless sensor nodes even with high resource constraint. And EPRM, being introduced in the next section, targets to address this challenge. IV.



System implementer functions peripheral device drivers

Figure 1.

DESIGN AND IMPLEMENTATION OF EPRM

……

network protocol stack

Software structure with EPRM.

2) Application Memory Resource Reservation. Inside the system project, a given ROM memory space should be reserved for the storage of application code, while a given RAM memory space for the application data.

A. EPRM Design Principle The rigorous requirement to EPRM basically determines its design principle as follows:

457

Although the application project is a built-independent one from the system project, there is still no necessity to reserve space in RAM memory for the application code execution stack. This is due to the design principle of using the same language in the two projects, under which condition the whole application code can just be regarded as a function in the system project, so a common stack can be shared by the two projects. However, in some reprogramming method such as simpleRTJ, a given space for Java program run-time heap should be reserved in RAM memory since another language other than Java is used in the system project.

/* Application customer function table */

/* System implementer function call table */

// Functions order in this table must match that // in the System implementer function call table

// The member order in this table must // match that in Application customer // function table

application_customer_function_table:

void sys_implementer_fun_call_table(void) {

/* Set the type of sensor node */ APP_node_type_set /* member 1 */ /* Set the channel for sensor node */ APP_node_channel_set /* member 2 */

asm ("CALL SYS_node_channel_set;"); asm ("RET"); /* member 2 */

/* Set the sleeptime for sensor node */ APP_sleeptime_set /* member 3 */

asm ("CALL SYS_sleeptime_set;"); aSm ("RET"); /* member 3 */

…………

3) Pre-linking Operation. One method to implement pre-linking for application customer functions is to record all the physical addresses of the implementer functions after the system project is built and then relocate the call address of all the customer functions. This is what Dunkels et al. mentioned in [14]. The severe drawback of this method is that any change to the system project would cause the application image become useless as the addresses of the implementer functions in the new system project were different from when the application program was linked. Dunkels et al. solved this problem by implementing dynamic linking on top of Contiki OS [14], but this method can't be adapted to iLive nodes due to the perceived run-time overhead in both energy consumption and memory resource requirement.

asm ("CALL SYS_node_type_set;"); asm ("RET"); /* member 1 */

…………

}

Figure 2.

Application customer function table and system implementer function call table.

4) Passing of Input Parameters and Return Value. As the input parameters of customer functions are assigned in the application project whereas they will actually be used in the implementer functions in the system project, EPRM should afford the task of passing parameters properly between these two projects, and what EPRM should do for this stage is determined by how customer functions and implementer functions operate the input parameters. If there is a transmit gap between them, EPRM should make it up.

In EPRM, in order to pre-link customer functions without pre-knowing the implementer functions’ physical addresses, an implementer function call table is established in the system project, depicted in Fig.2. This table will be put in a fixed address and built together with the implementer functions, and the functionality of each entry in it is to call different implementer functions. With this table, the application customer function can be linked to an appropriate entry’s address in this table other than the physical address of the implementer function. In this case, the change to system project will not have an influence to the execution of application image, as the jumping address of each entry in the table will adapt to the new implementer functions’ address after a new built process. To pre-link every consumer function, two values should be calculated. One is the position value in the raw application image where the pre-linking operation should be done. This value can be calculated by analyzing every relocation entry in the application object files following the format standard of Executable and Linkable Format (ELF) [26]. If the associated symbol of an entry is found to be a customer function one, then the interrelated address information will be withdrawn from this entry to locate the pre-linking position in the image. The other one to calculate is the pre-linked address value for the customer function, which is actually the physical address of its corresponding entry in the implementer function call table. For this calculation, a customer function table is established in the application project, depicted in Fig. 2, inside which all the customer function names are listed and the entry order in this table match that in the implementer function call table. Under these conditions, the pre-linked address of a customer function can be calculated with its index value in the customer function table, the fixed location address and entry size of implementer function call table.

Seen from the assembler language in the application project, before the execution of a calling operation for a customer function, all the input parameters will be stored one by one into the registers beginning from R24, while at the beginning of the corresponding implementer function the value of input parameters will be obtained from register R24 one by one. So nothing needs to be done in EPRM for the input parameters passing, this still results from the design principle of using the same language in both the application and system space. For the passing of returned values, the same mechanism as input parameters is applied. V. EXPERIMENTAL WORK To evaluate EPRM, its performance is compared with simpleRTJ ones in terms of supported application image size, memory requirements, execution efficiency and portability complexity on both Live node (ARM core) [23] and iLive node (AVR core) platforms. A. Experimental Details The iLive nodes, shown in Fig. 3, are equipped with ATMEGA1281 microcontroller with 8 kilobytes of RAM and 128 kilobytes of ROM, 4 Watermark sensors, 3 Decagon sensors, 1 temperature sensor, 1 air humidity sensor, 1 light sensor, 1 RS232/USB slave port, as well as an IEEE802.15.4 ZigBee wireless access medium. Note that it's not a sound way to run simpleRTJ on iLive nodes due to the insufficient memory resource, yet it's still feasible for the evaluation work as only a very simple application program will be used. As simpleRTJ sources are available in three memory models: linear 64KB, banked 64KB and linear 16MB [24]. In terms of the sensor platform features, linear 16MB model is chosen for Live nodes, while linear 64KB model for iLive nodes.

458

Moreover, C language is used in both the two reprogramming methods and standard GNU tool chains are chosen as the compiler with the optimization option for small size.

Figure 3.

Table II shows the comparison results of required memory resource for the two different methods. From the results, it can be seen that for EPRM, just 1 kilobyte of ROM is required since only a system implementer function call table is needed to add in the system project. While for simpleRTJ, up to 320 bytes of RAM [27] and almost 20 kilobytes of ROM are needed for its basic execution. 3) Executive efficiency As both EPRM and simpleRTJ act as a middleware between the application customer function and the system implementer function, therefore the execution efficiency can be evaluated from the overload of execution time and energy consumption between the executions of these two kind functions. The example shown in Fig. 4 is also used for this measurement. Moreover, the corresponding system led blink implementer function is defined as an empty block to ensure to the maximum that only the execution of reprogramming method is involved during this experiment stage. The measured value is shown in Table III. It can be seen that compared with simpleRTJ, EPRM has a much better performance in execution time as well as energy consumption.

Figure of iLive sensor node.

B. Performance Comparison 1) Application Image Size. Application image size is a key performance metric for reprogramming method as it’s a crucial factor for the energy consumption during the process of code update through wireless access medium. For the comparison, a led blink program is implemented in C language for EPRM and Java language for simpleRTJ, shown in Fig. 4. The image size results are shown in Table I. From the results, it can be seen that on both sensor platforms, EPRM has a great advantage over simpleRTJ from the image size aspect. /* Example application program for EPRM method */

import application.customer.*;

int main(void) {

class Test { static void main() {

TABLE I. Sensor Platform

iLive node

Live node

simpleRTJ EPRM simpleRTJ

1

0

17.5

320

1

0

19.2

320

TABLE III. COMPARISON RESULTS OF EXECUTIVE EFFICIENCY Executive Situation Sensor Platform

iLive node

}

Figure 4.

Memory Resource Required RAM (bytes)

ROM (kilobytes)

EPRM

Live node

}

}

Reprogramming method

iLive node

int i, j; for(i = 0; i < 1000; i++) for(j = 0; j < 2000; j++) { AppCustomer.LedBlink(); }

return 0;

COMPARISON RESULTS OF REQUIRED MEMORY RESOURCES

Sensor Platform

/* Example application program for simpleRTJ method */

#include

int i, j; for(i = 0; i < 1000; i++) for(j = 0; j < 2000; j++) { AppCustomer_LedBlink(); }

TABLE II.

Live node

Application examples for EPRM and simpleRTJ.

Reprogramming method

Voltage (V)

Electric current (mA)

Executed time (S)

Energy consumption (mJ)

EPRM

3

10.5

70

2205

simpleRTJ

3

10.5

2425

76387.5

EPRM

5

27.6

11

1518

simpleRTJ

5

27.3

285

38902.5

COMPARISON RESULTS OF APPLICATION IMAGE SIZE

Dependent reprogramming method

Application Image Size (bytes)

EPRM

102

simpleRTJ

2264

EPRM

220

simpleRTJ

3620

4) Complexity of portability For simpleRTJ, although it targets at providing a straightforward portability, substantive porting work still needs to be done in some cases, one example for the iLive nodes is that instead of using pointer, load program memory instruction should be used to access the data stored in program space, this will cause many modifications to numbers of bytecode implementation functions. To implement EPRM on a specific platform, only an implementer function call table is needed to add in the system project. Although the raw object files needs to be analyzed for pre-linking operation during the post-built process, it's still not a difficult task as ELF is currently one of the most common object code format and enough software utilities have been provided by GCC for manipulating ELF files. From this point

2) Memory resource requirements Since simpleRTJ has the functionality besides reprogramming such as multi-threading and runtime notifications, these related modules are not compiled for the rationality of comparison.

459

of view, EPRM is a straightforward portable reprogramming method.

[4]

J. Jeong, S. Kim, and A. Broad. Network reprogramming. TinyOS documentation, 2003. Visited 2011-06-09. http://www.tinyos.net/tinyos-1.x/doc/NetworkReprogramming.pdf.

C. Alternative Implementation With EPRM or simpleRTJ, the application program in WSN becomes very simple, making it practicable to reprogram wireless sensor nodes from Internet by webpage, thus an unwell-rounded user-friendly integrated development environment is implemented by us with the objective of facilitating the process of upgrading new code and acquiring sensor nodes information remotely from Internet. The global website address to access is http://edss.isima.fr.

[5]

A. Boulis, C. Han, and M. B. Srivastava. Design and implementation of a framework for efficient and programmable sensor networks. In Proc. of MobiSys, May 2003. Tinypy group. Tinypy, a minimalist implementation of python in 64k of code. online at http://www.tinypy.org. Visited 2011-06-09. P. Levis and D. Culler. Maté: A tiny virtual machine for sensor networks. In Proc. ASPLOS-X, San Jose, CA, USA, Oct. 2002.. P. Levis, D. Gay, and D Culler. Active sensor networks. In Proc. USENIX/ACM NSDI, Boston, MA, USA, May 2005. H. Liu, T. Roeder, K. Walsh, R. Barr, and E.G. Sirer. Design and Implementation of a Single System Image Operating System for Ad Hoc Networks. In Proc. ACM MobiSys, pp. 149-162, 2005.

[6] [7] [8] [9]

In addition, simpleRTJ provides a friendly development environment for the users and also shows its advantage in heterogeneous environments, whereas its primary drawback in huge application code size restricts its use for some resource-constraint sensor platforms. To overcome this problem, several methods can be applied. One is to reduce the code size of application libraries by optimizing them according to a specific application domain. One is to allocate the application code particularly at the top 64 kilobytes of ROM space, and then only 2 bytes other than 4 bytes can be used to address the symbols and indexes in the classes, which can decrease the final image size in a degree. Another method is to change the way of linking classes by putting all the indispensable constant classes at the beginning of the application image, after that, instead of transferring and replacing the whole image, only the changeable part located at the end of the image is needed to reprogram each time.

[10] J. Koshy and R. Pandey. Vm*: Synthesizing scalable runtime environments for sensor networks. In Proc. SenSys, San Diego, CA, USA, November 2005. [11] N. Brouwers, K. Langendoen, P. Corke: Darjeeling, a feature-rich vm for the resource poor. In Proc. SenSys, New York, NY, USA, ACM (2009) 169–182. [12] C. Cota, L. Aguilar, G. Licea. A Java Compatible Virtual Machine as an Embedded Middleware for Wireless Sensor Networks. In Proc. CERMA, Cuernavaca, Mexico, September 2010. [13] C. Han, R. K. Rengaswamy, R. Shea, E. Kohler, and M. Srivastava. Sos: A dynamic operating system for sensor networks. In MobiSY. ACM Press, 2005. [14] A. Dunkels, N. Finne, J. Eriksson, and T. Voigt. Run-time dynamic linking for reprogramming wireless sensor networks. In Proc. SenSys, Boulder, Colorado, USA, 2006. [15] T. Liu, C. Sadler, P. Zhang, and M.Martonosi. Implementing software on resource-constrained mobile sensors: Experiences with Impala and ZebraNet. In Proc. MOBISYS, June 2004. [16] K. Klues, C.-J. M. Liang, J. Paek, R. Musaloiu-E., P. Levis, A. Terzis and R. Govindan. TOSThreads: Safe and Non-Invasive Preemption in TinyOS. In Proc. SenSys, Berkeley, CA, Nov. 2009. [17] N. Reijers and K. Langendoen. Efficient code distribution in wireless sensor networks. In Proceedings of the 2nd ACM international conference on WSNA, pp. 60–67, 2003. [18] J. Jeong and D. Culler. Incremental network programming for wireless sensors. In Proc. IEEE SECON, October 2004. [19] J. Koshy and R. Pandey. Remote incremental linking for energy-efficient reprogramming of sensor networks. In Proceedings of the second European Workshop on Wireless Sensor Networks, 2005.

VI. CONCLUSION We have presented an efficient and portable reprogramming method named EPRM by using pre-linked native code. The performances of EPRM in term of resource consumption, execution efficiency and portability complexity are compared with simpleRTJ ones. The implementation and validation on Live and iLive platforms proved that EPRM is well adapted to high resource-constraint wireless sensor nodes. For the ongoing work, this new technique will be evaluated on 200 iLive nodes and the obtained experimental results will be used to validate the large scale WSN model acquired by using SHAWN simulator.

[20] Weijia Li, Youtao Zhang, Jun Yang, and Jiang Zheng. Ucc:update-conscious compilation for energy efficiency in wireless sensor networks. In Proc. PLDI, Jun. 2007, pp. 104-109. [21] R. K. Panta and S. Bagchi. Hermes: Fast and Energy Efficient Incremental Code Updates forWireless Sensor Networks. In Proceedings of IEEE INFOCOM, 2009.

ACKNOWLEDGMENT We would like to thank the 'China Scholarship Council' (2009627016), 'Conseil Général du Puy-de-Dôme' (France) and the International scientific cooperative research program of China (2010DFA14400) for their supports to this project.

[22] R. K. Panta, S. Bagchi, and S. Midkiff. Efficient incremental code update for sensor networks. ACM TOSN, Volume 7 Issue 4, February 2011, ACM New York, NY, USA. [23] K. M. Hou et al.. LiveNode: LIMOS versatile embedded wireless

sensor node. Journal of Harbin Institute of technology, vol(32), pp.139-144, Oct. 2007.

REFERENCES [1]

[2]

[3]

[24] RTJ Computing Pty. Ltd. simpleRTJ a small footprint Java VM for embedded and consumer devices. online at http://www.rtjcom.com/. Visited 2011-06-09. [25] Wassim Masri, Zoubir Mammeri. Middleware for Wireless Sensor Networks: Approaches, Challenges and Projects. In Proc. ICSPC, November 2007, Dubai, United Arab Emirate.

R. Sugihara and R. K. Gupta. Programming models for sensor networks: A survey. ACM Transactions on Sensor Networks, 4(2):1-29, March 2008, ACM New York, NY, USA. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for networked sensors. In Proc. ASPLOS, Cambridge, MA, USA, Nov. 2000, pp. 93–104, ACM. J. W. Hui and D. Culler. The dynamic behavior of a data dissemination protocol for network programming at scale. In Proc. SenSys, Nov. 2004.

[26] TIS Committee. Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2, May 1995. [27] RTJ Computing Pty. Ltd. Developer’s Guide to Simple Real Time Java. online at http://rtjcom.com/downfile.php?f=srtjdoc. Visited 2011-06-16.

460