Aleksandar Crnjin, M.Eng. with Prof. Dr. Veljko Milutinovic ProSense team at ETF, U. of Belgrade - PowerPoint PPT Presentation

Title: Aleksandar Crnjin, M.Eng. with Prof. Dr. Veljko Milutinovic ProSense team at ETF, U. of Belgrade


1
A Survey of Software Toolsfor Sensor Networks

• Aleksandar Crnjin, M.Eng.with Prof. Dr. Veljko
  MilutinovicProSense team at ETF, U. of Belgrade

2
Topics

• IntroductionComparison of ArchitecturesGoing
  Full Custom
• TinyOS NesC
• Java on SunSPOTs
• Concluding Remarks

3
Comparison of Architectures

• Crossbow Mica2DotSensor Node

• A Typical Desk Computer

• Processing powerAtmel 4MHz, 8 bit
  Microcontroller
• Memory128Kb Instruction Memory4 Kb SRAM
• Storage32KB on a 24LC256 Chip
• Communication10kbps Radio link
• PowerTwo AA batteries

• Processing powerTwo 2GHz64-bit Processors
• Memory2 GBs of RAM
• Storage320GB Hard Drive
• Communication1Mbit ADSL link
• PowerPractically 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
• 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 OSesnot enough
  memory, esp. for stack
• Impossible to save context for each task
  separatelyall 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
  partsis called a componentComponent 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 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

10
Component Configurations

• Components are interconnectedinto
  configurationsby wiring their interfaces
• Cmd/Event Chain
• commands flow downward
• events climb upward
• Non-blocking cmd/eventnotification
• System commands at the top
• Hardware events at the bottom

11
NesC

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

12
Example ApplicationBlink

• configuration Blink
• implementation components Main, BlinkM,
  ClockC, LedsCMain.StdControl-gtBlinkM.StdControl
  BlinkM.Clock-gtClockCBlinkM.Leds-gtLedsC

Wiring components togetherUser.Interface -gt
Provider
Component tree
13
Example ApplicationBlink
connections to Clock and Leds modules

• module BlinkM provides interface
  StdControluses interface Clockuses interface
  Leds
• implementation bool statecommand 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 !stateif
  (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 devicesand an operating system/Java
  virtual machine

16
SunSPOTsIntroduction

• SunSPOTSmall Programmable Object Technology
• A Sun Labs research project to investigatesmall
  wireless sensor technology
• Primary motivationenable 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 SPOTs
• 2.4 GHz ZigBee Radio Various Sensors

A Sun SPOT device
17
SquawkJava 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 developmentto 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
  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 interfacesan
  instance of such interface is retrieved using
  getxxx() method

19
Programming a SPOTExamples

• Looking for a switch press
• Getting temperature readings

Import com.sun.spot.sensorboard.EDemoBoardImport
com.sun.spot.sensorboard.ISwitchISwitch
ourSwitches EDemoBoard.getInstance().getSwitches
() if (ourSwitches0.isOpen())
ourSwitches0.waitForChange()
Import com.sun.spot.sensorboard.EDemoBoardImport
com.sun.spot.sensorboard.ISwitchITemperatureInp
ut ourTempSensor EDemoBoard.getADCTemperature()
double celsiusTemp ourTempSensor.getCelsius()
double fahrTemp ourTempSensor.getFahrenheit()
20
Programming a SPOTExamples

• Outputting to LEDs
• Radio communication Using Data Streams

Import com.sun.spot.sensorboard.EDemoBoardImport
com.sun.spot.sensorboard.ITriColorLEDITriColorL
ED ourLEDs EDemoBoard.getInstance().getLEDs()
ourLEDs0.setRGB(255,0,0) // bright
red ourLEDs1.setRGB(0,255,0) // bright
green ourLEDs2.setRGB(0,0,255) // bright
blue ourLEDs3.setRGB(255,255,255) // white
StreamConnection conn (StreamConnection)
Connector.open (radiostream//nnnn.nnnn.nnnn.nnnn
xxx) DataInputStream dis conn.openDataInputSt
ream () DataOutputStream dos
conn.openDataOutputStream ()
21
SunSPOTs JavaConclusion

• 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 isnt 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.

23
References

• 1 Dario Rossi,Sensors as Software TinyOS
• 2 Dario Rossi,Sensors as Software nesC
• 3 SunSPOT Owners Manual (www.sunspotworld.com)
• 4 SunSPOT Developers Guide (www.sunspotworld.co
  m)
• 5 Holger Karl, Andreas Willig, Protocols and
  Architectures for Wireless Sensor Networks,
  Wiley, 2005.

24
Thank You!

• Aleksandar Crnjin
• acrnjin_at_gmail.com