2012 Wireless Advanced (WiAd)
Efficient Middleware for User-friendly Wireless Sensor Network Integrated Development Environment Xing Liu, Kun Mean Hou, Honglin Shi
Chengcheng GUO
LIMOS Laboratory UMR 6158 CNRS Blaise Pascal University Clermont-Ferrand II Clermont-Ferrand, France {liu, kun-mean.hou, shi}@isima.fr
Laboratory of Internet and Information Technology Wuhan University Wuhan, China
[email protected] close effect on both the energy consumption and the new code wireless transmission success probability [17]. Thus, it's significant to implement a user-friendly WSN integrated development environment (IDE) to meet these challenges. Besides, sensor nodes are mostly equipped with constraint memory and energy resources [18], therefore any sound approach targeting at this objective should have a low resource requirement.
Abstract—Wireless sensor networks (WSNs) have played an important role in widespread applicable domains. However, the programming and reprogramming processes in WSNs are complicate, this results from the diverse software and hardware platforms in WSNs, the constraint memory and energy resources on sensor nodes as well as the unstable wireless transmission process, etc. Thus, it’s significant to design and implement an efficient user-friendly integrated development environment (IDE) for the WSN users. Several related mechanisms have been implemented, such as script language machines, dynamic linking mechanism, embedded Java virtual machine. But these methods are not suitable for the high resource-constraint sensor nodes. In this paper, a middleware named EMIDE is implemented for providing a user-friendly WSN IDE. This middleware simplifies the user programming process and improves the reprogramming performance by separating the application part from the lowlevel system one. Moreover, it provides sufficient functionalities for the application development and has low requirements to the memory and energy resources. To evaluate the performances of EMIDE, it is compared with Embedded Java Virtual Machine (simpleRTJ) and Contiki dynamic linking mechanisms in terms of resources consumption, application code size and execution efficiency. The obtained results show that EMIDE is an efficient method to provide a user-friendly WSN IDE, even on the high resource-constraint sensor nodes.
One effective method to address the challenges above is to develop a middleware which divides the whole software space into both application and system spaces, and provide sufficient services from the system space to application one, depicted in Fig.1. By this way, not only the application programming process will be simplified as the WSN users only need to focus on the application space without the necessity of considering the low-level system details, but also the reprogramming performance will be improved since only application code other than the full image needs to be replaced. APPLICATIONI SPACE
SYSTEM SPACE
Keywords - middleware; wireless sensor network; development environment
I.
Low-level System Parts (OS, Device drivers, etc)
EXECUTIVE IMAGE 2
Figure 1. Elementary diagram for the system structure with middleware
INTRODUCTION
Wireless sensor networks (WSNs) have played an important role in diverse areas, such as precision agriculture [1, 2, 3], industrial monitoring and control [4, 5, 6], smart medical care [7, 8, 9], smart home [10, 11, 12], military battlefield surveillance [13, 14], etc. Its widespread applicable domains make WSN technique become a key and hot issue nowadays.
Several related mechanisms have been developed to separate the application part from the system one, such as script language [19, 20], loadable modules [21, 22] and embedded Java Virtual Machine (EJVM) [23 - 30]. However, the memory and energy resource consumptions of these methods are too high for the rigorous resource-constraint wireless sensor nodes, e.g., the sensor nodes equipped with ATMEGA1281 as the microcontroller. Therefore, the objective of implementing an efficient user-friendly WSN IDE with low resource consumption is targeted in this paper.
To develop on WSN nodes, programming and reprogramming are two important stages. The challenges for programming process mainly focus on two aspects, one is that WSN users may not be experts [15], the other is that hardware and software platforms in WSNs are diverse [16]. And for the reprogramming process, updating with a small code size is another critical challenge, because the code size will have a
978-1-4577-2194-6/12/$31.00 ©2012 IEEE
MIDDLEWARE (Intermediate Layer)
EXECUTIVE IMAGE 1
The first contribution of this paper is the performance evaluation of script language, dynamic linking and EJVM mechanisms on providing a user-friendly IDE for the WSN
22
features required from any decent JVM implementation, including:
users. The second contribution is the design, implementation and evaluation of a new efficient middleware EMIDE. Furthermore, a practical remote reprogramming work is presented and the ongoing work is addressed. II.
JAVA APPLICATION SPACE OPTIMIZED JAVA LIBRARY
RELATED WORK
JAVA APPLICATION PROGRAM
Script language, dynamic linking and EJVM methods all separate the application program from the low-level system one. Therefore, a more user-friendly IDE is provided to the users if compared with the traditional monolithic system.
CLASS FILE 1
…
JDK
CLASS LINKER
CLASS FILE N
JAVA APPLICATION IMAGE
simpleRTJ
A. Script language Script language method has been implemented in several different ways, such as TCL machine [19], Python machine [20], etc. It avoids the process of compiling, whereas the high resource requirement restricts its employment on the resourcesconstraint WSN nodes.
Embedded Java Virtual Machine SYSTEM SPACE
JAVA RUN-TIME OPERATING SYSTEM MEMORY MANAGEMENT ASYNCHORONOUS EVENT
B. Dynamic linking Dynamic linking method uses loadable modules to perform programming and reprogramming, only parts of the system need to be modified when deploying a new program to the WSN nodes. It has been implemented in several OS, such as Contiki [21], SOS [22], etc, and it typically requires support from OS.
…. THREAD SUPPORT
GARBAGE COLLECTION
Device Drivers, Network Protocol, etc
EXCEPTION HANDLER
Figure 2. Elementary diagram of simpleRTJ
1) small memory footprint: SimpleRTJ requires no more than 18-24 Kilobytes ROM space and about 0.2 Kilobytes RAM space to run [32]. Moreover, it uses optimized set of standard libraries, links and replaces all the symbolic references inside the class files with offsets and indexes during the application post-compile process. These operations preserve small memory footprint of Java application and simplify the system run-time architecture, making EJVM be capable to be used on many WSN platforms, e.g., the Live node equipped with the microcontroller AT91SAM7S256. 2) Run as a stand-alone miniature Java OS: SimpleRTJ has built-in support to manage heap memory for the Java application execution, it can allocate memory space for class instances and method frames dynamically, which allows it to be used on the target devices independently without the support of a real-time OS. 3) Thread support: SimpleRTJ provides thread support with wait/notify synchronization and object's monitor locking. It provides means for Java threads to execute several independent tasks concurrently, it uses periodic interrupts (ex. real-time interrupts) to implement pre-emptive time sliced thread switching. All threads have the same priority except the event threads created from javax.events package. Event threads have the execution priority over the other ones, thus the appropriate event handler can be ensured to run quickly when an event is triggered. With the thread support, a flexible programming environment is provided to the WSN users. 4) Asynchronous events support: Processing asynchronous events is very important for the embedded software development. In simpleRTJ, asynchronous events involve many cases, such as data reception from the communication ports, change on the input digital and analog lines, and any other changes that require software attention. And the processing of asynchronous events is encapsulated in the javax.events package. After the events class is instantiated and
Loadable modules should not only contain code and data, but also the functions and variables references. After being loaded to target devices, these references should be resolved to the physical address before being executed. The resolved process is operated by a dynamic linker at run-time, and a symbolic name table with all global variable and function names and their corresponding addresses needs to be created and reserved in the system core for this process. Although dynamic linking mechanism simplifies the programming and reprogramming process by comparing with monolithic system case, the module size is still much larger than pre-linked code, this is due to the extra reference information contained inside the module. In addition, the system run-time overhead, no matter energy consumption, execution time, or memory requirement is also higher than prelinked case. C. Embedded Java Virtual Machine Since JVM can simplify the application programming by using high-level abstract JAVA language and address the challenge of heterogeneous environment in WSNs by executing byte code, several kinds of EJVM have been developed, such as TakaTuka VM [23], Darjeeling VM [24], KESO VM [25], LeJOS [26], NanoVM [27], simpleRTJ [28], Sentilla [29], Squawk [30], etc. As simpleRTJ is a simple Real-Time Java VM/OS with small memory footprint as well as a clean room JVM implementation for the small embedded and consumer devices, it's chosen, researched and ported to the Live nodes [31] for the evaluation of EJVM's performances in WSNs. The elementary diagram of simpleRTJ is depicted in Fig.2, it has all the key
23
the appropriate events and event handlers are registered, the thread enters a suspend mode and resumes when the external event is recognized in the system native code, then the handlers for the recognized event will be called. Asynchronous event mechanism in simpleRTJ enables the WSN users to process the low-level events from the application program, which is significant to the WSN application development. 5) Garbage collection support: Garbage collection to the unused objects in the Java application heap is supported in simpleRTJ. It works automatically and is invoked when there is not enough room on the heap for new class instances or new method frame. In addition, heap compaction will be performed to avoid the memory fragments and improve the new allocation efficiency if the amount of free memory declines to a certain level. 6) Heterogeneity: Exception handling is fully implemented and the Java programming interfaces are fully supported by simpleRTJ. Moreover, simpleRTJ can be built independently and be configured with many start-up configuration options, which allow it to execute different Java applications without the necessity of reloading each time. The experimental work proves that simpleRTJ can help the WSN users to program on sensor platforms more easily by using popular and familiar Java language, meanwhile its support of multitasking programming, event processing and exception handling from the application space improve the performance of user development process. It has been validated as an advisable choice for providing a user-friendly WSN IDE, especially in heterogeneous WSN environments. However, some drawbacks are likewise observed. Firstly, even to make a simple led blink program, the Java application image size can be more than 2 kilobytes, which is relatively too big for energy-efficient reprogramming task in WSN. Secondly, compared with the execution efficiency of native code, the one of simpleRTJ is much lower due to the extra interpretation operations. And these two drawbacks are the inherent ones of EJVM. Therefore, for the high energy constraint WSN nodes, EJVM is not suitable to be employed. III.
Use native code other than bytecode to avoid the extra time and energy consumption during the interpretation process.
Use application programming language the same as the system one. Since in EJVM, the application program is written by the JAVA language that is different from the one used in the system space, thus a new run-time environment should be established in the system space for the application code execution. Using the same language in the two spaces will avoid this problem and simplify the system run-time architecture.
Application Program
AVR GCC Compiler
OBJECT Files
Parse and Information Extract Parsing and Relevant Extracting Information
ELF Files RAW IMAGE
RE-LINK RE-LINK PROCESS PROCESS
Implementer Implementer Functions Functions Jump Jump TableTable
Strip Useless Code
APPLICATION EXECUTIVE IMAGE
SYSTEM SPACE
EMIDE MIDDLEWARE MIDDLEWARE EMIDE
SYSTEM Implementer Functions System IMPLEMENTER Functions
OPERATING SYSTEM / Network Protocols, Devices Drivers, etc.
Figure 3. Development diagram for the basic functionalities of EMIDE
1) Customer and Implementer Functions Declaration: EMIDE provides a set of function interfaces from system space to application one, for each interface, an application consumer function and a corresponding system implementer function should be defined respectively in the two spaces. 2) Memory Resource Allocation: Since application and system codes will be executed together on the same target devices, it's necessary to pre-reserve a given ROM and RAM memory spaces in the system run-time environment for the storage and execution of application image. 3) Linking Operation: Pre-linked application code is used in EMIDE for its advantages in small application code size, efficient executive speed and low resources consumption. However, any change in the system project can cause the application customer functions to be useless since the system implementer function addresses will be different from the value when the application program was linked. EMIDE solves this problem by providing an implementer function jump table between application and system spaces. This table will be located in a fixed address. Owing to this table, the application customer functions can be linked to the appropriate address in the table other than directly to the system implementer functions. After this, the system rebuilt process will not influence the application code execution validity in case that the implementer function index in the jump table is not changed.
A. Basic Design Principle of EMIDE In order to meet the rigorous requirements of EMIDE, its basic principles are designed as follows:
•
•
LIB of GCC & LIB of GCC & APPLICATION CUSTOMER Customer Functions SPACE Functions
The drawbacks of dynamic linking and EJVM mechanisms motivate us to design and implement a middleware which will not only provide a user-friendly IDE for the WSN users, but also be applicable to the high energy and memory constraint nodes. And EMIDE, an efficient middleware being introduced in this section, targets to address these challenges.
EMIDE will be a middleware (intermediate layer) which separates the application part from system one.
Use pre-linked code other than dynamic linking module to decrease the application code size and reduce the memory and energy consumption during the references resolving process.
B. Implementation of Basic Functionalities in EMIDE The elementary diagram for the basic functionalities of EMIDE is depicted in Fig.3. The whole implementation process can generally be summarized into four steps:
EFFICIENT MIDDLEWARE FOR USER-FRIENDLY IDE
•
•
24
Moreover, a task queue management mechanism is built-in support for managing the task entry, fetch and exit operations.
4) Passing of Input Parameters and Return Value: Since the whole space is divided by middleware into two spaces, middleware must undertake the work of passing the input parameters from application customer functions to system implementer ones, as well as the return values from implementer functions to customer ones. In EJVM, this process is operated by means of JAVA method frame stacks. Whereas in EMIDE, nothing needs to be done for this step, this is because the same language and compiler are used in both application and system projects, thus there are no passing gaps between the two spaces, and the execution of application code can be simply regarded as that of a common system function.
With the design and implementation above, the application space and system space can interact with each other unrestrictively in both the function invokes and parameters passing aspects. Thus, processing low-level interruption event from application space can consequentially be supported, and the main difference between the registrations of an interruption handling and a common task is that a parameter about the interruption type should be appointed, this parameter will be used to bind an application interruption handling to a dedicated system interruption event. Fig. 5 shows a program example which supports multitasks and lower-level interruption handling in the application space.
C. Implementation of Extended Functionalities in EMIDE With the basic functionalities of EMIDE, the functions in application space can invoke the ones in the system space, whereas the reversed process cannot be operated. However, it's practical to expect that some given application functions will be invoked from the system space when necessary, e.g., defining several tasks in the application program, and invoke some of them at appropriate time from the system space. Therefore, the extended functionalities of EMIDE are implemented for achieving the objective of "Two spaces are built independently as there are two, but work cooperatively as there are only one".
/* Examples for supporting multi-tasks and low-level interruption handling from application space */ #include int main(void) { // register an application task, which will be schedulered by the system tasks manager. app_task_register(app_task_light_crtl_decagonSensor, REPEAT_MODE, PRI_7); // register interruption handler, which allows to process low-level interruption from application space app_interruption_handler_register(intrp_pack_arrival_handler, PACK_ARRIVAL_EVENT); …... } /* One application task to be registered */ void app_task_light_crtl_decagonSensor(void) { // in the night, turn off the watermark sensor. When daylight arrives, restart watermark sensor if(sensorDataGet_light() < 100) sensor_stop(decagonSensor_id); else sensor_start(decagonSensor_id); } /* Process low-level interruption from the application program */ void intrp_pack_arrival_handler(AppMessage_t *sensorData_pack) { // if sensor data package arrived, forward it by USART to Edge Router appSendMessageToUart(sensorData_pack, sizeof(AppMessage_t)); }
Fig. 4 shows the elementary diagram for implementing the extended functionalities of EMIDE. In the application space, the registration functionality is provided for registering different tasks into the system tasks queue. Once an application task is registered, it will become a system task member waited to be scheduled by the system task manager. APPLICATION SPACE
Application Task 1
EMIDE SYSTEM SPACE
SYSTEM Task Manager
Application Task 2
...
Figure 5. Application example with multi-tasks and low-level interruption handling support
Application Task n
Customer function for Application task registration
IV.
To evaluate EMIDE, its performances are compared with the simpleRTJ and Contiki dynamic linking ones in terms of memory resource requirements, application image size and application code execution efficiency on the iLive node platforms. The iLive node, shown in Fig. 6, is equipped with one ATMEGA1281 microcontroller with 128 kilobytes of ROM and 8 kilobytes of RAM, 1 light sensor, 1 temperature sensor, 1 air humidity sensor, 3 Decagon sensors, 4 Watermark sensors, one IEEE802.15.4 ZigBee wireless access medium, as well as one RS232/USB slave port.
Implementer function for Application task registration Queue Management (Entry, Fetch, Delete)
System Task Queue APP Task Member 1
...
EXPERIMENTAL WORK
APP Task Member n
Network protocol, Device drivers, etc.
Figure 4. Development diagram for the extended functionalities of EMIDE
Two parameters can be assigned to each registered application task. One is the task priority determining the position where to insert the task into the system task queue. Task with higher priority will be put at the front place, thus being executed ahead of the others with lower priority. The other parameter is the execution attribution which can be assigned as repeating execution or one slot execution mode. For one slot case, the task will be deleted from the queue once the execution process is complete, while for repeating mode, it will be invoked at intervals by the system task manager until an unregistered implementer function is called from the application program.
Figure 6. iLive sensor node
25
For the comparison, a basic WSN application program is implemented in both C and Java languages, shown in Fig. 7. The image size comparison results are shown in Table II. From the results, EMIDE has a great advantage over the other methods.
A. Performance Comparison 1) Memory resource requirements Since simpleRTJ has the featured functionalities such as garbage collection, exception handling, etc., the code related to these functionalities are not compiled for the comparison rationality. Table I shows the comparison results of required memory resources. For simpleRTJ, up to 320 bytes of RAM and almost 20 kilobytes of ROM are needed for its basic execution [32]. For Contiki dynamic linking mechanism, 5.7 kilobytes of ROM and 18 bytes of RAM are required [21]. While for EMIDE, only 1.6 kilobytes of ROM and 40 bytes of RAM are required. The ROM space for EMIDE is used to store the code for intermediate jump table, tasks registration and task queue management, while the RAM space is reserved for the system task queue. It is seen from the results that EMIDE can be applicable even on high resource-constraint sensor nodes. TABLE I.
COMPARISON RESULTS OF REQUIRED MEMORY RESOURCES Mechanism
ROM (kilobytes)
RAM (bytes)
Contiki dynamic linking (Compact ELF)
5.7
18
EJVM simpleRTJ (JAVA bytecode)
20
300
EMIDE
1.6
40
/* Example in C language for EMIDE and Dynamic linking mechanism */
/* Example in JAVA lanague for EJVM simpleRTJ */
#include int main(void) { // Configure WSN node type node_type('E'); // Configure device sleep period node_E_sleepperiod(10000); // Chanel set node_channelset(18); // Configure logical network address node_set_staticNetAddr(12); // Control sensor sensor_start(temperature_id); // start WSN network network_start(); }
import wsn.comm.*;
Figure 7. Example for image size comparison TABLE II.
2) Application Image Size Application image size is a key metric for the performance evaluation since it has a close influence on the energy consumption during the reprogramming process. The reprogramming energy consumption can be modeled with E = Et + Es + Ep + Ef
class Test { static void main(String[] args) { wsn.node_type('E'); wsn.node_E_sleepperiod(10000); wsn.node_channelset(18 ); wsn.node_set_staticNetAddr(12); wsn.sensor_start(temperature_id); wsn.network_start(); } }
COMPARISON RESULTS OF APPLICATION IMAGE SIZE Mechanism
Code size (bytes)
Monolithic system (Full image)
111516
Contiki dynamic linking (Compact ELF)
1568
EJVM simpleRTJ (JAVA bytecode)
2232
EMIDE
68
(1)
where Et is the energy spent in transferring the update code over the network. Es is the energy cost in storing the code temporarily on the target device, e.g., energy consumption in storing the raw code in the external ROM for further references resolving in the Contiki dynamic linking mechanism. Ep is the energy consumed for the raw code processing, such as the code re-linking and relocating operations. And Ef is the required energy for storing the final executive code into flash ROM.
3) Application Code Executive efficiency Native code is used in the EMIDE and Contiki dynamic linking mechanism, other than the bytecode in simpleRTJ. To compare the executive efficiency of these two kinds of codes, an application example which executes a customer function for one million times in a loop is built into both native code and bytecode respectively. After testing on the iLive node, the execution details are obtained and listed in Table III. From the results, the execution efficiency of native code, which is used by EMIDE, is much better than that of JAVA bytecode.
Note that Es and Ep in (1) do not exist in EMIDE and EJVM. And for Et and Ef, they can be valued as being proportional to the update code size. Formally,
TABLE III.
Et = PtSc, Ef = PfSc .
Code Type
where Sc is the update code size, Pt and Pf are the constant scale factors depending respectively on the wireless network transmission protocol and the target device hardware characteristic. Since energy consumption of transferring one bit in wireless network is in some cases equal to that of executing 3000 instructions on a general processor with 100MIPS/M power [33], Pt is not a petit numerical value. Thus, reprogramming with a small code size is very significant, especially for energy constraint sensor nodes.
EXECUTIVE EFFICIENCY COMPARISON RESULTS Executive details
Executive Time (S)
Voltage(V)
Current (mA)
Energy Consumption(mJ)
Bytecode
1215
3
10.5
38272.5
Native code
37
3
10.6
1176.6
B. WSN Establishment and Remote Reprogramming In the experimental work, a star topology sensor network with one iLive node as the coordinator and 10 iLive nodes as the end-devices is established following the IEEE802.15.4
26
ZigBee specification [34]. Star topology is chosen as it can be a basic case study for the other ZigBee network topologies. The coordinator in WSN is responsible for the new network establishment, devices associations as well as communications with external networks. While the End-devices are in charge of collecting sensor data and transmitting the data packages to the Coordinator.
receive packages from coordinator at this moment. Once the end-devices signal is detected by coordinator, a wake up command package will be sent to notify all the end-devices no more fall asleep and enter the code update ready status. 5) Code Update Process: Coordinator splits the new code image and broadcast them frame by frame to all the enddevices. End-devices will response the acknowledge information which will be used by the coordinator for retransmission decision. If parts of end-devices failed to receive the whole image code, a peer-to-peer update mode will start to continue the update process. For remote reprogramming, EMIDE mainly contributes in two aspects. 1) the application code size becomes very small with the support of EMIDE, this certainly decreases the reprogramming energy consumption and improves the success probability of new code wireless transmission. 2) the application program becomes very simple, making it practicable to update the new program remotely from Internet by webpage. Currently, an unwell-round web server for managing WSN remotely by Internet has been implemented in our work with the website address "http://edss.isima.fr".
Sensor network can be controlled remotely from Internet by the user terminal devices, such as laptop, PDA, mobile phone, etc, depicted in Fig. 8.
V.
Figure 8. Network topology structure
CONCLUSION
We have presented an efficient middleware EMIDE for the user-friendly WSN IDE. The performances of EMIDE in term of resource consumption and execution efficiency are compared with those of EJVM (simpleRTJ) and Contiki dynamic linking mechanisms. The implementation and evaluation work on iLive platforms proved that EMIDE not only provided a user-friendly WSN IDE for the users, but also was well adapted to the high resource-constraint wireless sensor nodes.
The WSN working and reprogramming process in our experiment work can be summarized as the following five ordinal steps: 1) Synchronization Process. All the end-devices are expected to work synchronously to ensure the data collected at the same time, this is necessary for data comparison, analysis and calibration operations. And this process is achieved by broadcasting synchronization packages from coordinator to end-devices after the network is formed. 2) Priority Distribution Process: It's observed in the experiment work that the quality of network communications begins to decrease if the number of end-devices is more than four, this mainly results from the serious communication collision and restricts the network scale accordingly. To solve this problem, priority identifications are distributed to all the end-devices after the synchronization process is complete. With this distribution, devices with the same priority identification will form a group, and a short back off time will be set between different device groups when a large scale communication event happens. By experiment, this collision problem is validated to be solved by this mechanism. 3) Working Process: In this stage, end-devices collect sensor data, send them to coordinator, and then fall asleep. The sleeping period can be configured and adjusted from the application program. After the data package is received by the coordinator, it will be forwarded to the desktop server by the Internet. 4) Waking Up Process: When the coordinator is informed remotely by the users for updating the new code to enddevices, it will buffer the code packages firstly and wait for the end-devices to wake up. Buffering process is necessary since all the end-devices may be in a sleeping status and cannot
For the ongoing work, EMIDE will be designed and implemented further to support the functionalities of inserting, repairing and removing modules in the system space with a low resource consumption and high executing efficiency. It will be a milestone to achieve the objective of robust WSN software system. ACKNOWLEDGMENT We would like to thank the 'China Scholarship Council' (2009627016) and 'Conseil Général du Puy-de-Dôme' (France) for their supports to this project. REFERENCES [1] [2] [3] [4] [5]
27
T. Kalaivani et al.. A survey on Zigbee based wireless sensor networks in agriculture. In Proc. of the 3rd Int'l Conf. TISC, pp. 85-89, 2011. Y. Zhu et al.. Applications of Wireless Sensor Network in the agriculture environment monitoring. In Proc. Int'l Conf. APEE 2011., pp. 608-614, 2011. P. Patil et al.. Wireless sensor network for precision agriculture. In Proc. Int'l Conf. CICN, pp. 763-766, 2011. Flammini, A et al.. Sensor networks for industrial applications. In Proc. IEEE 2nd Workshop IWASI, 2007. A Flammini et al.. Wired and wireless sensor networks for industrial applications. In Microelectronics Journal, pp. 1322-1336, 2009.
[6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
[31] 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. [32] RTJ Computing Pty. Ltd. Developer‟s Guide to Simple Real Time Java. online at http://rtjcom.com/downfile.php?f=srtjdoc. Visited 2012-02-19. [33] Chen WANG et al., “A Simple Energy Effcient Transceiver for IEEE 802.15.4”, In Proceedings of IEEE International Symposium on Circuits and Systems (ISCAS), pp. 597-600, 2010. [34] ZigBee Alliance. Zigbee Specification. http://www.zigbee.org/Specifications/ZigBee/Overview.aspx.Visited 2012-02-16.
J. Åkerberg et al.. Future research challenges in wireless sensor and actuator networks targeting industrial automation. In Proc. IEEE Int'l Conf. INDIN, pp. 410-415, 2011. B. Zhou et al.. A wireless sensor network for pervasive medical supervision. In Proc. IEEE Int'l Conf. ICIT, pp. 740-744, 2007. O. Garcia-Morchon et al.. Efficient and context-aware access control for pervasive medical sensor networks. In 8th IEEE Int'l Conf. Workshop PERCOM, pp. 322-327, 2010. I. Kirbas et al.. HealthFace: A web-based remote monitoring interface for medical healthcare systems based on a wireless body area sensor network. Journal EJEECS, pp. 629-638, 2012. D.H. Park et al.. Design and implementation of home sensor service platform. Technical Papers Int'l Conf. ICCE, pp. 481-482, 2010. J. Zhang et al.. Design of a wireless sensor network based monitoring system for home automation. In Proc. Int'l Conf. Future Computer Sciences and Application, ICFCSA, pp. 57-60, 2011. M.C. Huang et al.. The wireless sensor network for home-care system using ZigBee. 3rd Int'l Conf. on Intelligent Information Hiding and Multimedia Signal Processing, IIHMSP, pp. 643-646, 2007. S.H. Lee et al.. Wireless sensor network design for tactical military applications: Remote large-scale environments. In Proc. IEEE Military Communications Conference MILCOM, 2009. I. Bekmezci et al.. Energy efficient, delay sensitive, fault tolerant wireless sensor network for military monitoring. IEEE Sensors Applications Symposium, SAS, pp. 172-177, 2008. L. Bai, R. Dick, and P. Dinda. Archetype-based design: Sensor network programming for application experts, not just programming experts. In Proc. Int. IPSN, April 2009. Ana-Belén García-Hernando et al.. Problem Solving for Wireless Sensor Networks. Journal of Computer Communications and Networks. 2008. Q. Wang, Y. Zhu, and L. Cheng. Reprogramming wireless sensor networks: Challenges and approaches. IEEE Network Magazine, 20(3):48–55, May-June 2006. W. Dargie and C. Poellabauer. Fundamentals of wireless sensor networks: theory and practice. Wiley, 2010. 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-11-16. A. Dunkels et al. Run-time dynamic linking for reprogramming wireless sensor networks. In Proc. SenSys, Colorado, USA, 2006. Chih-Chieh Han, et al., "A Dynamic Operating System for Sensor Nodes," In Proc. Int'l Conf. MobiSys, ACM Press, pp. 163-176, 2005. F. Aslam, C. Schindelhauer, G. Ernst, D. Spyra, J. Meyer, and M. Zalloom. Introducing TakaTuka: A Java virtual machine for motes. In SenSys’08, pages 399–400, New York, NY, 2008. N. Brouwers, K. Langendoen, and P. Corke, B. Darjeeling, a feature-rich VM for the resource poor. in Proc. ACM Sensys, pp. 169–182, 2009. Thomm, I. et el. Keso: an open-source multi-jvm for deeply embedded systems. In Proceedings of the 8th International Workshop on JTRES, pages 109–119, New York, NY, USA. ACM, 2010. Nikander, Pekka: An Operating System in Java for the LEGO Mindstorms RCX Microcontroller. In: 2000 USENIX Annual Technical Conference, 2000. T. Harbaum, The NanoVM - Java for the AVR, http://www.harbaum. org/till/nanovm/index.shtml. Visited 2012-02-29. RTJ Computing Pty. Ltd. simpleRTJ a small footprint Java VM for embedded and consumer devices. online at http://www.rtjcom.com/. Visited 2012-02-29. Sentilla. Online at http://www.sentilla.com/. Visited 2012-02-29. Simon D. et al., Java on the Bare Metal of Wireless Sensor Devices: the Squawk Java Virtual Machine, in Proc. of VEE, Ottawa, Canada, June 2006, pp. 78–88.
28
