scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

DAViM: a dynamically adaptable virtual machine for sensor networks

TL;DR: DaviM, the Distrinet Adaptable Virtual Machine is presented and how it allows to customize sensor behavior, to extend its functionality and to execute multiple applications in parallel is described.
Abstract: Sensor networks are being deployed for substantial periods of activity, and are being used by multiple applications with possibly diverse requirements. Since manually upgrading or updating sensor software is often impossible, run-time software reconfiguration represents a considerable success factor for many practical usage scenarios of sensor networks. This paper presents DAViM, the Distrinet Adaptable Virtual Machine and describes how it allows to customize sensor behavior, to extend its functionality and to execute multiple applications in parallel. We have evaluated the proposed architecture by implementing a proof-of-concept prototype on micaZ hardware. First results indicate that it is already feasible to run the DAViM core on micaZ hardware, while memory requirements of the full DAViM implementation are close enough to fit on more recent sensor hardware.

Summary (2 min read)

2. REQUIREMENTS SUMMARY

  • The authors summarize the key requirements of the system from both perspectives: customizability of sensor behavior, extendability of sensor functionality, and concurrency.
  • The first requirement offers support to service providers, the others help manage the sensor network as a service platform.

2.1 Customizability of sensor behavior

  • Secondly, the system must offer functionality that is spe-cific for a particular application domain.
  • This functionality is offered as operation libraries that can be called by applications running on the node.
  • By consequence, applications can be very lightweight since the core functionality is already available in the libraries on the node.

2.2 Extendability of sensor functionality

  • In order to handle such changing circumstances, first of all, the system must be extendable by adding missing functionality when needed.
  • At all times, the system should offer the most appropriate set of operations without pre-installing unneeded functionality.
  • Secondly, the system must be able to support the execution of added functionality, i.e. reacting to new types of events and handling these events correctly.
  • Finally, the system must provide each application with an execution environment that offers the minimal but sufficient (sub)set of operations.
  • Some operations may be used by multiple applications, some operations may be application specific.

2.3 Concurrency

  • The system should allow multiple applications to use the set of operation libraries in parallel.
  • Each application should execute as if it were the only one on the system and the only application using a particular operation library, also known as Concurrency should be transparent.
  • The system must ensure safe execution and prevent race conditions and deadlocks; it must protect shared variables and schedule operations from different applications.

4. DAVIM ARCHITECTURE

  • The architecture is explained by exploring how it supports a representative use case that incorporates the requirements outlined in Section 2.
  • The use case is presented incrementally by using three scenarios: the first scenario illustrates the basic VM support of DAViM, the second scenario shows how DAViM enables a VM to be dynamically updated and the third scenario describes DAViM support for executing multiple VMs in parallel.
  • It should be noted that the DAViM architecture assumes that the underlying operating system provides dynamic memory and dynamic modules.

4.1 Basic virtual machine support

  • Whenever a new container with a sensor node attached enters the sensor network, the Coordinator component will cooperate with the Coordinator components of neighboring nodes to synchronize the state of the DAViM system.
  • In case the entering node misses an application loaded on the other nodes, neighboring nodes will send it to the new node.

4.3 Support for multiple virtual machines

  • In order to enable flexible and transparent sharing of operation libraries, the library identifier encoded in the byte code of an instruction set is decoupled form the actual library identifier known by the Library Manager.
  • In addition, this enables dynamic updates of the operation libraries that are included in a virtual machine and loading of operation libraries without interference with running virtual machines.

4.4 Discussion

  • As such, the authors argue that the DAViM architecture combines the advantages of both reconfigurable operating systems and virtual machines: as long as the needed operation libraries are present, lightweight applications can be downloaded to a DAViM VM to reconfigure the system's behavior.
  • This is, however, acceptable, given the low frequency of performing such major updates and the considerable added value for employing sensor networks during a substantial period of time.

5. PROTOTYPE IMPLEMENTATION

  • The limited amount of dynamic memory that could be reserved on micaZ hardware currently prevents realistic field tests.
  • MicaZ sensor nodes have available 4KB of RAM of which SOS reserves 1,5 KB for dynamic memory allocation.
  • Experiments on micaZ nodes have shown that more dynamic memory is needed to use more than one simultaneously activated VM for a realistic application.
  • Yet, simulations show that DAViM needs less than twice the amount of dynamic memory available on micaZ hardware.
  • The authors expectations are that more recent hardware will solve current memory limitations.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

DAViM: a Dynamically Adaptable Virtual Machine for
Sensor Networks
Sam Michiels, Wouter Horr
´
e, Wouter Joosen, Pierre Verbaeten
IBBT-DistriNet Research Group, Department of Computer Science,
K.U.Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium
{sam.michiels,wouter.horre}@cs.kuleuven.be
ABSTRACT
Sensor networks are being deploye d for substantial periods
of activity, and are being used by multiple applications with
possibly diverse requirements. Si nce manually upgrading or
updating sensor software is often impossible, run-time soft-
ware reconfiguration represents a considerable success fac-
tor for many practical usage scenarios of sensor networks.
This paper presents DAViM, the Distrinet Adaptable Vir-
tual Machine and describes how it allows to customize sensor
behavior, to extend its functionality and to execute multi-
ple applications in parallel. We have evaluated the proposed
architecture by implementing a proof-of-concept prototype
on micaZ hardware. First results indicate that it is already
feasible to run the DAViM core on micaZ hardware, while
memory requirements of the full DAViM implementation are
close enough to fit on more recent sensor hardware.
Categories and Subject Descriptors
C.2.4 [Computer-Communication Networks]: Distributed
Systems—Distributed Applications; D.2.11 [Software En-
gineering]: Software Architectures—Domain-specific archi-
tectures
General Terms
Design, Management
Keywords
Sensor middleware, software architecture, adaptability
1. INTRODUCTION
Sensor networks must be dynamically adaptable to sur-
vive software bugs and changes in network conditions, ap-
plication requirements, or available resources [16]. Sensors
are typically deployed for substantial periods of activity and
integrated in office buildings or warehouses, implanted in
Copyright ACM, 2006. This is the author’s version of the work. It is
posted here by permission of ACM for your personal use. Not for redis-
tribution. The definitive version was published in Proceedings of the 1st
International Workshop on Middleware for Sensor Networks (MidSens’06),
http://doi.acm.org/10.1145/1176866.1176868
animals, or spread out in nature [4]. By consequence, in-
stalling a new sensor network may imply a considerable in-
vestment. In addition, sensor networks may produce data
that are relevant for multiple purposes, which implies that
multiple applications should be able to reuse the same sensor
infrastructure.
From this perspective, a sensor network becomes a light-
weight service platform on which service providers can in-
stall a wide variety of applications. Figure 1 sketches the
context of such a service platform and illustrates how it is
linked with end-user appli cations. Think, for example, of
a chemical factory in which a sensor network has been de-
ployed to manage operations and safety. The same sensor
network can be used, for instance, by (1) a facility manage-
ment application to control the temperature in ro oms where
inflammable substances are stored, (2) a stock management
application to check in real-time the availability of particu-
lar supplies and to monitor incoming and outgoing products,
and (3) a safety monitoring application to l ocalize dangerous
pro ducts and to detect when incompatible substances ap-
proach within a pre-defined perimeter. These applications
make use of various services offered by the sensor network
such as temperature monitoring, data querying, sensor lo-
calization, and distance measuring. In addition, each appli-
cation may require different behavior and accuracy related
to data collection, data aggregation, lo cal ization, or timing.
In this context, one of the key research challenges is to
manage sensor networks in such a way that they can be
dynamically customized to various (unanticipated) circum-
stances. Since resource limitations prevent sensors to have
an extensive set of services pre-installed, sensor software
should be dynamically reconfigurable [13]. This implies not
only customizing the behavior of a sensor node, i.e. chang-
ing how a sensor operates by using the same functionali ty in
different ways, but also adding and removing functionality,
i.e. changing what the sensor node does.
The contribution of this paper i s the presentation of DA-
ViM, the Distrinet Adaptable Virtual Machine. DAViM is
partly inspired by ASVM [10], but offers more possibilities
for dynamic reconfiguration of sensor networks. DAViM
allows not only running lightweight applications, but also
allows adding or removing operation libraries. In addition,
it allows multiple applications to execute concurrently on a
no de . The architecture has been validated by implementing
a proof-of-concept prototype on micaZ hardware. Although
the full implementation of the current prototype i s slightly
to o large to fit on micaZ hardware, it shows that DAViM’s
memory requirements are modest enough to fit on more re-

OS (Windows CE, Palm OS, ...)
Airco
application
Airco technician PDA
OS (Symbian, Linux, Windows CE, ...)
Safety
application
Safety Officer mobile phone
Gateway node
OS (Windows, Linux, ...)
Safety
application
DAViM tools
Safety Officer Portable
TCP/IP
Zigbee
OS (SOS, Contiki, ...)
Sensor node
Sensor network
OS (Linux, Windows, ...)
Airco
application
Application Server
Airco
application
Safety
application
Localization
People
detection
DAViM
...
Airco
control
DBMS
DAViM
tools
...
Safety
application
DAViM tools DAViM tools
Figure 1: A sensor network as a lightweight service platform on which service providers can install a wide
variety of applications, e.g. for airco control, localization and people detection. Application components are
distributed over user terminals (e.g. a portable, PDA or a mobile phone), the sensor network and the gateway
between the two. DAViM is installed on the sensor network. The DAViM tools on the user terminals support
functionality for code injection and operation library management.
cent hardware.
The remainder of the paper is structured as follows. Sec-
tion 2 summarizes the key requirements that DAViM must
support. Section 3 describes related work in the context
of dynamically reconfigurable sensor systems. Section 4
presents the DAViM architecture through exploring a rep-
resentative use case and discusses its main contributions.
Section 5 describes the proof-of-concept implementation of
the architecture. Section 6 formulates the main conclusions
and sketches directions for future work.
2. REQUIREMENTS SUMMARY
When considering a sensor network as a lightweight ser-
vice platform, we can identify two key roles of the DAViM
architecture. On the one hand, DAViM must enable s ervi ce
providers to use and extend the sensor network by installing
various applications on it and retrieving data from its sen-
sors. On the other hand, DAViM must support network
administrators to manage the sensor network by distribut-
ing, storing and handling applications.
To implement this segregation successfully and to enable
complex applications to execute on the sensor network, DA-
ViM must offer support to as many applications as possible
by extending the available set of operations if needed and
by allowing applications to execute in parallel.
We summarize the key requi rements of the system from
both perspectives: customizability of sensor behavior, ex-
tendability of sensor functionality, and concurrency. The
first requirement offers support to service providers, the oth-
ers help manage the sensor network as a service platform.
2.1 Customizability of sensor behavior
First of all, sensor behavior must be customizable by dy-
namically injecting application code in the sensor network.
This code is stored in every node of the network and its
execution makes each sensor behave as preferred.
Secondly, the s ys tem must offer functionality that is spe-
cific for a particular application domain. This functionality
is offered as operation libraries that can be called by appli-
cations running on the node. By consequence, applications
can be very lightweight since the core functionality is already
available in the libraries on the node.
2.2 Extendability of sensor functionality
Deciding what functionality will be installed on every sen-
sor node is complex since requirements can vary during the
life-time of an application, network conditions are highly un-
predictable, and system resources are very scarce and vari-
able. For example, when a more efficient sensor localization
algorithm becomes available, it can be much more efficient
to dynamically i nstall this building block as needed.
In order to handle such changing circumstances, first of
all, the system must be extendable by adding missing func-
tionality when needed. T he set of operations should be
modularized in order to allow fine-grained extensions. At
all times, the system should offer the most appropriate set
of operations without pre-installing unneeded functionality.
Secondly, the system must be able to support the exe-
cution of added functionality, i.e. reacting to new types of
events and handling these events correctly. Consequently,
the system must be extendable by adding specific event han-
dlers and corresponding state machines. For example, when
functionality is added to communicate with a previously un-
used hardware sensor, the system must be extended to han-
dle new types of hardware events.
Finally, the system must provide each application with
an execution environment that offers the minimal but suffi-
cient (sub)set of operations. Different applications may have
highly diverse requirements, resulting in different amounts
of system support needed. Some operations may be used by
multiple applications, some operations may be application
specific. Consequently, common operations must be decou-
pled from the application and concentrated in libraries that
dynamically offer operation sets with respect to the system.

2.3 Concurrency
The system should allow multiple applications to use the
set of operation libraries in parallel. Concurrency should be
transparent: each application should execute as if it were
the only one on the system and the only application us-
ing a particular operation library. The system must ensure
safe execution and prevent race conditions and deadlocks; it
must protect shared variables and schedule operations from
different applications.
3. RELATED WORK
Related research in the domain of sensor reconfigurability
typically focuses on either operating system reconfigurabil-
ity or v irtual machine support.
Research in dynamically reconfigurable sensor operating
systems has shown that it is feasible to dynamically extend
system services in a sensor network. The cost of extending
sensor functionality mainly depends on the granularity of
the code to be transported in the network. TinyOS/Deluge
[6], for instance, replaces a complete system image which
implies considerable network overhead to transport the up-
date to all nodes in the network. Several approaches [12,
14, 7] have been proposed to reduce the code that has to
be transported to be able to reconstruct the updated image.
SOS [5] modularizes the operating system in a static ker-
nel and multiple service modules for routing, localization,
timing, etc. Modules are position independent co de, have
a limited size (4KB) and can be dynamically downloaded
to update the system. Contiki [3, 2] allows to dynamically
load binary modules in the standard ELF file format and a
variant called CELF (compact ELF).
Research in the domain of sensor virtual machines shows
that the update cost can be decreased considerably by in-
stalling on every node a virtual machine that offers a set
of high-level operations related to a specific application do-
main. In order to customize sensor behavior, application
scripts are downloaded to every sensor node. Such applica-
tions can use high-level operations that are available in the
VM of every node, which makes them very lightweight. By
consequence, sensor updates can be very efficient on condi-
tion that the operation library that is available on the node
offers enough functionality to cover the life-time of the sen-
sor network.
Deciding what functionality will be offered in the VM is
complex given the highly dynamic circumstances in which
a sensor network operates. ASVM [10], based on the work
in Mat´e [9], al lows customization of the available operations
at deployment-time. VM* [8] provides a continuous update
model in which the functionality of a sensor virtual ma-
chine can be incrementally extended as needed. VM* only
includes the operations that are neede d by the application
that is running on the node, and extends the virtual machine
when applications with extra requirements are installed.
The two related research domains, operating systems and
virtual machines for sensor networks, focus on two require-
ments that were described in Section 2: customizability of
sensor behavior and extendability of sensor functionality.
The research for this paper can be positioned between the
two state-of-the-art approaches for dynamic sensor updat-
ing. Virtual machine approaches enable highly efficient up-
dates but are limited to a pre-defined application domain.
Mo dul ar operating systems enable any service to be up-
dated, but imply a higher cost since downloaded modules are
more coarse-grained compared to a virtual machine applica-
tion. The DAViM architecture offers a best-of-both-worlds
solution by extending the idea of ASVM [10] to allow cus-
tomization of available operations at runtime through dy-
namically loadable operation libraries. In addition, DAViM
can b e reused for various application domains by enabling
concurrent execution of different VMs.
Dunkels e.a. have investigated the energy efficiency of
various reprogramming techniques for wireless sensor net-
works [2]. They confirm that the combination of virtual
machine code and native code using dynamically loadable
modules, which is the approach taken in this paper, is ben-
eficial for energy efficiency.
Balani e.a. present DVM [1], which takes a similar ap-
proach for dynamically updating sensor VMs. DAViM, how-
ever, is positioned in a broader and more open perspective
by approaching sensor networks as lightweight service plat-
forms. In view of this, DAViM also enables multiple appli-
cations to be executed in parallel. Furthermore, the DAViM
architecture is independent from the underlying sensor op-
erating system.
4. DAVIM ARCHITECTURE
This section presents the main components of the DAViM
architecture (see Figure 2). The three key aspects that dif-
ferentiate the DAViM architecture from related sensor vir-
tual machines are: (1) a network coordinator that is respon-
sible for distributing application code, operation libraries,
as well as VM descriptions, (2) a scheduler that schedules
op e rations over multiple VMs, and (3) a library manager
that allows dynamic updates of the used instruction set of
a VM.
The architecture is explained by exploring how it supports
a representative use case that incorporates the requirements
outlined in Section 2. We consi der a sensor network deployed
in a building of a chemical factory used for storage of chem-
icals (see Figure 1). The use case is presented incrementally
by using three scenarios: the first scenario illustrates the ba-
sic VM support of DAViM, the second scenario shows how
DAViM enables a VM to be dynamically updated and the
third scenario describes DAViM support for executing mul-
tiple VMs in parallel. It should be noted that the DAViM
architecture assumes that the underlying operating system
provides dynamic memory and dynamic modules.
4.1 Basic virtual machine support
The sensor network is used by the air conditioning system
to detect when to switch the system on or off. The sensor
network informs the air conditioning system whenever an ob-
served temperature rises above or falls below certain thresh-
olds. These thresholds may change during the lifetime of
the sensor network. The nodes in the sensor network may
also change due to addition or removal of containers that
have a node attached.
To support this basic application, the system must first
of all include the application specific functionality that is
needed by the air condi tioning system. Secondly, it must be
possible to dynamically customize the application to change
the thresholds. Thirdly, new nodes that enter the network
must be brought up to date to enable them to be used in
the application.
This scenario is supported by deploying the DAViM sys-

Figure 2: Overview of the DAViM architecture.
tem on the sensor nodes along with one virtual m achine
with an instruction set capable of sensing temperature and
communicating with the air conditioning system. The ap-
plication itself is implemented in the instruction set of this
virtual machine.
To change the thresholds, the air conditioning s ys tem can
install a new version of (a part of) the application on the
gateway node. The Coordinator component on the gate-
way will inform the neighbors of the update and distributes
the new code to them. Each node that receives the update
via its Coordinator component passes the code to the Ap-
plication Manager, which i nstall s the newly arrived update
and informs the VM Store of this change. The Concurrency
Manager analyzes the new code to determine which shared
variables are used. This information is stored to ensure safe
execution of the different parts of an application. After-
wards the VM Manager reboots the virtual machine with
the new application.
Whenever a new container with a sensor no de attached
enters the sensor network, the Coordinator component will
co operate with the Coordinator components of neighboring
no de s to synchronize the state of the DAViM system. In
case the entering node misses an application loaded on the
other nodes, neighboring nodes will send it to the new node.
4.2 Dynamic adaptation of virtual machines
Since the energy cost to cool down the whole building
can be quite high, and since only a fraction of the stored
chemicals must be kept really cold, the management may
decide to divide the building in several rooms that can be
co ol ed down separately by the air conditioning system.
To support this new situation, the application on the sen-
sor network needs to be able to not only detect when a tresh-
old is exceeded, but also where this happens. This requires
the instruction set of the virtual machine to be extended to
with a localization instruction.
The instruction sets of the virtual machines are grouped in
op e ration libraries of related instructions. These operation
libraries can be loaded, changed or removed dynamically.
To extend the virtual machine of our air conditioning sys-
tem with a localization service, we implement this service
as an operation library and load it into the DAViM system.
The op e ration librarie s are impl emented as operating system
modules. The Coordinator uses the m echanisms provided by
the op erating sys tem to distribute and install the library in
the sensor network. After the op eration library is loaded,
the Coordinator informs the Library Manager. The Library
Manager is part of the Operation Store, to which also the
op e ration libraries belong. Its task is to do the bookkeeping
associated with the operation libraries. The most important
task is to keep track of the mapping between the identifier
of a l ibrary and the actual op erating system module imple-
menting it.
Before the localization library can be used, it has to be in-
cluded in the instruction set of the virtual machine of the ai r
conditioning application before it can be used. Again, this
update is installed on the gateway node and distributed au-
tomatically by the Coordinator component of DAViM. The
installation of the updated v irtual machine is handled by
the VM Manager.
4.3 Support for multiple virtual machines
To comply with new legislation, a safety officer, possibly
externally hired, has to keep statistics of the presence of
workers in the neighborhood of the most dangerous chemi-
cals. To ease his work, the safety officer wants to deploy a
service on the existing sens or network to m onitor the pres-
ence of people in the buildi ng and to trigger an alarm when
somebody stays in the neighb orhood of a dangerous chemi-
cal for too long. In addition, it must be possible to monitor
the distance between the chemicals to ensure that a safety
perimeter around dangerous chemicals is preserved.
This new application is independent of the already de-
ployed air conditioning application and, by consequence,
they should be isolated. The new functionality needed for
detecting people must be added without interfering with the
already install ed application. Furthermore, since the appli-
cation also needs the functionality for localization, the sys-
tem must supp ort flexible and transparent sharing of this
functionality in order to minimize mem ory requirements.
DAViM supports the isolation of applications by allow-
ing multiple virtual machines to run concurrently. These
virtual machines do not have to be loaded in advance, but
can be loaded dynamically. This makes it possible to deploy

DAViM on a sensor network without predicting the future
applications that will run on it. For the safety application,
a new virtual machine is installed. To perform this instal-
lation, a description of the new virtual machine is loaded
onto the gateway node. After arrival on a no de, the addi-
tion of a virtual machine is handled similar to an update to
an existing vi rtual machine.
The applications in both virtual machines, as well as the
virtual machines itself can be updated without interfering
with the application in the other virtual machine. The
VM Controller ensures the running virtual machines oper-
ate smoothly. The Scheduler enforces a scheduling policy
involving all loaded virtual machines. The Event Manager
dispatches the events in the system (e.g. timer events, events
generated by operation libraries, . . . ) to the appropriate vir-
tual machine.
In order to enable flexible and transparent sharing of op-
eration libraries, the library identifier encoded in the byte
co de of an instruction set i s decoupled form the actual l i-
brary identifier known by the Library Manager. In addition,
this enables dynamic updates of the operation libraries that
are included in a virtual machine and loading of operation
libraries without i nterference with running virtual machines.
4.4 Discussion
The DAViM architecture supports the requirements that
were described in Section 2 as follows. First of all, sen-
sor behavior can be customized by distributing applications
in the network via the Co ordinator component, and stor-
ing them in the Application Store that is available on every
no de . Secondly, the functionality offered by each sensor can
be dynamically extended by distributing operation libraries
(again via the Coordinator) and storing them in the Oper-
ation Store. The Library Manager decouples the operation
libraries from the VM that is using them. In this way, an op-
eration li brary can be transparently added to a VM, which
allows to offer exactly those operations that are needed by
the applications running on a node. Thirdly, the Concur-
rency Manager and the Scheduler enable multiple VMs to
safely execute in parallel. In combination with the extension
capabilities, each VM can be offered a customized operation
library that can be used as if only one VM were present.
As such, we argue that the DAViM architecture combines
the advantages of both reconfigurable operating systems and
virtual machines: as long as the needed operation libraries
are present, lightweight applications can be downloaded to
a DAViM VM to reconfigure the sys tem’s behavior. When
multiple applications need to be deployed in parallel, or
when extra sensor functionality is required by an applica-
tion, operating system mo dul es can be downloaded to re-
configure the VMs itself. Because such an update implies
more code to be transported, i t is less efficient. This is,
however, acceptable, given the low frequency of performing
such major updates and the considerable added value for
employing sensor networks during a substantial period of
time.
5. PROTOTYPE IMPLEMENTATION
The presented architecture has been evaluated by imple-
menting a proof-of-concept prototype. The implementation
offers support to download and install applications on a VM,
extend the functionality in each node by downloading oper-
ation libraries, and activate multiple VMs on a single sensor
no de . The current implementation allows to activate up to
eight VMs in parallel, each of which can use up to eight
op e ration libraries. Due to memory limitations of micaZ
hardware, however, only one VM can be deployed at the
moment.
The architecture relies on an underlying operating sys-
tem that provides dynamic memory and loadable modules.
We have chosen the SOS operating system for our imple-
mentation because it provides this features and has good
support for micaZ hardware. The core architecture and
the operation libraries are implemented as SOS modules,
what enables the operation libraries to be loaded dynami-
cally. Code snippets for the basic operation libraries and
some algorithms related to the Coordinator, the Concur-
rency Manager, and the Scheduler could be reused from an
existing port of ASVM to the SOS operating system.
1
The
architecture does not imply a specific algorithm for the Co-
ordinator component. The current implementation uses the
mechanism provided by SOS for distributing operation li-
braries (SOS uses a variant of MOAP [15]) and Trickle [11]
for distributing applications and VM descriptions.
The limited amount of dynamic memory that could be re-
served on micaZ hardware currently prevents realistic field
tests. MicaZ se nsor nodes have available 4KB of RAM of
which SOS reserves 1,5 KB for dynamic memory all ocation.
Experiments on micaZ nodes have shown that more dynamic
memory is needed to use more than one simultaneously acti-
vated VM for a realistic application. Yet, simulations show
that DAViM needs less than twice the amount of dynamic
memory available on micaZ hardware. This is a promis-
ing result that motivates us to implement the prototype on
more recent hardware.
2
Our expectations are that more re-
cent hardware will solve current memory limitations.
6. CONCLUSION & FUTURE WORK
This pap er has presented the DAViM architecture, which
offers a blueprint for dynamically adaptable sensor virtual
machines. The architecture offers support for three key re-
quirements that sensor networks have to deal with: cus-
tomizability of sens or behavior, extendability of sensor func-
tionality, and concurrent execution of multiple applications.
The paper has discussed the main components. By way of
evaluation of the architecture, we have implemented a proof-
of-concept prototype which provides promising indications
that it is feasible to implement the described functionality
on state-of-the-art sensor hardware.
With respect to future work, we will first of all evaluate
and refine the architecture in the context of an industrial
case study. Our research will gradually extend its focus
from an individual sensor node and a single sensor network
towards an end-to-end view. With end-to-end sensor appli-
cations we mean applications that are distributed over an
enterprise back-end and one or more sensor networks with
possibly different types of sensor nodes.
Developing and deploying end-to-end sensor applications
in a realistic business context remains very complex. This
complexity is partly caused by the highly resource limited,
dynamic and heterogeneous environments in which sensor
1
Networked and Embedded Systems Lab at UCLA
(http://cvs.nesl.ucla.edu/cvs/viewcvs.cgi/ASVM/).
2
For example TelosB (10KB RAM), XYZ (32 KB RAM) or
iMote2 (32 MB RAM)

Citations
More filters
Journal ArticleDOI
TL;DR: This paper outlines a set of requirements for IoT middleware, and presents a comprehensive review of the existing middleware solutions against those requirements, and open research issues, challenges, and future research directions are highlighted.
Abstract: The Internet of Things (IoT) envisages a future in which digital and physical things or objects (e.g., smartphones, TVs, cars) can be connected by means of suitable information and communication technologies, to enable a range of applications and services. The IoT’s characteristics, including an ultra-large-scale network of things, device and network level heterogeneity, and large numbers of events generated spontaneously by these things, will make development of the diverse applications and services a very challenging task. In general, middleware can ease a development process by integrating heterogeneous computing and communications devices, and supporting interoperability within the diverse applications and services. Recently, there have been a number of proposals for IoT middleware. These proposals mostly addressed wireless sensor networks (WSNs), a key component of IoT, but do not consider RF identification (RFID), machine-to-machine (M2M) communications, and supervisory control and data acquisition (SCADA), other three core elements in the IoT vision. In this paper, we outline a set of requirements for IoT middleware, and present a comprehensive review of the existing middleware solutions against those requirements. In addition, open research issues, challenges, and future research directions are highlighted.

805 citations


Cites methods from "DAViM: a dynamically adaptable virt..."

  • ...In populating the tables, a few common legends are used [e.g., supported (S), not supported (NS), no information (NI)—if no information available about the requirement] along with requirement-specific legends [e.g., for lightweight requirements: memory needed (M) and energy efficiency (E)]....

    [...]

Proceedings ArticleDOI
25 Aug 2007
TL;DR: A survey of the current state-of-the-art in the field is presented, establishing a classification and highlighting some likely research challenges and future directions.
Abstract: Wireless sensor networks (WSNs) constitute a new pervasive and ubiquitous technology. They have been successfully used in various application areas and in future computing environments, WSNs will play an increasingly important role. However, programming sensor networks and applications to be deployed in them is extremely challenging. It has traditionally been an error-prone task since it requires programming individual nodes, using low-level programming issues and interfacing with the hardware and the network. This aspect is currently changing as different high-level programming abstractions and middleware solutions are coming into the arena. Nevertheless, many research challenges are still open. This paper presents a survey of the current state-of-the-art in the field, establishing a classification and highlighting some likely research challenges and future directions.

52 citations


Cites background from "DAViM: a dynamically adaptable virt..."

  • ...Since resource limitations prevent sensors from having an extensive set of services pre-installed, sensor software should be dynamically reconfigurable....

    [...]

Proceedings ArticleDOI
25 Aug 2007
TL;DR: This survey discusses the representative state-of-the- art virtual machine (VM) class of middleware for WSNs highlighting the state of the research.
Abstract: In the last few years, various middleware solutions have been proposed for bridging the gap between the complexity of the applications and the low hardware abstraction in order to program and manage the sensor nodes of the wireless sensor networks. The proposed middleware range from market and data- centric approaches to message oriented middleware. This survey discusses the representative state-of-the- art virtual machine (VM) class of middleware for WSNs highlighting the state of the research.

32 citations


Cites background from "DAViM: a dynamically adaptable virt..."

  • ...But this is an approach that has two main drawbacks: first, according to [35], this is not a competitive approach and second, this method represents a big investment and thus it doesn’t contribute to the vision of the WSNs hardware where it must progressively become smaller and cheap....

    [...]

Journal ArticleDOI
TL;DR: This survey discusses IoT middleware requirements and challenges, and presents the current state of research in this domain, and a technical taxonomy is presented according to the abstract and processing approach of data.

32 citations

Journal ArticleDOI
TL;DR: DAVIM is adaptable middleware that enables dynamic management of services and isolation between simultaneously running applications.
Abstract: Middleware services facilitate sensor-network application development. DAVIM is adaptable middleware that enables dynamic management of services and isolation between simultaneously running applications.

27 citations

References
More filters
Proceedings ArticleDOI
16 Nov 2004
TL;DR: This work presents Contiki, a lightweight operating system with support for dynamic loading and replacement of individual programs and services, built around an event-driven kernel but provides optional preemptive multithreading that can be applied to individual processes.
Abstract: Wireless sensor networks are composed of large numbers of tiny networked devices that communicate untethered. For large scale networks, it is important to be able to download code into the network dynamically. We present Contiki, a lightweight operating system with support for dynamic loading and replacement of individual programs and services. Contiki is built around an event-driven kernel but provides optional preemptive multithreading that can be applied to individual processes. We show that dynamic loading and unloading is feasible in a resource constrained environment, while keeping the base system lightweight and compact.

2,566 citations


"DAViM: a dynamically adaptable virt..." refers background in this paper

  • ...Contiki [3, 2] allows to dynamically load binary modules in the standard ELF file format and a variant called CELF (compact ELF)....

    [...]

Proceedings Article
01 Jan 2004
TL;DR: In this paper, the authors describe how to dynamically download code into large scale wireless sensor networks, which are composed of large numbers of tiny networked devices that communicate untethered.
Abstract: Wireless sensor networks are composed of large numbers of tiny networked devices that communicate untethered. For large scale networks it is important to be able to dynamically download code into t ...

2,522 citations

Proceedings ArticleDOI
01 Oct 2002
TL;DR: Maté's concise, high-level program representation simplifies programming and allows large networks to be frequently reprogrammed in an energy-efficient manner; in addition, its safe execution environment suggests a use of virtual machines to provide the user/kernel boundary on motes that have no hardware protection mechanisms.
Abstract: Composed of tens of thousands of tiny devices with very limited resources ("motes"), sensor networks are subject to novel systems problems and constraints. The large number of motes in a sensor network means that there will often be some failing nodes; networks must be easy to repopulate. Often there is no feasible method to recharge motes, so energy is a precious resource. Once deployed, a network must be reprogrammable although physically unreachable, and this reprogramming can be a significant energy cost.We present Mate, a tiny communication-centric virtual machine designed for sensor networks. Mate's high-level interface allows complex programs to be very short (under 100 bytes), reducing the energy cost of transmitting new programs. Code is broken up into small capsules of 24 instructions, which can self-replicate through the network. Packet sending and reception capsules enable the deployment of ad-hoc routing and data aggregation algorithms. Mate's concise, high-level program representation simplifies programming and allows large networks to be frequently reprogrammed in an energy-efficient manner; in addition, its safe execution environment suggests a use of virtual machines to provide the user/kernel boundary on motes that have no hardware protection mechanisms.

1,217 citations

Proceedings ArticleDOI
03 Nov 2004
TL;DR: It appears very hard to significantly improve upon the rate obtained by Deluge and it is argued that the rates obtained for dissemination are inherently lower than that for single path propagation.
Abstract: To support network programming, we present Deluge, a reliable data dissemination protocol for propagating large data objects from one or more source nodes to many other nodes over a multihop, wireless sensor network. Deluge builds from prior work in density-aware, epidemic maintenance protocols. Using both a real-world deployment and simulation, we show that Deluge can reliably disseminate data to all nodes and characterize its overall performance. On Mica2-dot nodes, Deluge can push nearly 90 bytes/second, one-ninth the maximum transmission rate of the radio supported under TinyOS. Control messages are limited to 18% of all transmissions. At scale, the protocol exposes interesting propagation dynamics only hinted at by previous dissemination work. A simple model is also derived which describes the limits of data propagation in wireless networks. Finally, we argue that the rates obtained for dissemination are inherently lower than that for single path propagation. It appears very hard to significantly improve upon the rate obtained by Deluge and we identify establishing a tight lower bound as an open problem.

1,152 citations


"DAViM: a dynamically adaptable virt..." refers background in this paper

  • ...TinyOS/Deluge [6], for instance, replaces a complete system image which implies considerable network overhead to transport the update to all nodes in the network....

    [...]

Proceedings Article
29 Mar 2004
TL;DR: Trickle as mentioned in this paper uses a "polite gossip" policy, where motes periodically broadcast a code summary to local neighbors but stay quiet if they have recently heard a summary identical to theirs.
Abstract: We present Trickle, an algorithm for propagating and maintaining code updates in wireless sensor networks. Borrowing techniques from the epidemic/gossip, scalable multicast, and wireless broadcast literature, Trickle uses a "polite gossip" policy, where motes periodically broadcast a code summary to local neighbors but stay quiet if they have recently heard a summary identical to theirs. When a mote hears an older summary than its own, it broadcasts an update. Instead of flooding a network with packets, the algorithm controls the send rate so each mote hears a small trickle of packets, just enough to stay up to date. We show that with this simple mechanism, Trickle can scale to thousand-fold changes in network density, propagate new code in the order of seconds, and impose a maintenance cost on the order of a few sends an hour.

929 citations

Frequently Asked Questions (2)
Q1. What are the contributions mentioned in the paper "Davim: a dynamically adaptable virtual machine for sensor networks" ?

This paper presents DAViM, the Distrinet Adaptable Virtual Machine and describes how it allows to customize sensor behavior, to extend its functionality and to execute multiple applications in parallel. The authors have evaluated the proposed architecture by implementing a proof-of-concept prototype on micaZ hardware. 

The architecture offers support for three key requirements that sensor networks have to deal with: customizability of sensor behavior, extendability of sensor functionality, and concurrent execution of multiple applications. With respect to future work, the authors will first of all evaluate and refine the architecture in the context of an industrial case study. By way of evaluation of the architecture, the authors have implemented a proofof-concept prototype which provides promising indications that it is feasible to implement the described functionality on state-of-the-art sensor hardware. Their research will gradually extend its focus from an individual sensor node and a single sensor network towards an end-to-end view.