Simplifying The Development Of Sensor Applications

Simplifying the Development of Sensor Applications Eric Arseneau, Ron Goldman, Arshan Poursohi, Randall B. Smith

John Daniels Syntropy Ltd 2 Stambourne Way, West Wickham Kent BR4 9NF, UK

Sun Microsystems Labs 16 Network Circle Menlo Park, CA 94025

[email protected]

[email protected], [email protected], [email protected], [email protected] ABSTRACT We report on a project at Sun Microsystems Laboratories investigating 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 technologies, standard tool support, custom tools and flexible hardware will make working with sensor applications significantly easier.

Categories and Subject Descriptors D.2.5 [Software Engineering]: Testing and Debugging—debugging aids; D.2.6 [Software Engineering]: Programming Environments; D.3.4 [Programming Languages]: Processors—interpreters, run-time environments; D.4.7 [Operating Systems]: Organization and Design—real-time systems and embedded systems.

General Terms Management, Performance, Design, Languages.

Keywords Wireless sensor networks, Sun SPOT, Java programming language, energy conservation, modeling.

1. INTRODUCTION The pervasive computing vision depicts a future in which computation 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.

computer that connects to the world with sensors and actuators. Despite the large interest in this area, few significant applications have been written so far. We believe this is due to the lack of adequate tools and languages to aid in the prototyping and development 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 languages, 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 typically 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 applications, as well as their productivity; resulting in more interesting applications sooner. The Java platform brings with it garbage collection, pointer safety, exception handling, and a mature thread library with facilities for thread sleep, yield, and synchronization. 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 Technology, 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.

• supports Isolates, and Isolate migration • supports standard Java tools

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 capabilities: • 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 hardware 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 project from Sun Microsystems Laboratories, Squawk [1, 5]. Squawk is a Java platform primarily written in the Java language itself and that can be run without the need for an underlying 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 management. 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

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 optimized 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 application 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 described in Java Specification Request JSR 121: Application Isolation 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 implementation 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 redistribute themselves should new resources become available. Isolate migration can serve as a simpler replacement for clientserver applications. To collect information from a sensor network, 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 debugging 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 considerable 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 execution 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 computer using standard Java tools, often including an integrated development 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 platformindependent Ant scripts, which can be integrated with the user’s IDE.

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 basestation, 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 directly 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, debugging, and programming tool called SPOTWorld (see Figure 2). SPOTWorld can run stand alone, or, as illustrated in the figure, 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.

Figure 2. The SPOTWorld environment is shown here running inside the NetBeans IDE. Triangular icons represent applications running on each device.

In SPOTWorld the user sees each SPOT with its current state including currently running applications. Users can send commands 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 application from one SPOT to another, thereby causing live application 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 Model-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 deployed 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 battery 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 managing 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 controlled automatically based on policies set for each open connection. In deep sleep all power is removed from the main ARM9 processor 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 ensure 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 mechanism 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 unlock 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 relationship 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 ownership 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 participation. 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 installation 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 application 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 programmers, used to working in typical desktop platforms, and they were able to use the Sun SPOT platform to design and install an embedded system using many low-level hardware control 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 Ecology 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 possible. 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 using all along.

ating custom sensor boards. Third, writing applications in the Java programming language is easier than using lower-level languages 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 environment that enables over-the-air deployment and debugging greatly simplifies the task of developing wireless network applications. The Sun SPOT is a mid-level sensor device that enables exploratory programming of sensor applications. The software architecture is designed to be a framework for experimentation, encouraging 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 networks 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 Computing, October 16, 2005. [3] Stajano F. and Anderson, R. The Resurrecting Duckling: Security Issues for Adhoc Wireless Networks, In Proceedings of the 7th International Workshop on Security Protocols, April 1999, pp 172-194. [4] http://www.sunspotworld.com

7. SUMMARY

[5] http://research.sun.com/projects/squawk

We feel that the Sun SPOT platform is ideally suited for the prototyping and developing of applications for wireless sensor networks. 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 connecting sensors or actuators to the demo sensor board or by cre-

[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/