[Tinyos-devel] Request for comments: TEP107

[Neil Hancock]

Hello Phil, 

response below based on my experience, it may be raising the bar too high
for the available resources - but its my two cents for what they are worth

 

Regards

Neil Hancock

 

-----Original Message-----

From: Philip Levis [mailto:pal at cs.stanford.edu] 

Sent: Thursday, October 26, 2006 10:29 PM

To: Neil Hancock

Cc: 'David Moss'; tinyos-devel at Millennium.Berkeley.EDU

Subject: Re: [Tinyos-devel] Request for comments: TEP107

 

On Oct 26, 2006, at 10:03 PM, Neil Hancock wrote:

 

> First I'm wondering about these reviews; - are they reviews of

> 

> 

> 

> 1)       how good it documents already generated code,

> 

> 2)       is the document put out there as a discussion for the way  

> the system is desired to work (irrespective of what code has  

> already been generated), including any potential hardware  

> requirements.

> 

> 

> 

> It seems to me  the scope of the "boot sequence " would be very  

> useful.  Does it for instance cover the whole of  the system  

> initialization till the system is declared fully operational - is  

> the end of the "boot sequence" when all the applications are fully  

> operational or do all applications have to individually implement  

> there own mini "boot sequences" if required.

> 

> 

> 

> It seems to TEP107 is implying that it covers a complete "System  

> Initialization"  - but maybe I've got that wrong as its not  

> explicitly stated.

> 

> 

> 

> Typical in a real life distributed system there is "meta data"   

> from somewhere else, sometimes a central server but possibly just  

> another node - and in my book a node is not ready to be operational  

> until all of defined "meta data" has been acquired.  >From past  

> experience a major part of the system design is to see that all the  

> "meta data" is in place before the system is declared operational.  

> So examples of "meta data" could be wall time, or could be some  

> configuration information that customizes how this node behaves.

> 

> 

> 

> I don't see that there is a framework in place for the applications  

> to be able to gather this information with the algorithms defined  

> in TEP 107. If I understand TEP 107's algorithms/code fragments,   

> then the only  application level initialization facility supported  

> is for the applications internal data.

> 

> 

That's an accurate assessment. The boot sequence puts the node into a  

state where you can turn on resource such as the radio, timers, etc.  

It does not mean that the application itself is ready to go: as you  

point out, you might want time synchronization, etc. But most of  

these higher-level setups require the low-level functionality to be  

turned on first.

 

[nh:] What I'm suggesting is that the TEP107 should have the semantics to
support the applications reporting that they are completely initialized -
lets call it "System Initialized". Without this as a TinyOS system grows and
more applications are added, the boot process is likely to become unreliable
and cause much code churn as complex inter-connections between applications
are designed to facilitate system level initialization (yes I've been there)
until the basic boot procedures are rewritten.  Which is why I'm making the
comment now.

[nh:] 

 

> I would suggest that the boot sequence control the RED & GREEN leds  

> until  system initialization is successful

This was actually something I thought a lot about. It would make  

sense to give some kind of feedback. But it turns out to be really  

tough without either making platform assumptions or mandating  

inclusion of a complex abstraction. If you look at the boot sequence,  

there's *zero* output on failures. Two reasons:

 

1) What if a node doesn't have LEDs (the really cheap output mechanism)?

1) For things like UARTs, including them in the boot sequence then  

mandates they be in all OS images, which I can imagine being an issue  

for very tight platforms.

 

[nh:] Well network embedded systems are never easy and require a lot more
thinking about the "Customer Domain" - and usually includes specific
requirements on the hardware level platform. 

If the current revision of platform doesn't support it - then the wiring
would wire the LEDS out. 

In the past I've worked with large systems of arrays of embedded networked
processors (8051, 68HC16s, 6502, 68008) the LEDs have been a simple but
essential way of establishing the hardware/boot is complete and the real
application is now supposed to be operating. Dealing with a system - its
looking at the forest not the trees - so to speak, and needs to be
simplified.

 

On your comment of what if a low cost system doesn't have LEDS:  then it is
simple to not wire the LEDs in for that build. 

 

So for me personally - I think your analysis of not including LEDS is
way-of-base. 

 

There needs to be a definition in there for the system to use. If the LEDs
aren't part of a low cost product, they are certainly likely to be there at
development. As I once overheard a former Vice-President of Engineering say
to the Hardware Engineering Director "Give the software people what they
need". Which means the software engineers have to understand what they need
from the hardware.

 

While I'm a real fan of the TinyOS, my biggest observation about it is that
it isn't based in a paradigm that can grow. There are some fantastic new
places that TinyOS 2.0 is going, but it needs to also look to the horizon of
a network of nodes, real-life failures - *zero* output on failures is
pushing the problem onto the customer, the customer now has to figure out
what is a misbehaving node. And for the real world the customer expects 

1-800-supportMe if there is anything that looks strange.

 

A more representative system failure analysis - and yes software design has
to think of hardware failures - is that there are four "Boot" states for a
mote 

A) inoperable hardware, probably no power applied (visually no LEDs)

B) faulty hardware - can't respond to any form of software enquiry
(visually, possible solid red LED if power consumption allows)

C) Some form of other error - node does not operate, but can respond to some
for of requests (radio, UART etc flashing LED) if available .

D) initialized and operating 

 

However for the design case of really low cost mote, and customers that
never actually see a mote, i.e. the motes are essentially duplicated and
data is reported in aggregate - then I could see the "Boot" States being
reduced to 

A) inoperable hardware, probably no power 

B) some form of error (hardware or software) - the mote never communicates
and is effectively dead. 

D) initialized and operating - the mote is communicating.

 

>From a system engineering perspective; *zero* failures is a software
simplification that doesn't map to real world conditions :).

 

The problem of power used by LEDs and radio messaging in low power systems
is complex - I heard a story of a network of battery powered embedded motes
that was installed, came up and couldn't communicate with each other. So the
initialization algorithm had it keep trying to communicate- and the
batteries that were supposed to last for 6 months, were used up in
6hours.!!! 

The customer wasn't very happy, as the motes were installed in grain silos
monitoring temperature - and weren't very accessible.

 

So power usage at System Initialization for power limited motes is also a
needed discussion - which means the mote can be put to sleep/hibernate while
still initializing. So the above problem requires careful attention to
application level initialization algorithms and turn-up/installation
procedures to solve a critical customer level problem.

 

 

[nh:] 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20061029/8944a1b5/attachment-0001.htm