1. A Survey of Software Tools for Sensor Networks
Aleksandar Crnjin, M.Eng. with Prof. Dr. Veljko Milutinovic ProSense team at ETF, U. of Belgrade

2. Topics Introduction: Comparison of Architectures; Going “Full Custom”
TinyOS + NesC
Java on SunSPOTs
Concluding Remarks

3. Comparison of Architectures
Crossbow Mica2Dot Sensor Node
A Typical Desk Computer
Processing power: Atmel 4MHz, 8 bit Microcontroller
Memory 128Kb Instruction Memory 4 Kb SRAM
Storage: 32KB on a 24LC256 Chip
Communication: 10kbps Radio link
Power: Two AA batteries
Processing power: Two 2GHz 64-bit Processors
Memory: 2 GBs of RAM
Storage: 320GB Hard Drive
Communication: 1Mbit ADSL link
Power: Practically Unlimited

4. Full Custom Approach?
An obvious method to program sensor networks is to do so as with any other embedded computer system.
Full Custom Software:
do not use any readymade software tool,
program directly in assembly language or in microcontroller-enabled C development tool (e.g. Keil C)
operate the peripherals using control and status registers
do not use an operating system, write the program directly to ROM
Full Custom Hardware:
do not use any readymade hardware platform,
make a sensor node “from scratch” instead (pick a microcontroller & add peripherals)

5. Full Custom Approach? IN FAVOR: AGAINST: Probably the optimal solution
in terms of speed of execution,
memory space used, and
battery power usage.
AGAINST:
Limited interoperability
A long time needed to establish basic functionality
Unsuitable for more complex problems

6. TinyOS + NesC
Component Model & Event Driven Programming

7. TinyOS: An Introduction
A very small (“Tiny”) special purpose operating system for sensor nodes
Problem with conventional OSes: not enough memory, esp. for stack
Impossible to save context for each task separately; all tasks must share a single context

8. TinyOS Component Model
Organize parts of code into distinct entities based on functionality, and associate statically allocated memory with these code parts
A part of code, with its associated memory frame, and described interface to other such parts is called a component Component = Code + Interface + Memory Frame
Components cannot rely on registers to save state (single execution context!); state must be saved only in the allocated memory frame

9. TinyOS Event Driven Programming
TinyOS components usually have:
command handling routines
event handling routines
a fixed amount of allocated memory (frame)
In response to commands and events, they execute tasks
Commands and events make up the interface of the component
All code is executed in response to commands and events
System events: Init, Start, Stop (interface StdControl)
System components – provide abstraction for onboard devices

10. Component Configurations
Components are “interconnected” into configurations by “wiring” their interfaces
Cmd/Event Chain
commands flow downward
events climb upward
Non-blocking cmd/event notification
System commands at the top;
Hardware events at the bottom

11. NesC Network Embedded Systems C
Developed for TinyOS; TinyOS subsequently rewritten in NesC
Supports the TinyOS component model natively
Embeds TinyOS structures:
configurations describe component interconnections
modules describe single components

12. Example Application: Blink
configuration Blink { } implementation { components Main, BlinkM, ClockC, LedsC; Main.StdControl->BlinkM.StdControl; BlinkM.Clock->ClockC; BlinkM.Leds->LedsC;
Wiring components together: User.Interface -> Provider
Component tree

13. Example Application: Blink
connections to Clock and Leds modules
module BlinkM { provides interface StdControl; uses interface Clock; uses interface Leds; } implementation { bool state; command result_t StdControl.init() { state = FALSE; call Leds.init (); return SUCCESS; }
command result_t StdControl.start() { return call Clock.setRate(128, 6); } command result_t StdControl.stop() { return call Clock.setRate(0,0); event result_t Clock.fire () { state = !state; if (state) call Leds.redOn(); else call Leds.redOff(); return SUCCESS; }
Calling a command
executed when Clock.fire () is triggered

14. TinyOS + NesC: Conclusion
IN FAVOR:
Excellent interoperability
Basic functionality attained quickly
De-facto standard
AGAINST:
Steep learning curve

15. Java on SunSPOTs
Sun SPOT devices and an operating system/Java virtual machine

16. SunSPOTs: Introduction
SunSPOT: Small Programmable Object Technology
A Sun Labs research project to investigate small wireless sensor technology
Primary motivation: enable non-EE students to develop applications for sensor networks
More powerful and more expensive than standard sensor node systems:
180 MHz ARM9 32-bit processor
$550 for a kit of two Sun SPOTs
2.4 GHz ZigBee™ Radio + Various Sensors
A Sun SPOT device

17. Squawk Java VM for SunSPOT
Java VM for SunSPOT devices
Runs on bare ARM, without an underlying OS
In contrast to standard Java VMs, Squawk is mostly written in Java
Complete set of native Java device drivers
Fully integrated with NetBeans IDE, builds and deploys using Ant
“Brings the ease of Java development to the world of sensors”
Squawk Java VM:
Blue – written in C++
Yellow – written in Java

18. Programming a SPOT
creating a new SunSPOT project is as easy as choosing File→New Project →Sun SPOT application in the NetBeans IDE
The whole fuctionality of a SPOT demo board is abstracted through the EDemoBoard class
Inputs (sensors and switches) and outputs (LEDs) are reachable through Java interfaces; an instance of such interface is retrieved using getxxx() method

19. Programming a SPOT: Examples
Looking for a switch press:
Getting temperature readings:
Import com.sun.spot.sensorboard.EDemoBoard; Import com.sun.spot.sensorboard.ISwitch; ISwitch[] ourSwitches = EDemoBoard.getInstance().getSwitches();
if (ourSwitches[0].isOpen()) ourSwitches[0].waitForChange();
Import com.sun.spot.sensorboard.EDemoBoard; Import com.sun.spot.sensorboard.ISwitch; ITemperatureInput ourTempSensor = EDemoBoard.getADCTemperature();
double celsiusTemp = ourTempSensor.getCelsius();
double fahrTemp = ourTempSensor.getFahrenheit();

20. Programming a SPOT: Examples
Outputting to LEDs:
Radio communication – Using Data Streams
Import com.sun.spot.sensorboard.EDemoBoard; Import com.sun.spot.sensorboard.ITriColorLED; ITriColorLED[] ourLEDs = EDemoBoard.getInstance().getLEDs();
ourLEDs[0].setRGB(255,0,0); // bright red
ourLEDs[1].setRGB(0,255,0); // bright green
ourLEDs[2].setRGB(0,0,255); // bright blue
ourLEDs[3].setRGB(255,255,255); // white
StreamConnection conn = (StreamConnection) Connector.open (“radiostream://nnnn.nnnn.nnnn.nnnn:xxx”);
DataInputStream dis = conn.openDataInputStream ();
DataOutputStream dos = conn.openDataOutputStream ();

21. SunSPOTs + Java: Conclusion
IN FAVOR:
Sensor node programming made very simple
AGAINST:
Large size of SunSPOT devices
Still expensive

22. Concluding Remarks
While it has its own merits, “Full Custom” approach ultimately isn’t suitable for the ProSense project
SunSPOT is an interesting insight to the future of sensor node programming, but as of now, its primary application is in the education field.
TinyOS + NesC approach is, in our opinion, still the best way to go.

23. References [1] Dario Rossi,”Sensors as Software: TinyOS”
[2] Dario Rossi,”Sensors as Software: nesC”
[3] SunSPOT Owner’s Manual (
[4] SunSPOT Developers’ Guide (
[5] Holger Karl, Andreas Willig, “Protocols and Architectures for Wireless Sensor Networks”, Wiley, 2005.

24. Thank You!
Aleksandar Crnjin