Programming Model for Sensor Actuator Systems

1
Programming Model for Sensor Actuator Systems

• Macro-Programming Group
• NESL UCLA

2
What are we doing ?

• Propose and implement a programming model for
  distributed control applications over sensor
  actuator networks
• A programming model is an abstraction of the
  underlying system architecture that exposes only
  the relevant details for a programmer to
  efficiently implement an application.

3
Balance Abstraction and Visibility

• ABSTRACTION
• Removes the need for the programmer to learn the
  details of the architecture just to begin
  programming.
• Programmer should be exposed to system level
  services (time-sync, localization, routing)
  rather than node level drivers (protocol stack,
  SPI, UART)
• Binding of system level services to logical
  entities instead of nodes

• VISIBILITY
• Allow the programmer to trade-off different
  design parameters
• Enable design exploration.
• All the system capabilities should be realizable
  through the programming model.
• The programmer should be able to vary the
  parameters of time-sync service (accuracy,
  frequency)
• Programmer can also dictate the mapping of
  logical entities to the physical nodes

4
System and Application Features

• System
• Large scale system
• Loosely coupled components
• Individual nodes are resource constrained
• Nodes are heterogeneous
• Low data rate inter-connect
• Low power operation
• Control Application
• Event triggered initiation
• Real time operation
• Multiple interacting controller modules

5
Modules

• Modules are the logical building blocks that
  would be inter-connected to form an application
• Binding of modules to physical nodes is dynamic
• Module is defined by
• Attributes
• In/Out Events
• Push/Pull Channels
• Methods
• Tasks

6
Attributes

• Aid in binding of modules to nodes at
  compile/run-time
• Location
• Fixed geographic location in the terrain
• (x,y) coordinates
• Landmark based
• Topological location
• Root node
• Cluster head
• Level in aggregation tree
• Node Type
• _at_ every Stargate

7
Events

• Rapid best-effort signaling mechanism between
  modules
• Events have attributes
• Type, Location, Time
• Modules declare a set of In Events and Out Events
• Modules react to In Events
• Modules generate Out Events
• Notification constraints
• All In-Events are associated with notification
  constraints
• User-Detected events within radius of 10 m of my
  location
• _at_ Source Scope the event delivery based on
  notification constraints
• _at_ Sink Drop events based on notification
  constrains
• Challenge
• Maintaining an end to end event signaling link in
  the presence of dynamic module binding
• Tiny-Diffusion with modifications can be applied

8
Channels

• Data communication links between modules
• Channel terminate at ports
• Producer module Connects to write port
• Consumer module Connects to read port
• Channel parameters
• Type Push or Pull
• Sample size
• Sample rate Guaranteed delivery of data in the
  sample period
• Push vs. Pull channel
• Push Read port buffers data
• Pull Write port buffers data
• Control/Real-time algorithms, typically push
• Sensors push data to controllers
• Controllers push commands to actuators

9
Channel Details

• Channel Constraints
• Connection established between two modules based
  on constraints upon their attributes
• Two modules that have adjacent level numbers in
  aggregation tree
• Two modules that are in geographical proximity to
  one another (controller, sensor actuator)
• Channel state
• Active/Inactive
• The consumer sets the state of the channel
• Multiple instances of a channel can be
  synchronized
• There will be multiple sensor controller channels
  and the data on all such channels should have the
  identical time-stamp on it.
• Challenge
• Number of channels may be determined at run-time
• The number of modules is not known apriori

10
Methods and Tasks

• Response of modules to Events that satisfy the
  notification constraints
• Quickly run-to-completion
• Tasks are schedulable units of computation
• Tasks can be activated and de-activated
• Tasks can have deadlines and periods
• Tasks read input from ports and write output to
  ports
• Tasks within a module are interconnected by
  queues
• Challenge
• Scheduling of tasks at node with multiple modules
  mapped onto it.

11
Meeting Agenda

• Further refine the programming model
• Brainstorm on mechanisms for the implementation
  of the model
• Can we use TinyDiffusion for implementing the
  channels and events ?
• What about the scheduling algorithm at a node
• MAC protocol for channels and events
• Project Timeline