EmStar Tutorial A Software Environment for Developing and Deploying Wireless Sensor Networks

1
EmStar TutorialA Software Environment for
Developingand Deploying Wireless Sensor Networks

• CENS Summer Intern Tutorial
• July 5th, 2005
• Contributors Lewis Girod, Thanos Stathopoulos,
  Nithya Ramanathan, Tom Schoellhammer, Ning Xu,
  Martin Lukac, Richard Guy, Deborah Estrin
• CENS Systems Lab

2
Outline

• What is EmStar
• Processes vs. Threads
• EmStar Basics
• Event based programing
• Device files
• EmStar code
• Running EmStar
• EmTOS

3
EmStar Preamble goes here
4
Processes and not Threads

• Process
• One execution context only one thing going on at
  a time
• One protected address space no other processes
  can access its memory
• Collaborate with Inter-Process Communication
  (IPC)... many forms
• Threads
• EmStar does not use any threading!
• If you do not know what they are, do not worry
  about it!
• If you know what they are EmStar does not use
  threads!

5
Processes
Process 1
Process 2
Code
Code
include ltstdio.hgt int do_stuff() return
0 void main() printf(Hellow
World!\n) return do_stuff()
include ltstdio.hgt int do_stuff() return
0 void main() printf(Hellow
World!\n) return do_stuff()
...
Memory
Memory
6
Using Processes to in a Server

• You can use processes to write a Server
• One process waits for incoming connection
• When new connection comes in, new process is
  spwaned to service connection
• After spawning, initial process returns to
  waiting for incoming connection
• For processes to access/change same data must use
  IPC
• Can get complicated to synchronize
• Standard IPC mechanism cumbersome

There is another way!
7
Polling and Blocking

• Must first understand polling and blocking
• Polling
• for/while loop that keeps checking something
• is it ready? is it ready? is it ready?
• Can do other things in between checking
• Blocking
• function call that stops everything and waits
• can not do anything else
• can create thread to block for you
• Most EmStar code neither blocks or polls!

8
Event Based Programming

• Do nothing until an event happens
• Programmer writes functions to handle events
• Functions are called callbacks
• Callbacks are never supposed to block or 'take
  long'
• Underlying system/library triggers callbacks to
  handle events
• Only one execution context no threads
• Only one callback at a time
• Once callback finishes returns control to
  underlying system
• High level events in EmStar
• Incoming packet, sensor reading complete, timer
  fires, state request, state change...

9
Using Events

• Server architecture is now different
• Only one process
• Process waits for multiple events
• Servicing connection broken into small tasks
• How do you determine what the tasks are? Depends
  on application
• Typically a task is 'complete' when it needs to
  block or poll
• Underlying system handles block or poll and
  trigers other events in the mean time
• eg. incoming packet, file becomes readble or
  writable, queue as been filled...
• No syncronization problem, since every event
  completely serviced before next one can begin
  running
• No need for IPC, since all state for one service
  maintained in one process
• This will make more sense when you see some code
  in a few slides...

10
Terminology

• An EmStar application runs on one sensor network
  node
• A sensor network node is a Stargate or a PC
• I may use node and EmStar application
  interchanablge

11
EmStar Basics

• Each EmStar application is a collection of
  processes
• The processes communicate through device files
• Each process maintains its own soft state
• Soft state provides basic form of reliability and
  robustness
• All processes are event based no polling or
  blocking
• Processes start and wait for an event
• OR
• Processes start and set a timer to trigger an
  event

12
Events in EmStar

• EmStar is event based
• no blocking or polling or threads
• Each process sits and waits for something to
  happen
• What does EmStar code look like?
• main() with lots of initialization
• main() ends with call to event loop function
  (g_main()), which does the 'waiting'
• Rest of the code you write is just callbacks
• More details on what code looks like later

Event Loop
dispatches
Callback1 (Data, Context_info) Callback2 (Data,
Context_info) Callback3 (Data, Context_info) Callb
ack4 (Data, Context_info)
Read Write Timer Packet
13
EmStar Basics

• Each EmStar application is a collection of
  processes
• The processes communicate through device files
• Each process maintains its own soft state
• Soft state provides basic form of reliability and
  robustness
• All processes are event based no polling or
  blocking
• Processes start and wait for an event
• OR
• Processes start and set a timer to trigger an
  event

14
Why device files?

• Because event based, do not need multiple
  processes/threads to handle one service
• However, each application has multiple services
• Could build it all into one big and complicate
  process
• OR, could create multiple processes
• With multiple processes
• Each processes has logically separate
  functionality
• Where some services depend on others, still
  communicate with IPC
• This is where the device files come in

15
Device Files

• /dev directory in Linux contains 'device files'
• device files are interfaces to the hardware in
  your sytem
• drivers make connections between devies files and
  hardware
• all drivers are 'kernel space'
• FUSD lets user space processes create device
  files
• device files now interface to the user space
  processes
• FUSD makes connection between device files and
  processes

16
Devices as Interfaces

• Work on event notification reads and writes
  trigger events
• Server-Client model
• Server exports a device(s)
• Client queries device for data and/or writes
  commands
• Services in Emstar provided through device-file
  interface
• Device implementation handles client and request
  queues
• Libraries around core provide different usage
  models
• Status device, query device, packet device,
  sensor device...
• Devices can be accessed by
• Command-line (either using cat or bin/echocat)
• Client libraries (all devices provide a client
  library for program access)

17
Status Device

• Provides current status (binary / printable)
• Getting status
• Status-Device process exports a device file
• Status-Clients process opens this device file
• Status-Client reads from fd
• Status-Device process is informed of read and
  sends data (ascii / binary) to Status-Client
  (through FUSD)
• Status-Device notifies clients when new updates
  are available (i.e. fd is readable) gt goto
  Step 3
• Binary vs Printable call-backs
• Demo's later...

18
Status Device Code

• struct state / component state /
• / packet stats status device callbacks /
• int printable_packetstats_cb()
• int binary_packetstats_cb()
• int gotcommand_packetstats_cb()
• int main(int argc, char argv)
• / init 'global' state, setup callbacks
• init devices, init client libraries
• enter event loop /

19
Main Anatomy

• int main(int argc, char argv)
• init_state()
• / process command-line arguments /
• / initialize standard options /
• misc_init()
• / create devices, clients, timers /
• / set-up emrun options /
• emrun_init()
• g_main() // Enter event loop!
• / Should never get here! Log error! /
• return 1 // return error

20
Hard State vs. Soft State

• Hard state means once we learn a fact about the
  state of the network, we assume that it remains
  true until we are told otherwise.
• Example Neighbor says I am here!, everyone
  assumes the neighbor is there until it says I am
  leaving!
• Soft state means always communicate full state
  periodically
• Example Neighbor says I am here! periodically,
  if serveral period pass without hearing this
  message, everyone assumes the neighbor is gone
• Resillient to missing or dropping state
• Helps processes startup again when fail
• Will not get into state it can not recover from
• A catchall... 'self healing'
• EmStar code follows the soft state design
  philosophy

add 1
5
5
add 1
X
6
add 1
6
7
add 1
7
8
...
http//cvs.cens.ucla.edu/emstar/tut/neighbors.html
21
EmStar Basics Revisited

• Now we should understand all of the following!
• Each EmStar application is a collection of
  processes
• The processes communicate through device files
• Each process maintains its own soft state
• Soft state provides basic form of reliability and
  robustness
• All processes are event based no polling or
  blocking
• Processes start and wait for an event
• OR
• Processes start and set a timer to trigger an
  event

22
Running EmStar

• EmStar has a couple different modes
• Real mode
• Simulation mode
• Emulation mode
• You only need to worry about Real mode and
  Simulation mode
• If interested in Emulation, lets talk afterwards

23
Where are all the binaries?

• Normal builds leave a huge mess inside your
  source tree, and make clean never seems to
  quite work.
• EasyBuild implements an out of tree build
• The results of the compilation process (binaries,
  object files, libraries, etc.) are all placed in
  a parallel tree structure
• This leaves your source tree clean
• Simplifies building for multiple architectures
  simultaneously
• If we compiled for i686-linux (the default), then
  all the binaries are in
• emstar/obj.i686-linux/
• Remember EmStar almost always expects the code
  to be run from the obj directories!!!

24
An EmStar Node Example

• Todays running example
• neighbor-app prints total neighbors
• neighbord translates linkstats output into
  neighbor list
• linkstats transparently talks with linkstats on
  other nodes to evaluate links
• udp provides link device to ethernet/wireless
  network
• Code is in
• neighbor-app link/examples/neighbors
• neighbord link/neighbors
• linkstats link/linkstats
• udp link/udp
• How do we make this all run? emrun! do demo!

25
Emrun

• Emrun process manager for a node
• Starts, stops, and manages processes
• Collects log messages from processes
• Presented to interactive client as in memory log
  ring
• Various runtime configurable log levels available
• (you should use elog() in your code, not
  printf()!!!)
• Sets up control channel to each processes to
  monitor health
• emrun_init() opens control channel back to emrun
  and starts heartbeat
• Respawns dead or stuck processes
• Initiates graceful shutdown
• Receives notification when starting up that
  initialization is complete

26
emrun devices

• /dev/emrun/status
• Reports the current state of all processes
  managed by emrun
• /dev/emrun/command
• Command interface for controlling emrun
• /dev/emrun/last_msg
• Lists the last time each process was terminated
  and why, as well as the last log message before
  death
• /dev/emlog/ltprocessgt/...
• Per-process in-memory log rings
• The -f versions can be used to stream the
  continuous log to a file with cat (or just use
  tail -f on non -f version)
• The non -f versions dump recent messages.
• /dev/emrun/emview_config
• Reports configuration information used to
  automatically configure the EmView visualizer

27
.run files

• .run config files
• Specify how the EmStar services are "wired"
  together
• Specifies dependency order for processes
• Allows emrun to maximize parallelism for startup

Process block
Key value pairs

• Required
• type once, daemon, boot
• cmd the command to run
• Optional
• waitfor specifies a dependency
• nice set the nice level for the process
• loglevel set the default loglevel
• no-core don't create a core file on crash
• no-sim only run when not in sim mode
• sim-only only run in sim mode

process lttaggt ltkeygt ltvaluegt ...
http//cvs.cens.ucla.edu/emstar/toc/em/emrun.html
28
Example .run file

• WARNING! .run files typically assume you
• are running from the obj directory!

29
emrun macros save the day
include link/link.run link_udp(udp0) link_link
stats(udp0,ls0) link_neighbors(ls0) link_black
list(ls0,bl0,ls0) link_frag(bl0,frag0) link_pi
ngd(frag0)

• Macros exist for most of the common components
  and services
• Easiest to understand by looking at examples
• Lets look at examples
• link/include/link.run
• mote/include/mote.run

include link/link.run include routing/routing.run
link_udp(udp0,class"raw") link_linkstats(udp0
,ls0) link_neighbors(ls0) routing_flood(ls0)
link_pingd(flood)
30
emsim

• emsim enables multiple nodes on one machine
• Start, stops, and manages emrun's and
  sim-components
• Requires SIM_GROUP environment var to be set
• How do the processes know which group and node?
• emsim sets environment variables, misc_init()
  reads
• accessible in code as my_node_id after
  misc_init()
• In reality, emsim and emrun and almost the same
  code
• emsim has it's own configuration files

31
emsim devices

• /dev/sim/group/config
• Reports position, config file, and on/off status
  of each node
• /dev/sim/group/emrun/status
• Reports the current state of all processes
  managed by emsim
• /dev/sim/group/emrun/command
• Command interface for controlling emsim
• /dev/sim/group/emrun/last_msg
• Lists the last time each process was terminated
  and why, as well as the last log message before
  death
• /dev/sim/group/emlog/ltprocessgt/...
• Per-process in-memory log rings
• The -f versions can be used to stream the
  continuous log to a file with cat (or just use
  tail -f on non -f version)
• The non -f versions dump recent messages
• For emsim, look at the sim-component-

32
emsim example
Node 1
Node 4
Node 2
Node 3
neighbor-app
neighbor-app
neighbor-app
neighbor-app
node004/link/ls0/neighbors
node003/link/ls0/neighbors
node002/link/ls0/neighbors
node001/link/ls0/neighbors
neighbord
neighbord
neighbord
neighbord
udp
udp
udp
udp
node004/link/udp0/data
node003/link/udp0/data
node002/link/udp0/data
node001/link/udp0/data
sim_radio
33
.sim files

• .sim files specify
• sim components
• number of nodes and field size
• .run files for each nodes
• position of nodes
• default on/off

Node Block
node ltidgt ltkeygt ltvaluegt ...
ltidgt values
default default for all nodes for a specific
node - for a range of nodes
Required
num-nodes usually passed in through
command line field-size (max x, max
y) sim-component sim-radio command
Key value pairs
position (x, y) emruntab specify the emrun
tab power on or off
http//cvs.cens.ucla.edu/emstar/tut/emsim-advanced
.html
34
Usefull Libraries in EmStar

• elog() -gt use this instead of printf
• Special printing function that allows varous
  levels of printing
• It is setup so emrun collect and redirect
  everything
• buf_t's -gt automatically growing buffer of data
• Takes care of dyanimc allocations so you do not
  have to
• Many usefull functions for adding to the buffer
• Many EmStar fuctions use buf_t's
• misc_opt.h -gt comand line parsing
• Provides easy to use functions for command line
  parsing
• All documented in libmisc/include/misc_opt.h

35
elog()

• emstar/libmisc/include/elog.h line 50
• Similar to printf
• elog(LOG_ALERT, File name is s. Something went
  wrong m, file_name)
• Anyone know what m is?
• Prints out time_stamp, node id, process,
  function, message
• Fri Oct 29 100221.517 5 trig helper Current
  state is 10
• Many different log levels
• LOG_ALERT, LOG_CRIT, LOG_WARNING, LOG_NOTICE,
  etc.
• LOG_DEBUG_ where is 1-100

36
buf_t

• emstar/libmisc/include/misc_buf.h line 88
• A "buf_t" is a structure that makes it easy to
  construct a growing buffer of data, without
  worrying about sizing it correctly.
• Initializing and freeing
• Heap buf_new() and buf_free()
• Stack buf_init()
• Writing
• Similar to sprintf bufprintf(buf b, )
• bufprintf(my_buf, "Immediate response
  's'\nUptime is d seconds\n", )

37
NesC

• NesC code runs on Motes
• TinyOS is the drivers and libraries that make
  writing code in NesC for motes easier
• NesC code can be compiled for PC's, but it can
  only run in TOSSIM... the TinyOS Simulator
• TOSSIM has limited ability to interact with much
  besides Java.

38
EmTOS

• Stargates and PC's can run NesC in TOSSIM, but it
  can not be connected to 'the outside world'
• So, how do you integrate the mote world and the
  Stargate/PC world?
• (motes can be attached to stargate btw)
• Option 1 Add code to your NesC program to
  forward data through the serial port to the
  Stargate
• Option 2 Make mote into packet forwarder
  (network card), and rewrite NesC code in C or
  Java
• Option 3 EmTOS! Run your NesC code as an EmStar
  process!

39
EmTOS

• EmTOS hooks up NesC code to other EmStar
  components
• The end effect is the Stargate or PC can act like
  one really big mote!
• Adding a few lines of code to your NesC program
  enables it to communicate with other EmStar
  services
• No rewriting NesC code into C
• No writing complex protocols to exchange data
  between mote and C/Java

40
Terminology

• EmTOS Builds a Linux binary from TinyOS code
  that uses other EmStar services
• Motenic/HostMote presents link interface to
  EmStar components and handles communication with
  mote
• Transciever Code that runs on the mote... it is
  what makes the mote act like a network card

Serial
41
EmTOS
42
How to Use EmTOS

• Add build targate to mote/BUILD file
• This build file contains examples
• Executable will be in obj./mote
• Add to .run file, just as any EmStar component
• Run file also needs hostmote and motenic macros

include mote/mote.run mote_hostmote(/dev/ttyS0,mi
ca2,0) mote_motenic(mote0,0,show"leds")

• Run, just as any standard EmStar application
• For examples of how to create EmStar devices with
  NesC, see
• tos-contrib/EmTos/...

http//cvs.cens.ucla.edu/emstar/toc/comp_services/
emtos.html
43
WAKE UP!

• All done... questions, email mlukac_at_lecs.cs.ucla.e
  du ...
• or just come find me!

44
Processes vs. Threads (cont.)
Process
Process with threads
Code
Thread 1
Thread 2
include ltstdio.hgt int do_stuff() return
0 void main() printf(Hellow
World!\n) return do_stuff()
include ltstdio.hgt int do_stuff() return
0 void main() printf(Hellow
World!\n) return do_stuff()
include ltstdio.hgt int do_stuff() return
0 void main() printf(Hellow
World!\n) return do_stuff()
Memory
Memory
45
Using Threads

• Standard server architecture
• Main thread waits for incoming connection
• When new connection comes in, spawns thread to
  service conenction
• After spawning, returns to waiting for incoming
  connection
• Problem arrises when multiple threads need to
  access/change same data
• OS controls how long each thread executes
• User has no control of 'when stuff happens'
• Must use libraries or language features to try to
  syncrhonize access to memory