Sensor Network Programming

1
Sensor Network Programming

• Bibudh Lahiri

2
Todays Menu

• Starter/ Beverages
• What are sensor networks?
• Applications
• Main course
• Characteristics
• Platforms
• Event-Driven Sensor Acquisition
• Tasks and Hardware Event Handler
• Dessert
• What are we doing at Iowa State?

3
What is a Sensor Network?

• A computer network consisting of spatially
  distributed autonomous devices using sensors to
  cooperatively monitor physical or environmental
  conditions, such as temperature, sound,
  vibration, pressure, motion or pollutants, at
  different locations

4
Applications

• military applications such as battlefield
  surveillance
• environment and habitat monitoring
• home automation
• traffic control

5
Characteristics

• Limited power
• Harsh environmental conditions
• Node failures
• Dynamic network topology
• Large scale of deployment
• Unattended operation

6
Platforms

• Hardware
• MICA, MICA2, MICAZ
• MIB510
• Serial "gateway" used to program and communicate
  with the motes
• Cost 95
• MPR400
• More commonly known as the MICA2 Mote
• 433 MHz motes get better range. Best for outdoor
  applications
• Cost 150
• MTS300
• Basic sensor board that plugs into the mote
• Contains light sensor, temperature sensor,
  microphone and sounder
• Cost 120

7
Platforms (contd.)

• Operating systems - TinyOS
• An open-source, event-driven, component-based OS
  and platform targeting WSN
• Written in the nesC programming language
• A set of cooperating tasks and processes
• Can operate within the severe memory constraints
  inherent in sensor networks

8
Platforms (contd.)

• Software
• nesC
• primarily intended for embedded systems such as
  sensor networks
• C-like syntax
• supports the TinyOS concurrency model, as well as
  mechanisms for structuring, naming, and linking
  together software components into robust network
  embedded systems
• applications are built out of components
• Components
• A component provides and uses interfaces
• Two types of components - modules and
  configurations

9
Platforms (contd.)

• Interfaces
• Commands
• A set of functions declared by an interface
• Interface provider must implement them
• Events
• a callback function that the implementation of an
  interface will invoke
• A module that uses an interface must implement
  the events that this interface uses
• Example
• interface Timer
• command result_t start (char type, uint32_t
  interval)
• command result_t stop()
• event result_t fired()

10
Platforms (contd.)

• Configuration
• used to assemble other components together,
  connecting interfaces used by components to
  interfaces provided by others
• Example
• configuration Blink
• implementation
• components Main, BlinkM, SingleTimer, LedsC
• Main.StdControl -gt SingleTimer.StdControl
• Main.StdControl -gt BlinkM.StdControl
• BlinkM.Timer -gt SingleTimer.Timer
• BlinkM.Leds -gt LedsC

11
Platforms (contd.)

• Configuration (contd.)
• a configuration itself can use and provide
  interfaces
• Example
• configuration GenericComm
• provides
• interface StdControl as Control
• // The interface are as parameterised by the
  active message id
• interface SendMsguint8_t id
• interface ReceiveMsguint8_t id
• // How many packets were received in the past
  second
• command uint16_t activity()

12
Platforms (contd.)

• Configuration (contd.)
• uses
• // signaled after every send
  completion for components which wish to
• // retry failed sends
• event result_t sendDone()
• implementation
• components AMStandard,
• Control AMStandard.Control
• SendMsg AMStandard.SendMsg
• ReceiveMsg AMStandard.ReceiveMsg
• activity AMStandard.activity
• sendDone AMStandard.sendDone

13
Platforms (contd.)

• Modules
• actually provides the implementation of the
  application
• module BlinkM
• provides
• interface StdControl
• uses
• interface Timer
• interface Leds

14
Platforms (contd.)

• Modules (contd.)
• implementation
• command result_t StdControl.init()
• call Leds.init() //initializes
  variables in LedsC
• return SUCCESS
• command result_t StdControl.start()
• return call Timer.start (TIMER_REPEAT,
  1000)
• command result_t StdControl.stop()
• return call Timer.stop()

15
Platforms (contd.)

• Modules (contd.)
• event result_t Timer.fired()
• call Leds.redToggle()
• return SUCCESS

16
Event-Driven Sensor Acquisition

• A simple sensor application that takes light
  intensity readings and displays
• configuration Sense
• implementation
• components Main, SenseM, LedsC, TimerC, Photo
• Main.StdControl -gt SenseM
• Main.StdControl -gt TimerC
• SenseM.ADC -gt Photo
• SenseM.ADCControl -gt Photo
• SenseM.Leds -gt LedsC
• SenseM.Timer -gt TimerC.Timerunique("Timer")

17
Event-Driven Sensor Acquisition (contd.)

• module SenseM
• provides
• interface StdControl
• uses
• interface Timer
• interface ADC
• interface StdControl as ADCControl
• interface Leds

18
Event-Driven Sensor Acquisition (contd.)

• implementation
• event result_t Timer.fired()
• return call ADC.getData()
• async event result_t ADC.dataReady(uint16_t data)
  
• //run in response to a hardware interrupt
• display(7-((datagtgt7) 0x7)) //takes bits at
  position 7,8,9 to 14,15,16 respectively
• return SUCCESS
• Interfaces
• ADC used to access data from the
  analogue-to-digital converter
• StdControl used to initialize the ADC component

19
Event-Driven Sensor Acquisition (contd.)

• Parameterized interfaces
• SenseM.Timer -gt TimerC.Timerunique("Timer")
• TimerC component declares
• provides interface Timeruint8_t id

20
Tasks and Hardware Event Handler

• Hardware Event Handler
• async declares a command or event that can be
  executed by a hardware event handler
• Could be executed at any time
• Possibility of data races on all shared data
• Tasks
• Can be used to perform general-purpose
  "background" processing in an application
• Usually longer jobs
• Can be preempted by hardware event handler

21
Tasks and Hardware Event Handler (contd.)

• Tasks (contd.)
• A task is declared in the implementation module
  using the syntax
• task void taskname() ...
• To dispatch a task for (later) execution, use the
  syntax
• post taskname()

22
Tasks and Hardware Event Handler (contd.)

• Tasks (contd.)
• Example
• async event result_t ADC.dataReady(uint16_t data)
     
• putdata(data)     //insert a new sample into
  the buffer
• post processData()    
• return SUCCESS  
• task void processData()    
• int16_t i, sum0    
• atomic    
• for (i0 i lt size i)
• sum (rdatai gtgt 7)
•      
• display(sum gtgt log2size)

23
What are we doing at Iowa State?

• Implementation of Arrow protocol for tracking
  mobile objects
• A directory service allows nodes to keep track of
  mobile objects
• We are trying to ensure reliable communication
• Challenge
• Medium cannot be sensed to detect collision
  since this is a wireless medium
• Any frame reaches all nodes in the neighborhood
  of the sender
• Approach
• Application-layer acknowledgements on reception
  of data
• Retransmission by the sender if acknowledgement
  is not received within a specified time period
• After maximum number of retransmissions, send the
  next frame

24
What are we doing at Iowa State? (contd.)

• Implementation of Arrow protocol for tracking
  mobile objects (contd.)
• Approach (contd.)
• Sender keeps on sending a series of n (currently
  32) consecutive odd/even numbers starting from
  1/0 respectively. The format of the data frame is
  
• Bit 1 - Frame type, 0 for data frame
• Bits 2,3 - Node ID of the sender of the data
  frame
• Bits 4-9 - Sequence no. of the frame
• Bits 10-15 data
• Bit 16 unused
• Receiver keeps on receiving a series of n
  consecutive odd/even numbers sent by the sender
• Maintains two sum variables as follows -
  rcvd_sum_of_odd and rcvd_sum_of_even
• With receiving each message, the receiver will
  send an ACK frame to the corresponding sender.
  The format of the ACK frame is

25
What are we doing at Iowa State? (contd.)

• Implementation of Arrow protocol for tracking
  mobile objects (contd.)
• Approach (contd.)
• Bit 1 - Frame type, 1 for ACK
• Bits 2,3 - Node ID of the sender of the data
  frame
• Bits 4-9 - Sequence no. of the frame
• Bits 10-15 unused
• At the end of sending n messages, rcvd_sum_of_odd
  should be equal to the sum of first
• n odd integers, and rcvd_sum_of_even should
  be equal to the sum of first n even integers, if
  no messages are lost
• post tasks to display rcvd_sum_of_odd modulo 7
  and rcvd_sum_of_even modulo 7 on receivers LEDs