t-kernel: Providing Reliable OS Support to Wireless Sensor Networks
(Lin Gu and John Stankovic, Sensys 2006)

Resource Aware Programming in the Pixie OS
(Konrad Lorincz et al, Sensys 2008 )

Today we took the plunge into OS design space for wireless sensor
networks. The TinyOS system encourages a component based design where
higher level components abstract away lower level or the hardware
components. While designing any application of reasonable complexity
the programming model quickly becomes a web of components and I have
found it difficult to follow the chain of execution without looking
into the app.c file. A lot of people would argue that TinyOS is not an
operating system but rather a collection of drivers, exposing too many
knobs for the end application to manage. At the other end of the
spectrum are systems like Eon which seeks to abstract away most of the
system complexity and exposes perhaps a little too less. As the
application complexity grows, it would become necessary to support
higher level services like protection domains and virtualized
resources, but the question is do we just strip down existing OSs or
do we need to come up with something more clever.

Gu's paper brought out some interesting debates in the class. Firstly,
it seems like the translations would have been easier at compile time.
One member thought that this approach was taken because it was easier
to implement. Another member pointed out that it was easier to move a
smaller binary to the flash. Moreover it was clear that reasoning
about resources was no longer straight forward (assuming that you
wanted to trace/ model resource consumption). What would have been a
simple call to switch on the LED and measure its power draw, can now
be preceded by swaps to and from the flash, making it difficult to
measure the energy consumed by the operation. Thus one form of
simplicity was traded off for reliability guarantees. Many people
complained that the paper did not bring out the reliability aspect of
the system. Some people felt that it would have been more convincing
if could be shown that the system was able to detect bugs in popular
existing "wild" programs or using other fault injection techniques.
Perhaps the only guarantee that the system provides is that a buggy
application would cause a callback to the kernel. A member argues that
this functionality could have been implemented with a hardware timer
that caused the node to reboot if it hung. The participants also felt
that the code bloat was perhaps excessive but did not necessarily
achieve the performance acceleration associated with such bloating.
Finally, one member vehemently defended t-kernel as a convoluted way
to write a micro-kernel whereas another member thought that is a
software fault isolation on the mote platform.

The Pixie paper was presented at this year's Sensys (along with
lance). It was pointed out that a number of operating systems,
specially those for laptops or mobile phones, tend to be resource
aware. However they might not expose those parameters to the end
application, eg DVFS allows the kernel to slow down operations without
the application really noticing. Having coming into this project late
the data-flow model does seem somewhat intuitive. However the fact
that tickets are not enforced implies that the scratchpad versions of
my programs bypass them. Working with Pixie for the class projects
would definitely help uncover shortcomings with the existing system.
For a while we have been planning on writing a profiling tool that
measures the steady state resource consumption of individual stages
and hopefully that will come out soon.

All these papers make me wonder if we are focusing too much on
managing individual nodes. After all the purpose of the entire WSN is
to monitor a phenomenon and I think that the time is right to take a
more holistic approach towards resource management. Perhaps it would
be easier to reason about the system as a whole than in its pieces.