EmStar Features and Architecture

1
EmStar Features and Architecture

• BLAM! Workshop
• Lewis Girod
• 8 November 2003

EmStar is joint work by a number of contributors
including Alberto Cerpa, Jeremy Elson, Lewis
Girod, Nithya Ramanthan, Thanos Stathoupolous,
and many others.
2
Q What is EmStar?
Defines Standard set of Interfaces
Simulation/Emulation
Run-time Environment for Microservers
Reusable modules, configurable wiring
3
Design should be familiar

• EmStar design very similar to TinyOS
• Modular decomposition, no strict layering
• Wiring together modules into an app
• Support for Simulation/Visualization tools
• Event driven model
• Reactive design
• Robustness
• Tolerate faults
• Adapt to environment

4
Leveraging Larger Platforms

• More transparency into running system
• Visualization, shell interaction, local logs
• Develop without optimization
• No hard limits on table sizes, etc.
• Modules always support multiple, dynamic clients
• Language agnostic
• Interfaces are system calls on device files
• Concurrency Model
• Modules run concurrently (Linux processes)
• Modules are typically single-threaded event loops

5
Whence and Whither?

• Where did EmStar come from?
• Where is it going?

6
Whence?

• EmStar ideas from work on the SHM program
• 100 Linux nodes, complex distributed app
• 150K lines C code
• 30 modules
• Lots of mundane details
• Getting S/W on nodes and running it
• Local error logs
• Why is node 12 acting up?
• Visualization of whole net
• Whats going on?

7
Whither?

• Reimplementation based on SHM experience
• Stargate is primary supported platform
• Current (evolving) users
• Jeremys seismic system
• Time distribution
• Deployment issues (S/W upgrade, etc.)
• NIMS robotics application
• Robotic sensors and actuators
• Acoustic sensing platform based on Stargate
• Audio H/W support

8
The EmStar Story

• Run-time environment for networked, wireless
  embedded systems
• Designed for
• Fault tolerance both within node and between
  nodes
• Robust, autonomous, remote operation
• Reactivity to dynamics in environment and task
• High visibility into system interactive access
  to all services
• Modular, but not strictly layered architecture
• NOT designed for network transparency (e.g.
  sockets)
• Wireless is too costly and flaky
• Connectivity to services on remote nodes is
  fundamentally different than to local services
  (reliability, latency, etc)

9
Sim,Emulation Deployment

• EmStar code runs transparently at many degrees of
  reality high visibility debugging before
  low-visibility deployment

10
Interacting With em

• Text/Binary on same device file
• Text mode enables interaction from shell and
  scripts
• Binary mode enables easy programmatic access to
  data as C structures, etc.
• EmStar device patterns support multiple
  concurrent clients
• IPC channels used internally can be viewed
  concurrently for debugging
• Live state can be viewed in the shell (echocat
  w) or using emview

11
Demo
emview
Emulator
nodeN
nodeN
nodeN
proxy
neighbor
neighbor

/dev/link/0/neighbors
linkstat
linkstats
motenic
/dev/link/0/linkstat
/dev/link/0/stats
motenic
/dev/link/0/data
/dev/link/0/status

Mote
Mote
Mote
hostmote
/dev/mote/status
/dev/mote/hostmote
12
Programming in EmStar

• EmRun init on steroids
• Logging
• Dependency graph
• Respawn, Shutdown
• FUSD IPC
• Transparency, interactivity
• Device Patterns
• Packet Device
• Status Device
• Sensor Device
• Command Device
• Directory Device

13
EmRun Manages Services

• Designed to start, stop, and monitor services
• Increases robustness, resilience, autonomy
• EmRun config file specifies service dependencies
• Starting and stopping the system
• Starts up services in correct order
• Respawns services that die
• Can detect and restart unresponsive services
• Notifies services before shutdown, enabling
  graceful shutdown and persistent state
• Error/Debug Logging
• Per-process logging to in-memory ring buffers
• Configurable log levels

14
FUSD IPC

• Inter-module IPC FUSD
• Creates device file interfaces
• Text/Binary on same file
• Standard interface
• Language independent
• No client library required
• Requires Linux devfs
• (Until kernel 2.6)

User
Kernel
15
Device Patterns

• FUSD can support virtually any semantics
• What happens when client calls read()? etc..
• But many interfaces fall into certain patterns
• Device Patterns
• Encapsulate specific semantics
• Take the form of a library
• Objects, with method calls and callback functions
• 1 priority ease of use
• Integrates with the GLib event loop

16
Status Device

• Designed to report current state
• No queuing clients not guaranteed to see every
  intermediate state
• Supports multiple clients
• Interactive and programmatic interface
• ASCII output via cat
• Binary output to programs
• Supports client notification
• Notification via select()
• Client configurable
• Client can write command string
• Server parses it to enable per-client behavior

17
Packet Device

• Designed for message streams
• Supports multiple clients
• Supports queuing
• Round-robin service of output queues
• Delivery of messages to all, or specific clients
• Client-configurable
• Input and output queue lengths
• Input filters
• Optional loopback of outputs to other clients
  (for snooping)

18
Sensor Device

• Driver submits timestamped blocks of sensor data
• Internal ring buffer
• Enables extraction of past data
• Integrates with TimeSync service for time series
  data
• Supports multiple clients
• Streaming or queried modes
• Notification when new samples arrive
• Supports configuration interface
• Driver can parse client config requests

Sensor Driver
Sensor Device
TimeSync Service
I
C
R
R
R
C
C
C
Client1
Client2
Client3
Currently under development
19
Conclusion

• EmStar has a lot of useful stuff
• Trying to create a run-time environment
• We can call build on and contribute to
• Build a community
• Emphasis on code re-use through
• Good interface design
• Factoring techniques
• (factoring guarantees at least one use!)

20
Future Work

• Work In Progress
• Device Interfaces, modules
• Sensor device interface
• Subject Server integration
• Documentation
• Sample code and skeletons
• Future work
• Sensor simulation, playback facilities
• World modeling, sensor modeling (integrate to
  stage?)
• Supporting libraries for persistent storage
• Embedded web server for configuration

21
The End!Thank you..