Simplifying the Development of Sensor Applications
Eric Arseneau, Ron Goldman,
Arshan Poursohi, Randall B. Smith
Sun Microsystems Labs
16 Network Circle
Menlo Park, CA 94025
eric.arseneau@sun.com, ron.goldman@sun.com,
arshan.poursohi@sun.com, randall.smith@sun.com
ABSTRACT
We report on a project at Sun Microsystems Laboratories invest-
igating small wireless transducer systems. Project Sun™ SPOT,
(Sun Small Programmable Object Technology), provides both
the hardware and software needed to more easily build many
different types of sensor applications. The hardware platform
provides enough resources and capabilities to allow developers
to build and experiment with applications without the concern of
limitations and/or expansion capabilities. The software platform
introduces a full complement of Java™ technologies to wireless
transducer systems. It also includes services tailored specifically
for these types of systems, such as over-the-air deployment,
over-the-air debugging, integration with desktop/server systems,
automatic power management, and more. Combining Java tech-
nologies, standard tool support, custom tools and flexible hard-
ware will make working with sensor applications significantly
easier.
Categories and Subject Descriptors
D.2.5 [Software Engineering]: Testing and Debugging—debug-
ging aids; D.2.6 [Software Engineering]: Programming Envir-
onments; D.3.4 [Programming Languages]: Processors—inter-
preters, run-time environments; D.4.7 [Operating Systems]:
Organization and Design—real-time systems and embedded sys-
tems.
General Terms
Management, Performance, Design, Languages.
Keywords
Wireless sensor networks, Sun SPOT, Java programming lan-
guage, energy conservation, modeling.
1. INTRODUCTION
The pervasive computing vision depicts a future in which com-
putation is widely embedded in the everyday world, like “smart
dust.” One medium for enabling this vision is the tiny, wireless
Copyright is held by Sun Microsystems, Inc.
OOPSLA’06, October 22-26, 2006, Portland, Oregon, USA.
ACM 1-59593-348-4/06/0010.
John Daniels
Syntropy Ltd
2 Stambourne Way, West Wickham
Kent BR4 9NF, UK
jd@syntropy.co.uk
computer that connects to the world with sensors and actuators.
Despite the large interest in this area, few significant applica-
tions have been written so far. We believe this is due to the lack
of adequate tools and languages to aid in the prototyping and de-
velopment of sensor-based applications.
Wireless sensor devices typically have limited capabilities, in
terms of processing power, amount of memory, and battery life.
These limits seem to make it hard for managed runtime lan-
guages, such as the Java TM language, to be considered for these
types of devices. The perception is that the static and dynamic
memory requirements of a managed runtime exceeds those typ-
ically found on these types of devices. Traditionally, wireless
sensor applications use languages such as C and assembler to
overcome the memory limitations. These languages normally
connect directly to a small embedded operating system (OS).
The choice of these languages comes at the expense of a longer
application development time. However, it is widely accepted
that development time using managed runtime languages is less
than that of non-managed languages.
We believe that running Java technology on a wireless sensor
device will simplify application and device driver prototyping,
thereby increasing the number of developers able to build ap-
plications, as well as their productivity; resulting in more inter-
esting applications sooner. The Java platform brings with it
garbage collection, pointer safety, exception handling, and a ma-
ture thread library with facilities for thread sleep, yield, and syn-
chronization. Standard Java development and debugging tools
can be used to write wireless sensor applications. Further, we
provide tools for managing, deploying and monitoring these
devices in a graphical user interface called SPOTWorld [2]. This
paper concentrates on the ways in which development of sensor
applications in such an environment is simplified.
2. ANATOMY OF A SUN SPOT
At Sun Microsystems Laboratories, we have been investigating
wireless sensor networks by creating a next generation device
we are calling the Sun™ Small Programmable Object Techno-
logy, or Sun SPOT [4](see Figure 1). The Sun SPOT main board
contains:
• ARM-9 processor
• 512 KB of RAM
• 4 MB of flash memory
• Chipcon 2420 IEEE 802.15.4 radio with an on-board
antenna to give a range of up to 100 meters.

Figure 1. Sun SPOT wireless sensor/actuator device, demo
sensor board on top, the main processor and radio in the
middle, and a battery board on the bottom.
Up to two external boards can be attached, stacked on top of
each other. To ease application development we provide a
“demo” sensor board supplied with an interesting set of capabil-
ities:
• 3-axis accelerometer
• light sensor
• temperature sensor
• A/D converter
• 8 tri-color LEDs
• 5 general purpose I/O pins
• 4 high current output pins.
The various I/O pins make it relatively easy to hook up a wide
range of sensors and actuators without the need to be an expert
at digital hardware (or even know how to solder). For real hard-
ware designers, the sensor board interface is published and
provides SPI, I2C, and USB interfaces, making it easy to create
custom sensor boards
The device can be fitted with a compact rechargeable battery or
powered via its USB socket, which is also used to recharge the
battery.
Sun SPOT devices are programmed using Java technology, more
specifically the Connected Limited Device Configuration
(CLDC) of the Java Platform, Micro Edition (Java ME). CLDC
defines a base set of application programming interfaces (API)
and a virtual machine (VM) for resource-constrained devices.
The standard API has been extended to include APIs which are
specific to Sun SPOT and wireless sensor devices.
The implementation of CLDC stems from another research pro-
ject from Sun Microsystems Laboratories, Squawk [1, 5].
Squawk is a Java platform primarily written in the Java lan-
guage itself and that can be run without the need for an underly-
ing operating system; commonly referred to as running on the
bare metal. Squawk provides the needed OS services, such as
the handling of interrupts, networking stack, and resource man-
agement. These services are mostly written in the Java language,
as are all device drivers and the 802.15.4 media access control
(MAC) layer.
A series of features made Squawk ideal for a wireless sensor
platform:
• designed for memory constrained devices
• designed for ease of porting to new platforms
• supports Isolates, and Isolate migration
• supports standard Java tools
Part of Squawk’s design is to reduce the amount of work a
device needs to do in order to enable it to execute Java code.
Squawk has a desktop component responsible for creating an op-
timized and byte-code-verified binary bundle. This bundle can
then be easily deployed, securely verified, and executed in place
on the device. This is called a split VM architecture. The
desktop component performs work once that would normally
have to be performed every time a Java application is executed.
This split VM features provide significant savings in terms of
execution time and power consumption.
The fact that Squawk supports standard Java tools provides ap-
plication developers the flexibility to use whatever tools they are
comfortable with to write and debug Java applications.
The Squawk VM also supports a feature called Isolates, as de-
scribed in Java Specification Request JSR 121: Application Isol-
ation API Specification [6]. Squawk’s implementation of Isolates
does not completely conform to JSR 121. This API provides a
uniform mechanism for managing Java application life cycles
that are isolated from each other, at least with respect to object
reachability, but that can potentially share underlying imple-
mentation resources. A VM supporting Isolates can run multiple
applications at the same time. Furthermore, each application has
the illusion that it has its own VM entirely to itself. Having the
ability to execute multiple applications using a single VM,
versus using one VM per application, is tremendously beneficial
for a memory constrained device like the Sun SPOT.
Thanks to Isolates, it is possible to manage other applications
from within Java code. These Isolate instances play a key role in
enabling remote application management on a Sun SPOT by
SPOTWorld.
One extension we have made to JSR 121 is to support Isolate
Migration, a feature by which a running Isolate can be halted at
an arbitrary point in its execution, then streamed to a remote
device (usually over the radio) to resume execution there. It
turns out that there are numerous interesting applications of this
capability. Sensor networks are (or are anticipated to be) far
more dynamic than conventional networks. For example,
devices may routinely run low on battery power, and new
devices may be added to a network simply by dropping them
into place. With live application migration, an Isolate could be
moved off of a failing device and onto another device for simple
in-the-field replacement, and applications could dynamically re-
distribute themselves should new resources become available.
Isolate migration can serve as a simpler replacement for client-
server applications. To collect information from a sensor net-
work, one would normally write a client program, deploy it to
each node, and radio back the required data to a separate server
that would be responsible for collecting all the data. With Isolate
migration, one could instead have an application that visits each
device in turn, collects values to hold within itself, and finally
returns “home” to print out or store its data.
One could imagine bringing an Isolate in from the field for de-
bugging while the device remains in place, or creating a running
deployment of Isolates distributed across simulated devices then
moving the Isolates one by one to real Sun SPOTs.
In order to realistically support Isolate migration, we have con-
siderable work ahead of us. An application needs hooks so the
VM can warn it of an impending move, and so a newly arrived
Isolate can reestablish connections in its new home. We have yet
to provide a complete set of these hooks. Also keep in mind
that, at the moment, Isolate migration is the migration of the ex-
ecution state of an application, it does not include the code of
the application. Checks are performed that the code contained
on a destination device is identical to the code found on the
device where the Isolate came from. However, none of this work
is really new to the world of object-oriented programming, and
expanding the capabilities of Isolate migration should find even
more interesting applications.
3. THE APPLICATION DEVELOPMENT
ENVIRONMENT
Applications for the Sun SPOT are written on a desktop com-
puter using standard Java tools, often including an integrated de-
velopment environment (IDE) such as NetBeans [7]. The Java
program is then compiled and packaged into a jar file.
Application build and deployment is controlled by platform-
independent Ant scripts, which can be integrated with the user’s
IDE.
Figure 2. The SPOTWorld environment is shown here running inside the NetBeans IDE. Triangular icons represent applications
running on each device.
Applications can be deployed from a desktop computer to a Sun
SPOT either directly, via a USB connection, or over-the-air
(OTA) using the 802.15.4 radio. For OTA deployment a second
SPOT, connected to the host machine via USB, is used as a bas-
estation, giving the desktop machine access to the radio.
The basestation can also be accessed from user-developed Java
applications running on the host, allowing such applications to
transfer data to and from a remote SPOT. One such program is
an http proxy that allows remote SPOTs to access the Internet.
One of the key aspects of our use of Squawk, was the ability to
use standard tools, such as debuggers to debug applications dir-
ectly on device. The Sun SPOT supports the Java Debug Wire
Protocol OTA via a proxy program running on the host machine,
allowing applications to be debugged on remote devices using
standard Java debug clients, such as those incorporated into
IDEs.
We are developing an integrated management, deployment, de-
bugging, and programming tool called SPOTWorld (see Figure
2). SPOTWorld can run stand alone, or, as illustrated in the fig-
ure, can be integrated with an IDE so that code can be written,
compiled, and deployed to a collection of Sun SPOTs with the
aid of SPOTWorld.
In SPOTWorld the user sees each SPOT with its current state in-
cluding currently running applications. Users can send com-
mands to the SPOT with context pop-up menus. For example,
the user can launch an application by selecting from a list of
those available on the device. The applications themselves can
be accessed through a pop-up menu on an icon representing that
application. This enables the user to pause, resume, or exit the
application. In an experimental feature, the user can drag an ap-
plication from one SPOT to another, thereby causing live applic-
ation migration using the Isolate migration mechanism.
When running SPOTWorld, each SPOT is represented by a
proxy object that relays messages over the radio to its associated
SPOT. This proxy serves as the “model” in a conventional Mod-
el-View-Controller design. Consequently, we can present the
user with multiple views of their SPOTs. In addition to the 2D
layout illustrated in Figure 2, we are adding a tree widget view
and plan to develop a 3D view. The tree view represents the de-
ployed SPOTs as nodes in a conventional list whose elements
can be expanded to show subparts. In the tree view, the top level
nodes are groups, and the next level presents the individual
SPOTs. The user can access the applications running on the
SPOT and inspect the SPOT’s hardware by expanding this node.
4. AUTOMATIC POWER MANAGEMENT
The need to conserve power is a significant issue for wireless
sensor devices. The Sun SPOT has a powerful processor, a radio,
and lots of memory, and so has the potential to exhaust its bat-
tery within a few hours.
A common solution to this problem is to allow an application to
turn off components it is not using and to elect to enter a special
low-power mode when idle. This places the full burden of man-
aging power consumption on the application developer, who
really wants to concentrate on just the application domain. It is
also likely that the application developer will miss opportunities
for power saving, especially during short idle periods.
Instead we have adopted the approach of automating power
management as much as possible. When no thread is scheduled
to be run for more than a system-specified minimum amount of
time, the system will automatically enter a power-saving mode.
If the radio is off then a deep sleep will occur; if the radio is on
then only a shallow sleep can occur. At present the application
must ensure that it turns off the radio when it is not in use, but
we will shortly be enhancing the system so that the radio is con-
trolled automatically based on policies set for each open connec-
tion.
In deep sleep all power is removed from the main ARM9 pro-
cessor and the sensor board, leaving just the power controller
chip (a low-power microcontroller that monitors the reset button
and has a wake-up timer) and the RAM powered. In this mode
consumption is less than 40 microamps. Starting with a full
charge, the SPOT has sufficient power to remain in deep sleep
for more than two years.
In shallow sleep all circuits are powered, but the ARM9 halts,
awaiting an interrupt. The SPOT has sufficient power, starting
with a full charge, to remain in this mode for approximately one
day.
5. SECURITY
Security is a very important aspect of sensor applications. To en-
sure that only trusted code is executed, malicious attacks are
prevented, and secure communications provided, we must
provide a mechanism for creating trust boundaries between the
host desktops and their owned devices. One also needs to strike
a balance between usability and security. Allowing for simple
sharing of devices without unduly increasing the risks of them
being compromised. Ideally, we would want the security mech-
anism to be as transparent as possible to the user.
We use public key cryptography which generally allows users to
communicate securely without having prior access to a shared
secret key. This is done by using a pair of cryptographic keys,
designated as public key and private key, which are related
mathematically. In public key cryptography, the private key is
kept secret, while the public key may be widely distributed. In a
sense, one key “locks” a lock; while the other is required to un-
lock it. More specifically, we use public key digital signatures—
allowing devices to verify that a message was created with a
specific private key.
Our key management proposal (inspired by [3]) offers a unique
combination of the following features:
• It easily supports large numbers of developers writing and
deploying code without access to a global network.
• Compromise of a single key only impacts the security of
code deployment on a small number of devices.
• Key management is completely transparent to the users
for the most common situations.
Each installation of the Sun SPOT software development kit
(SDK) transparently generates a public/private key pair. Device
ownership is established via the installation of an SDK’s public
key. A factory fresh device is configured to have no owner, i.e.
no public keys installed. The first use of a device, either via a
wired or wireless connection, causes an automatic ownership re-
lationship to be established. Only an owner is allowed to install
new applications, issue commands, or make ownership changes
to a device.
Any application or command is digitally signed using the SDK’s
private key prior to being sent to a device. In turn a device will
only accept applications or commands that it can successfully
verify against any of its installed public keys.
For many environments, such as within a classroom, the policy
governing ownership change can be relaxed. Instead of always
requiring cooperation of the current owner, we can allow owner-
ship change if the new owner has physical access to the device.
This is implemented by having the device overwrite its trusted
key with the newly received key when code is deployed over a
direct connection (e.g. a USB cable).
6. EXAMPLES
Sun SPOTs were used as the framework for an installation piece
at the 2006 ZeroOne Festival in San Jose California [8]. The art
piece used multiple wireless networks to allow interactive parti-
cipation. The experience was designed to provoke thought about
public and private spaces and how technology effects them. Sun
SPOTs were used in all aspects of sensing and controlling the
environment. The system used the onboard processing of the
SPOTs to do the routing of messages in a modified peer-based
system, where the results of the message passing decisions were
reflected back to the participants and spectators so that they
could see the technology making decisions about the interaction.
The Sun SPOT platform eased the development of the installa-
tion from start to finish. The first steps were taken using a
simple Java SE-based simulation of the proposed grid of lights,
then that same Java code was used as the basis for the applica-
tion running on each individual SPOT in the installed artifact.
Once we were running on the real hardware we made use of the
existing transducer libraries to control theater lighting to handle
lighting effects in hotel rooms, and street light coloring. The
code was refined and redeployed, using over-the-air deployment
to keep from having to physically connect to all of the installed
hardware. The programmers on the project were all Java pro-
grammers, used to working in typical desktop platforms, and
they were able to use the Sun SPOT platform to design and in-
stall an embedded system using many low-level hardware con-
trol protocols, infrared and RF wireless networks in a matter of
weeks.
Sun SPOTs were also used by a class at the Art Center College
of Design in Pasadena, California. A class called “The New Eco-
logy of Things” [9] used the Sun SPOT as a platform to develop
various ideas forecasting the future of consumer products. The
class was asked to imagine future uses of embedded computing
and sensing, with the Sun SPOT as an example of what is pos-
sible. The class was able to design simple prototypes of their
imagined products using the built-in sensors and processing of
the Sun SPOT, giving them the opportunity to flesh out far more
of their ideas then the usual styrofoam mock up generally does.
The interface to their projects used simple extensions of the
flash-based programming environment that the students had
already been trained to use, giving them access to the real world
in their projects using the same software that they had been us-
ing all along.
7. SUMMARY
We feel that the Sun SPOT platform is ideally suited for the pro-
totyping and developing of applications for wireless sensor net-
works. First, there is enough memory, processing power, etc. on
each SPOT that one can do interesting things locally; it is much
easier to prototype when not constrained by tight resources.
Second, it is easy to extend the functionality of a SPOT by con-
necting sensors or actuators to the demo sensor board or by cre-
ating custom sensor boards. Third, writing applications in the
Java programming language is easier than using lower-level lan-
guages such as C. Programming in the Java language also makes
it possible to share code between applications on the device and
on the desktop, and also makes it easier to integrate the wireless
devices with the desktop. Fourth, a program development envir-
onment that enables over-the-air deployment and debugging
greatly simplifies the task of developing wireless network ap-
plications.
The Sun SPOT is a mid-level sensor device that enables explor-
atory programming of sensor applications. The software archi-
tecture is designed to be a framework for experimentation, en-
couraging the replacement and addition of new components,
such as a mesh-radio stack.
We hope that the Sun SPOT will make it possible for a variety
of potential developers to experiment with wireless sensor net-
works in robotics, art, toys, personal electronics and commercial
applications. Java technology on “wireless sensor networks” is
here now. Program the world!
8. REFERENCES
[1] Simon, D., Cifuentes, C., Cleal, D., Daniels, J., White, D.
Java™ on the Bare Metal of Wireless Sensor Devices—The
Squawk Virtual Machine. In VEE’06 June 14–16, Ottawa,
Ontario, Canada. ACM Press.
[2] Smith, R., Cifuentes, C., , and Simon, D. Enabling Java™
for small wireless devices with Squawk and Spotworld.
OOPSLA Workshop Bringing Software to Pervasive Com-
puting, October 16, 2005.
[3] Stajano F. and Anderson, R. The Resurrecting Duckling:
Security Issues for Adhoc Wireless Networks, In Proceed-
ings of the 7th International Workshop on Security Proto-
cols, April 1999, pp 172-194.
[4] http://www.sunspotworld.com
[5] http://research.sun.com/projects/squawk
[6] http://jcp.org/en/jsr/detail?id=121
[7] http://www.netbeans.org
[8] http://research.sun.com/spotlight/2006/2006-07-28_
spot_the_spots.html
[9] http://people.artcenter.edu/~vanallen/ecology/