FLEXOR: User Friendly Wireless Sensor Network Development and ...

FLEXOR: User Friendly Wireless Sensor Network Development and Deployment Anna F¨orster, Kamini Garg, Daniele Puccinelli and Silvia Giordano Networking Laboratory University of Applied Sciences of Southern Switzerland {anna.foerster,kamini.garg,daniele.puccinelli,silvia.giordano}@supsi.ch

Abstract—Wireless sensor networks (WSNs) penetrated the market mainly as solutions for specific application scenarios. However, this strong specialization limits WSNs reuse both in terms of development as well as in terms of technical results: Every new application scenario requires a new design, development and validation, as well as management skills. This is frustrating for any WSNs user, developer or manager. To reverse this tendency and thus improve the quality of experience and user-friendliness in WSNs, we designed FLEXOR, a sustainable software architecture optimized to support the implementation, rapid prototyping, evaluation, and testing of wireless sensor network applications, that is platform independent and user-friendly. FLEXOR is designed to accommodate many different applications and services for wireless sensor networks and foster code re-usability and cross-platform component re-usability. FLEXOR offers high modularity, well defined interfaces, remote node management functionality as well as run-time module exchange. Finally, the introduction of a unifying way for WSNs development opens to a higher homogeneity and thus to more easy comparison among different solutions. We present here an analysis of FLEXOR from these new angles and show how effective it is for several purposes and in particular for non-experts and in education. Keywords-QoE, User-friendliness, Wireless Sensor Networks, Architecture, Sustainable reuse, Mobility

I. I NTRODUCTION Wireless Sensor Networks (WSNs) technology is highly successful both in the industrial market as well as in the mass market. The research in WSNs addressed many key challenges of WSNs with various degrees of success, but a significant number of valid solutions have not had the broad impact they deserve. The primary reason for this limited success lies in the inability to simply treat individual solutions as plug-and-play components that work across a wide array of operating systems and platforms. The Quality of Experience (QoE) and the User-Friendliness (UF) for the WSNs developers and managers, the users of all those components and solutions, is very low. Whenever a new WSN needs to be developed, it is necessary to follow all the steps in the development process, from design and implementation up to prototyping and testing. In order to boost both high QoE and UF for WSN developers, we advocate for a sustainable, modular, and flexible software architecture that intrinsically promotes crossplatform code reuse and fast prototyping and enables the remote control and selective activation of specific modules on individual nodes at run time. In this paper we present a c 978-1-4673-1239-4/12/$31.00 2012 IEEE

QoE and UF performance analysis of FLEXOR, a platformindependent software architecture for the rapid development, testing and tuning of WSNs. We demonstrate that this new design can significantly simplify the WSNs development while resulting in excellent memory, processing, and energy overhead. To simplify WSNs development and management, some efforts were done in the past in that direction, mainly addressing one out of many issues: dealing with heterogeneous devices (e.g. EU FP7 projects SENSEI, WISEBED, FRONTS, SmartSantander), extending from static to mobile networks like RoombaNet [1], or remote debugging of nodes like in Marionette [2]. However, we still lack in the literature a global solution that is clearly designed for effectively improving QoE and UF at all levels. To the best of our knowledge, FLEXOR is the first architecture that considers all those aspects together by explicitly addressing QoE and UF by design, and providing powerful development and management services. Finally, to date, as WSNs solutions were mainly application scenario dependent, their comparison was barely qualitative in most cases. FLEXOR, as unifying methodology for WSNs solutions, allows for more quantitative comparison and evaluation. The remainder of this paper is organized as follows: Section II motivates our goals and identifies requirements for the software architecture to be implemented. Section III presents the overall structure of FLEXOR, the proposed architecture, and its most important components and properties; in Section IV we work out a complete example of how to use FLEXOR. In Section V, we show that we can achieve high QoE and UF with FLEXOR while having an excellent overhead in terms of processing, energy and memory consumption. Section VI discusses the potential uses of FLEXOR. Finally, Section IV concludes the paper. II. T HE NEED FOR A USER - FRIENDLY WSN PROGRAMMING ARCHITECTURE

Though many of the inherent challenges of WSNs have been successfully tackled, many open problems remain. The WSNs research either moved toward solving application dependent problems (e.g. avalanches risk, badger movements, etc.), or toward some single networking problem (e.g. routing, energy efficiency, etc.) with the assumption of some networking scenario. Very rarely results obtained in a specific given scenario can be effectively re-used in another

Modularization

FLEXOR Application 2

FLEXOR Routing 1

FLEXOR Routing 1

FLEXOR Addressing

FLEXOR Routing 2

FLEXOR Localization

FLEXOR Localization

FLEXOR CORE MODULE MANAGER

SPECIFICATIONS

IMAGES

CALLBACK MANAGER

Platform Independence

Runtime software exchange

FLEXOR MODULES FLEXOR Application 1

PACKET POOL

Remote function calls

scenario, and this enormously augments the development effort while reducing the possibility of comparing solutions that are highly scenario dependent. Furthermore, most of the work in WSNs has followed a vertical design paradigm whereby all the necessary components and services are implemented holistically with little or no modularization for code optimization. Such an approach has been employed to address a significant array of problems and challenges, ranging from medium access to routing to time synchronization, but mostly, scenario dependent. Thus, a very critical open challenge is arguably the (lack of) availability and reusability of software components across different solutions and platforms. In order to achieve components and solution re-usability we need to have a completely different approach from the non-modular, holistic, ad hoc design which can address the following technical challenges: • Code re-usage – rare due to the widespread vertical design approach. • Cross-platform code usage – practically impossible (e.g., using TinyOS components in Contiki) • Solution comparison – barely possible in few special cases, due to the ad hoc design • Solution validation – not possible without a timeconsuming prototyping Augmenting these technical challenges with user friendliness and quality of experience needs, we define the following requirements for our software architecture FLEXOR: • Simple, well known programming language (e.g. C) Enable non-expert programmers to easily immerse into the topic of WSN and experience their own programs. • Platform independence Enable code re-use across hardware platforms and simulators to ease the comparison and validation process. • High level of modularization Enable graphical user support and code re-use. • Remote function invocation support Enable remote full control of the sensor nodes. • Remote component exchange without reboot Enable seamless testing of different algorithms and protocols in fair conditions (parallel tests) • Graphical support for programming, debugging and deployment Enable non-programmers to test, deploy and tune WSNs. Enable student experiences. Certainly, there have been many efforts to solve some of these problems. We have summarized some of the most prominent examples from the literature in Table I. As can be seen from this comparison, there is no single solution to all challenges and individual works address only a subset of the requirements we summarized above. This is the main motivation for us to design a new, lightweight and easily portable software architecture, which levevarges existing works as much as possible, while meeting all of the above

FLEXOR INTERFACE OMNeT++

TinyOS

...

Figure 1. FLEXOR overall structure, with the main components and the requirements they implement.

requirements in an unified way. In the next sections, we present the design and evaluation of FLEXOR. III. FLEXOR S YSTEM A RCHITECTURE The architecture of FLEXOR is designed to meet all the aforementioned requirements. The general structure of FLEXOR is presented in Figure 1. The overall design of FLEXOR is deeply informed with the willingness to boost the QoE and the UF of its users. A. Programming language We decided to use C as our user-oriented programming language. Although the language is not object oriented, it is very wlel known and widely used. Furthermore, almost all of the existing WSN operating systems and simulators can easily integrate C code, so that an extra compiler or code generator is spared and the porting of FLEXOR to new platforms and systems eased. B. Platform Independence To guarantee platform-independence, FLEXOR is organized into three levels, depicted in Figure 1. The core and the modules are implemented in a platform-independent way, while an interface is bridging them to the hosting platform. The platform-dependent interface implements the basic functionalities of WSNs. It also provides entry points for the user to activate or deactivate and manage individual functional blocks to provide FLEXOR’s users with as much freedom and flexibility as they require. The interface functions of FLEXOR include basic functionalities such as scheduling and removing timers, sending and receiving messages through the radio and serial interfaces, getting the current local time, node ID, logging data in the flash memory, or reading sensory inputs. The interface is the main component that enables the platform- independent implementation of different modules and aligns different

Requirements

TinyOS [3]

Contiki [4]

Marionette [2]

TinyCubus [5]

Runes [6] Darjeeling [7] Mat´e [8]

Programming language

NesC

C

Python

NesC

Java, C

Java

TinyScript

Platform independence

No

No

No (TOS)

No (TOS)

Yes

Yes

No (TOS)

High level of modularization

Yes

Yes

NA

Yes

Yes

No

No

Remote function call support

No

No

Yes

No

No

No

No

Remote component exchange without reboot

No

Yes

NA

No

Yes

No

No

Graphical support for programming/ debugging

No

No

NA

No

No

No

No

Table I A COMPARISON OF STATE OF THE ART WSN OPERATING SYSTEMS , TOOLS AND SOFTWARE ARCHITECTURES IN TERMS OF OUR REQUIREMENTS . fromUp

IMAGE_1

IMAGE_2

Specifications

Specifications

toUp

FLEXOR module archetype

init start

callback_module

callback_module

application

application

MAC 1

MAC 2

callback_module

stop fromDown

application

toDown

Figure 2. FLEXOR basic module archetype with three management functions and four gates.

operating systems, platforms, and even network simulators to the same WSN-specific interface. To maximize the user’s freedom and guarantee full flexibility of usage, FLEXOR does not provide high-level programming primitives or data structures like neighbor tables or multi-hop communication. FLEXOR only provides a one-hop broadcast service. MAC protocols can be implemented on either side: as an interface service, if special optimizations and non-standard hardware is required, or in the FLEXOR modules. C. High Modularization FLEXOR is designed to be highly modular. Indeed, a so-called FLEXOR module represents the basic building block for all applications developed in FLEXOR. Figure 2 presents the basic archetype with its 3 interface functions INIT, START, STOP and 4 gates FROM U P, FROM D OWN , TO U P, TO D OWN . The first three interface functions are called at node startup (init) as well as whenever the module is switched on (start) or off (stop) at run time. This enables the preservation of the internal state of the module at all times. The four gates enable a module to interface with other modules. A module receives packets through its fromUp, fromDown functions and sends packets to other modules via toUp, toDown. The connections among modules are not static, but are managed at runtime by the module manager (see below). Modules may implement protocols, services, algorithms, or applications. For best results, it is advisable to keep modules small. Ideally, each module ought to focus on a single service or functionality; arbitrarily complex functionalities should be achieved by linking various modules together. Note that only modules are allowed to produce or receive packets/messages, although they are not required to

routing MAC 1 MAC 1 SPEC

Figure 3.

MAC 2 SPEC TinyOS Interface

ROUTING SPEC Contiki Interface

FLEXOR specification and image examples.

do so. Since flexibility is a key tenet of QoE, FLEXOR allows users to extend the basic archetype with new incoming/outgoing gates. A specification represents a set of interconnected modules. Several specifications can coexist on the same node at runtime, but only one single specification can be active at any given time. Modules can be shared among different specifications, depending on the application requirements. A set of co-existing specifications residing together in the memory of a single node is called an image. Examples of two images are presented in Figure 3. The Module Manager serves to exchange specifications when an internal or external command (callback) is issued.

D. Remote Function Invocation Support Remote callbacks are handled locally by a special component, the callback manager. All other components (modules, module manager, and the interface) can register and deregister callbacks, which have a callback identifier and a pointer to the callback function. The callback manager receives callback invocation commands with destination and source node ids, a sequence number, and a callback id. Upon receiving a callback command, if possible the callback manager invokes the registered callback function.

4 50 255 1 4 60 255 2 ...

Image

2 experiment scenarios, XML commands implement

APP

APP

MAC1

MAC2

FLEXOR IDE

1

BS 8

7

manage

control

deploy

3

FLEXOR under OMNeT++

FLEXOR COMANDER

6

debug

5

compare / evaluate

4 explore parameters

Figure 4. An example of working with FLEXOR tool-chain. We assume that two MAC protocols need to be implemented, validated, optimized and compared against each other in a real world scenario. With FLEXOR, this task becomes manageable and well structured.

E. Remote Component Exchange without Reboot One of the key advantages of FLEXOR is the ability to swap components remotely at run time without having to reboot the node. Because of this feature, FLEXOR can be viewed as the missing link between testbed experimentation and real-world deployment. By exchanging components on the fly, the fair benchmarking of WSN solutions becomes significantly easier to achieve. In fact, different WSN solutions can be run one after the other to boost the likelihood of encountering self-similar network conditions. IV. FLEXOR TOOL - CHAIN In the last section, we presented the general architecture of FLEXOR and how it satisfies the individual requirements identified in Section II. Here, we present the extensive graphical support of FLEXOR, consisting of a dedicated programming environment and a graphical user tool for deployment management. We also give a simple example of how FLEXOR is used in practice. Let us consider a sample scenario, where two MAC protocols need to be validated, optimized in terms of their parameters and then compared against each other in a real hardware environment. With existing tools, this process will be rather unstructured and will consist of several prototype deployments of both protocols for validation and optimization (trial and error tests) and then an sequential comparison, where each of the protocols is run in the same environment for some time, one after another. This process is not only error-prone, but also quite unfair to both protocols. There is no guarantee to find the best parameters, as this will require too many experiments. It is unfair, as the real hardware environment is never exactly the same throughout time. The development process with FLEXOR is depicted in Figure 4. First (1), the user uses an extensive pool of already developed FLEXOR modules, such as neighbor tables, other

MAC protocols, time synchronization protocols, node ID assignment, etc. The missing modules can be easily defined and implemented by using the extensive graphical support, which hides all internal FLEXOR details, such as interconnections of modules. (2) Two FLEXOR specifications need to be defined (graphically), which consist of some testing application module (e.g. periodic reporting) and the MAC protocol to be tested. The specifications are also depicted in Figure 3. One FLEXOR image is defined with the two specifications inside, so that they can easily exchanged during run-time without reprogramming or reboot. Then, the code generator is used to generate the required C code and to link it with the necessary platforms. First, in (3), it is linked with the network simulator OMNeT++ to validate the general implementation of both protocols and to explore a large spectrum of their parameters (4). After this validation is done and all errors corrected, the code is linked to a real hardware platform such TinyOS (5). The graphical user tool FLEXOR Commander (7,8) is used to program the sensor nodes. It is also used to change the parameters of the protocols at run-time without rebooting the nodes (6). Novel is the comparative evaluation between the two MAC protocols. Instead of loading the first protocol onto the nodes, running it for some time, gathering the data and then repeating the same procedure for the second protocol, FLEXOR is able to exchange the protocols seamlessly at run-time. Thus, it is able to change them very often and very quickly, for example every 10 seconds for several hours or at random intervals. This allows for fairness, as it spreads the impact of the environment over time and allows both protocols to act in all conditions. The lack of reboot or reprogramming saves time and preserves the internal status of all involved modules (protocols and data structures). V. E VALUATION OF FLEXOR Here we demonstrate the validity of FLEXOR in terms of user friendliness and quality of experience and performance. The first dimension is clearly subjective, but our experience with teaching FLEXOR to students of all ages has been very positive. In terms of performance evaluation, we have implemented interfaces between FLEXOR and TinyOS and OMNeT++. We selected TinyOS because it represents the de facto standard for WSN operating systems and it is supported by most off-the-shelf WSN platforms. OMNeT++ is selected to demonstrate the platform-independence of FLEXOR and the portability of the code from one system to another. A. Quality of Experience and User friendliness There are three important aspects of FLEXOR in terms of its quality of experience (QoE) and its user friendliness (UF): user experience and programmer experience. 1) Non-programming user experience: In this paper, we refer to people, who program in FLEXOR and use it to develop and deploy WSNs as the users. However, a very important audience for FLEXOR are also students and non-programmers, who need to experience a WSN in an

End-user tool

Platform supported

Graphical Interface

Backchannel Changing pasupport rameters

Remote debugging

Over-the-air programming

Runtime component exchange

Surge [9]

TinyOS 1.X

Yes

Yes

No

Yes

No

No

MViz [10]

TinyOS 2.X

Yes

Yes

No

Yes

No

No

Octopus [11]

TinyOS 2.X

Yes

Yes

Yes (partial)

Yes

No

No

MoteLab [12]

TinyOS 2.X

No

Yes

No

No

No

No

WiseBed [13]

Crossplatform

No (Commandline based)

Yes

No

Yes

Yes

No

Marionette [2]

TinyOS 1.X

Yes

No

Yes

Yes

Yes (Deluge)

No

Marwis [14]

Contiki

Yes

Yes

No

Yes

Yes

No

xM [15]

TinyOS 2.X

Yes

Yes

No

Yes

No

No

FLEXOR Commander

Crossplatform

Yes

No

Yes

Yes

No

Yes

Table II Q UALITY OF E XPERIENCE AS A NON - PROGRAMMER WITH FLEXOR C OMMANDER , AS OPPOSED TO SOME OTHER WSN TOOLS .

interactive way to learn the basics of WSN development. This possibility is provided by the FLEXOR Commander, as discussed in Section IV. Generally speaking, it provides an entry point to any FLEXOR based WSN implementation. It forwards commands to the nodes in the network and returns back their status, data, debugging information, etc. Because of the high flexibility of the FLEXOR architecture, it is possible to also exchange individual modules (software components) at run-time and thus ”quasi“– program the network without recompilation or reprogramming. In order for a WSN to be accessible to non-programmers and still be of value to their experience and/or education, it requires a good graphical tool to control the network. We have summarized the properties of such tools in Table II. In fact, there are only few tools targeted to non-programmers. The most tools we found in the literature are targeted to experts and programmers to more easily debug and control their deployments, but are highly application dependent and platform dependent. Furthermore, most of them require a backchannel to the nodes, which is both effort and time consuming. The only sophisticated tool is Marionette [2], which is unfortunately developed for TinyOS 1.x only. Compared to these tools, our FLEXOR Commander is the most flexible and general-use one. 2) Programming experience: We evaluated the programming experience in two different university-level courses in introductory wireless sensor networks. The first one was a master-level course at the University of Lugano1 , Switzerland with students with good Java programming experience and some (little) C experience. The second course was a summer school course for students and practitioners at Informatica Feminale in Bremen, Germany2 , with bachelor students and experienced educators and practitioners in the field of computer science. The students were asked first to evaluate the complexity (subjectively) of several new 1 www.inf.usi.ch 2 www.informatica-feminale.de

platforms and languages, as presented in Table III. There were exactly 10 students in total from both courses. As can be seen from the results (percent of all received answers), the students rated the complexity and the flexibility depending in their subjective experience. Generally speaking, they perceived C++ as the most simple to understand and NesC the most complex programming language. The reason for this is probably their extensive experience with Java and OOP. In terms of WSN platforms, they perceived Scatterweb as relative simple to understand with main challenge the hardware itself (waiting, sleeping, blocking calls, overwriting of packet buffers, etc.). OMNeT++ was perceived as the most flexible, but also very large and complex system. Compared to all other platforms and languages, FLEXOR was perceived as simple to understand (its architecture) and very flexible. Interestingly, the students felt like FLEXOR takes away some of the inherent complexity of C itself, mainly because of the exclusion of dynamic memory in FLEXOR and its simple hardware interface. These results clearly show the usability of FLEXOR for non-expert programmers and university-level students. It enables extensive WSN experience without the full complexity of WSN hardware and performance-optimized operating systems. It is perceived as simple, straightforward and flexible. We will continue studying the user friendliness of FLEXOR in the future with larger groups too. 3) Programming complexity: Here we attempt to evaluate the user friendliness of FLEXOR with respect to TinyOS. We use a simple periodic reporting application to explore the implementation process for both systems, where a node reads its sensor regularly and sends the data over radio to a base station. We explore various properties and implementation requirements, such as lines of code, programming languages, graphical tools, etc. This comparison is presented in Table IV. We compare three implementation environments/methodologies: standard textbased implementation of TinyOS applications, used by the

Platform / Language

Simple

C OMPLEXITY Medium Complex Challenge

Not flexible

Medium

F LEXIBILITY Flexible Reason

C

0%

20%

80%

Syntax, pointers

70%

30 %

0%

Low-level, re-use

NesC

0%

0%

100%

Wiring, split calls

50%

50 %

0%

Many supported platforms, no re-use across OS

C++

20 %

70%

10%

OOP

0%

30 %

70%

OOP

Scatterweb

20 %

70%

10%

Hardware

100%

0%

0%

Only one supported platform (MSB430)

TinyOS

0%

30%

70%

Non-transparent components, debugging

30%

50 %

20%

Same as NesC

FLEXOR

40 %

40%

20%

None

0%

30 %

70%

Easily portable

OMNeT++

0%

10%

90%

Very large

0%

20 %

80%

”Do what you want“

Table III S UBJECTIVE COMPLEXITY OF VARIOUS WSN PLATFORMS AND PROGRAMMING LANGUAGES , AS EVALUATED BY VARIOUS UNIVERSITY- LEVEL STUDENTS . T INYOS/N ES C WAS RATED THE MOST COMPLEX SOLUTION , OMN E T++/C++ THE MOST FLEXIBLE SOLUTION . H OWEVER , ONLY FLEXOR SATISFIES BOTH REQUIREMENTS AT THE SAME TIME . Implementation platform

Language

Architectural complexity

Code generation

Lines of code

Cross-platform Portability

TinyOS basic

NesC

Complex

no

133

special code wrappers needed

TinyOS + tools (hypothetical)

NesC

Complex

component wiring

98

special code wrappers needed

FLEXOR

C

Simple

partial

25

full-featured

Table IV P ROGRAMMING USER FRIENDLINESS OF FLEXOR AGAINST T INYOS. T HE SAME SIMPLE SENSING NODE APPLICATION IS IMPLEMENTED FOR BOTH FLEXOR AND T INYOS.

majority of TinyOS programmers, a hypothetical graphical implementation environment for TinyOS, and our FLEXOR graphical tool-chain. We use the term hypothetical for the graphically assisted TinyOS implementation, because, to the best of our knowledge, no such tool currently exists that supports TinyOS 2.x. Note that efforts in this direction have been already made, for example the GRATIS [16] development environment, which graphically represents TinyOS 1.x components and their wirings. One of the main advantages of FLEXOR as opposed to TinyOS is the platform-independence and abstraction from TinyOS components, the NesC language, and the intercomponent wirings, which are often perceived as challenging by non-expert programmers and require a relatively steep learning curve. Instead, we offer an implementation environment based on standard C with extensive graphical support. Furthermore, FLEXOR’s architecture with its modules, specifications, and images is simple and linear and can be learned rapidly. No understanding of TinyOS or its hierarchical component structure is required. Another important advantage is the absence of a main component: FLEXOR requires only the implementation of individual modules and then interconnecting them. FLEXOR core handles the initialization, activation/deactivation, and management of modules. The most important metric for the assessment of the user friendliness of FLEXOR is the number of lines of code required to write a specific application. In standard TinyOS

implementations, all the code, including component wirings, is written manually and thus the required number of lines is the highest among all presented implementations. In graphically supported TinyOS implementations, the complexity of wiring components is taken over by the code generation tool, leading to a significant drop in the total number of lines of code. On the other hand, the application implementation, including the usage of all components and their interactions, remains relatively complex. Finally, FLEXOR only requires the user to write small snippets of code, while all the code for module interaction and initialization is automatically generated. Therefore, FLEXOR offers the lowest amount of complexity, while at same time offering the developer a full-featured platform portability of her code. B. Quality of Service of FLEXOR We evaluate the overhead of FLEXOR in terms of processing time, memory, and energy consumption by using the same sample application on top of FLEXOR using the typical WSN scenario of a periodic reporting application. In this application, a node reports the reading of one of its sensors to a base station over a wireless link. We use the DemoSensor TinyOS component, which reports the internal voltage sensor in the case of the TelosB platform and constant values in the case of the MICAz platform. The base station listens to the sensing node and logs the received data in its on-board Flash or simply drops it, depending on the evaluation requirements.

744 Module Manager 766 Callback Manager TOS Interface 2170 + Packet Buffer

3708

Current [mA|

3680

3912

3498 52 29610

153

36 65

1462

22

Legend FLEXOR Native

24124

28640

199

27628

145

21

Reading sensor data, preparing packet

1517

1553

~ 3 msec

20

Native 6100

1370

~14 msec Preparing for sending

~1.03 msec

19

149

Sending packet

6105 6110 6115 6120 Time [milliseconds]

6125

22

ROM RAM Sensing Node TelosB

ROM RAM Logging Node TelosB

ROM RAM Sensing Node MicaZ

ROM RAM Logging Node MicaZ

Figure 5. Static memory footprint in bytes for native and FLEXOR based implementations of the same periodic reporting application, compiled for TelosB and MicaZ platforms.

In order to quantify the individual overhead of each FLEXOR component, we implemented many different variants of this application both on top of FLEXOR and natively on TinyOS. We measured the maximum achievable throughput and tested FLEXOR with high incoming traffic. Generally, FLEXOR has a very low overhead both in terms of processing time and memory consumption. Furthermore, the implementation of FLEXOR enforces widely accepted TinyOS programming practices which is a great advantage for both programming novices and experts and has a positive impact on the system reliability. 1) Memory overhead: Figure 5 shows the memory requirements for the native implementation of the periodic reporting application and for the corresponding FLEXOR implementation. Note that exactly the same TinyOS components are included in both FLEXOR and native: once by way of traditional TinyOS wiring and implementations and once by way of switching on/off FLEXOR interface parameters. As the comparison shows, the overhead of FLEXOR over the native TinyOS implementation is very small, especially if we take into account all of the advantages and additional functionalities that FLEXOR provides. For example, while the application functionality for both implementations is the same, FLEXOR makes it possible to interact with the nodes by way of serial communication or through a wireless link as well as to exchange specifications remotely. Note that the overhead of FLEXOR on top of the native implementation varies across different applications due to the optimization techniques of the nesC compiler. Figure 5 also presents a breakdown of the memory consumption of the main FLEXOR components, with a specific focus on the platform-specific interface along with the packet buffers and buffer handling mechanism, the callback manager, and the module manager with its corresponding specifications. The most costly property of FLEXOR is its platform independence as well as the packet management

Current [mA]

Reading sensor data, preparing packet

21

~1.33 msec

Sending packet ~14 msec Preparing for sending

~ 3.7 msec

20

FLEXOR

19 5960

5965

5970 5975 5980 Time [milliseconds]

5985

5990

Figure 6. Energy expenditure patterns for the periodic reporting application for native TinyOS and FLEXOR implementation.

and buffering. The other two components, the callback and the module manager, are rather inexpensive, but have a significant impact on the user friendliness of the system and its run-time management abilities. 2) Processing and energy overhead: The energy expenditure and processing overhead of the FLEXOR sensing node implementation compared to the TinyOS native implementation are presented in Figure 6. We distinguish three steps in the application: the acquisition of a sensor reading, the preparation and forwarding of packets to the TinyOS components devoted to wireless transmission, and the TinyOS transmission overhead. As expected, the first step is slightly more time-consuming for FLEXOR, as it incorporates the overhead of buffer management, module passing, etc. The second step is the same for both implementations, as it is does not directly involve FLEXOR. The third step is also slightly more time-consuming for FLEXOR, because its packets contain an extra header. We have acquired very similar results for the base station, where the native implementation requires around 0.06 ms for processing and dropping the packet, and the FLEXOR implementation needs 0.6 ms. This overhead is mainly due to the packet buffer management of FLEXOR and is expected to be constant for any application or module stack. In summary, the processing and energy overhead of FLEXOR is very small compared to the benefits that FLEXOR offers. 3) Load tests and throughput: In this experiment we explore the maximum throughput of FLEXOR in terms of processing incoming packets. This cannot be seen from the experiments presented so far, because the processing of a single packet in FLEXOR requires immediate buffering and delayed processing. With low incoming traffic, these two processes are executed immediately one after the other. With

Platform

Inter-Packet Interval (sender)

Dropped packets (receiver)

FLEXOR TinyOS

12 msec 12.8 msec

0 1

Table V T HROUGHPUT OF BOTH FLEXOR AND T INYOS APPLICATIONS IN TERMS OF ACHIEVED IPI AND DROPPED PACKET RATE . I N FACT, THE T INYOS IMPLEMENTATION HAS HIGHER LATENCY DUE TO THE RATHER UNSTRUCTURED CODE .

high incoming traffic, the processing of packets is delayed until the system is free. To conduct this experiment, we again use our example application and implement it both under FLEXOR and natively under TinyOS. For both applications, we let the reporting node produce packets at the lowest possible InterPacket Interval (IPI). The results from this experiment are presented in Table V. We report on the lowest achieved IPI at the reporting node and the number of dropped packets at the receiver’s node. It can be seen that both throughputs are the same. In fact, the TinyOS implementation seems to have even more latency. This is due to the rather unstructured code of the native implementation. In other words, FLEXOR does not exhibit latency in its packet production, sending and receiving mechanisms, nor in its packet buffer management. This is very important result, as it enables FLEXOR to implement the same complexity of protocols as native applications. As we demonstrated in this section, FLEXOR is userfriendly and it improves the quality of experience of WSNs programming, as well as, at the same time, maintain a perfectly acceptable overhead in terms of memory, processing, and energy. It represents a good trade-off for the functionality and properties it offers. VI. T HE POTENTIAL OF FLEXOR FLEXOR QoE and UF are beneficial for several categories of users, whose research tasks range from new architecture development and evaluation to novel programming paradigms. In this section, we elaborate on some of the potential uses of FLEXOR in several domains. A. Teaching wireless sensor networks As discussed in Section V, we have already employed FLEXOR for teaching WSNs at a university level. However, FLEXOR is also accessibly by non-programmers and can be used also in non-engineering courses for demonstrating the use of WSNs, such as in oceanography, biology, ecology, archeology, etc. There, several scenarios can be prepared for the students to experiment with. B. Testbed management FLEXOR eliminates the need for a backchannel in a testbed. While a backchannel is undoubtedly very convenient for testing and debugging, it is not always available or

very costly to implement. Furthermore, managing mobility in testbeds and deployments is a major challenge, as nodes typically rely on a wired backchannel to receive new software, log data, etc. With FLEXOR, these features can be taken over by the callback invocation and the runtime management of modules, as described in Section III. FLEXOR can also be used together with any platformdependent and independent debuggers, code inspections, and visualization mechanisms, since it is entirely C-based. For example, its TinyOS implementation can be visualized and inspected with the toolkit of Dalton et al. [17]. C. Performance analysis and optimization Link level traces: Link level traces represent an important tool to boost the realism of simulation. It is critical to be able to collect such traces not only from traditional backchannel-based testbeds, such as MoteLab [12], but in any environment, including outdoors. FLEXOR simplifies this task by making it possible to easily send commands to the nodes, change their behavior, and even collect the traces at a centralized sink point without the use of a backchannel. Fairness and visibility: Fairness is a major challenge when several protocols co-exist on the same node [18]. Payloads coming from different modules are packed into the same packet, thus minimizing the overall network traffic. An additional isolation or packet compression module can be implemented and placed just before the interface, thus enabling inspection of packets and additional fairness-oriented mechanisms. Finally, the extreme modularity of FLEXOR allows for better visibility of the individual modules [19], as individual modules can be clearly separated and their internal state and processes can be logged. Evaluation and benchmarking: Another typical task for WSN developers is to evaluate and benchmark protocols or services. Typically, protocols are loaded and tested in a sequence. FLEXOR simplifies this task, especially in a real-world deployment where backchannels are not available. Callback invocation is used to easily exchange protocols without affecting the state of the other protocols. Recently the case has been made that protocols need to be testbed not in sequence, but concurrently [20]. This can be achieved with FLEXOR by simply connecting the two protocols in the module stack and letting them work simultaneously. D. Dynamic software FLEXOR enables the long-term management of software modules, known as software rejuvenation [21]. Software rejuvenation can be easily achieved with FLEXOR by using the module interface and its main functions init, start and stop. Instead of rebooting a node and loosing its complete state, all of the FLEXOR modules can be re-started at any time and thus achieve rejuvenation of the existing state of individual modules. More sophisticated techniques, such as run-time introspection of modules, can be implemented as

FLEXOR modules to observe the other modules and to control them. VII. C ONCLUSION WSN research has been very successful in producing solutions to solve challenges at different levels and in variegate scenarios. However, most of those solutions remained limited to solve the original challenge they were thought, and could barely be reused in very few cases. We argued that WSNs developers work would be very much simplified and enriched, as well as they would experience much better quality when they are offered with an architecture that allows cross-platform code reuse and fast prototyping, and enables the remote control and selective activation of specific modules on individual nodes at run-time. With those design goals, FLEXOR is a modular and flexible software architecture for the rapid prototyping of WSNs. As we presented in our evaluation, FLEXOR: • has the potential to streamline WSN development by encouraging code reuse; • lowers the barriers to entry into the traditionally challenging WSN development process by offering a platform-independent software architecture as well as a user-friendly programming environment and toolchain; • represents an orthogonal effort with widely used WSN operating systems such as TinyOS and Contiki; • can also be viewed as a framework for the integration of advanced debugging techniques such as passive infield inspection of WSNs; • offers a rich set of functionalities with a very low energy footprint and processing overhead. As part of our follow-up work, we plan to implement a large number of components to enrich FLEXOR’s basic set of modules. ACKNOWLEDGMENT This work is partially supported by the SUPSI funded research project MOTEL, by the EU Cooperating Objects Network of Excellence (CONET) and by the EU FP7 Project SCAMPI: Service platform for social Aware Mobile and Pervasive computIng (ICT grant agreement 258414). R EFERENCES [1] M. A. Hail, J. Pinkowski, T. Teubler, M. Danckwardt, D. Pfisterer, and H. Hellbr¨uck, “Roombanet - testbed for mobile networks,” in Proceedings of WowKiVS 2011, T. Margaria, J. Padberg, and G. Taentzer, Eds., vol. 37. [2] K. Whitehouse, G. Tolle, J. Taneja, C. Sharp, S. Kim, J. Jeong, J. Hui, P. Dutta, and D. Culler, “Marionette: using rpc for interactive development and debugging of wireless embedded networks,” in The Proc. of IPSN., 2006, pp. 416 –423. [3] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, “System architecture directions for networked sensors,” in Proc., ser. ASPLOS-IX. , 2000, pp. 93–104. [4] The Operating System for Embedded Smart Objects - the Internet of Things, “http://www.sics.se/contiki/.”

[5] P. J. Marr´on, A. Lachenmann, D. Minder, J. H¨ahner, R. Sauter, K. Rotherme, “TinyCubus: A flexible and adaptive framework for sensor networks,” in Proc. of EWSN, 2005, pp. 278–289. [6] P. Costa, G. Coulson, C. Mascolo, G. Picco, and S. Zachariadis, “The runes middleware: a reconfigurable componentbased approach to networked embedded systems,” in Proc. of PIMRC, vol. 2, 2005, pp. 806 –810 Vol. 2. [7] N. Brouwers, K. Langendoen, and P. Corke, “Darjeeling, a feature-rich vm for the resource poor,” in Proc. of SenSys, Berkeley, California: ACM, 2009, pp. 169–182. [8] P. Levis and D. E. Culler, “Mate: A virtual machine for tiny networked sensors,” in Proc. of the ACM Conf. on Arch. Support for Progr. Languages and Operating Systems, 2002. [9] P. Levis, N. Patel, D. Culler, and S. Shenker, “Trickle: a selfregulating algorithm for code propagation and maintenance in wireless sensor networks,” in Proc. of the Conf. on Netw. Syst. Design and Impl. Berkeley, USA, 2004, pp. 2–2. [10] MViz, “http://www.tinyos.net/tinyos-2.x/apps/mviz/,” 2008. [11] R. Jurdak, A. G. Ruzzelli, A. Barbirato, and S. Boivineau, “Octopus: monitoring, visualization, and control of sensor networks,” Wirel. Commun. Mob. Comput., vol. 11, pp. 1073–1091, August 2011. [12] G. Werner-Allen, P. Swieskowski, and M. Welsh, “Motelab: a wireless sensor network testbed,” in Proc. of IPSN, 2005, pp. 483–488. [13] Wisebed, “www.wisebed.eu,” 2011. [14] G. Wagenknecht, M. Anwander, T. Braun, T. Staub, J. Matheka, and S. Morgenthaler, “Marwis: a management architecture for heterogeneous wireless sensor networks,” in Proc. of WWIC, Berlin, 2008, pp. 177–188. [15] W. Backes and J. Cordasco, “xm: a graphical user interface for mobile ad-hoc sensor and pda networks,” in Proceedings of SESENA, New York, USA, 2010, pp. 55–60. [16] P. V¨olgyesi, M. Mar´oti, S. D´ora, E. Osses, and A. L´edeczi, “Software composition and verification for sensor networks,” Science of Comp. Programming, vol. 56, pp. 191–210, 2005. [17] A. R. Dalton and J. O. Hallstrom, “A toolkit for visualizing the runtime behavior of tinyos applications,” in Proc. of ICPC. Amsterdam, The Netherlands, 2008, pp. 43–52. [18] J. Il Choi, M. Kazandjieva, M. Jain, and P. Levis, “The case for a network protocol isolation layer,” in Proc. of SenSys, Berkeley, CA, USA, 2009. [19] M. Wachs, J. I. Choi, J. W. Lee, K. Srinivasan, Z. Chen, M. Jain, and P. Levis, “Visibility: a new metric for protocol design,” in Proc. of SenSys, Sydney, AU, 2007, pp. 73–86. [20] O. Gnawali, L. Guibas, and P. Levis, “A case for evaluating sensor network protocols concurrently,” in Proc. of WinTECH, Chicago, USA, 2010, pp. 47–54. [21] M. Woehrle, A. Meier, K. Langendoen, “On the potential of software rejuvenation for long-running sensor network deployments,” in Proc. of SESENA, South Africa, 2010.