[Firebug-cvs] firebug/doc/sensor_interface .cvsignore,NONE,1.1 Makefile,NONE,1.1 sensor_interface.tex,NONE,1.1

[David M. D. <do...@us...>]

Update of /cvsroot/firebug/firebug/doc/sensor_interface
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17504

Added Files:
	.cvsignore Makefile sensor_interface.tex 
Log Message:
Sensor interface paper with figures, extracted from 
poster presented at TOS Tech exchange.

--- NEW FILE: .cvsignore ---
*.log *.aux *.dvi *.ps *.pdf *.blg *.bbl chicago.sty spie.bib
*.out

--- NEW FILE: sensor_interface.tex ---
\documentclass[10pt,letter]{article}

\usepackage{color}
\usepackage{chicago}
\usepackage{subfigure}
\input{comment}
\usepackage{times}
\usepackage{graphicx}
\usepackage{algorithm}
\usepackage{algorithmic}


\newcommand{\tinyos}{TinyOS}
\newcommand{\firebug}{Firebug}
\newcommand{\sensor}{\textcolor{black}{HLSensor}}
\newcommand{\fireboard}{Fireboard}
\newcommand{\fig}{Fig.}
\newcommand{\figs}{Figs.}


\setlength{\topmargin}{0in}
\setlength{\textheight}{8.5in}
\setlength{\oddsidemargin}{0in}
\setlength{\textwidth}{6.5in}


\begin{document}

\title{High-level Sensor interface for TinyOS 
applications}
\author{David M. Doolin\thanks{% 
Civil and Environmental Engineering,
University of California, Berkeley,
2108 Shattcuk Ave., Berkeley, CA 94720-1716
\tt{email: do...@ce...}}}
\date{\today}
\maketitle


    
\begin{abstract}
Wireless sensors for conducting wildfire 
monitoring share many of the capabilities of 
other environmental sensors, collecting 
data such as humidity, temperature and barometric pressure.
On-board GPS location finding allows rapid, remote 
deployment.  In this poster, a scheme for 
developing driver and interface software for 
employing the Crossbow MTS420CA sensorboard
is described.  A high-level, generalized 
sensor interface is presented.  Data collection 
algorithms implemented over implementations
of this sensor interface do not require 
programming changes to the underlying 
sensor driver code.
\end{abstract}




\section{Introduction}


Monitoring rapidly changing environmental 
conditions occurring during wildfire requires
deployment of large numbers of sensors
into dangerous environments.  
The NSF Information Technology Research sponsored
``Firebug'' project~\citeyear{chen:mm2003}
is developing a small, inexpensive
platform using wireless communication networks
to support a heterogeneous array of sensors
useful for detecting the initiation and 
monitoring the spread of wildfires.  One 
component of the \firebug\ project is a 
environmental sensor board with GPS 
location capabilities (``Fireboard'').
The software architecture for the fireboard
is described in this poster.



\subsection{Fireboard}

%%%%%%%%%%%%  Change all of this to a ``positive'' slant.

The \fireboard, bottom and top 
shown in \figs~1 and 2 respectively, is composed
of an Analog Devices ADXL202JE accelarometer, 
an Sensirion SHT11 combined 
temperature and humidity sensor, an Intersema 5534AP
combined barometric pressure and temperature 
sensor a Taos 250RD light sensor, and a LeadTek
9546 GPS unit.  The driver code for the board
initially combined previously written  mica 
weatherboard code with preexisting code
from a GPS unit.  The code, while useful for 
demonstration purposes, required updating for 
TinyOS 1.1 and was written for synchronous 
operation using either the GPS unit, 
or all the other sensors, but not both 
at the same time.

%%%%%%  Here are a few notes I want to save, but can't yet use:
% * Current TinyOS stuff is very good for it is being used for.
% * Need to ``sell'' the concept of an API wrapped over ``core 
%   tos''.  Compare to BLAS/LAPACK, etc.
% * The work in the poster is not necessarily proposed for 
%   ``core tos''.  
% * The developers should be ready for nesc/tos to run away in 
%   entirely unexpected directions.
% * Our focus is on ``customers''
% * Current sensor boards have test code that can be wrapped
%   to implement the interfaces proposed here.


\begin{figure}
\begin{center}
\subfigure[]{\label{}
\includegraphics[width=2in]{figs/fireboard_bottom.eps}}
\subfigure[]{\label{}
\includegraphics[width=2in]{figs/fireboard_top.eps}}
\caption{Fireboard}
\label{fig:fireboard}
\end{center}
\end{figure}



\subsection{Sensor and sensorboard operation}


Currently, sensor values are collected  
by implementing components providing access
directly to ADC or UART.  This has the 
advantage of being ``close to the metal'',
at the expense of introducing unnecessary 
complexity for application programmers.

To reduce the complexity of sensor board
programming, 
Gay et al.~\citeyear{gay:d2004a} recently
proposed formalizing a specification for implementing
sensor driver code as part of a sensorboard 
specification.  This proposal, in part, reflects current 
implementations of code for operating sensors
on ``weather boards'', such as that deployed 
at Great Duck Island~\shortcite{mainwaring:a2002}.
For example, controlling sensors would still require 
understanding the code and mechanisms behind the 
operation of I2C, UART, and ADC.  


Ho~\citeyear{ho:h2004} proposed 
a MATLAB-based system for sending messages
to motes pre-programmed with a ``GenericSensor'' application.
Specifications for the active message (AM) structure are provided,
including messages for command and control, route discovery,
and data transmission.
The advantage of this scheme is that once the software supporting
the sensor hardware has been implemented, the system requires
little further work on the mote software; data collection 
and mote control are provided through software written 
on the widely-familiar MATLAB platform.  Disadvantages include:
latency induced by having centralized control over 
mote behavior, slowing down the response of adaptive
data collection algorithms and necessity of rewriting the 
application to fit changes in sensor hardware.

The Gay et al. and Ho proposals 
could be considered as part of a ``DPI'': Developer's
Programming Interface.  
The \sensor\ interface described here could be
considered part of an
API; an Applications Programming Interface 
constructed on the lower level modules, as
shown in \fig~3.






\begin{comment}
\paragraph{Data collection/Data processing}
The \tinyos\ model for data collection is 
characterized by the following:
\begin{itemize}

\item Centralized control on a PC, for 
example running the TASK toolset, instead of distributed control.

\item \cite{hong:w2003}:

\item \cite{gay:d2004b}:

\end{itemize}
\end{comment}


%%%  Perhaps mention this later.
%In terms of a recently proposed framework for 
%application development in TinyOS~\cite{levis:pa2004}, 
%implementations of \sensor\ are intended to be 
%{\em modules}: compatible with but outside the 
%TinyOS core.

    

\begin{figure}
\begin{center}
\includegraphics[width=2in]{figs/api_stack.eps}
\caption{An API stack for \tinyos\ applications.}
\label{fig:api_stack}
\end{center}
\end{figure}

\subsection{Requirements and capabilities}

We needed at least the following characteristics 
for the driver code:
\begin{itemize}
\item Ability to control which sensors are working at 
a given time.
\item Separate data collection algorithm from sensor
driver code.  Changing the data collection algorithm 
should not require any changes in the lower level 
sensor driver code.
\item Understandable, in principle, by 
participants without formal training in electrical 
engineering /computer science.
\end{itemize}



%%%%%  Save for later, too hard to work it into this.
%Any network deployment of sensors requires at 
%least the following capabilities:
%\begin{itemize}
%\item Configuration management
%\item Acquisition control
%\item Communications control
%\item Time synchronization
%\item Trigger control/trigger synchronization
%\item Power management
%\end{itemize}


The definition and implementation of 
the \sensor\ interfaces form a ``Programmer's
API'' that resides above the \tinyos\ 
core modules, but below the level of applications.
Other types of applications benefit from 
this kind of abstraction.  For example, 
Lynch et al.~\citeyear{lynch:jp2003:SEM} use a 
microcontroller to power both sensors and 
a computational unit for performing fast 
fourier transform on the platform.  Typically,
such transforms are used to extract a 
small number of lower order terms representing 
the dominant response.  This saves a considerable 
amount of network traffic since the time 
series is not transmitted and low accuracy,
higher order terms are ignored.



%%%%%%%%%%%%  Save for later.
\begin{comment}
\subsection{Interface definitions}

\begin{itemize}
\item Sensorboard
\item Sensor
\item Trigger
\end{itemize}
\end{comment}



\begin{comment}
\begin{verbatim}
interface Sensor {

  command result_t powerOn();
  event   result_t powerOnDone();
  command result_t init();
  command result_t powerOff();
  event   result_t powerOffDone();
  command result_t setSamplingInterval(//
                   uint16_t interval);
  command result_t getSamplingInterval(//
                   uint16_t interval);
  command result_t startSampling();
  command result_t stopSampling();
  command result_t sampleOnce();
  event   result_t dataReady(void * userdata);    
  command result_t loadProgram(uint8_t * program);
  event   result_t error(uint16_t error_code);
}
\end{verbatim}

\paragraph{set/getSamplingInterval} allows run
time control necessary for adaptive sampling.
\end{comment}



%%%%%%%%%%%%%%%%%  Do triggering some other time.
\begin{comment}
\subsection{Trigger  Control and Synchronization}

The following trigger abilities will be needed.  
They either can be included in the OS by the Mote 
hardware manufacturer with necessary software hooks, 
or the necessary on-board processing hooks made 
available to end user.

\begin{enumerate}

\item Each sensor is remotely programmable for a different trigger level.

\item Multiple types of trigger conditions should be supported:

\begin{itemize}

\item Excursion over/under a programmable threshold. 
Threshold can be either a  positive or negative value 
or both (window condition)

\item Excursion into a positive/negative threshold (i.e. 
sensor value is initially outside the window and then 
moves into the window).

\item Both of the above trigger conditions should have 
an associated time value. Time value of zero means trigger 
generated immediately after trigger detected. Non zero 
value means trigger generated N samples after entering 
trigger condition if trigger condition is still true 
during all $N$ samples.
\end{itemize}


\item Each sensor can be remotely enabled/disabled to trigger.

\item Sensor trigger levels are programmable in units of 
ADC lsbs. The base station is required to compute these levels.

\item Number of pretrigger samples to be stored in flash

\item Number of postrigger samples to be stored in flash

\item Each sensor can be programmed to broadcast a detected trigger. 
Units receiving this message then (if enabled) start to store 
data from their own sensors.

\item Time alignment of triggers is critical. When the broadcasted 
trigger message is sent it may take several hops to reach all 
other motes which introduces a time delay. This time delay must 
be accounted for in every mote receiving the trigger message. 
The receiving mote must time align its data to this trigger 
delay. 
\end{enumerate}
\end{comment}



\section{Module architecture}


Separating a sensor board into constituent 
sensors has the following advantages:
\begin{itemize}
\item Reduces complexity --- divide and conquer.
\item Encourages incremental implementation and testing.
For example, not every command in an interface need be 
implemented initially.  As commands are incrementally 
implemented, the implementation can be debugged.
\end{itemize}


TinyOS and nesC use a number of naming conventions.
The Sensor interface follows this example:
\begin{itemize}
\item Each sensor located in a directory named by:\\
 {\tt manufacturer\_modelnumber} (Figs. 4, 5). 

Example: \textcolor{red}{\tt sensirion\_sht11}.



\item Each sensor board located in directory named by\\
{\tt manufacturer\_modelnumber}.

Example: \textcolor{red}{\tt xbow\_mts420ca}.
\end{itemize}


%For analogous component in Linux system code, 
%consider how graphic or network card 
%code is written: the header files are at 
%least somewhat mnemonic.  Using generic 
%filenames such as ``networkcard.h'' or
%graphicscard.h'' probably would not be 
%very convenient.


\begin{figure}
\begin{center}
\subfigure[]{\label{}
\includegraphics[width=2in]{figs/tostree.eps}}
\subfigure[]{\label{}
\includegraphics[width=2in]{figs/tostreetop.eps}}
\caption{Fireboard}
\label{fig:fireboard}
\end{center}
\end{figure}



The actual files making the sensor work
are divided into a driver file, then 
everything else:
\begin{itemize}
\item *\_driver.nc is the configuration for 
sensor ``*''.   This provides a ``first line
of defense'' when driver code needs to be modified,
and should consist only of nesC system code.
\item Every other file in the directory 
supports the driver, and may consist of 
a mixture of nesC system code and hardware
specific code.
\item CPU specific code (Atmel, TI, etc) 
should not be located in this directory.
\end{itemize}



Constructing unique names for sensor
boards eliminates any ambiguity about 
precisely which piece of hardware is
being used.  A unique name reduces the 
potential for blunders caused
by incorrect include paths, where {\tt 
sensorboard.h} may be included more than 
once, or from the wrong location.  An example
of this is compiling the micawbdot into an 
application, then using the fireboard, which 
will return data of some unknown sort.



\subsection{High-level Sensor interface}


\begin{verbatim}
interface HLSensor {

  command result_t powerOn(uint8_t power_state);
  event   result_t powerOnDone();
  command result_t init();
  command result_t powerOff();
  event   result_t powerOffDone();
  command result_t setSamplingInterval(//
                   uint16_t interval);
  command result_t getSamplingInterval(//
                   uint16_t interval);
  command result_t startSampling();
  command result_t stopSampling();
  command result_t sampleOnce();
  event   result_t dataReady(void * userdata);    
  command result_t loadProgram(uint8_t * program);
  event   result_t error(uint16_t error_code);
}
\end{verbatim}



The \sensor\ interface is ``heavier'' than most 
of the interfaces defined in the TinyOS core.
Interfaces in the core are more general, 
designed for flexibility.  The \sensor\ interface
trades some flexibility for ease-of-programming at the 
application level.  Interfaces in the  TinyOS core 
could be considered an API for library extension 
development, constituting a ``developer's 
programming interface'' (DPI).  In contrast, 
the \sensor\ interface provides an 
application's programmer interface (API).  
Implementations of \sensor\ allow application
programmers to experiment with distributed data 
collection algorithms, such as feedback-controlled
adaptive algorithms, without having to modify any 
driver code.  One advantage of \sensor\ is that 
a general sensorboard component may be written
that provides multiple sensors.  The sensorboard 
component then packages the requisite data into a
custom data structure which is then tucked into 
an active message for radio transmission.



\paragraph{Sampling}
is controlled by 6 commands which 
reflect the expectations and vocabulary of 
domain experts: $[$get,set$]$SamplingInterval,
$[$start,stop$]$Sampling, sampleOnce and 
dataReady.
These commands do exactly what the names suggest.
The commands $[$start,stop$]$Sampling are 
useful for continuous, asynchronous sampling 
where the implementation controls the timing 
of the data collection.  This capability is 
useful for adaptive sampling.  sampleOnce is 
useful for synchronous data collection controlled,
for example, by a sensorboard component.


The dataReady event provides a void 
pointer cast to a sensor-specific 
data structure.  This differs from the 
Gay et al.~\citeyear{gay:d2004a} proposal
for a lower level sensor interface, where the 
dataReady event returns raw values from 
hardware components such as the ADC.  
This and the Gay et al. specifications complement each 
other in the sense that \sensor\ may be 
implemented on top of the Gay et al. design for
processing and calibrating hardware readings
on the mote to allow distibuted/autonomous 
control over data collection.


\paragraph{Power, init and error} 
Arguments to the powerOn command 
allow control of sensors with multiple power states.
The init command provides software initialization
of a sensor component, independent of
the power$[$On/Off$]$ command.  The 
error event passes an sensor-specific 
error argument, defined in the header file
for each sensor.


\paragraph{Runtime sensor programming}
is performed using the loadProgram command.
All sensors are assumed {\em logically} programmable,
\begin{itemize}
\item If there is hardware support for programming,
loading a program causes sensor/implementation 
dependent behavior.
\item If there is no hardware programming support,
then loading a program is a no-op.
\end{itemize}
Note that the program could just as easily be
used for controlling driver software state controlling 
sensor hardware operations.





\begin{comment}
\section{Implementation}

    
\subsection{Algorithm for data collection}
    
Because the GPS unit is an independently functioning microcomputer,
the data collection algorithm must be more involved than simply
powering on the sensor board and polling for data.

\bigskip

\hrule

\smallskip

%\begin{algorithm}
%\caption{Directional points.  Superscript $d$  indexes the 
%directional points, subscripts  index the time step.}
\begin{minipage}{\figwidth}
\addtocounter{algorithmcount}{1}{\small \captcolor 
Algorithm~\arabic{algorithmcount}.  
Synchronous algorithm for controlling MTS420CA \\
sensor board.}
\smallskip
\hrule

\begin{algorithmic}[1]
   \STATE Power GPS from cold start.
   \REPEAT [Sample NMEA output]
      \STATE  Examine GPS satellite fix quality.
   \UNTIL {GPS satellite fix obtained.}
   \STATE Signal GPS fix ready for RF.
   \STATE Put GPS in Trickle Power.
   \FOR {$i = 1,...n$ time steps}
      \STATE Sample temperature/humidity.
      \STATE Sample barometric pressure.
      \STATE Sample light intensity.
      \STATE Signal data ready for RF.
   \ENDFOR
\end{algorithmic}
\end{minipage}
%\label{alg:directionalpoint}
%\end{algorithm}
\bigskip
\hrule
\smallskip
\hrule
\bigskip
\end{comment}
   
\begin{comment}
    \begin{minipage}{\figwidth}
      \begin{center}
	\includegraphics[scale=0.5]{figs/satellite.lg.eps} \\
	\addtocounter{figscount}{1}{
	  \small \captcolor 
	  Figure~\arabic{figscount}.  Satellites are used for GPS
          fixes.
	}
      \end{center}
    \end{minipage}
\end{comment}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{comment}
    \begin{minipage}{\figwidth}
      \begin{center}
\includegraphics[scale=1.6]{figs/TestGPS.testgps.nc.if.ps}\\
	\addtocounter{figscount}{1}{
	  \small \captcolor{ 
	  Figure~\arabic{figscount}.  Wiring diagram using 
          \sensor\ interface for GPS test application.}
	}
      \end{center}
    \end{minipage}
\end{comment}

\begin{comment}
    \begin{minipage}{\figwidth}
      \begin{center}
\includegraphics[scale=1.6]{figs/TestTaos.testtaos.nc.if.ps}\\
	\addtocounter{figscount}{1}{
	  \small \captcolor 
	  Figure~\arabic{figscount}.  Caption.
	}
      \end{center}
    \end{minipage}
\end{comment}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\begin{comment}
\subsection{Example --- LeadTek 9546}

\textcolor{red}{Add a bunch more specs for the 
GPS unit here.}


\begin{itemize}

\item NMEA --- many different data formats:
GGA, GLL, GSA, GSV, RMC, VTG.  Of these, we only
care for the GGA format.

\item Active or passive antenna, supplies 2.85 VDC 
for antenna power.

\item Internal clock for unit.

\item Operating temperature -20 C to 70 C.

\end{itemize}

%%%%  How the UART transmit and receive work?
\end{comment}

\section{Summary}


\begin{itemize}

\item Separating the Fireboard sensors into 
modules allowed driver code for each sensor
to be upgraded independently. 

\item Using an implementation of the \sensor\ interface
is much easier than modifying drivers.

\item The \sensor\ interface is not a panacea, but 
given there is no ``one size fits all'' the current
implementation works well.

\item In light of recently proposed sensor 
abstractions~\shortcite{gay:d2004a,ho:h2004},
more work needs to be done 
to define the interaction 
between the TinyOS core and higher levels 
interfaces such as \sensor.

\end{itemize}



\bibliographystyle{chicago}
\bibliography{sensor,tinyos}


\end{document}















\begin{comment}
\A*nal"o*gy\, n.; pl. {Analogies}. [L. analogia, Gr. ?,
fr. ?: cf. F. analogie. See {Analogous}.]
1. A resemblance of relations; an agreement or likeness
   between things in some circumstances or effects, when the
   things are otherwise entirely different. Thus, learning
   enlightens the mind, because it is to the mind what light
   is to the eye, enabling it to discover things before
   hidden.

Note: Followed by between, to, or with; as, there is an
      analogy between these objects, or one thing has an
      analogy to or with another.

Note: Analogy is very commonly used to denote similarity or
      essential resemblance; but its specific meaning is a
      similarity of relations, and in this consists the
      difference between the argument from example and that
      from analogy. In the former, we argue from the mere
      similarity of two things; in the latter, from the
      similarity of their relations. --Karslake.

2. (Biol.) A relation or correspondence in function, between
   organs or parts which are decidedly different.

3. (Geom.) Proportion; equality of ratios.

4. (Gram.) Conformity of words to the genius, structure, or
   general rules of a language; similarity of origin,
   inflection, or principle of pronunciation, and the like,
   as opposed to {anomaly}. --Johnson.
\end{comment}


--- NEW FILE: Makefile ---

sensor_interface:
	latex sensor_interface
	bibtex sensor_interface
	latex sensor_interface
	latex sensor_interface
	dvips -o sensor_interface.ps sensor_interface.dvi
	dvipdfm sensor_interface.dvi

all: sensor_interface

clean:
	rm -rf *.ps *.dvi *.aux *.log *.bbl *.blg *~ *.fff *.lof