aleksandar crnjin, m.eng. with prof. dr. veljko milutinovic prosense team at etf, u. of belgrade a...
TRANSCRIPT
Aleksandar Crnjin, M.Eng.with Prof. Dr. Veljko Milutinovic
ProSense team at ETF, U. of Belgrade
A Survey of Software Tools
for Sensor Networks
of 24
Topics
2
Introduction:Comparison of Architectures;Going “Full Custom”
TinyOS + NesCJava on SunSPOTs
Concluding Remarks
Processing power:Atmel 4MHz, 8 bit Microcontroller
Memory128Kb Instruction Memory4 Kb SRAM
Storage:32KB on a 24LC256 Chip
Communication:10kbps Radio link
Power:Two AA batteries
Comparison of ArchitecturesCrossbow Mica2DotCrossbow Mica2DotSensor NodeSensor Node
A Typical Desk A Typical Desk ComputerComputer
3
Processing power:Two 2GHz64-bit Processors
Memory:2 GBs of RAM
Storage:320GB Hard Drive
Communication:1Mbit ADSL link
Power:Practically Unlimited
of 24
Full Custom Approach?
4
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)
of 24
Full Custom Approach?
5
IN FAVOR:Probably the optimal solution
in terms of speed of execution,memory space used, andbattery power usage.
AGAINST:Limited interoperabilityA long time needed to establish basic
functionalityUnsuitable for more complex problems
TinyOS + NesC
Component Model & Event Driven Programming
6
of 24
TinyOS: An Introduction
7
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
of 24
TinyOS Component Model
8
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 partsis 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
of 24
TinyOS Event Driven Programming
9
TinyOS components usually have:command handling routinesevent handling routines a fixed amount of allocated memory
(frame)In response to commands and
events,they execute tasks
Commands and events make up theinterface of the component
All code is executed in response tocommands and events
System events: Init, Start, Stop(interface StdControl)
System components – provide abstraction for onboard devices
of 24
Component Configurations
10
Components are “interconnected”into configurationsby “wiring” their interfaces
Cmd/Event Chain commands flow downwardevents climb upwardNon-blocking cmd/event
notificationSystem commands at the top;Hardware events at the bottom
of 24
NesC
11
Network Embedded Systems CDeveloped for TinyOS;
TinyOS subsequently rewritten in NesCSupports the TinyOS component model
nativelyEmbeds TinyOS structures:
configurations describe component interconnections
modules describe single components
Example Application:Blink
12
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
Example Application:Blink
13
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
connections to Clock and Leds modules
of 24
TinyOS + NesC: Conclusion
14
IN FAVOR:Excellent interoperabilityBasic functionality attained quicklyDe-facto standard
AGAINST:Steep learning curve
Java on SunSPOTs
Sun SPOT devicesand an operating system/Java virtual machine
15
of 24
SunSPOTs:Introduction
16
SunSPOT:Small Programmable Object Technology
A Sun Labs research project to investigatesmall wireless sensor technology
Primary motivation:enable non-EE students to developapplications for sensor networks
More powerful and more expensivethan standard sensor node systems:180 MHz ARM9 32-bit processor$550 for a kit of two Sun SPOTs2.4 GHz ZigBee™ Radio + Various Sensors
A Sun SPOT device
of 24
SquawkJava VM for SunSPOT
17
Java VM for SunSPOT devicesRuns on bare ARM,
without an underlying OSIn contrast to standard Java VMs,
Squawk is mostly written in JavaComplete set of native Java device
driversFully integrated with NetBeans IDE,
builds and deploys using Ant
“Brings the ease of Java developmentto the world of sensors”
of 24
Programming a SPOT
18
creating a new SunSPOT project is as easy aschoosing File→New Project →Sun SPOT applicationin the NetBeans IDE
The whole fuctionality of a SPOT demo boardis 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
of 24
Programming a SPOT:Examples
19
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();
of 24
Programming a SPOT:Examples
20
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 redourLEDs[1].setRGB(0,255,0); // bright greenourLEDs[2].setRGB(0,0,255); // bright blueourLEDs[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 ();
of 24
SunSPOTs + Java:Conclusion
21
IN FAVOR:Sensor node programming made very simple
AGAINST:Large size of SunSPOT devicesStill expensive
of 24
Concluding RemarksWhile it has its own merits,
“Full Custom” approach ultimately isn’t suitablefor the ProSense project
SunSPOT is an interesting insightto 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.
22
of 24
References
23
[1] Dario Rossi,”Sensors as Software: TinyOS”
[2] Dario Rossi,”Sensors as Software: nesC”[3] SunSPOT Owner’s Manual
(www.sunspotworld.com)[4] SunSPOT Developers’ Guide
(www.sunspotworld.com)[5] Holger Karl, Andreas Willig,
“Protocols and Architectures for Wireless Sensor Networks”, Wiley, 2005.
